Anchoring manifests to a public ledger, without putting them on it

Status: this is a design note. Merkle batching and inclusion proofs are live today; on-chain submission of batch roots is not.

A signature proves who issued a manifest. It does not, on its own, prove when. An issuer who controls their own signing key could in principle backdate a manifest, or reissue one after the fact. For provenance to hold up under adversarial review, a verifier wants evidence that a manifest existed at a particular time and has not changed since.

The instinct is to put manifests on a blockchain. That is the wrong primitive for the job. It is expensive per record, it is slow, and it publishes your content commitments to a public ledger forever. What you actually need is an anchor, not storage.

The design batches manifest hashes into a Merkle tree and commits only the tree root to Base, an Ethereum layer-two network. The root is a single 32-byte value. It reveals nothing about the individual manifests, and one transaction covers every manifest in the batch regardless of how many there are.

Each manifest then carries a Merkle inclusion proof: the short list of sibling hashes needed to recompute the root from that manifest alone. A verifier hashes the manifest, walks the proof, and checks the result against the recorded batch root. If they match, the manifest was part of that committed batch and has not been altered.

In this design the inclusion proof and the anchored root are both public: a verifier reads the transaction on Base directly and runs the Merkle math themselves. Today the proof endpoint serves the recorded root.

This is the same separation that runs through the rest of the system. We make provenance practical to operate. The properties that matter for trust live in open formats, where anyone can check them.

Once live, on-chain anchoring would add a small per-batch transaction cost that amortizes across the batch.