When people hear we make cryptographic, tamper-evident receipts for AI-agent decisions, the suggestion arrives within about a minute: “Why not just put it on the blockchain?” I get the instinct — a public ledger is append-only, visible to everyone, and carries its own consensus. For a few narrow uses that’s a fine fit. For the actual records of what an AI agent decided, it’s usually the wrong default. We built Marturia off-chain on purpose, and the industry is converging the same way.
What happens when you put the records on a public chain¶
Three problems show up immediately, and they get worse at production volume:
- Cost and speed. Every write carries a fee and waits for block finality, and throughput is capped by the chain’s design. Agents make decisions constantly; paying per decision and waiting for confirmation is the wrong shape for high-frequency records.
- Everything is public, forever. Anything you write to a public ledger is visible to anyone and can’t be taken back. For decision records — which often touch customer data, internal logic, or regulated information — that collides head-on with data-residency rules.
- You can’t honor erasure. This is the big one. A public chain is immutable by design, which is exactly wrong when a customer or regulator invokes a right-to-erasure. You cannot delete from an immutable public ledger. An off-chain design can use a tombstone — replace the payload, keep the hash that proves the original existed — so you satisfy erasure and keep the integrity proof. (See our tombstone-pattern guide for how that works.)
This isn’t theoretical hand-wringing. As high-risk obligations under the EU AI Act and frameworks like the NIST AI RMF approach, teams need records they can produce on demand — without publishing every intermediate agent step to the open internet or paying per decision at scale.
The pattern that actually scales¶
The emerging consensus keeps the cryptography and drops the public database. Each decision becomes a receipt: signed (we use a per-tenant Ed25519 key), hash-chained with SHA-256 so any insertion, deletion, or reordering breaks the sequence, and periodically aggregated into a Merkle root that independent witnesses cosign. The receipts and the decision data stay private, under your control, and deletable under policy. A verifier still gets everything needed to check authenticity — the signature, the hash chain, and the witnessed root — with no account:
pip install marturia-verify
marturia-verify --receipt receipt.json --pubkey-hex <tenant-public-key>
If an operator genuinely wants an external clock, the Merkle root — just the root, not the records — can be timestamped on a public ledger. That’s the honest, useful role for a chain here: immutable time-ordering of roots, not storage of the data. A ledger used where it adds value, not as the foundation.
The tradeoff we’re choosing — out loud¶
Marturia’s receipts are witnessed by our own in-house cosigners rather than by a public chain’s consensus. I want to be straight that this is a real tradeoff, not a free lunch: a verifier trusts that our witness keys are sound and the witness set is operated honestly, instead of trusting a public ledger that thousands of strangers replicate. We accept that because of what it buys: no per-write cost, sub-second receipt creation, records that stay private and in your control, and the ability to honor an erasure request — none of which a public chain gives you. And because we control the format and the verifier, we can move to post-quantum signatures or new schemes when the time comes, without waiting for a chain to upgrade.
If your threat model genuinely requires that no single operator (including us) be trusted for time-ordering, the optional public-ledger anchor on the Merkle root closes most of that gap. For almost every team shipping agents that take real actions, it’s overkill.
Pick the tool whose constraints match the job¶
That’s really the whole argument. A blockchain optimizes for trustless consensus among mutually-suspicious parties writing public data forever. AI decision records are the opposite problem: high-volume, privacy-sensitive, and often subject to erasure. Off-chain signed hash chains — witnessed, independently verifiable, cheap, private, deletable — fit that job. Full on-chain storage doesn’t.
I spent years as a carpenter before this, and it’s the same lesson as reaching for a sledgehammer to set a finish nail: impressive, and wrong for the work.
Closed beta is open — you can verify a real receipt yourself in about fifteen minutes:
pip install marturia-verifyfor the public verifier/docs/quickstart.htmlfor the agent-side integration
Related Marturia resources - /blog/why-we-built-marturia.html - /guides/gdpr-immutable-audit-tombstone.html - /guides/marturia-vs-langsmith-vs-sigstore.html