Why KAURAX is a Layer-3
A Layer-3 is a chain whose settlement layer is itself a rollup. KAURAX settles to a Layer-2, which settles to Ethereum.
The test
A chain is an L3 if all three hold:
- Its transaction data is published to the L2, so anyone can reconstruct it without
the operator's cooperation. KAURAX: KauraxBatchInbox, verified by tests/acceptance.ts step 8, which recovers a transaction from L2 calldata alone. 2. Its state is committed to the L2, so a claim about KAURAX state can be pointed at. KAURAX: KauraxL2OutputOracle. 3. Assets enter and leave through contracts on the L2, not through an operator-run service. KAURAX: KauraxPortal, with withdrawals proven by Merkle inclusion under a committed root.
KAURAX satisfies all three today. What it does not yet satisfy is the fourth property that separates a credible L3 from a merely structural one:
- Its state commitments are enforceable on the L2 by a third party. This requires a
fault-proof system. KAURAX does not have one. An incorrect output root that survives the challenge window is accepted.
What KAURAX inherits, and what it does not
| Property | Source | Status on KAURAX |
|---|---|---|
| Data availability | L2 → Ethereum | Inherited |
| Censorship resistance for entry | L2 (deposit events cannot be suppressed) | Inherited |
| Liveness of execution | KAURAX sequencer | Not inherited — one operator |
| Validity of state | Fault or validity proofs | Not inherited — none exist |
| Finality | L2 → Ethereum | Inherited for data, not for state |
Stating this plainly matters more than the architecture diagram: an L3 without fault proofs is a chain whose users trust the operator not to lie, backed by the ability to prove after the fact that the operator did lie.
Why not just deploy on the L2?
An application-specific L3 buys:
- Blockspace that is not contended by unrelated applications. KAURAX's block gas limit
is its own. - Fee denomination in the application's own asset (KAX). - Freedom to change execution parameters — block time, gas limit, fee policy — without a governance process spanning a general-purpose chain.
It costs:
- An extra trust hop. KAURAX's security is bounded by the L2's, minus everything
KAURAX has not yet implemented. - Data fees paid twice — to the L2, and by the L2 to Ethereum. - Withdrawal latency that stacks: the KAURAX challenge window, then the L2's.
Whether that trade is worth making is an application question, not an architectural one. KAURAX does not claim it is universally correct.
Terminology used throughout this repository
| Term | Meaning |
|---|---|
| L1 / Ethereum | Ethereum mainnet or testnet |
| L2 / underlying rollup | The configurable rollup KAURAX settles to |
| L3 / KAURAX | This chain |
| Output root | Commitment to KAURAX state, published on the L2 |
| Batch | Compressed KAURAX transaction data, published on the L2 |
| Deposit | L2 → KAURAX transfer, derived from an L2 event |
| Withdrawal | KAURAX → L2 transfer, proven against an output root |