KAURAX — Mainnet Readiness

Date: 2026-09-08 · Score: 47/100 · Verdict: not ready, and one reason dominates.

There is no fault proof system. Everything else on this page is secondary to that, and no amount of operational polish substitutes for it.

Nothing is marked done unless it was verified. Where evidence is a test, the test is named.

A. Architecture

An application-focused Layer-3 rollup.

Ethereum (L1)          settlement and data availability
    ▲
Underlying L2          KauraxPortal · KauraxL2OutputOracle · KauraxBatchInbox
    ▲   batches (calldata) + output roots + bonds
KAURAX (L3)            sequencer · derivation · batcher · proposer

There are no validators and no consensus. Ordering is one sequencer's. Security comes from data availability, forced inclusion, and settlement — not from a quorum. The explorer says so where users see it.

B. Trust assumptions

T1 and T2 are the fault-proof gap. The rest is ordinary operational centralisation.

C. Security model

Trustless today: data availability, deposit derivation, forced inclusion, withdrawal proofs.

Trusted today: output roots, dispute resolution, ordering.

Honest summary: funds are safe if at least one honest party challenges a bad root and the guardian rules correctly. A fault proof would remove the second clause.

D. Known limitations

1. No fault proofs. No one-step verifier exists and no stub was written.
2. Bisection reaches a block, not an instruction — no trace commitments exist.
3. Single sequencer; no rotation.
4. Devnet operator keys are local, though the signing seam is implemented and tested.
5. No TLS on the public RPC (host blocks 80/443 on trial accounts).
6. No external audit.
7. No source verification in the explorer — reported as verified: false, not hidden.

E. Attack surface

F. Security tests executed

Executed for this report, not quoted from memory.

Verified live: dispute opened → 4 bisections → guardian resolution → output deleted → node recovered unaided; proposer escrow held on chain; faucet cooldown enforced.

G. Remaining blockers

Critical 1. One-step verifier — not started

High 2. External audit — not started 3. Guardian is the final arbiter (follows from 1)

Medium 4. Sequencer decentralisation 5. Operator keys to the signing service in production 6. TLS on the public RPC 7. Disaster recovery rehearsed, not just scripted

H. Operational requirements

Documented failure behaviour for every component: docs/TESTNET.md.

I. Fault proof roadmap

docs/FAULT_PROOF_ROADMAP.md. Summary: a proving VM, trace commitments, a preimage oracle and a one-step verifier — 18–30 engineer-months, then an audit. The dispute game was built so integration replaces one call and leaves bonds, timeouts and settlement untouched.

J. Launch checklist

Done - [x] Contracts deploy reproducibly - [x] Node syncs, produces, batches, proposes - [x] Data availability verified by reconstruction - [x] Forced inclusion verified on a live chain - [x] Withdrawal proofs verified - [x] Dispute game with bonds and bisection - [x] Proposer escrow at proposal time - [x] Finalization blocked during a dispute - [x] Governance holds portal guardian, inbox owner and dispute guardian (2-of-3, 1h timelock) - [x] Wallet with real signing; keys encrypted at rest - [x] Faucet with cooldowns - [x] Health, metrics, structured logs - [x] Backups that verify by restoring - [x] 262 + 121 + 12 tests passing

Not done - [ ] One-step verifier - [ ] External audit - [ ] Sequencer decentralisation - [ ] TLS on the public RPC - [ ] Operator keys on the signing service in production - [ ] Recovery rehearsal - [ ] Alerting

An incident worth recording

While handing roles to governance, forge script printed contract addresses from a run that reverted. Those are simulated addresses; nothing was deployed at them. Pointing live roles at one bricked the portal guardian, inbox owner and dispute guardian — unrecoverable, because only the current holder may rotate a role.

Recovered by redeploying on the devnet, which a mainnet would not permit. The wiring script now refuses to assign a role to an address with no code, and governance is set at construction rather than transferred afterwards.

Any mainnet role handover must verify code at the target address first, and rehearse the whole sequence on a fork.

Score: 47/100

Fault proofs and the audit are 30 of the 100 and both are zero. That is the honest position: a well-built rollup with a real dispute game and no fault proof system.