{
"dataAvailability": [
{
"name": "All transaction results (state diffs) are published in Ethereum blobs",
"description": "Each checkpoint proposal includes EIP-4844 blob commitments that are checked against the blob hashes in the proposing transaction. The epoch proof revalidates the accumulated blob commitments before the epoch is finalized.",
"references": [
{
"title": "Rollup.sol - propose() on Etherscan",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
},
{
"title": "Rollup.sol - validateBlobs() on Etherscan",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
}
],
"risks": []
}
],
"exitMechanisms": [
{
"name": "Regular messaging",
"description": "The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. ZK proofs are required to settle blocks. Once the epoch root proof has been verified, the rollup inserts the epoch root into the Outbox, from which withdrawals and other L2->L1 messages can be consumed on Ethereum. Withdrawals can be initiated privately on L2, revealing only the L1-facing portion of the transaction. There is no canonical bridge escrow: only the canonical messaging layer is immutable, while each token bridged through a locking escrow may introduce additional trust assumptions tied to that specific escrow.",
"risks": [],
"references": [
{
"title": "Rollup.sol - submitEpochRootProof() on Etherscan",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
},
{
"title": "Outbox.sol - consume() on Etherscan",
"url": "https://etherscan.io/address/0xc9698B7AdEf9ee63F3Bf5cFF38086e4E836579f0#code"
}
]
}
],
"operator": {
"name": "There is no central operator",
"description": "There is no privileged sequencer. Anyone can stake 200 K AZTEC to join the sequencer queue, and anyone can call flushEntryQueue() to activate queued sequencers once the queue rules allow it.",
"risks": [],
"references": [
{
"title": "Rollup.sol - deposit() on Etherscan",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
},
{
"title": "Rollup.sol - flushEntryQueue() on Etherscan",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
}
]
},
"otherConsiderations": [
{
"name": "Upgrades replace the canonical rollup",
"description": "The core contracts are immutable, but Governance owns the Registry and GSE and can register a new rollup version as canonical after the governance delay. Governance also owns critical config parameters that can freeze or compromise the Rollup system.",
"references": [
{
"title": "Registry.sol - addRollup() on Etherscan",
"url": "https://etherscan.io/address/0x35b22e09Ee0390539439E24f06Da43D83f90e298#code"
},
{
"title": "Governance.sol - execute() on Etherscan",
"url": "https://etherscan.io/address/0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e#code"
}
],
"risks": []
},
{
"name": "No canonical bridge escrow",
"description": "There is no default canonical escrow. The rollup is deployed only with an immutable canonical messaging bridge, which can be used by any escrow. As a result, each token bridged to Aztec via Ethereum lock-mint must be assessed individually by examining its specific locking escrow. The trust assumptions of a given escrow may differ from those of the immutable rollup itself. Gas tokens are bridged through the FeeJuicePortal, an immutable one-way portal that only supports bridging to public L2 addresses. Although the rollup and its canonical messaging bridge are immutable, an upgradeable escrow could migrate its funds to a new rollup version without requiring users to migrate, effectively trading immutability for convenience.",
"references": [
{
"title": "FeeJuicePortal.sol - on Etherscan",
"url": "https://etherscan.io/address/eth:0x2891F8b941067F8B5a3F34545A30Cf71E3E23617#code"
},
{
"title": "Outbox.sol - on Etherscan",
"url": "https://etherscan.io/address/0xc9698B7AdEf9ee63F3Bf5cFF38086e4E836579f0#code"
}
],
"risks": []
},
{
"name": "Inclusion is probabilistic",
"description": "All censorship resistance tools that are part of the protocol rely on probabilistic inclusion. In contrast to \"forced transactions\", there is no simple deterministic inclusion after some maximum delay, but rather different inclusion probabilities after different time horizons. The \"time needed to exit\" of 20d for the exit window was simulated by using a simple model of the decentralized sequencer set at launch. The escape hatch and private transactions can give additional inclusion guarantees.",
"references": [
{
"title": "CRsim - Simulated inclusion probability on Aztec",
"url": "https://sekuba.github.io/crsim"
}
],
"risks": []
}
],
"sequencing": {
"name": "Transactions are ordered by a staked committee",
"description": "Joining the sequencer set is permissionless and requires staking 200 K AZTEC. For each epoch, the rollup samples a 48-member committee from the active sequencer set of 3709 and selects one proposer per slot. The committee and regular sequencer set can be circumvented via the escape hatch, which designates a bonded proposer (via RANDAO) who can publish checkpoints without committee attestations.",
"description": "Joining the sequencer set is permissionless and requires staking 200 K AZTEC. For each epoch, the rollup samples a 48-member committee from the active sequencer set of 3740 and selects one proposer per slot. The committee and regular sequencer set can be circumvented via the escape hatch, which designates a bonded proposer (via RANDAO) who can publish checkpoints without committee attestations.",
"references": [
{
"title": "Rollup.sol - getProposerAt() on Etherscan",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
},
{
"title": "EscapeHatch.sol - selectCandidates() on Etherscan",
"url": "https://etherscan.io/address/0x8c189ead28D5987A48e522162f9225124D50AD1B#code"
}
],
"risks": []
},
"stateValidation": {
"description": "Each epoch root proof is verified by the HonkVerifier smart contract on Ethereum before the proven checkpoint number is advanced and the epoch outbox state root is inserted into the Outbox. Proving is permissionless, and a single proof can cover one Checkpoint (1m 12s) to one epoch (38m 24s). Unproven checkpoints are pruned after the proof submission window of 1h 16m expires.",
"categories": [
{
"title": "State root proposals",
"description": "The rollup only advances the proven chain after submitEpochRootProof() succeeds. That call verifies the epoch proof and then inserts the epoch outbox state root for L2->L1 messaging.",
"references": [
{
"title": "Rollup.sol - submitEpochRootProof() on Etherscan",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
}
],
"risks": []
},
{
"title": "Validity proofs",
"description": "Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.",
"risks": [],
"references": [
{
"title": "Rollup.sol - submitEpochRootProof() on Etherscan",
"url": "https://etherscan.io/address/0xAe2001f7e21d5EcABf6234E9FDd1E76F50F74962#code"
},
{
"title": "HonkVerifier.sol - verify() on Etherscan",
"url": "https://etherscan.io/address/0x70aEDda427f26480D240bc0f4308ceDec8d31348#code"
}
]
},
{
"title": "Slashing",
"description": "\nEach stake of 200 K AZTEC that is locked to join the sequencer set and vote in governance can be slashed under certain conditions. Slashing is voted on by sequencers each time they propose a checkpoint and is grouped in rounds that span 4 epochs (2h 33m) each.\n\nSlashing conditions are programmed into each sequencer node and can be changed by node operators by updating or editing their node software. Nodes usually submit votes to slash automatically on L1. The `TallySlashingProposer` contract only enforces the formalities of the slashing system:\n* A given slashing round's votes always target the checkpoint proposals from 2 rounds ago.\n* As soon as a round's votes have reached a quorum of 65/128, it enters an execution delay of 28 rounds (2d 23h)\n* An automatically generated slashing payload is executable by anyone on L1 after the execution delay, applying the slashing penalties defined by the sequencer votes.\n\nSlashing penalties are defined onchain in three levels: large (2.00 K AZTEC), medium (2.00 K AZTEC), and small (2.00 K AZTEC). Offenses that lead to slashing usually include:\n* Inactivity: A sequencer fails to attest or propose when selected.\n* Data Withholding: A sequencer proposes a checkpoint including state diff data availability on L1 but withholds the public transaction bodies and/or CHONK proofs required for permissionless proving.\n* Invalidity: A sequencer attests to invalid proposals, multiple conflicting proposals, with invalid signatures, or proposes a block that is not proven in time.\n\nThe above offense list is not exhaustive and not defined onchain but usually in the software the sequencers decide to run. This is also where the mapping of offenses to the slashing penalty levels can be defined.\n\nThe SlashVeto Council is a 5/9 Multisig that can veto specific proposals and/or all slashing for 3d at a time.",
"references": [
{
"title": "Slashing - Aztec Docs",
"url": "https://docs.aztec.network/operate/operators/sequencer-management/slashing_and_offenses"
},
{
"title": "SlashVeto Council - Github",
"url": "https://github.com/aztec-slash-veto/council"
},
{
"title": "slashveto.me - Monitor Slashing",
"url": "https://slashveto.me"
}
],
"risks": []
}
]
},
"upgradesAndGovernance": "\n# Standard Path (Signaling)\nBecause sequencers stake AZTEC tokens to secure the L2 network, they are also the primary governors of the system. Any governance proposal must be encoded and deployed as a smart contract payload on Ethereum. While core contracts are immutable, the onchain Governance system can designate a new 'canonical' rollup with a 1mo delay and has access to critical configuration permissions that can freeze or compromise the Rollup system. These permissions can only be accessed through the process described below.\n\n## 1. The Signaling Phase (`GovernanceProposer`)\nAztec uses an onchain \"Empire\" signaling system. Active sequencers operating on the 'canonical rollup' (as defined by the Registry) call `signal(payloadAddress)` on the L1 `GovernanceProposer` contract during their designated L2 slots to support a specific upgrade payload. A voting round consists of 1,000 slots. To win a round and become a formal proposal, a payload must receive signals from at least 600 slots. Once quorum is reached, the payload is submitted to the L1 `Governance` contract.\n\n## 2. The Voting Phase (`Governance`)\nOnce submitted, the proposal enters a delay and voting flow:\n* **Pending (3d):** At the end of this delay, voting power is snapshotted.\n* **Active (7d):** AZTEC token holders can vote. To pass, a proposal must reach a 20% Quorum of all staked power, and the `yea` votes must exceed a required margin of 33%.\n* **Queued (1mo):** If successful, the proposal enters an execution delay. This acts as an exit window, allowing dissenting sequencers to initiate a withdrawal of their staked tokens before the malicious/disagreed-upon code is executed.\n* Executable (7d): The proposal enters a grace period where anyone can call `execute()`. If not executed, it expires.\n\nTotal standard delay from proposal to execution: **1mo 10d**.\n\n### Emergency Path (Circumvent Signaling)\nIf the L2 sequencer set is offline, censoring, or acting maliciously, the `GovernanceProposer` cannot be used. To ensure liveness, anyone can bypass the Sequencer signaling phase using the `proposeWithLock()` function directly on the `Governance` contract.\n* An actor must lock **258 M AZTEC**, roughly 2.5% of total supply\n* These funds are locked for an extended 3mo.\n* Once proposed, the payload enters the exact same 1mo 10d Voting Phase (Pending -> Active -> Queued -> Executable) as the standard path.\n\n### Rollup Immutability\nThe smart contract code of `Rollup`, its verifier and its canonical messaging contracts cannot be changed. However, `Governance` owns critical permissions for configuration parameters that can freeze the L2 indefinitely. 'Upgrading' a Rollup contract involves a `Governance` action that designates a new `Rollup` contract address as canonical. The `GSE` (Governance Staking Escrow) automatically migrates the voting power and stake of all active sequencers to the new rollup version if they staked to the default magic address `0x9064Fb41156D300196d5Eb95E0B3c1f08eBc39a8` instead of a specific immutable rollup. Importantly, `Governance` retains ownership of the old rollup, with the permissions to freeze it in the same or any future governance proposal. In summary and practice, the current Aztec rollup system is not immutable and prone to governance changes with the configured 1mo delay.\n\n### Slashing and the SlashVeto Council\nAztec features onchain slashing for equivocation or missing attestations, managed by `Slasher` and `TallySlashingProposer`. \n\nThere is a protective **Vetoer** role held by the SlashVeto Council. The Council cannot upgrade the protocol, alter governance, or steal funds. Instead it is limited to two permissions:\n* call `vetoPayload()` to stop a specific slashing event.\n* call `setSlashingEnabled(false)`, which pauses all slashing in the protocol for a period of 3d.\n\n### Economics & Treasury\n* **Coin Issuer:** The `CoinIssuer` contract is owned by Governance and is authorized to mint new AZTEC tokens up to a cap of 20%.\n* **Protocol Treasury:** Funds owned by the DAO sit in the `ProtocolTreasury`. The Treasury has a hardcoded timestamp (approx. Nov 2026). Before this date, the DAO cannot spend Treasury funds. After this date, Treasury funds and token ownership can be moved with a Governance Proposal.",
"warning": "Aztec v4 has [know security vulnerabilities](https://aztec.network/blog/critical-vulnerability-in-alpha-v4) that can only be fixed in a new deployment."
}
permissions+3-3
{
"ethereum": {
"roles": [],
"actors": [
{
"id": "Governance",
"name": "Governance",
"accounts": [
{
"address": "eth:0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e",
"type": "Contract",
"isVerified": true,
"name": "0x1102…B75e",
"url": "https://etherscan.io/address/0x1102471Eb3378FEE427121c9EfcEa452E4B6B75e"
}
],
"chain": "ethereum",
"description": "DAO contract used for proposals and token voting. Heavily interdependent with the GSE for voting power snapshots.\n* Can interact with CoinIssuer\n * mint new AZTEC in the bounds of the minting caps and forward the acceptOwnership() call to the AZTEC Token [via: ProtocolTreasury the GATED_UNTIL timestamp has passed]\n* Can interact with Slasher\n * slash sequencers from the active set \n* Can interact with GSE\n * add a new rollup address, which automatically triggers all sequencers staked in the bonus address to be migrated to the new rollup \n* Can interact with Rollup\n * change the escape hatch address and disable the escape hatch, change the slasher address which can slash arbitrary sequencers, change the sequencer queue config and disallow new sequencers joining, set the ejection threshold that exits sequencers from the active set, change various critical fee and reward configurations ",
"discoveryDrivenData": true
},
{
"id": "GovernanceProposer",
"name": "GovernanceProposer",
"accounts": [
{
"address": "eth:0x06Ef1DcF87E419C48B94a331B252819FADbD63ef",
"type": "Contract",
"isVerified": true,
"name": "0x06Ef…63ef",
"url": "https://etherscan.io/address/0x06Ef1DcF87E419C48B94a331B252819FADbD63ef"
}
],
"chain": "ethereum",
"description": "Intermediary contract that allows the L2 Sequencers operating the canonical rollup (as defined by the Registry) to submit formal proposals to the L1 Governance contract by signalling their support of any smart contract payload on L1 with each checkpoint proposal. A signalling round comprises 1000 checkpoints. 600 signals or more during one round allow submitting the payload as a governance proposal.\n* Can interact with Governance\n * create proposals ",
"discoveryDrivenData": true
},
{
"id": "CoinIssuer",
"name": "CoinIssuer",
"accounts": [
{
"address": "eth:0x02FAdF157d551aa6d761b2A2237D03Af68E41CA6",
"type": "Contract",
"isVerified": true,
"name": "0x02FA…1CA6",
"url": "https://etherscan.io/address/0x02FAdF157d551aa6d761b2A2237D03Af68E41CA6"
}
],
"chain": "ethereum",
"description": "Manages the inflation and minting schedule of the Aztec token. It enforces an annual percentage cap and mints new tokens for the budget.\n* Can interact with AZTEC Token\n * mint unlimited amounts of the AZTEC token and transfer the ownership of the contract ",
"discoveryDrivenData": true
},
{
"id": "SlashVeto Council",
"name": "SlashVeto Council",
"description": "A Multisig with 5/9 threshold. \n* Can interact with Slasher\n * veto specific slashing payloads and/or disable all slashing for 3d at a time ",
"accounts": [
{
"address": "eth:0xBbB4aF368d02827945748b28CD4b2D42e4A37480",
"type": "Contract",
"isVerified": true,
"name": "0xBbB4…7480",
"url": "https://etherscan.io/address/0xBbB4aF368d02827945748b28CD4b2D42e4A37480"
}
],
"chain": "ethereum",
"references": [],
"participants": [
{
"address": "eth:0xb33a08eF4624eE8F409F749Ee73766E225bEd0F4",
"type": "EOA",
"isVerified": true,
"name": "0xb33a…d0F4",
"url": "https://etherscan.io/address/0xb33a08eF4624eE8F409F749Ee73766E225bEd0F4"
},
{
"address": "eth:0xb6Da7B7a0d8c7349630183f4Bd6F13D4a8AD9216",
"type": "EOA",
"isVerified": true,
"name": "0xb6Da…9216",
"url": "https://etherscan.io/address/0xb6Da7B7a0d8c7349630183f4Bd6F13D4a8AD9216"
},
{
"address": "eth:0xB216FcaF63c6C0f73a557B342e1Da9710C95DA81",
"type": "EOA",
"isVerified": true,
"name": "0xB216…DA81",
"url": "https://etherscan.io/address/0xB216FcaF63c6C0f73a557B342e1Da9710C95DA81"
},
{
"address": "eth:0x81062F03742B88923eaB121243B69D0a0092089e",
"type": "EOA",
"isVerified": true,
"name": "0x8106…089e",
"url": "https://etherscan.io/address/0x81062F03742B88923eaB121243B69D0a0092089e"
},
{
"address": "eth:0x32e90E88bb2E6Ee4382e6884cC5c299a6bA27920",
"type": "EOA",
"isVerified": true,
"name": "0x32e9…7920",
"url": "https://etherscan.io/address/0x32e90E88bb2E6Ee4382e6884cC5c299a6bA27920"
},
{
"address": "eth:0x23d4A9533627eA70915026638ff5989a967Be667",
"type": "EOA",
"isVerified": true,
"name": "0x23d4…e667",
"url": "https://etherscan.io/address/0x23d4A9533627eA70915026638ff5989a967Be667"
},
{
"address": "eth:0xb31e6d9661720A93d54AF7D1815d9bb399280629",
"address": "eth:0x8138c46A572D989E54837d5e5dEB506889edFb5D",
"type": "EOA",
"isVerified": true,
"name": "0xb31e…0629",
"url": "https://etherscan.io/address/0xb31e6d9661720A93d54AF7D1815d9bb399280629"
"name": "0x8138…Fb5D",
"url": "https://etherscan.io/address/0x8138c46A572D989E54837d5e5dEB506889edFb5D"
},
{
"address": "eth:0x0Fb6215099f48D723CfB89434C2cb887357Bc871",
"type": "EOA",
"isVerified": true,
"name": "0x0Fb6…c871",
"url": "https://etherscan.io/address/0x0Fb6215099f48D723CfB89434C2cb887357Bc871"
},
{
"address": "eth:0x7EAbE4F636B937628A7Fe503bD7F06772C047FEe",
"type": "EOA",
"isVerified": true,
"name": "0x7EAb…7FEe",
"url": "https://etherscan.io/address/0x7EAbE4F636B937628A7Fe503bD7F06772C047FEe"
}
],
"discoveryDrivenData": true
},
{
"id": "EOA-1",
"name": "EOA 1",
"accounts": [
{
"address": "eth:0x92Ba0FD39658105FaC4dF2B9BADE998B5816b350",
"type": "EOA",
"isVerified": true,
"name": "0x92Ba…b350",
"url": "https://etherscan.io/address/0x92Ba0FD39658105FaC4dF2B9BADE998B5816b350"
}
],
"chain": "ethereum",
"description": "* Can interact with AztecTokenPositionRegistry_ProtocolTreasury\n * set the time at which the ProtocolTreasury funds can be transfered and manage staker implementations referenced by this contract ",
"discoveryDrivenData": true
}
]
}
}
{
"architectureImage": "megaeth",
"dataAvailability": [
{
"name": "Data is posted to EigenDA",
"description": "Transactions roots are posted onchain and the full data is posted on EigenDA. The sequencer is publishing data to EigenDA v2. Since the DACert Verifier is not used, availability of the data is not verified against EigenDA operators, meaning that the Sequencer can single-handedly publish unavailable commitments. If EigenDA becomes unavailable, the sequencer falls back to Ethereum.",
"risks": [
{
"category": "Funds can be lost if",
"text": "the sequencer posts an unavailable transaction root.",
"isCritical": true
},
{
"category": "Funds can be lost if",
"text": "the data is not available on the external provider.",
"isCritical": true
}
],
"references": [
{
"title": "EigenDA Docs - Overview",
"url": "https://docs.eigenda.xyz/overview"
},
{
"title": "Derivation: Batch submission - OP Mainnet specs",
"url": "https://github.com/ethereum-optimism/specs/blob/main/specs/protocol/derivation.md#batch-submission"
},
{
"title": "BatchInbox - address",
"url": "https://etherscan.io/address/0x02B8d1329B653d6f53A8420C8DDbBbb5518F51b2#code"
"url": "https://etherscan.io/address/0x00656C604FC470e6a566A695B74455e18a6D75D3#code"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x55400445e384393f9c1BE23e7E734e8d44Ed9fd9#code"
}
]
}
],
"exitMechanisms": [
{
"name": "Regular exits",
"description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 7d to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
"risks": [],
"references": [
{
"title": "OptimismPortal2.sol - Etherscan source code, proveWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x55400445e384393f9c1BE23e7E734e8d44Ed9fd9#code"
},
{
"title": "OptimismPortal2.sol - Etherscan source code, finalizeWithdrawalTransaction function",
"url": "https://etherscan.io/address/0x55400445e384393f9c1BE23e7E734e8d44Ed9fd9#code"
}
]
},
{
"name": "Forced messaging",
"description": "If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.",
"risks": [],
"references": [
{
"title": "Forced withdrawal from an OP Stack blockchain",
"url": "https://docs.optimism.io/stack/transactions/forced-transaction"
}
]
}
],
"forceTransactions": {
"name": "Users can force any transaction",
"description": "Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.",
"risks": [],
"references": [
{
"title": "Sequencing Window - OP Mainnet Specs",
"url": "https://github.com/ethereum-optimism/optimism/blob/51eeb76efeb32b3df3e978f311188aa29f5e3e94/specs/glossary.md#sequencing-window"
},
{
"title": "OptimismPortal2.sol - source code, depositTransaction function",
"url": "https://etherscan.io/address/0x55400445e384393f9c1BE23e7E734e8d44Ed9fd9#code"
}
]
},
"operator": {
"name": "The system has a centralized operator",
"description": "The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.",
"risks": [
{
"category": "MEV can be extracted if",
"text": "the operator exploits their centralized position and frontruns user transactions."
}
],
"references": []
},
"otherConsiderations": [
{
"name": "EVM compatible smart contracts are supported",
"description": "OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.",
"risks": [],
"references": [
{
"title": "Introducing EVM Equivalence",
"url": "https://medium.com/ethereum-optimism/introducing-evm-equivalence-5c2021deb306"
}
]
}
],
"stateValidation": {
"categories": [
{
"title": "State root proposals",
"description": "Proposers submit state roots as children of any (possibly unresolved) previous state root proposal, by calling the `propose()` function in the KailuaTreasury. A parent state root can have multiple conflicting children, composing a tournament. Each proposer requires to lock a bond, currently set to 0.00001 ETH, that can be slashed if any proposal made by them is proven incorrect via a fault proof or a conflicting validity proof. The bond can be withdrawn once the proposer has no more pending proposals that need to be resolved and was not eliminated.\n\nProposals consist of a state root and a reference to their parent and implicitly challenge any sibling proposals who have the same parent. A proposal asserts that the proposed state root constitutes a valid state transition from the parent's state root. To offer efficient zk fault proofs, each proposal must include 3600 intermediate state commitments, each spanning 1 L2 blocks. \n\nProposals target sequential tournament epochs of currently 3600 * 1 L2 blocks. A tournament with a resolved parent tournament, a single child- and no conflicting sibling proposals can be resolved after 7d. \n\nThe **Vanguard** is a privileged actor who can always make the first child proposal on a parent state root. They can, in the worst case, delay each tournament for up to 36558901084y 8mo by not making this first proposal. Sibling proposals made after the Vanguard's initial one or after the 36558901084y 8mo vanguardAdvantage in each tournament are permissionless.",
"references": [
{
"title": "Sequencing - Kailua Docs",
"url": "https://boundless-xyz.github.io/kailua/design.html#sequencing"
},
{
"title": "Vanguard - Kailua Docs",
"url": "https://boundless-xyz.github.io/kailua/parameters.html#vanguard-advantage"
}
],
"risks": [
{
"category": "Funds can be frozen if",
"text": "the vanguard exploits their vanguard advantage (36558901084y 8mo), halting the chain until they propose."
}
]
},
{
"title": "Challenges",
"description": "\nAny conflicting sibling proposals within a tournament that are made within the 7d challenge period of a proposal they are challenging, delay resolving the tournament until sufficient ZK proofs are published to leave one single tournament survivor.\n\nIn the tree of proposed state roots, each parent node can have multiple children. These children are indirectly challenging each other in a tournament, which can only be resolved if but a single child survives. A state root can be resolved if it is **the only remaining proposal** due to any combination of the following elimination methods: \n1. the proposal's challenge period of 7d has ended before a conflicting proposal was made\n2. the proposal is proven correct with a full validity proof (invalidates all conflicting proposals)\n3. a conflicting sibling proposal is proven faulty\n\nProving any of the 3600 intermediate state commitments in a proposal faulty invalidates the entire proposal. Proving a proposal valid invalidates all conflicting siblings. Pruning of a tournament's children happens strictly chronologically, which guarantees that the first faulty proposal of a given proposer is always pruned first. When pruned, an invalid proposal leads to the elimination of its proposer, which invalidates all their subsequent proposals, slashes their bond, and disallows future proposals by the same address. A slashed bond is transferred to an address chosen by the prover who caused the slashing.\n\nA single remaining child in a tournament can be 'resolved' and will be finalized and usable for withdrawals after an execution delay of 3d 12h (time for the Guardian to manually blacklist malicious state roots).",
"references": [
{
"url": "https://boundless-xyz.github.io/kailua/operate.html",
"title": "How to run a challenger - Boundless Docs"
},
{
"url": "https://boundless-xyz.github.io/kailua/dispute.html",
"title": "Disputes - Kailua Book"
}
]
},
{
"title": "Validity proofs",
"description": "Validity proofs and fault proofs both must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.\n\nThe Kailua state validation system is primarily optimistically resolved, so no validity proofs are required in the happy case. But two different zk proofs on unresolved state roots are possible and permissionless: The proveValidity() function proves a state root proposal's full validity, automatically invalidating all conflicting sibling proposals. proveOutputFault() allows any actor to eliminate a state root proposal for which they can prove that any of the 3600 intermediate state transitions in the proposal are not correct. Both are zk proofs of validity, although one is used as an efficient fault proof to invalidate a single conflicting state transition.",
"references": [
{
"url": "https://boundless-xyz.github.io/kailua/introduction.html",
"title": "Kailua Proof System - Boundless Docs"
},
{
"url": "https://github.com/risc0/risc0-ethereum/blob/main/contracts/version-management-design.md",
"title": "Verifier upgrade and deprecation - Kailua Docs"
}
],
"risks": [
{
"category": "Funds can be stolen if",
"text": "the validity proof cryptography is broken or implemented incorrectly."
},
{
"category": "Funds can be stolen if",
"text": "no challenger checks the published state."
},
{
"category": "Funds can be stolen if",
"text": "the proposer routes proof verification through a malicious or faulty verifier by specifying an unsafe route selector."
},
{
"category": "Funds can be frozen if",
"text": "a verifier needed for a given proof is paused by its permissioned owner."
}
]
}
]
},
"stateValidationImage": "megaeth"
}