Proofs anyone can check, without trusting us

Problem

RFC 0045 sets the direction: AI engineering that has to prove its work. RFC 0046 defines what a proof contains: the claim, who acted, what was measured, the verdict, and the ground truth it was graded against.

Today a record is a JSON file marked unsigned: draft. That proves nothing to anyone who does not trust us. Three things are missing:

1. Integrity. Nothing shows the record was not changed after it was written.
2. Time. Nothing shows the record existed by a given moment, before an incident review, an audit or a dispute asked for it.
3. Independence. Every check today ends at our own database. A proof that only we can verify is an assertion.

Some customers have to answer exactly these questions to regulators: banks under DORA, operators under NIS2, anyone with a SOC 2 auditor. Some of them will also want a proof they can check with tools they already run, including public blockchains.

What a proof has to show

A proof of an evidence record answers four questions, each checkable without us:

No single mechanism answers all four. The design combines them.

The ways to prove, compared

1. Signatures

The record is a DSSE envelope around an in-toto statement (RFC 0046), signed by the platform.

Choice: a platform key (ECDSA P-256 or Ed25519, kept in a hardware-backed key store), with every key and its validity period published at a well-known address. When a key rotates or is suspected compromised, the list says so; records signed after a revocation fail verification. Customer countersignatures come later, as an option.

2. Transparency logs

An append-only log over all records, where anyone can verify that a record is included and that the log never rewrote its past (inclusion and consistency proofs, the model of Certificate Transparency).

Choice: our own log of salted record digests, with a signed checkpoint every hour. The hourly checkpoint's root hash is what the witnesses below anchor. Outside cosigning witnesses (the checkpoint format used by public transparency logs) are added when there are organisations willing to run them; until then the time witnesses below protect the log against silent rewriting.

3. Qualified timestamps

An RFC 3161 timestamp from a qualified trust service provider under the EU eIDAS regulation. Art. 41(2) gives it a legal presumption of accurate date and time and of integrity in every member state. Providers on the EU Trusted List charge from about €0.03 per stamp.

This is the proof a court, a regulator or an auditor in the EU accepts without a technical explanation. It depends on one provider; the next option covers that.

4. Bitcoin

A hash committed into a Bitcoin transaction through free public calendar servers that batch many requests into one transaction (OpenTimestamps). It proves the hash existed before a given block. Confirmation takes a few hours. Verifying it fully needs a Bitcoin node, a pruned one is enough, or trust in a block explorer.

It costs nothing, depends on no company, and is the hardest witness to rewrite. It has no legal standing of its own and resolves to hours, not seconds.

5. Ethereum and its layer 2 networks

Anchoring one root an hour on a layer 2 costs about $10 a year; on mainnet about $800. A layer 2's ordering is final only when its batch is final on Ethereum; a verifier checks against the finalised state, not the latest.

This is the witness for customers who already work on Ethereum and want to check a proof with their own tools, or reference it from a contract.

6. Fast, cheap networks

Bitcoin and Ethereum are the strongest public witnesses. They are also the slowest and, on Ethereum's main network, the most expensive. A layer 2 confirms in a fraction of a second, but its anchor is final only when its batch is final on Ethereum, about twenty minutes later. Some networks are final in seconds and cost a fraction of a cent. Live fees and official finality figures, measured on 2026-10-06:

Each makes a different trade:

• Stellar is the cheapest by far. Independent organisations publish hash-chained history archives anyone can check offline. Its top tier of validators is small.
• Algorand has the most trustless verification of the cheap networks: a Merkle proof of the transaction against its block, and state proofs that let a light client check block headers. Old transactions need an archival node.
• Hedera orders the messages on a topic and returns a consensus timestamp, a sequence number and a running hash, so the topic is itself an ordered log. Thirty nodes run by a governing council set its prices; they rose eightfold in January 2026.
• The XRP Ledger is cheap and fast, with a curated validator list and a halt of about an hour in February 2025.
• Solana is cheap but slower to finality today; that changes if its announced sub-second finality goes live.

Choice: a root every minute on Stellar, with Algorand as a second, independent witness. Hedera and the XRP Ledger are alternatives a customer can choose (RFC 0072). Two witnesses on different networks mean one network's halt delays a minute's proof, never loses it. These networks are witnesses beside the qualified timestamp and Bitcoin, never a replacement: none has legal standing in the EU, and each is run by fewer parties.

7. Merkle batching, in two levels

All of the anchors above anchor a root, never a record.

• Every minute, the digests of that minute's records form a Merkle tree. Its root goes to the fast witnesses.
• Every hour, the sixty minute roots form a second tree. Its root goes to the qualified timestamp, Bitcoin and the Ethereum layer 2.

A record's proof is its path to its minute root, plus that root's path to the hour root: log2(N) × 32 bytes for N records, 640 bytes for a million. A verifier who trusts the fast network checks the minute; one who wants Bitcoin or a court-ready timestamp checks the hour. The cost per record is effectively zero.

Per record. Anchoring each record on its own is affordable on the cheapest networks: 100,000 records a day cost about $0.22 a day on Stellar and about $12 on Algorand. It is not the default. A public write per record shows the volume and timing of an account's activity to anyone watching, and the minute tree already gives every record its own proof. It is an option for a single record that matters enough, such as a signed incident report or a release verdict.

Privacy

Nothing personal goes on a chain or into a public log. That includes hashes of personal data: a public chain cannot erase, and GDPR's right to erasure still applies.

The EDPB guidelines on blockchain (02/2025, final July 2026) describe how to stay within the law, and we follow them:

• each leaf is H(salt ‖ record digest), with a random salt per record kept beside the record, never published. Erasing the record and its salt leaves the leaf unlinkable to anything;
• records themselves already hold references and hashes only, never customer content (RFC 0046);
• anchors are sent from a company key, never from a key that identifies a person;
• no account id, tenant name, email or customer name appears in any anchor, log entry or transaction;
• a data protection impact assessment is done before anchoring customer records.

Who decides what is public

• Records about our own platform (our changes under RFC 0047, our incidents) are always anchored, on every witness. We are the first customer.
• A customer's records are anchored on the qualified timestamp and the Bitcoin witness by default, because a salted hash reveals nothing. The timing of their activity is still visible as volume per hour, so an account can switch public witnesses off.
• The fast witnesses and the Ethereum witness cover a customer's records when the account turns them on. A root covers every included record of that minute or hour, so it reveals only the platform's total volume, never one account's.

Verifying

A proof bundle is everything a verifier needs, in one file:

• the record and its salt;
• the signature, and the key list at that time;
• the record's Merkle path to the hour's root, and the log checkpoint;
• each witness's own proof: the timestamp token, the Bitcoin attestation, the layer 2 transaction and its finalised block.

The verifier needs no InOrbit service. It ships in every SDK language and as iohr evidence verify <bundle>. For each check it prints a separate pass or fail, never one combined score. The verifier is open source, and its tests use bundles with known answers (a valid one, a tampered record, a wrong salt, a revoked key, a root anchored after the record's claimed time), so anyone can confirm it fails where it should.

Costs

Hourly roots, all witnesses on, at list prices on 2026-10-06:

Each paid witness needs a small balance of its network's token for fees. Holding it is a treasury and accounting matter, not a licensed activity.

Failure modes

Regulation

Anchoring our own hashes, paying gas from our own account, holds and transfers no one's crypto-assets. It is none of the crypto-asset services that MiCA (Regulation 2023/1114, Art. 3) licenses. Two things would change that, and neither is planned: holding a customer's crypto-assets, or paying gas on a customer's behalf from funds they give us. A feature that ever sends transactions to third-party contracts or addresses first gets sanctions screening against the EU and US lists.

Plan

1. This RFC and RFC 0072 (other networks).
2. Signing: the platform key, the published key list, the DSSE envelope. RFC 0046 records stop being unsigned: draft.
3. The log with hourly checkpoints, and the qualified timestamp and Bitcoin witnesses.
4. The minute roots on Stellar and Algorand.
5. The verifier: the command line first, then each SDK, with the known-answer bundles.
6. The Ethereum layer 2 witness.
7. Per-record anchoring as an option, customer countersignatures, and outside cosigning witnesses.

Each step runs on our own records first (RFC 0047).

Alternatives considered

• Only a public chain. Rejected as the default: no legal standing in the EU, and a verifier must run or trust chain infrastructure. It stays a witness, not the base.
• Only a qualified timestamp. Rejected: one provider, and a proof that cannot be checked with open, independent infrastructure.
• Records or their content on chain. Rejected: permanent, costly, and incompatible with erasure.
• A permissioned chain run with partners. Possible later for a consortium of customers. A public witness proves more to outsiders, and costs less to run.
• Our own token or chain. Rejected. Nothing here needs one.

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. Records are still written unsigned (RFC 0046).