Protocol
A neutral protocol, one portable envelope
The FileOnChain Evidence Protocol defines an evidence envelope — subject, claims, signatures, receipts — that anyone can produce and anyone can verify locally with the open verifier, no FileOnChain service in the loop. Application profiles like the Agent Evidence Profile make it opinionated; the core stays neutral and independently implementable.
The architecture
Each concept has its own check, and they compose without requiring each other — an unsigned hash-only envelope is valid evidence of integrity and time; signatures, receipts, and profile claims extend the same schema. The normative specification lives on GitHub.
1 · The envelope
One portable JSON document: a subject (digests, size, media type), namespaced claims about it, artifact and envelope signatures, receipts, and extensions — sealed by an envelope digest computed over the canonical encoding, so any implementation produces byte-identical output.
2 · Artifact vs envelope signatures
Two distinct questions, two distinct signature sets. Artifact signatures cover the subject and claims — who made or approved the thing, including delegated signing. Envelope signatures cover the finalized envelope digest — who assembled the evidence. The verifier reports them separately.
3 · Receipt adapters
Storage, settlement, and inclusion receipts each name the adapter that produced them and the system they point at. Verification of a receipt is delegated to its adapter, so new storage or settlement systems plug in without changing the envelope format.
4 · Application profiles
The core protocol is neutral; profiles are opinionated. A profile defines required claims in its namespace and their validation — the Agent Evidence Profile (org.fileonchain.agent/v1), covering agent runs, tool calls, approvals, and policies, is the first.
5 · Reference implementations
The spec is normative; the packages are one implementation of it. @fileonchain/protocol (envelope building and validation), @fileonchain/agent-profile, the SDK's sealing helpers, and @fileonchain/verify are all MIT — and anyone can implement the protocol without them.
6 · Verification
fileonchain verify evidence.json — deterministic, local, open source. Recomputes digests, checks both signature sets and inclusion proofs, dispatches receipts to their adapters, and optionally confirms settlement receipts against public RPC endpoints. Never calls FileOnChain.
How anyone verifies an envelope
Deterministic and local: fileonchain verify evidence.json runs every offline check; the online pass additionally confirms settlement receipts against public RPC endpoints of your choosing. The /verify page runs the same verifier in your browser — no account, no wallet.
Recompute the digests
Hash the bytes you were given: the SHA-256 must match the envelope's subject, and for batched artifacts the digest must prove into the anchored Merkle root through the envelope's inclusion receipt.
Check both signature sets
Artifact signatures verify against the keys embedded in the envelope, over the canonical signing payload; envelope signatures verify over the envelope digest. The verifier reports who signed, who assembled — and whether a delegation is proven or merely claimed.
Confirm the receipts
Each receipt is checked by its adapter; settlement transactions can be looked up on any public node or explorer of their system. The block and timestamp are the system's own record — no FileOnChain endpoint involved.
Run it yourself
fileonchain verify evidence.json in a terminal, or paste the envelope into the /verify page — the same isomorphic verifier runs in your browser. The report never collapses to a single green check: valid, valid with warnings, incomplete, and invalid stay distinct.
What cannot be verified
A passing verification shows that specific bytes existed at a specific time, are unchanged, and were signed by specific keys — with receipts on public systems anyone can consult. It cannot verify truthfulness (signed claims are attested, not fact-checked), legal validity (an envelope is not, by itself, a legal instrument), or identity beyond the key (who controls a key is a claim unless an external attestation proves it). And multiple settlement receipts are independent attestations, not a proof that one system verified another — no system verifies another's consensus in this design.
The contracts in v1
The on-chain surface is deliberately small — and most families need no deployment at all, anchoring through the system's native channel.
FileRegistry
A minimal anchor registry on contract runtimes (EVM, Aptos, Sui, Starknet, NEAR): event-carrier writes for chunk, file, and manifest payloads, plus an optional first-write CID record on EVM. Free beyond gas — no token anywhere. Memo families and native channels (Substrate remarks, Solana Memo, Hedera HCS) need no deployment at all.
CachePayments
USDC payments for the private cache tier: client-side-encrypted chunks served at CDN speeds for the duration paid. Retrieval acceleration — never a replacement for the chain.
DonationEscrow
Native-coin donations routed to public cache node operators — the free pin for research data, archives, and open-source releases.
What v1 leaves out — on purpose
No token, no validator staking, no tips or bonds, no challenge windows, no juries, no slashing, no bridges, no token governance, no fee splits — anywhere: contracts, SDKs, API, database, or UI. Anchoring costs each system's ordinary transaction fee, and hosted services charge account credits or USDC. An earlier experimental design for a staked verification market is preserved, unmaintained, on the archive branch — nothing in v1 depends on it. The specification, the profiles, and the product overview are collected on the documents page.