A single-round fraud-proof audit primitive for Layer 1 — design, honest limits, and open problems.
We describe Refutation-Matured Audit (RMA): a pattern in which off-chain agents point at a specific suspected invariant violation and the chain resolves the accusation deterministically, by recomputing that one element as a pure function of chain state. RMA is a single-round instance of interactive fraud proofs (Arbitrum, TrueBit) with a watchtower/fisherman watcher population and Nakamoto work-finality. We implemented it inside an L1 (WakeChain) and — crucially — report honestly that its incentive and finality layers do not yet hold on a proof-of-work / UTXO chain. As implemented it is a defense-in-depth check with unsolved incentives, not a security mechanism.
Implementation status. RMA consensus enforcement is currently disabled. The implementation is retained as a committed observability and research mechanism — not a consensus security gate.
Two goals recur in chain design: let off-chain intelligence (agents, models, monitors) participate without being trusted inside consensus; and verify a chain's safety invariants cheaply. RMA explores one point in that space. We do not claim it as new — the deterministic-verifier-of-a-narrowed-fault idea is the core of optimistic systems. What we set out to test is whether that pattern, taken to L1 with named per-invariant units and an agent watcher population, buys anything. The honest answer is very little as implemented, for reasons made explicit below.
Each block commits a cheap, possibly sampled attestation over named safety units (value conservation, coinbase maturity, custody segregation). An audit-challenge names a single (unit, locator) and stakes a bond. For deterministic units the chain resolves the accusation itself — no external adjudicator — by recomputing that one element directly: O(1) for a block-local scalar invariant (value conservation or the subsidy cap — plain arithmetic over the block's own inputs and outputs), or O(log n) for a set-membership fact checked against the committed UTXO accumulator — a sparse-Merkle tree whose proofs are logarithmic in n, the size of the UTXO set. A false accusation burns the bond: a real, working safety property — a false challenge cannot invalidate a good block. It is a single-round version of the Arbitrum/TrueBit one-step proof; no bisection is needed because the units are already atomic.
assumevalid; sampling-plus-fraud-proofs in Celestia.Naming the challenger "AI" adds no cryptographic or game-theoretic substance. We keep the framing only as a deployment stance — deliberately building agent tooling as the watcher population — not as a primitive.
Our internal adversarial review found the following, all traced to code. We state them as our own results.
The flag lands on the block containing the challenge (the honest reporter's), not the block that produced the bad state. Fork-choice then rejects the honest chain and adopts the censoring one. Including a valid fraud proof is the one act that makes a miner lose fork-choice — honest reporting is strictly dominated. The implementation realizes the opposite of the intended sign.
There is no staked producer to slash; minting a reward would itself violate the conservation invariant the audit protects. With no reward, no rational agent watches — the verifier's dilemma.
The within-window rejection lived only on the reorg path, not the fast-extend path — two honest nodes could hold different tips for a full window from the same valid blocks.
The window was pinned to a small, fixed work budget — on the order of six minimum-difficulty blocks — rather than to actual difficulty. Writing D for the chain's difficulty as a multiple of the minimum (powLimit) target, that fixed budget buys only about 6/D real blocks, so for any real D ≫ 6 the window falls below a single block. The 6 is an illustrative budget constant, not a measured law — and the mechanism it belongs to was refuted and removed (see the note below); we keep the item to record why.
The units only fire on a deterministic bug inside the transition — a bug shared by all nodes, so ordinary consensus already agrees. RMA catches essentially nothing plain validation does not.
These are our own findings about our own design. The fork-choice penalty was removed; fork-choice is now pure most-accumulated-work, and the audit is kept as a committed observability record only — not a consensus gate.
RMA's honest residue is a clean, node-reproducible deterministic single-round fraud-proof check with a safe false-accusation-burns-bond property — a known primitive, useful at most as defense-in-depth — plus a candid map of why its economic-security and finality layers fail on a PoW/UTXO chain. The value of this note is not a breakthrough; it is the discipline, applied here to our own design, which did not survive intact. Turning the open problems into working mechanisms would be real research. Claiming they are solved would not be true.
WakeChain also ships WakeChat, an end-to-end encrypted messenger with no phone, email or name — the identity is a secp256k1 key made on the device, and the address is its public key. We record it here because its development followed the same rule as the audit above: build it, try hard to break it, and report what broke.
The construction. A custom implementation of the published Double Ratchet algorithm, adapted to WakeChat's secp256k1 identity model. An ECDH handshake seeds an HKDF-SHA256 root chain; each message derives a one-time key from an HMAC-SHA256 symmetric chain and encrypts with AES-256-GCM, with the header authenticated as associated data. A DH ratchet advances on every change of direction, and consumed message-key material is removed from active application state once it is no longer needed. Post-compromise recovery is expected only after an attacker loses access to the endpoint and a fresh DH ratchet completes successfully.
The refutation. Our first implementation (v1) was reviewed by two independent internal passes — one context-aware, one deliberately blind to our design. Both found the same two defects, and they were fatal to the whole point:
A bootstrapping deadlock left both parties using the same static ephemeral keys forever. Without ratchet turnover there is no post-compromise recovery, and the key schedule never moves.
The session kept the material needed to recompute past chain keys, so a single state capture unwound the entire history. A "forward-secret" design that was not forward-secret.
The maturation. We redesigned (v2): the ratchet turns over on every direction flip, and the root secret, spent ephemeral keys, and — crucially — the ratchet session's working copy of the identity key are removed from the persisted and active ratchet session state once they are no longer needed, so a captured session cannot recompute the opening chain. (Your long-term identity key itself is kept on your device, encrypted with your password, so you keep your address — it is only the session's transient copy that is discarded.) This is verified by a state-capture test confirming a stolen current session cannot decrypt an earlier message. (By state capture we mean the persisted ratchet application state — the serialized session record itself — not a full memory dump of a live, unlocked device; that fully-compromised-device case is a separate, stronger threat, flagged in the residue below.) A re-audit by both eyes then found one further, lesser issue and we fixed it:
A session-reset decision was taken on a header flag before the message was authenticated, so a man-in-the-middle could flip one bit to force a reset. Availability only — no key or forward-secrecy loss — but real; we removed the branch, so a forged flag now simply fails authentication and is discarded atomically.
Honest residue. v2 passes both reviews and its test suites; it is now live. It remains self-audited, not third-party audited — so we do not call it "secure" or "perfect." Forward secrecy protects what the network relays, not plaintext history on a fully-compromised device; metadata (who/when) and IP remain visible; and a rare simultaneous-first-message race can silently drop an opening message, since without a prekey server the two sides cannot always converge. As with RMA: the value is the discipline, not a claim of perfection.
Document version 1.0 · Last updated 2026-07-24
WakeChat implementation: v2 · commit 960bc72
Test artifacts: persisted-state capture test · forged-header (unauthenticated-bit) test
wakeratchet.js SHA-256: 72ede21fafff8c2b385f0e2568a09560d1b6bfa33b999a271621a95d792decf1