Self-custodied receipts
More agent systems now emit signed receipts. In most of them the system that took the action also writes the record, signs it, and stores it. That is a real improvement over a mutable log, and it is enough for a large class of problems. It is not evidence for a reader who wants the record to be false.
This page compares a design pattern, not a vendor. Any system — ours included — can be measured against it.
A record the acting system wrote and holds is a party’s testimony. However tamper-evident it is, the custodian and the interested party are the same entity.
The adverse reader test
Records earn their form from the reliance placed on them. Ask who has to believe this record, and what happens when that reader would prefer it were false — opposing counsel, a reinsurer, a regulator, an acquirer’s diligence team. Evidence built for that reader needs three properties:
- Sealed at execution — created when the action happened, not reconstructed once a dispute exists.
- Anchored outside the operator’s custody — committed to an append-only log the operator does not control.
- Verifiable without trusting anyone who benefits — the check runs on open primitives, against a public log, by a party with no stake in the outcome.
- · The environment is air-gapped or classified and no external anchor is permitted
- · You are the only reader — internal forensics and debugging
- · Verification must complete with no network dependency
- · The threat model is operator error, not operator interest
- · The reader is adverse and funded
- · The question is what the record looked like before today
- · A record that should exist is missing
- · Someone asks who could have changed this, and the honest answer is you
| Criterion | Sealed Evidence Record | Self-custodied receipt |
|---|---|---|
| Custody | ||
| Who holds the record | Public append-only transparency log | The party that took the action |
| Who can verify it | Anyone, without trusting the operator | Anyone who already trusts the operator |
| Survives operator key compromise | Anchor sits outside the blast radius | No — attacker holds keys and store |
| Time | ||
| Whose clock timestamps the record | The transparency log's, independently witnessed | The operator's, self-asserted |
| When sealing happens | At execution, before a dispute exists | Whenever the operator chooses to write |
| Backdating resistance | Log inclusion time is third-party | None — signing time is self-declared |
| Adversarial | ||
| Detects silent deletion | Inclusion proof makes absence provable | No — a deleted record leaves no trace |
| Holds when the operator benefits from the answer | The log does not benefit from the answer | Not demonstrable to a third party |
| FRE 902(13)/(14) certification posture | Open cryptographic process + external anchor | Certifier is the interested party |
| Operational | ||
| Runs fully air-gapped with no network | Deferred anchoring — sealed locally, anchored on reconnect | Yes — no external dependency at all |
| Verification latency inside your own perimeter | Local verify, plus an anchor round-trip for third parties | Local only — nothing to fetch |
The last two rows are ours to lose. A self-custodied receipt needs nothing from the outside world, and inside your own perimeter it verifies with no round trip. External anchoring buys independence and charges you a dependency for it. If your reader is never adverse, that is a bad trade.
Evidence is what survives a reader who wants it to be false.
Do not take that on our word either. Seal a record yourself and check the anchor in a public log we do not operate.
Seal a record and verify the anchor →