{
"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't force any transaction",
"description": "There is no general mechanism to force the sequencer to include a transaction.\nForced inclusions are disabled in the current `MainnetInbox` implementation: `saveForcedInclusion()` always reverts and `propose()` only accepts zero forced inclusions.\nIf the selected proposer is down or censoring, user transactions that are not included by the permissioned proposer remain non-included.",
"risks": [
{
"category": "Users can be censored if",
"text": "the operator refuses to include their transactions."
}
],
"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"
}
]
},
"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, batch proposing is permissioned through the `PreconfWhitelist` contract, which currently has 3 active operators registered.\nFor each epoch, `PreconfWhitelist` selects a single active operator that can propose to MainnetInbox. There is no fallback proposer path, and non-selected operators cannot propose for the current epoch.\nProving is controlled separately by `ProverWhitelist`, which currently has 2 whitelisted provers.\nWhile the prover whitelist is non-empty, non-whitelisted actors cannot submit proofs. MainnetInbox currently sets minBond=0 and livenessBond=0.\nCurrently, 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. 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 2 whitelisted provers. While the whitelist is non-empty, non-whitelisted actors cannot submit proofs, and the configured permissionless proving delay is not used to open proving. 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": {
"content": "Taiko 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."
"content": "Taiko 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 forward a Standard proposal to the OptimisticTokenVotingPlugin contract. It can be vetoed by 10% of votable TAIKO tokens during a 10d public veto period. If not vetoed, a further 7d timelock applies before the proposal 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.",
"governanceInfo": {
"securityCouncil": {
"Composition": "**5/9 standard · 7/9 emergency** — 9-member signer set shared by custom Aragon OSx standard and emergency multisig plugins. Members were appointed by the Taiko team rather than elected and include Taiko Labs employees. Members can appoint EOA agents to act for them.",
"Members public": "**Mapped** — Taiko publishes a [member wallet-to-entity mapping](https://github.com/taikoxyz/dao-ui-mono/blob/main/packages/ui/src/data/security-council-profiles.json). The 9 current onchain members are Aragon, Chainbound, Drew Van der Werff, Gattaca, Taiko Labs, Halborn, L2BEAT, Nethermind, and Toni Wahrstätter. Each member wallet is mapped to its voting agent onchain.",
"Charter": "**No public charter** — the [DAO values](https://dao-docs.taiko.xyz/understanding-the-dao/taiko-dao-values/) define the council’s security mission and principles, while the [proposal guidelines](https://dao-docs.taiko.xyz/understanding-the-dao/proposal-guidelines/) restrict emergency proposals to protocol-security and integrity matters. Council selection, terms, conflicts, and accountability are not defined in a public charter.",
"Can bypass DAO?": "**Yes, for emergencies** — 7 Security Council approvals execute an encrypted proposal immediately, with no TAIKO-holder veto or delay. Standard proposals require 5 approvals and remain vetoable. The council controls most core upgrades but no longer has permissions over Treasury funds.",
"DAO can override SC?": "**No** — 10% of eligible TAIKO can block a standard proposal but never an emergency one. Token holders cannot create proposals, approve payloads, remove council members, or block emergency proposals; changing the signer list requires another council-approved proposal."
},
"upgrades": {
"Normal upgrade path": "Security Council member creates a public executable payload → 5 council approvals → **10d token-holder veto period** → if less than 10% of eligible TAIKO vetoes, **7d timelock** → permissionless execution of the approved onchain actions.",
"Emergency upgrade path": "**7 Security Council approvals, instant** — proposal metadata and actions stay encrypted while approvals are collected. A council member decrypts the payload, which is integrity-checked against the approved ciphertext and executed without a token-holder veto or timelock; its contents become public upon execution or expiry.",
"Exit window": "**17d standard · 0 emergency** — the standard path provides 10d of public vetoing followed by a 7d timelock. Emergency proposals bypass both."
},
"tokenGovernance": {
"Governance token": "`TAIKO` on Ethereum — 1,000,000,000 total supply, all minted at initialization; the current implementation has no further mint function. One delegated TAIKO equals one veto vote, snapshotted when the proposal is created. The Foundation treasury, DAO controller, canonical ERC20 vault, and zero address are excluded from eligible supply.",
"Voting venue": "[Taiko DAO](https://dao.taiko.xyz/) for onchain vetoes; proposals and temperature checks are discussed on the [Taiko forum](https://community.taiko.xyz/c/formal-governance-proposals-including-temperature-checks-drafts-and-proposals-for-on-chain-voting/9).",
"Proposal threshold": "**No TAIKO threshold** — only a Security Council member can create an onchain proposal. Community members can submit forum proposals, but a council member must sponsor the idea and supply the executable payload.",
"Quorum": "**No approval quorum; 10% veto threshold.** Standard proposals pass optimistically unless at least 10% of eligible TAIKO at the proposal snapshot vetoes. Unused and undelegated eligible tokens still count in the denominator.",
"Execution model": "**Council-gated optimistic veto + permissionless execution.** The Security Council approves the exact onchain actions. Token holders can only veto; if the threshold is not reached and the 7d timelock expires, anyone can call `execute()`. Emergency proposals skip the veto and delay."
}
}
}
}