{
"dataAvailability": [
{
"name": "All data required for proofs is published on chain",
"description": "All the data that is used to construct the system state is published on chain in the form of blobs. This ensures that it will be available for enough time.",
"references": [],
"risks": []
}
],
"exitMechanisms": [
{
"name": "Regular exit",
"description": "The user initiates the withdrawal by submitting a regular transaction on this chain. When the block containing that transaction is finalized the funds become available for withdrawal on L1. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.",
"risks": [],
"references": []
}
],
"forceTransactions": {
"name": "Users can force any transaction via L1",
"description": "Users can submit a blob reference containing a standalone transaction by calling the `saveForcedInclusion()` function on the `MainnetInbox` contract.\n Once any forced inclusion has been queued for 9m 36s, whitelisted proposers cannot submit new proposals unless they process all due forced inclusions.\n If the oldest queued forced inclusion is still ignored for 1d 1h, proposing becomes permissionless and anyone can include it.",
"references": [
{
"title": "MainnetInbox.sol - Etherscan source code, saveForcedInclusion function",
"url": "https://etherscan.io/address/0x6f21C543a4aF5189eBdb0723827577e1EF57ef1f#code"
},
{
"title": "MainnetInbox.sol - Etherscan source code, propose function",
"url": "https://etherscan.io/address/0x6f21C543a4aF5189eBdb0723827577e1EF57ef1f#code"
}
],
"risks": []
},
"operator": {
"name": "The system uses whitelist-based sequencing and proving",
"description": "The system uses a whitelist-based sequencing mechanism to allow for fast preconfirmations on the L2. On the L1, whitelisted preconfirmers can propose Taiko L2 data to the MainnetInbox contract.\n The whitelist is managed by the `PreconfWhitelist` contract, which currently has 3 active operators registered.\n Forced inclusions become mandatory after 9m 36s and proposing becomes permissionless after 1d 1h if the queue is still ignored.\n Proving is controlled separately by `ProverWhitelist`, which currently has 1 whitelisted prover.\n Non-whitelisted actors must wait 5d after an unproven proposal before the whitelist is dropped. MainnetInbox currently sets minBond=0 and livenessBond=0.\n Currently, proving a proposal requires SGX (Geth), plus either SGX (Reth), SP1, or RISC0.",
"references": [
{
"title": "MainnetInbox.sol - Etherscan source code, propose function",
"url": "https://etherscan.io/address/0x6f21C543a4aF5189eBdb0723827577e1EF57ef1f#code"
},
{
"title": "MainnetInbox.sol - Etherscan source code, prove function",
"url": "https://etherscan.io/address/0x6f21C543a4aF5189eBdb0723827577e1EF57ef1f#code"
},
{
"title": "PreconfWhitelist.sol - Etherscan source code",
"url": "https://etherscan.io/address/0xDBae46E35C18719E6c78aaBF9c8869c4eC84c149#code"
},
{
"title": "ProverWhitelist.sol - Etherscan source code",
"url": "https://etherscan.io/address/0xEa798547d97e345395dA071a0D7ED8144CD612Ae#code"
}
],
"risks": [
{
"category": "MEV can be extracted if",
"text": "the operator exploits their centralized position and frontruns user transactions."
}
]
},
"stateValidation": {
"categories": [
{
"title": "Validity proofs",
"description": "Taiko uses a multi-proof system to validate state transitions. The system requires two proofs among four available verifiers: SGX (Geth), SGX (Reth), SP1, and RISC0. The use of SGX (Geth) is mandatory, while the other three can be used interchangeably. This means that a proposal range can be proven without providing a ZK proof if SGX (Geth) and SGX (Reth) are used together. New proposals target a proof submission cadence of 4h. Proving is currently centralized behind ProverWhitelist with 1 whitelisted prover. Non-whitelisted actors must wait 5d before the whitelist is dropped, and MainnetInbox currently sets minBond=0 and livenessBond=0. The multi-proof system allows detecting bugs in the verifiers if they produce different results for the same proposal range. If such a bug is detected, the system gets automatically paused.",
"description": "Taiko uses a multi-proof system to validate state transitions. The system requires two proofs among four available verifiers: SGX (Geth), SGX (Reth), SP1, and RISC0. This means that a proposal range can be proven without providing a ZK proof if SGX (Geth) and SGX (Reth) are used together. New proposals target a proof submission cadence of 4h. Proving is currently centralized behind ProverWhitelist with 1 whitelisted prover. Non-whitelisted actors must wait 5d before the whitelist is dropped, and MainnetInbox currently sets minBond=0 and livenessBond=0. The multi-proof system allows detecting bugs in the verifiers if they produce different results for the same proposal range. If such a bug is detected, the system gets automatically paused.",
"references": [
{
"title": "MainnetInbox.sol - Etherscan source code, getConfig function",
"url": "https://etherscan.io/address/0x6f21C543a4aF5189eBdb0723827577e1EF57ef1f#code"
},
{
"title": "MainnetInbox.sol - Etherscan source code, prove function",
"url": "https://etherscan.io/address/0x6f21C543a4aF5189eBdb0723827577e1EF57ef1f#code"
},
{
"title": "ProverWhitelist.sol - Etherscan source code",
"url": "https://etherscan.io/address/0xEa798547d97e345395dA071a0D7ED8144CD612Ae#code"
}
],
"risks": [
{
"category": "Funds can be stolen if",
"text": "a malicious block is proven by compromised SGX instances."
}
]
}
]
},
"upgradesAndGovernance": "\nTaiko Alethia has a governance structure relying primarily on a 7/9 Security Council, checked by a token DAO that is limited to veto permissions. The closed operator whitelists are managed by the 4/6 Taiko Multisig and related EOAs. Governance proposals (both paths) hold all important upgrade and config permissions in the system.\n# Standard proposals\nA threshold of 5 approving Security Council members is required to create a Standard proposal. It is delayed while being publicly auditable by 7d in the OptimisticTokenVotingPlugin contract and can be vetoed by 10% of votable TAIKO tokens during that time. If not vetoed, the standard proposal passes and can be executed.\n# Emergency proposals\nEmergency proposals are encrypted at proposal time and can only be read by Security Council members. If approved by 7 Security Council members, they can be immediately decrypted and executed.\n\n# Proof system and operators\nThe proof system currently does not require zk proofs to validate state transitions and state can be finalized with SGX proofs only. The optional zk verifier contracts can be upgraded by Multisigs. Operator roles (sequencer, proposer) are closed and the whitelist is managed by the Taiko Multisig and related EOAs.\n"
}