A fork-proof audit chain on a single Durable Object.

Steven Martinez · Published July 27, 2026

Logs you administer are not evidence. An auditor’s first question is whether a record could have been altered after the fact, and for any database your own team operates, the honest answer is yes. I’m building OmniStrat around a different primitive: every consequential action. An AI routing decision, a trade, a signed agreement, becomes a receipt that anyone can verify without trusting me. This post is the architecture, including the race condition that shaped it and the places it’s still weak.

Anatomy of a receipt

A receipt commits to four things: what (a payload hash), who (Ed25519 signatures), when (timestamps, externally anchored), and where in history (a hash-chain position). Content hashing starts with canonical JSON, the same bytes on every runtime, or nothing verifies:

function canonicalJson(obj: unknown): string {
  if (obj === null || typeof obj !== "object") return JSON.stringify(obj);
  if (Array.isArray(obj)) return "[" + obj.map(canonicalJson).join(",") + "]";
  const keys = Object.keys(obj).sort();
  return "{" + keys.map(k =>
    JSON.stringify(k) + ":" + canonicalJson(obj[k])
  ).join(",") + "}";
}
// payload_hash = SHA-256(canonicalJson(payload))

Signing keys are generated client-side with WebCrypto. The signer’s browser creates an Ed25519 keypair, signs the payload hash, and submits only the public key and signature. My servers verify signatures; they cannot create them. That asymmetry is the entire trust model. I can’t forge a record even if I wanted to, and neither can anyone who compromises me.

The race that forks a chain

Each finalized record incorporates the previous record’s hash, so rewriting history means recomputing every later link. But a hash chain is only as good as its linearity, and my first implementation had a classic flaw: the chain tip lived in a KV key. Two concurrent finalizations could both read the same tip, both compute a “next” hash, and both write. Last write wins, and the loser’s chain hash becomes orphan noise. A verifiable ledger that occasionally forks is worse than no ledger, because it hands a skeptic a genuine inconsistency.

The fix is the most boring possible distributed-systems answer: stop distributing it. Every finalization advances the chain through a single global serialization point — one Durable Object, globally — so read-tip-and-append happens atomically and two finalizations can never both claim the same position. One writer for the tip; everything else, storage and verification reads, scales around it.

A single serialization point sounds like a bottleneck until you do the arithmetic: advancing the chain is one hash and one write, comfortably within what a single serialized writer handles at far beyond a receipts workload’s volume. And if that path is ever briefly unavailable, the system favours availability over purity in a controlled way, because a rare recoverable hiccup beats a wedged pipeline.

Nobody has to ask my permission to check

Every finalized record is public JSON at GET /api/attest/verify/<cert_id>, no auth, CORS open. It returns everything verification needs and nothing more: the payload hash, the signatures and public keys, the chain hashes, the timestamps, and a pointer to the previous record so you can walk the ledger backward hop by hop. Content is sealed by default. Disclosed only if the record’s owner opted in, and party emails are masked, because none of that is required for verification: everything commits to the hash.

There’s a page at omnistrat.ai/verify that runs the whole procedure in your browser, re-hash, signature check, chain recompute, backward walk, with no libraries, so view-source is the audit. And because a page I serve deserves no trust either, the verification recipe is printed on it for reproduction with curl and openssl.

Time, from someone who isn’t me

A chain proves order, not wall-clock time. My timestamps are just claims. So the chain tip is periodically anchored with an RFC 3161 timestamp from an external Time-Stamping Authority. Since every link commits to its predecessor, one anchored tip proves the entire ledger existed at that moment. I cannot backdate a record into an already-anchored past without breaking hashes I no longer control.

What a receipt does and does not prove

Worth being precise about scope, because overclaiming is its own kind of dishonesty. A verified receipt proves integrity and authorship: that nobody rewrote the record after the fact, and that the signer is who the signature says. It does not prove the underlying claim was true — only that it has not been altered. Ordering and existence-at-a-point-in-time do not rest on our word either; they are anchored to an external timestamping authority, so the chain’s position in time is independently checkable rather than asserted by us.

Lean by design

The whole thing runs on Cloudflare’s platform — no servers, no containers — and the receipts pipeline costs approximately nothing at startup volume. One person can operate all of it. Which is the point: proof infrastructure shouldn’t require a platform team.