Problem
A proof is only as useful as the place a verifier is willing to check it. A bank's auditor accepts a qualified timestamp. A Bitcoin user trusts Bitcoin. A team on Solana, Polkadot or a Cosmos chain will want to check against the network they already run, with the tools they already have. A consortium may run a permissioned chain and want our proofs there.
If every network is a special case in code, each one costs a project, and the verifier in six SDK languages grows with every addition. RFC 0071 chose three witnesses. This RFC makes the fourth and the twentieth cheap, reviewed and safe.
Proposal
One witness interface
Every network implements the same four operations. They are written once per network kind (EVM, Bitcoin-like, Stellar, Algorand, XRP Ledger, Substrate, Cosmos SDK, Solana, Hedera, RFC 3161), not once per network:
| Operation | What it does |
|---|---|
submit(root) |
Commits a 32-byte root and returns a pending receipt |
confirm(receipt) |
Waits for the network's notion of finality and returns a proof |
verify(proof, root) |
Checks a proof offline against the network's finalised state, given a trusted header source |
describe() |
Returns the witness's properties, below |
A witness carries no business logic. It never sees a record, a salt or an account; it sees one root an hour.
The properties every witness declares
| Property | Example values |
|---|---|
| Finality | probabilistic after N blocks; deterministic after one round; final when the layer 2 batch is final on layer 1 |
| Time to final | minutes to hours, measured, not quoted |
| Cost model | per transaction, per byte, fixed fee per message |
| Permanence | full history kept by all nodes; history pruned after a period; depends on archive nodes |
| Who can censor or reorder | open validator set; small committee; a sequencer; a single company |
| Legal standing | qualified (eIDAS), none |
| Verifier needs | a full node, a light client, a block-header source, the provider's public key |
The verifier prints these beside each result. A reader sees what a proof rests on, never just a green tick.
Networks as data
A network is a reviewed file of the kind the platform already uses for connection kinds. It names:
- the witness kind (
evm,bitcoin,stellar,algorand,xrpl,substrate,cosmos,solana,hedera,rfc3161); - the cadence: every minute for fast networks, every hour for slow ones (RFC 0071);
- the chain identifier and the confirmation rule (for example finalised tag, block depth, or batch finality);
- how the root is written: transaction data, a contract call, a remark, a memo or a consensus message;
- read endpoints, more than one, cross-checked;
- for verification: the light client or header source the verifier uses;
- spending limits for the network's fees.
Adding a network is a pull request with that file, the known-answer test bundles below, and the measured numbers. No new code unless the kind is new.
Before a network may witness
A network is added only after these pass, measured on our own roots for at least two weeks:
- Known answers. The verifier accepts a valid proof and rejects a tampered root, a proof from a non-final block, a proof from another chain id, and a replayed receipt.
- Finality behaviour. Measured time to final, and what happens across a reorganisation or a halted chain.
- Cost. Measured cost per root over the period, and the ceiling we set.
- Independence. Read endpoints from at least two independent providers that agree, or a light client.
- Permanence. How long the proof can be verified, and what a verifier needs in five years.
The results are themselves an evidence record. A network that stops meeting them is switched off as a witness; proofs already made stay verifiable as long as the network's history does.
Candidate networks
The mechanisms below are what each network offers for committing a small piece of data. Costs and finality are measured before a network is added; the table quotes none.
| Network | Kind | How a root is written |
|---|---|---|
| Stellar | stellar | a native 32-byte hash memo; the first fast witness (RFC 0071) |
| Algorand | algorand | the transaction note; the second fast witness (RFC 0071) |
| XRP Ledger | xrpl | a transaction memo |
| Bitcoin | bitcoin | through the calendar servers of RFC 0071, or our own transaction with a small data output |
| Ethereum | evm | transaction data, or the attestation contract of RFC 0071 |
| OP Stack networks (OP Mainnet, Base, others) | evm | the same; final when the batch is final on Ethereum |
| Arbitrum One | evm | the same |
| Zero-knowledge rollups on Ethereum | evm, or their own kind | the same where EVM-compatible; finality follows proof verification on Ethereum |
| Other EVM networks (Polygon PoS, Gnosis, Avalanche C-Chain) | evm | the same; finality rules differ per network |
| Solana | solana | a memo instruction carrying the root |
| Polkadot and Substrate chains | substrate | a remark extrinsic carrying the root |
| Cosmos SDK chains | cosmos | a transaction memo, or a small contract where the chain runs one |
| Hedera | hedera | a message on a consensus topic, which the network orders and timestamps |
| A permissioned chain of a customer or consortium | evm or its own kind | a contract the consortium deploys |
| Further qualified timestamp providers | rfc3161 | a second provider removes the single-provider dependency |
Networks not chosen as witnesses, for now
Measured on 2026-10-06 against the bar for a fast witness, under $0.001 a write and final within ten seconds:
| Network | Why not now |
|---|---|
| Base, OP Mainnet, Arbitrum | Pre-confirmation in a fraction of a second, but final only when the batch is final on Ethereum, about twenty minutes. They stay the hourly Ethereum witness. |
| zkSync Era, Linea, Starknet | Final after the validity proof lands on Ethereum: hours, at a cent or more |
| Polkadot, Tezos | Finality above ten seconds |
| Avalanche C-Chain, NEAR | Just above the cost bar |
| Solana | Final in about 13 seconds today; it qualifies if its announced sub-second finality goes live |
| Celestia | Its data can be pruned after a few weeks; a proof must outlive that |
| Sui | Several halts in 2026 |
| Internet Computer | Keeps no block history; a contract that runs out of funds is deleted |
| Cosmos Hub, Osmosis | Qualify on cost and speed; alternatives when a customer asks, with archive nodes for history |
A network that changes is measured again; this table is a snapshot, not a rule.
A customer's own network
Two ways, and in neither do we hold a customer's key:
- We anchor, on their network, with our key. The network file names their chain; we pay fees from our own account and are bound by the same limits.
- They anchor our roots themselves. Every hourly root is published, signed, at a public address. An SDK helper takes a root and the customer's own signer and writes it on their network. The verifier accepts their transaction as a witness when they add it to the bundle.
The second is the default for networks we have not reviewed. It needs nothing from us beyond publishing roots.
What we never do
- Hold, receive or move a customer's crypto-assets, or pay fees with funds a customer gives us. Either would bring MiCA licensing into scope.
- Write anything but a salted root. RFC 0071's privacy rules apply on every network.
- Send transactions to third-party contracts or addresses without first screening them against the EU and US sanctions lists.
- Issue a token, run a chain or take part in consensus.
Plan
- This RFC, with RFC 0071.
- The witness interface, and the three kinds RFC 0071 starts with (rfc3161, bitcoin, evm), as the reference implementations.
- Networks as data, the known-answer bundles, and the two-week admission run.
- Publishing signed hourly roots, and the SDK helper for customers who anchor themselves.
- Further kinds, one at a time, when a customer asks for one: each through step 3.
Alternatives considered
- One cross-chain bridge or oracle network to reach every chain. Rejected. It adds a third party whose failure breaks every proof at once, and a verifier must trust it.
- Supporting every network a customer names immediately. Rejected. A witness that was not measured can lose proofs: on a reorganisation, a pruned history or a halted chain.
- A network of our own. Rejected. A proof should rest on infrastructure we do not control.
Out of scope
Proving facts about other parties' networks, nodes or contracts is not part of this RFC.
Status log
- 2026-10-06: RFC opened, nothing built.