Summary Value Secured Activity Onchain costs Data posted Liveness Milestones & Incidents Risk summary Risk analysis Stage Data availability State validation Upgrades & Governance Ossification & Updates Operator Withdrawals Permissions Smart contracts

Taiko Alethia

Name: Taiko Alethia
Creator: ETHBEAT

1 recent update

Badges

About

Taiko Alethia is an Ethereum-equivalent rollup on the Ethereum network. Taiko combines a preconfirmation-based sequencing mechanism with a multi-proof system using SP1, RISC0 and TEEs.

Total Value SecuredTVS

$10.92 M9.04%

Past day UOPSDaily UOPS

0.511.69%

Stage

Gas token

ETH

Type

ZK Rollup

Purpose

Universal

Chain ID

167000

Tokens breakdown

Value secured breakdown

1.98% with additional trust assumptions

View TVS breakdown

Sequencer failureState validationData availabilityExit windowProposer failure

Explore more in Discovery UI

Badges

About

Taiko Alethia is an Ethereum-equivalent rollup on the Ethereum network. Taiko combines a preconfirmation-based sequencing mechanism with a multi-proof system using SP1, RISC0 and TEEs.

Value Secured

Compare View TVS breakdown

Exclude restricted RWA tokens

Total

Canonically BridgedCanonically Bridged ValueCanonical

Natively MintedNatively Minted TokensNative

Externally BridgedExternally Bridged ValueExternal

ETH & derivatives

Stablecoins

BTC & derivatives

Other

View TVS breakdown

Compare with other projects

Activity

Compare

Past Day UOPS

Past Day Ops count

Max. UOPS

Past day UOPS/TPS Ratio

Compare with other projects

Onchain costs

Compare

The section shows the operating costs that L2s pay to Ethereum.

Total cost

Avg cost per L2 UOP

Avg cost per day

Compare with other projects

Data posted

Compare

This section shows how much data the project publishes to Ethereum over time. It leaves out data posted to other data-availability (DA) layers. The project currently posts data toEthereum.

Data posted

Avg size per day

Avg size per L2 UOP

Compare with other projects

This section shows how "live" the project's operators are by displaying how frequently they submit transactions of the selected type. It also highlights anomalies - significant deviations from their typical schedule.

No ongoing anomalies detected

Avg. tx data subs. interval

Avg. state updates interval

Past 30 days anomalies

99% normal uptime

Last 30 day anomalies

All liveness anomalies detected for this project in the last 30 days, helping you review recent downtime and availability issues.

No Tx data submissions were performed for 10m 24s (from 29 Oct 2026, 20:30 UTC until 29 Oct 2026, 20:41 UTC). These typically occur every 56s on average.

No State updates were performed for 3h 19m (from 15 Oct 2026, 15:43 UTC until 15 Oct 2026, 19:03 UTC). These typically occur every 1m 40s on average.

No Tx data submissions were performed for 7d 23h (from 22 Jun 2026, 02:10 UTC until 30 Jun 2026, 01:17 UTC). These typically occur every 56s on average.

No State updates were performed for 7d 12h (from 22 Jun 2026, 02:10 UTC until 29 Jun 2026, 14:49 UTC). These typically occur every 1m 40s on average.

Milestones & Incidents

Bridge recalls disabled

12 Oct 2026

Failed bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. messages must be retried successfully, with no source-chain refund path.

Learn more

Unzen upgrade: validity rollup

3 Aug 2026

Every proven proposal range now requires at least one SP1 or RISC0 validity proofThe output of a cryptographic proving system attesting to correct computation. ZK-Rollups use succinct validity proofs (also called zero-knowledge proofs) to prove a batch of rollup transactions and blocks were properly executed. Validity proofs are submitted to a verifier, such as an Ethereum smart contract, which accepts them if properly constructed..

Learn more

Risk summary

Risk analysis

Sequencer failureState validationData availabilityExit windowProposer failure

Sequencer failure

Enqueue via L1

Users can submit transactions to an L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. queue, but can’t force them. The sequencers cannot selectively skip transactions but can stop processing the queue entirely. In other words, if the sequencers censor or are down, they are so for everyone. An inclusion becomes due after 9m 36s. From then on, a whitelisted proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. cannot publish another proposal without processing up to ten due inclusions.

State validation

Validity proofs

Every proposal range is verified by exactly two proofs chosen from SGX (Geth), SGX (Reth), SP1 and RISC0, with at least one SP1 or RISC0 proof required. Proof submission is gated by ProverWhitelist, which has 2 whitelisted provers. This can affect livenessLiveness refers to the ability of a system to respond to requests and to process them in a timely manner. In the context of L2s, it refers to the ability of settling transactions, proofs and state roots to the base layer. but does not allow finalizing invalid state.

Data availability

Onchain

All of the data needed for proof construction is published on Ethereum L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development..

Exit window

None

There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.

Proposer failure

Cannot withdraw

Only the whitelisted proposers can publish state rootsA cryptographic hash succinctly representing a state using a Merkle tree. on L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development., so in the event of failure the withdrawals are frozen. Proposing is gated by PreconfWhitelist, which selects a single active operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. for the current epoch and has no permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. fallback.

Stage

Taiko Alethia is a

Stage 0

ZK Rollup.

Learn more about Stages

Please keep in mind that these stages do not reflect project security, this is an opinionated assessment of project maturity based on subjective criteria, created with a goal of incentivizing projects to push toward better decentralization. Each team may have taken different paths to achieve this goal.

Data availability

All data required for proofs is published on chain

All the data that is used to construct the system state is published on chain in the form of blobsThe data that a rollup publishes to its L1/data availability (DA) layer. They consist of the L2 transactions that are rolled up, along with some metadata. Blobs are introduced as a new transaction type within Ethereum with EIP-4844, and has rollup scaling specifically in mind. Blobs persist on Ethereum’s Beacon Chain ephemerally.. This ensures that it will be available for enough time.

Learn more about the DA layer here:

Ethereum

State validation

Validity proofs

Taiko uses a multi-proof systemA rollup settlement concept that relies on a combination of multiple different proving systems. For example, a combination of fraud proof and validity proof. The goal is to reduce reliance on a single system-type or implementation. A more complex example of a multi-proof system: if anyone submits two conflicting state roots to a prover and both roots pass, that prover is turned off. to validate state transitions. Exactly two proofs are required from four available verifiers: SGX (Geth), SGX (Reth), SP1, and RISC0. At least one proof must come from SP1 or RISC0. The RISC0 verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. also accepts Groth16A zk-SNARK proving system introduced by Groth in 2016 that proves arithmetic circuits and requires a separate trusted setup for each circuit. It allows extremely efficient proof verification. proofs under a verifying key that matches no published RISC Zero trusted setupGeneration of a piece of data that must then be used for some cryptographic protocol to run. Generating this data requires some secret information. The "trust" comes from the fact the secret must be destroyed after the ceremony, otherwise cryptographic properties of the protocol could be broken. Once the data is generated, and the secrets are forgotten, no further participation from the creators of the ceremony is required. There are two types of trusted setups for SNARKs: (i) trusted setup per circuit where it is generated from scratch for each circuit, (ii) trusted universal setup per proving system where it can be used for several circuits.. 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 permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. proving delay is not used to open proving. MainnetInbox currently sets minBond=0 and livenessBond=0.

PROVER

SP1 Hypercube

Trusted Setups

Onchain verifier

SP1Verifier

Used in

Onchain verifier

SP1Verifier

Used in

PROVER

RISC Zero

Trusted Setups

Onchain verifier

RiscZeroGroth16Verifier

Used in

Onchain verifier

RiscZeroGroth16Verifier

Used in

Program Hashes

Name

Hash

Repository

Verification

Used in

Name

Hash

Repository

Verification

Used in

Name	Hash	Repository	Verification	Used in

	0x0012...8c97	Github
	0x095c...8c97	Github
	0x0017...e51e	Github
	0x0bc8...e51e	Github
	0x8871...dfb0	Github
	0x0448...040a	Github

Upgrades & Governance

A diagram of the upgrades and governance

Taiko Alethia has a governance structure relying primarily on a 4/5 Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups., checked by a token DAO that is limited to veto permissions. The closed operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. 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.

Standard proposals

A threshold of 3 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.

Emergency proposals

Emergency proposals are encrypted at proposal time and can only be read by Security Council members. If approved by 4 Security Council members, they can be immediately decrypted and executed.

Proof systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system. and operators

A single EOA controls shared RISC0 verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. routes through a 3d timelock. It can also freeze RISC0 verifiers immediately. Operator roles (sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs., proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block.) are closed and the whitelist is managed by the Taiko Multisig and related EOAs.

Security Council

Composition: 3/5 standard · 4/5 emergency — 5-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 the Taiko Labs multisig and a Taiko co-founder. Members can appoint EOA agents to act for them.
Members public: Mapped — Taiko publishes a member wallet-to-entity mapping. The 5 current onchain members are Sebastian Kugler, Aragon, Taiko Labs, Gustavo Gonzalez, Daniel Wang. Gustavo Gonzalez and Daniel Wang sign as plain EOAs rather than multisigs. Each member wallet is mapped to its voting agent onchain.
Charter: No public charter — the DAO values define the council’s security mission and principles, while the 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 — 4 Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. approvals execute an encrypted proposal immediately, with no TAIKO-holder veto or delay. Standard proposals require 3 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 blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. 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 CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. member creates a public executable payload
3 council approvals
10d token-holder veto period
If less than 10% of eligible TAIKO vetoes, 7d timelock
PermissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. execution of the approved onchain actions

Emergency upgrade path

4 Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. 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.

Token governance

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 for onchain vetoes; proposals and temperature checks are discussed on the Taiko forum.
Proposal threshold: No TAIKO threshold — only a Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. 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 + permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. execution. The Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. 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.

Past upgrades

The metrics include upgrades on the currently used proxy contracts. Historical proxy contracts and changes of such are not included.

Count of upgrades

Last upgrade

16d 8h ago

Avg upgrade interval

4mo 9d

Ossification & Updates

Ossification

Contracts our research team classifies as critical form the project's critical perimeter. Its clock starts at the ossification genesis, and every critical change resets it (changes within 24 hours count as one). The ossification score is the share of recorded code-bug exploits whose exploited code was younger than this perimeter is today. Battle-tested exposure is the value secured, summed over that unchanged period.

Ossification %

32since 27 Oct 2026

TVS & changes (1Y)

Battle-tested exposure

$233.84 K·years

Critical changes / year

28across 46 contracts

Exit window

Discovery updates

28 Oct 2026, 13:50 UTC

Critical state change

11changes

The RISC Zero EOA 0xF616…d412 executed the scheduled addVerifier(0x8b38038c, 0x9660…) through the timelock. Taiko's RISC0 proofs can now route through the estop 0x9660… to RiscZeroGroth16Verifier v3.1.0. Its code equals v3.0.0. Only the constants differ: the Groth16 verifying key, control root and BN254 control ID. None of them appear in a public RISC Zero release or published trusted setup. The deployer left the contract unverified. L2BEAT verified the reconstructed source on etherscan and sourcify with an exact bytecode match. Current Taiko RISC0 proofs still use selector 0x73c457ba (v3.0.0). https://disco.l2beat.com/diff/eth:0x2a098988600d87650Fb061FfAff08B97149Fa84D/eth:0x953814e6dfC46d007557B511Dc4F2954dAaf2c9e The Safe 0xF28C…, a member of the Taiko Foundation Treasury Multisig, moved to the canonical Safe 1.5.0 singleton. https://disco.l2beat.com/diff/eth:0x41675C099F32341bf84BFc5382aF534df5C7461a/eth:0xFf51A5898e281Db6DfC7855790607438dF2ca44b

The RISC Zero EOA 0xF616…d412 executed the scheduled addVerifier(0x8b38038c, 0x9660…) through the timelock. Taiko’s RISC0 proofs can now route through the estop 0x9660… to RiscZeroGroth16Verifier v3.1.0. Its code equals v3.0.0. Only the constants differ: the Groth16 verifying key, control root and BN254 control ID. None of them appear in a public RISC Zero release or published trusted setup. The deployer left the contract unverified. L2BEAT verified the reconstructed source on etherscan and sourcify with an exact bytecode match. Current Taiko RISC0 proofs still use selector 0x73c457ba (v3.0.0). https://disco.l2beat.com/diff/eth:0x2a098988600d87650Fb061FfAff08B97149Fa84D/eth:0x953814e6dfC46d007557B511Dc4F2954dAaf2c9e

The Safe 0xF28C…, a member of the Taiko Foundation Treasury Multisig, moved to the canonical Safe 1.5.0 singleton. https://disco.l2beat.com/diff/eth:0x41675C099F32341bf84BFc5382aF534df5C7461a/eth:0xFf51A5898e281Db6DfC7855790607438dF2ca44b

	contract TimelockController (eth:0x0b144E07A0826182B6b59788c34b32Bfa86Fb711) [global/TimelockController] {
	+++ description: A timelock with access control. The current minimum delay is 3d.
	values.callsExecuted.21:
+	{"id":"0x682e79774f6b8e0fc1dbddd69bfca4374e9827b815d8fb2a73d602d541714c82","index":0,"target":"eth:0x8EaB2D97Dfce405A1692a21b3ff3A172d593D319","value":0,"data":"0xd0a6af308b38038c000000000000000000000000000000000000000000000000000000000000000000000000000000009660bd6dcdf455dcfb30c07c642ab22e7cb89f50"}
	}

	contract RiscZeroVerifierRouter (eth:0x8EaB2D97Dfce405A1692a21b3ff3A172d593D319) [risc0/RiscZeroVerifierRouter] {
	+++ description: A router proxy that routes to verifiers based on selectors. The mapping can be changed by a permissioned owner (eth:0x0b144E07A0826182B6b59788c34b32Bfa86Fb711).
	+++ severity: MEDIUM
	values.verifier_8b38038c:
-	"eth:0x0000000000000000000000000000000000000000"
+	"eth:0x9660bD6dCDf455DCFb30c07c642Ab22E7Cb89F50"
	}

	contract Safe (eth:0xF28C8D6b44361255FA7C116d09ccD5F914398C10) [GnosisSafe] {
	+++ description: None
	sourceHashes.1:
-	"0xe23c519b7324d6dc9132c8567ac55ae72bdf168c914d22825c7614d822364b0f"
+	"0xb66849da6643e8cd188f73efe4edb32704a1540eda5b1aef77a2217ad2d81f78"
	values.$implementation:
-	"eth:0x41675C099F32341bf84BFc5382aF534df5C7461a"
+	"eth:0xFf51A5898e281Db6DfC7855790607438dF2ca44b"
	values.getChainId:
-	1
	values.VERSION:
-	"1.4.1"
+	"1.5.0"
	implementationNames.eth:0x41675C099F32341bf84BFc5382aF534df5C7461a:
-	"Safe"
	implementationNames.eth:0xFf51A5898e281Db6DfC7855790607438dF2ca44b:
+	"Safe"
	}

	EOA (eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412) {
	+++ description: None
	receivedPermissions.9:
+	{"permission":"interact","from":"eth:0x9660bD6dCDf455DCFb30c07c642Ab22E7Cb89F50","description":"pause the verifier.","role":".owner"}
	}

+	Status: CREATED
	contract RiscZeroGroth16Verifier (eth:0x953814e6dfC46d007557B511Dc4F2954dAaf2c9e) [taiko/RiscZeroGroth16Verifier]
	+++ description: Verifier contract for RISC Zero Groth16 proofs (version 3.1.0).

+	Status: CREATED
	contract RiscZeroVerifierEmergencyStop (eth:0x9660bD6dCDf455DCFb30c07c642Ab22E7Cb89F50) [risc0/RiscZeroVerifierEmergencyStop]
	+++ description: A verifier wrapper for the eth:0x953814e6dfC46d007557B511Dc4F2954dAaf2c9e that allows pausing (emergency stop) the verifier by its owner.

24 Oct 2026, 16:55 UTC

Critical code change

49changes

DAO proposal 0024 (2026-10-19) upgraded the MainnetInbox: the whole basefee now goes to the block's coinbase, and the reentrancy lock moved to transient storage. The same proposal rotated the trusted RISC Zero images, SP1 programs and SGX enclave measurements. The RISC Zero timelock regranted proposer, executor and canceller to the EOA 0xF616…d412 (2026-10-20). The 2/5 Safe renounced its roles (2026-10-22), so one signer now governs the RiscZeroVerifierRouter behind a 3-day delay. The EOA scheduled addVerifier(0x8b38038c, 0x9660bd6d…) , executable from 2026-10-26. The estops moved to the same EOA. Discovery now watches the timelock's scheduled and executed calls, as bob does: the router emits no event on verifier changes.

DAO proposal 0024 (2026-10-19) upgraded the MainnetInbox: the whole basefee now goes to the block’s coinbase, and the reentrancy lock moved to transient storage. The same proposal rotated the trusted RISC Zero images, SP1 programs and SGX enclave measurements.

The RISC Zero timelock regranted proposer, executor and canceller to the EOA 0xF616…d412 (2026-10-20). The 2/5 Safe renounced its roles (2026-10-22), so one signer now governs the RiscZeroVerifierRouter behind a 3-day delay. The EOA scheduled addVerifier(0x8b38038c, 0x9660bd6d…), executable from 2026-10-26. The estops moved to the same EOA.

Discovery now watches the timelock’s scheduled and executed calls, as bob does: the router emits no event on verifier changes.

	contract TaikoRisc0Verifier (eth:0x059dAF31F571da48Ab4e74Ae12F64f907681Cd8b) [taiko/Risc0Verifier] {
	+++ description: Gating router contract to verify batches using RISC Zero.
	+++ description: Taiko specific Image IDs (i.e. program digest) of Risc0 programs (block proving and aggregation program separately) trusted by this verifier gateway. Only proofs for these programs can be successfully verified. Note that proofs contains image ID data within them.
	+++ severity: HIGH
	values.trustedImages.0:
-	"0xd6ab71c22201c23ef512b706f2e2d720f6da1b559fb76834aa9d4e35276f6e10"
+	"0x88712dad7dc78126ee7bb592282d3102569c706f1b9db80580a582e5ffd1dfb0"
	+++ description: Taiko specific Image IDs (i.e. program digest) of Risc0 programs (block proving and aggregation program separately) trusted by this verifier gateway. Only proofs for these programs can be successfully verified. Note that proofs contains image ID data within them.
	+++ severity: HIGH
	values.trustedImages.1:
-	"0xdd9b8abff96c409ae2418edfb51d893ea2bd10f4873a0226f17a6998c1afc1b7"
+	"0x04480b22e244d60165f3d0898bc61ea084d9c76221464a8a3c3343c74889040a"
	}

	contract TimelockController (eth:0x0b144E07A0826182B6b59788c34b32Bfa86Fb711) [global/TimelockController] {
	+++ description: A timelock with access control. The current minimum delay is 3d.
	values.accessControl.PROPOSER_ROLE.members.0:
-	"eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609"
+	"eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412"
	values.accessControl.CANCELLER_ROLE.members.0:
-	"eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609"
+	"eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412"
	values.accessControl.EXECUTOR_ROLE.members.0:
-	"eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609"
+	"eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412"
	values.callsExecuted.18:
+	{"id":"0xb88d38cc5995760c99a754e1fef6919fc7ee643d4de92b098d916b906b359910","index":0,"target":"eth:0x0b144E07A0826182B6b59788c34b32Bfa86Fb711","value":0,"data":"0x2f2ff15db09aa5aeb3702cfd50b6b62bc4532604938f21248a27a1d5ca736082b6819cc1000000000000000000000000f616a4f81857cfee54a4a049ec187172574bd412"}
	values.callsExecuted.19:
+	{"id":"0xb88d38cc5995760c99a754e1fef6919fc7ee643d4de92b098d916b906b359910","index":1,"target":"eth:0x0b144E07A0826182B6b59788c34b32Bfa86Fb711","value":0,"data":"0x2f2ff15dd8aa0f3194971a2a116679f7c2090f6939c8d4e01a2a8d7e41d55e5351469e63000000000000000000000000f616a4f81857cfee54a4a049ec187172574bd412"}
	values.callsExecuted.20:
+	{"id":"0xb88d38cc5995760c99a754e1fef6919fc7ee643d4de92b098d916b906b359910","index":2,"target":"eth:0x0b144E07A0826182B6b59788c34b32Bfa86Fb711","value":0,"data":"0x2f2ff15dfd643c72710c63c0180259aba6b2d05451e3591a24e58b62239378085726f783000000000000000000000000f616a4f81857cfee54a4a049ec187172574bd412"}
	values.callsScheduled.24:
+	{"id":"0x682e79774f6b8e0fc1dbddd69bfca4374e9827b815d8fb2a73d602d541714c82","index":0,"target":"eth:0x8EaB2D97Dfce405A1692a21b3ff3A172d593D319","value":0,"data":"0xd0a6af308b38038c000000000000000000000000000000000000000000000000000000000000000000000000000000009660bd6dcdf455dcfb30c07c642ab22e7cb89f50","predecessor":"0x0000000000000000000000000000000000000000000000000000000000000000","delay":259200}
	+++ severity: MEDIUM
	values.Canceller.0:
-	"eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609"
+	"eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412"
	+++ description: Executing proposals is only open to all addresses if this resolves to the 0x0 address
	+++ severity: MEDIUM
	values.Executor.0:
-	"eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609"
+	"eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412"
	+++ severity: MEDIUM
	values.Proposer.0:
-	"eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609"
+	"eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412"
	}

	contract AutomataDcapV3Attestation (eth:0x0ffa4A625ED9DB32B70F99180FD00759fc3e9261) [taiko/AutomataDcapV3Attestation] {
	+++ description: Contract managing SGX DCAP attestation policy, trusted measurements, and certificate revocation data.
	+++ description: Trusted SGX enclave measurements accepted by attestation verification.
	+++ severity: HIGH
	values.mrEnclaves.0:
-	"0x5f7da556f3b75dcc71465030e1b7274e82df9e9120c0b3eaf5bb76246a514005"
+	"0x8c23c79045b9b6bb827eab208e0fe58d7446a57a55f3dfc825c90e904953105b"
	}

	contract RiscZeroVerifierEmergencyStop (eth:0x1efDd13f831ceeEa14940806705A53D3211CD698) [risc0/RiscZeroVerifierEmergencyStop] {
	+++ description: A verifier wrapper for the eth:0xafB31f5b70623CDF4b20Ada3f7230916A5A79df9 that allows pausing (emergency stop) the verifier by its owner.
	+++ severity: MEDIUM
	values.owner:
-	"eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609"
+	"eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412"
	values.pendingOwner:
-	"eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412"
+	"eth:0x0000000000000000000000000000000000000000"
	}

-	Status: DELETED
	contract Safe (eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609) [GnosisSafe]
	+++ description: None

	contract RiscZeroVerifierEmergencyStop (eth:0x68dC2cB4e61774873971c499D9b239ec5Ac540E3) [risc0/RiscZeroVerifierEmergencyStop] {
	+++ description: A verifier wrapper for the eth:0x20ff7C2Cf391a5F096A2Cc181cb41916680f8E97 that allows pausing (emergency stop) the verifier by its owner.
	+++ severity: MEDIUM
	values.owner:
-	"eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609"
+	"eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412"
	values.pendingOwner:
-	"eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412"
+	"eth:0x0000000000000000000000000000000000000000"
	}

	contract MainnetInbox (eth:0x6f21C543a4aF5189eBdb0723827577e1EF57ef1f) [taiko/MainnetInbox] {
	+++ description: The core Layer 1 entrypoint for the Taiko rollup where L2 block batches are proposed and their corresponding state transitions are proven. Users can enqueue forced inclusions by publishing an L1 blob. Once an inclusion is due, subsequent proposals must process it, but proposing remains restricted by the configured proposer checker. If the configured prover whitelist is non-empty, proofs from non-whitelisted provers revert.
	sourceHashes.1:
-	"0xa0a8e3ebc196ae2703fc2c0dc5bc16012644bbcd103c34bf6241389ccadc0fd0"
+	"0x2dcf603b82b38ffd0745a55af8329dd811aff4e0b4e754f1fc240cc39e6b474e"
	values.$implementation:
-	"eth:0x5253D4C91e80b880DdB54B78E74082Abe066F6b9"
+	"eth:0xA18431d42C8dF9778905fBEa912aCF1881b49D2e"
	values.$pastUpgrades.4:
+	["2026-10-19T01:27:59.000Z","0x3f8f55e6651184d5794e4362661ebe709ae3a33df2424f664dc2bf235465859f",["eth:0xA18431d42C8dF9778905fBEa912aCF1881b49D2e"]]
	values.$upgradeCount:
-	4
+	5
	values.getConfig.basefeeSharingPctg:
-	75
+	100
	values.impl:
-	"eth:0x5253D4C91e80b880DdB54B78E74082Abe066F6b9"
+	"eth:0xA18431d42C8dF9778905fBEa912aCF1881b49D2e"
	implementationNames.eth:0x5253D4C91e80b880DdB54B78E74082Abe066F6b9:
-	"MainnetInbox"
	implementationNames.eth:0xA18431d42C8dF9778905fBEa912aCF1881b49D2e:
+	"MainnetInbox"
	}

	contract TaikoSP1Verifier (eth:0x73A0Db393ef87ce781ac7957bE10D6628432100F) [taiko/SP1Verifier] {
	+++ description: Gating router contract to verify batches using SP1.
	+++ description: Taiko-specific SP1 program verification keys trusted by this verifier gateway. Only proofs for these programs can be successfully verified.
	+++ severity: HIGH
	values.trustedPrograms.0:
-	"0x0025425c22e827507428a3d9c7b0f89635be5462f34bb6780563e3d6086be7c7"
+	"0x0012b97234e59f2319d44202c7b093fed9c9a51b2068e38d26625c139d668c97"
	+++ description: Taiko-specific SP1 program verification keys trusted by this verifier gateway. Only proofs for these programs can be successfully verified.
	+++ severity: HIGH
	values.trustedPrograms.1:
-	"0x12a12e113a09d41d05147b387b0f89632df2a3174d2ed9e00ac7c7ac086be7c7"
+	"0x095cb91a3967c8c63a8840587b093fed4e4d28d901a38e344cc4b8271d668c97"
	+++ description: Taiko-specific SP1 program verification keys trusted by this verifier gateway. Only proofs for these programs can be successfully verified.
	+++ severity: HIGH
	values.trustedPrograms.2:
-	"0x0051ac1d9e8cfd4196e37f9cfefd08e9b0f7ce653bad4634cd1ee84b71ca3be6"
+	"0x0017912dfd72308e2e2cd4211b05ed73a97eb7f576816adec2606a37507de51e"
	+++ description: Taiko-specific SP1 program verification keys trusted by this verifier gateway. Only proofs for these programs can be successfully verified.
	+++ severity: HIGH
	values.trustedPrograms.3:
-	"0x28d60ecf233f50655c6ff39f6fd08e9b07be73296eb518d31a3dd09671ca3be6"
+	"0x0bc896fe5c8c238b459a8423305ed73a4bf5bfab5a05ab7b04c0d46e507de51e"
	}

	contract RiscZeroVerifierEmergencyStop (eth:0x844D5f01161E3559d36f23d0Aa9E9620949aF782) [risc0/RiscZeroVerifierEmergencyStop] {
	+++ description: A verifier wrapper for the eth:0x5005aBa3DFf7C940fcc1e48DccCAD611a80eEB85 that allows pausing (emergency stop) the verifier by its owner.
	+++ severity: MEDIUM
	values.owner:
-	"eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609"
+	"eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412"
	values.pendingOwner:
-	"eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412"
+	"eth:0x0000000000000000000000000000000000000000"
	}

	contract AutomataDcapV3Attestation (eth:0x8d7C954960a36a7596d7eA4945dDf891967ca8A3) [taiko/AutomataDcapV3Attestation] {
	+++ description: Contract managing SGX DCAP attestation policy, trusted measurements, and certificate revocation data.
	+++ description: Trusted SGX enclave measurements accepted by attestation verification.
	+++ severity: HIGH
	values.mrEnclaves.0:
-	"0x3564b6a30089fcb3e2f69c19b22d23f84ce148387cd7a15f5c1df165b2ae5847"
+	"0xfeabd725eb5bb621b5c6a5071d1702bcbe06a643b42a0db8f381d5bc07dd81bf"
	+++ description: Trusted SGX enclave measurements accepted by attestation verification.
	+++ severity: HIGH
	values.mrEnclaves.1:
-	"0xae2c7b92b2a71238226cb624ecd1171b66bf943cc372314affca0e6748ccecdf"
+	"0x6f3c8c55ec62fe48b83e57463e8717aa9f8594418203c9520f0f80e6f4fc4d87"
	}

	contract RiscZeroVerifierEmergencyStop (eth:0x9F9994Eb4Cb5200198FEfb470f8b50301662e696) [risc0/RiscZeroVerifierEmergencyStop] {
	+++ description: A verifier wrapper for the eth:0x2a098988600d87650Fb061FfAff08B97149Fa84D that allows pausing (emergency stop) the verifier by its owner.
	+++ severity: MEDIUM
	values.owner:
-	"eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609"
+	"eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412"
	values.pendingOwner:
-	"eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412"
+	"eth:0x0000000000000000000000000000000000000000"
	}

	contract RiscZeroVerifierEmergencyStop (eth:0xDa8f3de6fBBdb261Ac771B813a578A7aBdA6B2b1) [risc0/RiscZeroVerifierEmergencyStop] {
	+++ description: A verifier wrapper for the eth:0x54aCE3ED46529B4d4F3770C8Bad5dDC48717B9bF that allows pausing (emergency stop) the verifier by its owner.
	+++ severity: MEDIUM
	values.owner:
-	"eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609"
+	"eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412"
	values.pendingOwner:
-	"eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412"
+	"eth:0x0000000000000000000000000000000000000000"
	}

	EOA (eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412) {
	+++ description: None
	receivedPermissions.0:
+	{"permission":"interact","from":"eth:0x0b144E07A0826182B6b59788c34b32Bfa86Fb711","description":"cancel queued transactions.","role":".Canceller"}
	receivedPermissions.1:
+	{"permission":"interact","from":"eth:0x0b144E07A0826182B6b59788c34b32Bfa86Fb711","description":"execute transactions that are ready.","role":".Executor"}
	receivedPermissions.2:
+	{"permission":"interact","from":"eth:0x0b144E07A0826182B6b59788c34b32Bfa86Fb711","description":"manage all access control roles.","role":".defaultAdminAC","via":[{"address":"eth:0x0b144E07A0826182B6b59788c34b32Bfa86Fb711","delay":259200}]}
	receivedPermissions.3:
+	{"permission":"interact","from":"eth:0x0b144E07A0826182B6b59788c34b32Bfa86Fb711","description":"propose transactions.","role":".Proposer"}
	receivedPermissions.4:
+	{"permission":"interact","from":"eth:0x1efDd13f831ceeEa14940806705A53D3211CD698","description":"pause the verifier.","role":".owner"}
	receivedPermissions.6:
+	{"permission":"interact","from":"eth:0x68dC2cB4e61774873971c499D9b239ec5Ac540E3","description":"pause the verifier.","role":".owner"}
	receivedPermissions.7:
+	{"permission":"interact","from":"eth:0x844D5f01161E3559d36f23d0Aa9E9620949aF782","description":"pause the verifier.","role":".owner"}
	receivedPermissions.8:
+	{"permission":"interact","from":"eth:0x8EaB2D97Dfce405A1692a21b3ff3A172d593D319","description":"add/remove verifiers and the selectors they are mapped to.","role":".owner","via":[{"address":"eth:0x0b144E07A0826182B6b59788c34b32Bfa86Fb711","delay":259200}]}
	receivedPermissions.9:
+	{"permission":"interact","from":"eth:0x9F9994Eb4Cb5200198FEfb470f8b50301662e696","description":"pause the verifier.","role":".owner"}
	receivedPermissions.10:
+	{"permission":"interact","from":"eth:0xDa8f3de6fBBdb261Ac771B813a578A7aBdA6B2b1","description":"pause the verifier.","role":".owner"}
	directlyReceivedPermissions:
+	[{"permission":"act","from":"eth:0x0b144E07A0826182B6b59788c34b32Bfa86Fb711","delay":259200,"role":".Executor"}]
	}

14 Oct 2026, 08:33 UTC

5changes

RISC Zero verifier owner Safe: ownership transfer of the five RiscZeroVerifierEmergencyStops to an EOA started ( pendingOwner ).

RISC Zero verifier owner Safe: ownership transfer of the five RiscZeroVerifierEmergencyStops to an EOA started (pendingOwner).

	contract RiscZeroVerifierEmergencyStop (eth:0x1efDd13f831ceeEa14940806705A53D3211CD698) [risc0/RiscZeroVerifierEmergencyStop] {
	+++ description: A verifier wrapper for the eth:0xafB31f5b70623CDF4b20Ada3f7230916A5A79df9 that allows pausing (emergency stop) the verifier by its owner.
	values.pendingOwner:
-	"eth:0x0000000000000000000000000000000000000000"
+	"eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412"
	}

	contract RiscZeroVerifierEmergencyStop (eth:0x68dC2cB4e61774873971c499D9b239ec5Ac540E3) [risc0/RiscZeroVerifierEmergencyStop] {
	+++ description: A verifier wrapper for the eth:0x20ff7C2Cf391a5F096A2Cc181cb41916680f8E97 that allows pausing (emergency stop) the verifier by its owner.
	values.pendingOwner:
-	"eth:0x0000000000000000000000000000000000000000"
+	"eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412"
	}

	contract RiscZeroVerifierEmergencyStop (eth:0x844D5f01161E3559d36f23d0Aa9E9620949aF782) [risc0/RiscZeroVerifierEmergencyStop] {
	+++ description: A verifier wrapper for the eth:0x5005aBa3DFf7C940fcc1e48DccCAD611a80eEB85 that allows pausing (emergency stop) the verifier by its owner.
	values.pendingOwner:
-	"eth:0x0000000000000000000000000000000000000000"
+	"eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412"
	}

	contract RiscZeroVerifierEmergencyStop (eth:0x9F9994Eb4Cb5200198FEfb470f8b50301662e696) [risc0/RiscZeroVerifierEmergencyStop] {
	+++ description: A verifier wrapper for the eth:0x2a098988600d87650Fb061FfAff08B97149Fa84D that allows pausing (emergency stop) the verifier by its owner.
	values.pendingOwner:
-	"eth:0x0000000000000000000000000000000000000000"
+	"eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412"
	}

	contract RiscZeroVerifierEmergencyStop (eth:0xDa8f3de6fBBdb261Ac771B813a578A7aBdA6B2b1) [risc0/RiscZeroVerifierEmergencyStop] {
	+++ description: A verifier wrapper for the eth:0x54aCE3ED46529B4d4F3770C8Bad5dDC48717B9bF that allows pausing (emergency stop) the verifier by its owner.
	values.pendingOwner:
-	"eth:0x0000000000000000000000000000000000000000"
+	"eth:0xF616A4f81857CFEe54A4A049Ec187172574bd412"
	}

12 Oct 2026, 07:16 UTC

Critical code change

198changes

L2 bridges and vaults upgrade. Recalls are disabled, so failed deliveries can strand funds until they succeed (recall proves a message failed on the destination and refunds funds on the source chain). ERC20 deposits add signed permits, and ETH sends receive more gas. The separate RISC0 governance Safe lowers its threshold from 3/5 to 2/5. - L1 Bridge, first upgrade - L1 Bridge, second upgrade - L1 ERC20Vault, first upgrade - L1 ERC20Vault, second upgrade - L2 Bridge, first upgrade - L2 Bridge, second upgrade - L2 ERC20Vault, first upgrade - L2 ERC20Vault, second upgrade - L1 ERC721Vault - L1 ERC1155Vault - L2 ERC721Vault - L2 ERC1155Vault - L2 resolver replacement - L1 NFT resolver replacement - L1 default ERC20 - L1 default ERC721 - L1 default ERC1155 - L2 default ERC20 - L2 default ERC721 - L2 default ERC1155

	contract ERC721Vault (eth:0x0b470dd3A0e1C41228856Fb319649E7c08f419Aa) [taiko/ERC721Vault] {
	+++ description: Escrows canonical ERC721 tokens and mints or burns their bridged representations. An immutable resolver selects the local bridge, counterpart vaults and default bridged token implementation. Releases authenticate the bridge and source vault.
	name:
-	"MainnetERC721Vault"
+	"ERC721Vault"
	sourceHashes.1:
-	"0x18fe27b80aff596fa58d3499fbe1ac44e8bd72cdc9ce0942afb53c5d9caa4b6e"
+	"0x783ac50fedc4522f4b68132d77dbab84b7738869e0c79eccc12ecca89e33be01"
	values.$implementation:
-	"eth:0xA4C5c20aB33C96B1c281Dca37D03E23609274C49"
+	"eth:0x611f3Dc278A14b6ED14410Cd9d56E1721cf33802"
	values.$pastUpgrades.6:
+	["2026-10-12T01:04:35.000Z","0x935e4a93cf26e7bef2ac3c445815e253496d82d51e4205e7073a3d511a9111f4",["eth:0x611f3Dc278A14b6ED14410Cd9d56E1721cf33802"]]
	values.$upgradeCount:
-	6
+	7
	values.addressManager:
-	"eth:0xEf9EaA1dd30a9AA1df01c36411b5F082aA65fBaa"
	values.impl:
-	"eth:0xA4C5c20aB33C96B1c281Dca37D03E23609274C49"
+	"eth:0x611f3Dc278A14b6ED14410Cd9d56E1721cf33802"
	values.lastUnpausedAt:
-	0
	+++ description: Immutable resolver selecting trusted bridge and vault counterparties and default token implementations.
	values.resolver:
+	"eth:0x8Efa01564425692d0a0838DC10E300BD310Cb43e"
	errors:
-	{"proxiableUUID":"Processing error occurred."}
	implementationNames.eth:0xA4C5c20aB33C96B1c281Dca37D03E23609274C49:
-	"MainnetERC721Vault"
	implementationNames.eth:0x611f3Dc278A14b6ED14410Cd9d56E1721cf33802:
+	"ERC721Vault"
	template:
+	"taiko/ERC721Vault"
	description:
+	"Escrows canonical ERC721 tokens and mints or burns their bridged representations. An immutable resolver selects the local bridge, counterpart vaults and default bridged token implementation. Releases authenticate the bridge and source vault."
	critical:
+	true
	fieldMeta:
+	{"owner":{"severity":"MEDIUM"},"pendingOwner":{"severity":"MEDIUM"},"paused":{"severity":"MEDIUM"},"resolver":{"description":"Immutable resolver selecting trusted bridge and vault counterparties and default token implementations."}}
	}

	contract SignerList (Security Council) (eth:0x0F95E6968EC1B28c794CF1aD99609431de5179c2) [taiko/SignerList] {
	+++ description: A signer list for storing multisig members and their agents, stores the addresses of the Multisigs that use this signer list. Each signer delegates their permissions to their agent address that they can configure here.
	receivedPermissions.1:
+	{"permission":"interact","from":"eth:0x0b470dd3A0e1C41228856Fb319649E7c08f419Aa","description":"pause and unpause NFT deposits, releases and refunds.","role":".owner","via":[{"address":"eth:0x75Ba76403b13b26AD1beC70D6eE937314eeaCD0a"},{"address":"eth:0x9CDf589C941ee81D75F34d3755671d614f7cf261","delay":604800,"condition":"(emergency proposals bypass the delay)"}]}
	receivedPermissions.9:
-	{"permission":"interact","from":"eth:0x91f67118DD47d502B1f0C354D0611997B022f29E","description":"update token withdrawal quotas and the quota refill period.","role":".owner","via":[{"address":"eth:0x75Ba76403b13b26AD1beC70D6eE937314eeaCD0a"},{"address":"eth:0x9CDf589C941ee81D75F34d3755671d614f7cf261","delay":604800,"condition":"(emergency proposals bypass the delay)"}]}
	receivedPermissions.11.description:
-	"pause and unpause token bridge flows and change the bridged token implementation for a canonical token after the migration delay."
+	"pause and unpause token flows and change a canonical token's bridged representation after the migration delay."
	receivedPermissions.15:
+	{"permission":"interact","from":"eth:0xaf145913EA4a56BE22E120ED9C24589659881702","description":"pause and unpause NFT deposits, releases and refunds.","role":".owner","via":[{"address":"eth:0x75Ba76403b13b26AD1beC70D6eE937314eeaCD0a"},{"address":"eth:0x9CDf589C941ee81D75F34d3755671d614f7cf261","delay":604800,"condition":"(emergency proposals bypass the delay)"}]}
	receivedPermissions.15.description:
-	"pause and unpause bridge message flows and execute one-time bridge recovery initializers."
+	"pause and unpause bridge flows and run one-time message recovery initializers."
	receivedPermissions.18:
-	{"permission":"interact","from":"eth:0xEf9EaA1dd30a9AA1df01c36411b5F082aA65fBaa","description":"can update the contract address for a given name","role":".owner","via":[{"address":"eth:0x75Ba76403b13b26AD1beC70D6eE937314eeaCD0a"},{"address":"eth:0x9CDf589C941ee81D75F34d3755671d614f7cf261","delay":604800,"condition":"(emergency proposals bypass the delay)"}]}
	receivedPermissions.20:
+	{"permission":"interact","from":"taiko:0x1670000000000000000000000000000000000001","description":"pause and unpause bridge flows and run one-time message recovery initializers.","role":".owner","via":[{"address":"taiko:0xfA06E15B8b4c5BF3FC5d9cfD083d45c53Cbe8C7C"},{"address":"eth:0x75Ba76403b13b26AD1beC70D6eE937314eeaCD0a"},{"address":"eth:0x9CDf589C941ee81D75F34d3755671d614f7cf261","delay":604800,"condition":"(emergency proposals bypass the delay)"}]}
	receivedPermissions.21:
+	{"permission":"interact","from":"taiko:0x1670000000000000000000000000000000000002","description":"pause and unpause token flows and change a canonical token's bridged representation after the migration delay.","role":".owner","via":[{"address":"taiko:0xfA06E15B8b4c5BF3FC5d9cfD083d45c53Cbe8C7C"},{"address":"eth:0x75Ba76403b13b26AD1beC70D6eE937314eeaCD0a"},{"address":"eth:0x9CDf589C941ee81D75F34d3755671d614f7cf261","delay":604800,"condition":"(emergency proposals bypass the delay)"}]}
	receivedPermissions.22:
+	{"permission":"interact","from":"taiko:0x1670000000000000000000000000000000000003","description":"pause and unpause NFT deposits, releases and refunds.","role":".owner","via":[{"address":"taiko:0xfA06E15B8b4c5BF3FC5d9cfD083d45c53Cbe8C7C"},{"address":"eth:0x75Ba76403b13b26AD1beC70D6eE937314eeaCD0a"},{"address":"eth:0x9CDf589C941ee81D75F34d3755671d614f7cf261","delay":604800,"condition":"(emergency proposals bypass the delay)"}]}
	receivedPermissions.23:
+	{"permission":"interact","from":"taiko:0x1670000000000000000000000000000000000004","description":"pause and unpause NFT deposits, releases and refunds.","role":".owner","via":[{"address":"taiko:0xfA06E15B8b4c5BF3FC5d9cfD083d45c53Cbe8C7C"},{"address":"eth:0x75Ba76403b13b26AD1beC70D6eE937314eeaCD0a"},{"address":"eth:0x9CDf589C941ee81D75F34d3755671d614f7cf261","delay":604800,"condition":"(emergency proposals bypass the delay)"}]}
	receivedPermissions.21.description:
-	"can update the contract address for a given name"
+	"update the contract address registered for any chainId-name pair."
	receivedPermissions.21.from:
-	"taiko:0x1670000000000000000000000000000000000006"
+	"taiko:0x2ea05A9CD06984Cf533a1829d8b0BE6289a43984"
	receivedPermissions.29:
-	{"permission":"upgrade","from":"eth:0x91f67118DD47d502B1f0C354D0611997B022f29E","role":"admin","via":[{"address":"eth:0x75Ba76403b13b26AD1beC70D6eE937314eeaCD0a"},{"address":"eth:0x9CDf589C941ee81D75F34d3755671d614f7cf261","delay":604800,"condition":"(emergency proposals bypass the delay)"}]}
	receivedPermissions.36:
-	{"permission":"upgrade","from":"eth:0xEf9EaA1dd30a9AA1df01c36411b5F082aA65fBaa","role":"admin","via":[{"address":"eth:0x75Ba76403b13b26AD1beC70D6eE937314eeaCD0a"},{"address":"eth:0x9CDf589C941ee81D75F34d3755671d614f7cf261","delay":604800,"condition":"(emergency proposals bypass the delay)"}]}
	receivedPermissions.44:
-	{"permission":"upgrade","from":"taiko:0x1670000000000000000000000000000000000006","role":"admin","via":[{"address":"taiko:0xfA06E15B8b4c5BF3FC5d9cfD083d45c53Cbe8C7C"},{"address":"eth:0x75Ba76403b13b26AD1beC70D6eE937314eeaCD0a"},{"address":"eth:0x9CDf589C941ee81D75F34d3755671d614f7cf261","delay":604800,"condition":"(emergency proposals bypass the delay)"}]}
	receivedPermissions.47:
+	{"permission":"upgrade","from":"taiko:0x2ea05A9CD06984Cf533a1829d8b0BE6289a43984","role":"admin","via":[{"address":"taiko:0xfA06E15B8b4c5BF3FC5d9cfD083d45c53Cbe8C7C"},{"address":"eth:0x75Ba76403b13b26AD1beC70D6eE937314eeaCD0a"},{"address":"eth:0x9CDf589C941ee81D75F34d3755671d614f7cf261","delay":604800,"condition":"(emergency proposals bypass the delay)"}]}
	}

	contract Safe (eth:0x2E5bcc9959dB5F5016F830E47943b07242CB2609) [GnosisSafe] {
	+++ description: None
	values.$members.3:
-	"eth:0xd5D43445d0227a47cA2eACCb9392352746eD9926"
+	"eth:0x9a017883e4A6BB2a6261D92D70f71107F2C39D12"
	values.$threshold:
-	3
+	2
	values.multisigThreshold:
-	"3 of 5 (60%)"
+	"2 of 5 (40%)"
	}

	contract TaikoDAOController (eth:0x75Ba76403b13b26AD1beC70D6eE937314eeaCD0a) [taiko/TaikoDAOController] {
	+++ description: Middleware contract that maintains ownership of DAO-controlled assets and contracts. Its token weight does not count towards the DAO quorum.
	directlyReceivedPermissions.2:
+	{"permission":"interact","from":"eth:0x0b470dd3A0e1C41228856Fb319649E7c08f419Aa","description":"pause and unpause NFT deposits, releases and refunds.","role":".owner"}
	directlyReceivedPermissions.8:
-	{"permission":"interact","from":"eth:0x91f67118DD47d502B1f0C354D0611997B022f29E","description":"update token withdrawal quotas and the quota refill period.","role":".owner"}
	directlyReceivedPermissions.9.description:
-	"pause and unpause token bridge flows and change the bridged token implementation for a canonical token after the migration delay."
+	"pause and unpause token flows and change a canonical token's bridged representation after the migration delay."
	directlyReceivedPermissions.12:
+	{"permission":"interact","from":"eth:0xaf145913EA4a56BE22E120ED9C24589659881702","description":"pause and unpause NFT deposits, releases and refunds.","role":".owner"}
	directlyReceivedPermissions.12.description:
-	"pause and unpause bridge message flows and execute one-time bridge recovery initializers."
+	"pause and unpause bridge flows and run one-time message recovery initializers."
	directlyReceivedPermissions.14:
-	{"permission":"interact","from":"eth:0xEf9EaA1dd30a9AA1df01c36411b5F082aA65fBaa","description":"can update the contract address for a given name","role":".owner"}
	directlyReceivedPermissions.22:
-	{"permission":"upgrade","from":"eth:0x91f67118DD47d502B1f0C354D0611997B022f29E","role":"admin"}
	directlyReceivedPermissions.28:
-	{"permission":"upgrade","from":"eth:0xEf9EaA1dd30a9AA1df01c36411b5F082aA65fBaa","role":"admin"}
	}

	contract DefaultResolver (eth:0x8Efa01564425692d0a0838DC10E300BD310Cb43e) [taiko/DefaultResolver] {
	+++ description: Maps chainId-name pairs to contract addresses. Bridge and vault contracts resolve their counterparties through this registry, so changes in this mapping effectively act as contract upgrades. The pause function is intentionally disabled in this implementation.
	values.namedAddresses.10.address:
-	"eth:0x65666141a541423606365123Ed280AB16a09A2e1"
+	"eth:0x9ccB9eBa4335096c5B64f050C3c734632D497c3b"
	values.namedAddresses.11.address:
-	"eth:0xC3310905E2BC9Cfb198695B75EF3e5B69C6A1Bf7"
+	"eth:0xD9c9dB7519011437C54BCD32495c0347A410bc4D"
	values.namedAddresses.12.address:
-	"eth:0x3c90963cFBa436400B0F9C46Aa9224cB379c2c40"
+	"eth:0x35001aB6f53CF9fE583653Ca3F56cae75E8C385e"
	}

-	Status: DELETED
	contract QuotaManager (eth:0x91f67118DD47d502B1f0C354D0611997B022f29E) [taiko/QuotaManager]
	+++ description: Defines withdrawal quotas for ETH and ERC20 releases from the shared bridge. A token quota of zero means unlimited withdrawals for that token.

	contract ERC20Vault (eth:0x996282cA11E5DEb6B5D122CC3B9A1FcAAD4415Ab) [taiko/ERC20Vault] {
	+++ description: Vault for canonical ERC20 tokens and their bridged representations. Deposits support standing approvals, ERC-2612 permits and Permit2 signatures. Successful deliveries consume token quota when a quota manager is configured. The bridge controls access to the refund callback.
	name:
-	"MainnetERC20Vault"
+	"ERC20Vault"
	template:
-	"taiko/SharedERC20Vault"
+	"taiko/ERC20Vault"
	sourceHashes.1:
-	"0x9b624be34d3f91047fd5ee6a056fd5d81ed43c3ba757e53661aeb4e4dabfe4aa"
+	"0x3a8df12e5f7ee6611bebe6784bc06bdd7ff8cc3c63d230e0260ca7ef9c97ead8"
	description:
-	"Shared vault for Taiko chains for bridged ERC20 tokens. Pausing stops token sends, message-triggered releases, and recalls. Released or minted tokens are subject to the configured quota manager."
+	"Vault for canonical ERC20 tokens and their bridged representations. Deposits support standing approvals, ERC-2612 permits and Permit2 signatures. Successful deliveries consume token quota when a quota manager is configured. The bridge controls access to the refund callback."
	values.$implementation:
-	"eth:0x024253C6FDC27d3161aFd43fb0241411A28dDc3c"
+	"eth:0xd429A698d19b5789ce6Eb72d8B3ae9fad3b28A92"
	values.$pastUpgrades.9:
+	["2026-10-08T07:28:47.000Z","0x17c27b257bb1445a512d4426c962de5c5f4b282f459c7e851c413702ad11d10c",["eth:0x32E47c04E8c329E8c10062731448e7658aDEEB8e"]]
	values.$pastUpgrades.10:
+	["2026-10-12T01:04:35.000Z","0x935e4a93cf26e7bef2ac3c445815e253496d82d51e4205e7073a3d511a9111f4",["eth:0xd429A698d19b5789ce6Eb72d8B3ae9fad3b28A92"]]
	values.$upgradeCount:
-	9
+	11
	values.impl:
-	"eth:0x024253C6FDC27d3161aFd43fb0241411A28dDc3c"
+	"eth:0xd429A698d19b5789ce6Eb72d8B3ae9fad3b28A92"
	values.proxiableUUID:
-	"EXPECT_REVERT"
	values.PERMIT2:
+	"eth:0x000000000022D473030F116dDEE9F6B43aC78BA3"
	fieldMeta.quotaManager.description:
-	"Quota manager that rate-limits ERC20 tokens released or minted by this vault."
+	"Immutable quota manager limiting successful token deliveries. Refunds consume no quota. The zero address disables quotas."
	fieldMeta.btokenDenylist.description:
-	"Bridged tokens denied by migration logic. Denied tokens cannot be sent through the vault."
+	"Bridged tokens excluded from sends by token migration logic."
	fieldMeta.owner:
+	{"severity":"MEDIUM"}
	fieldMeta.pendingOwner:
+	{"severity":"MEDIUM"}
	fieldMeta.resolver:
+	{"description":"Immutable registry resolving the bridge, counterpart vaults and default bridged token implementation."}
	implementationNames.eth:0x024253C6FDC27d3161aFd43fb0241411A28dDc3c:
-	"MainnetERC20Vault"
	implementationNames.eth:0xd429A698d19b5789ce6Eb72d8B3ae9fad3b28A92:
+	"ERC20Vault"
	}

	contract Taiko Multisig (eth:0x9CBeE534B5D8a6280e01a14844Ee8aF350399C7F) [GnosisSafe] {
	+++ description: None
	receivedPermissions.4.description:
-	"pause and unpause bridge message flows and fund the bridge through direct ETH transfers."
+	"pause and unpause bridge flows and fund the bridge through direct ETH transfers."
	}

	contract ERC1155Vault (eth:0xaf145913EA4a56BE22E120ED9C24589659881702) [taiko/ERC1155Vault] {
	+++ description: Escrows canonical ERC1155 tokens and mints or burns their bridged representations. An immutable resolver selects the local bridge, counterpart vaults and default bridged token implementation. Releases authenticate the bridge and source vault.
	name:
-	"MainnetERC1155Vault"
+	"ERC1155Vault"
	sourceHashes.1:
-	"0x4493f2ac281fab06a2ac9a899815cfeb485eb5f3c813020f91d6091bb85f101b"
+	"0xf2cbbe079d267fc8e34c5014c14f0dd4269da004cf9c1dc223ac4cb9ec351163"
	values.$implementation:
-	"eth:0x838ed469db456b67EB3b0B74D759Be4DA999b9c8"
+	"eth:0xca775D0Bb8CEFe388E344f75De91Aebd0E73c58E"
	values.$pastUpgrades.6:
+	["2026-10-12T01:04:35.000Z","0x935e4a93cf26e7bef2ac3c445815e253496d82d51e4205e7073a3d511a9111f4",["eth:0xca775D0Bb8CEFe388E344f75De91Aebd0E73c58E"]]
	values.$upgradeCount:
-	6
+	7
	values.addressManager:
-	"eth:0xEf9EaA1dd30a9AA1df01c36411b5F082aA65fBaa"
	values.impl:
-	"eth:0x838ed469db456b67EB3b0B74D759Be4DA999b9c8"
+	"eth:0xca775D0Bb8CEFe388E344f75De91Aebd0E73c58E"
	values.lastUnpausedAt:
-	0
	+++ description: Immutable resolver selecting trusted bridge and vault counterparties and default token implementations.
	values.resolver:
+	"eth:0x8Efa01564425692d0a0838DC10E300BD310Cb43e"
	errors:
-	{"proxiableUUID":"Processing error occurred."}
	implementationNames.eth:0x838ed469db456b67EB3b0B74D759Be4DA999b9c8:
-	"MainnetERC1155Vault"
	implementationNames.eth:0xca775D0Bb8CEFe388E344f75De91Aebd0E73c58E:
+	"ERC1155Vault"
	template:
+	"taiko/ERC1155Vault"
	description:
+	"Escrows canonical ERC1155 tokens and mints or burns their bridged representations. An immutable resolver selects the local bridge, counterpart vaults and default bridged token implementation. Releases authenticate the bridge and source vault."
	critical:
+	true
	fieldMeta:
+	{"owner":{"severity":"MEDIUM"},"pendingOwner":{"severity":"MEDIUM"},"paused":{"severity":"MEDIUM"},"resolver":{"description":"Immutable resolver selecting trusted bridge and vault counterparties and default token implementations."}}
	}

	contract Bridge (eth:0xd60247c6848B7Ca29eDdF63AA924E53dB6Ddd8EC) [taiko/Bridge] {
	+++ description: Bridge escrow for ETH and cross-chain messages. Pausing stops all message flows. The immutable recallEnabled setting controls failed-message refunds. Successful ETH releases use the configured quota manager.
	name:
-	"MainnetBridge"
+	"Bridge"
	template:
-	"taiko/TaikoBridge"
+	"taiko/Bridge"
	sourceHashes.1:
-	"0x61b87867a3f041292eb5da7940c9fc5d33aee32c063a7cf1696beb6eafac4a2b"
+	"0x765f8d75f0a63f536ea3c68dd988c86a2d844ec6fb08baeabbe309578bb04a01"
	description:
-	"Shared bridge escrow for Taiko chains for bridged ETH and arbitrary bridge messages. Pausing stops sending, processing, recalling, retrying, and failing messages. ETH released from the bridge is subject to the configured quota manager."
+	"Bridge escrow for ETH and cross-chain messages. Pausing stops all message flows. The immutable recallEnabled setting controls failed-message refunds. Successful ETH releases use the configured quota manager."
	values.$implementation:
-	"eth:0x1c94D798CFA08F396E5BA9F81697289c53273381"
+	"eth:0xe6BF63dCc936063caD2300f32DaA67d9eE5c57b6"
	values.$pastUpgrades.13:
+	["2026-10-08T07:28:47.000Z","0x17c27b257bb1445a512d4426c962de5c5f4b282f459c7e851c413702ad11d10c",["eth:0xA15dca0A72da684f20e0FC708DECFb230a715462"]]
	values.$pastUpgrades.14:
+	["2026-10-12T01:04:35.000Z","0x935e4a93cf26e7bef2ac3c445815e253496d82d51e4205e7073a3d511a9111f4",["eth:0xe6BF63dCc936063caD2300f32DaA67d9eE5c57b6"]]
	values.$upgradeCount:
-	13
+	15
	values.impl:
-	"eth:0x1c94D798CFA08F396E5BA9F81697289c53273381"
+	"eth:0xe6BF63dCc936063caD2300f32DaA67d9eE5c57b6"
	values.proxiableUUID:
-	"EXPECT_REVERT"
	+++ description: Immutable switch controlling failMessage, recallMessage and the failed branch of retryMessage. When false, failed deliveries must succeed on retry to release their funds.
	values.recallEnabled:
+	false
	fieldMeta.quotaManager.description:
-	"Quota manager that rate-limits ETH released by processed or recalled bridge messages."
+	"Immutable quota manager limiting successful ETH releases. The zero address disables quotas."
	fieldMeta.signalService.description:
-	"Signal service used to prove cross-chain message delivery and failure signals."
+	"Immutable signal service proving cross-chain message delivery and failure signals."
	fieldMeta.owner:
+	{"severity":"MEDIUM"}
	fieldMeta.pendingOwner:
+	{"severity":"MEDIUM"}
	fieldMeta.recallEnabled:
+	{"description":"Immutable switch controlling failMessage, recallMessage and the failed branch of retryMessage. When false, failed deliveries must succeed on retry to release their funds."}
	fieldMeta.resolver:
+	{"description":"Immutable registry resolving the trusted counterpart bridge on each chain."}
	implementationNames.eth:0x1c94D798CFA08F396E5BA9F81697289c53273381:
-	"MainnetBridge"
	implementationNames.eth:0xe6BF63dCc936063caD2300f32DaA67d9eE5c57b6:
+	"Bridge"
	}

-	Status: DELETED
	contract L1SharedAddressManager (eth:0xEf9EaA1dd30a9AA1df01c36411b5F082aA65fBaa) [taiko/L1SharedAddressManager]
	+++ description: Maps contract names to contract addresses. Changes in this mapping effectively act as contract upgrades.

	EOA (taiko:0x0000000000000000000000000000000000000000) {
	+++ description: None
	receivedPermissions:
+	[{"permission":"interact","from":"taiko:0x1670000000000000000000000000000000000001","description":"pause and unpause bridge flows and fund the bridge through direct ETH transfers.","role":".pauser"}]
	}

	contract Bridge (taiko:0x1670000000000000000000000000000000000001) [taiko/Bridge] {
	+++ description: Bridge escrow holding preminted ETH on Taiko. Failed messages remain retryable, but message failure and source-chain refunds are disabled.
	template:
-	"taiko/L2Bridge"
+	"taiko/Bridge"
	sourceHashes.1:
-	"0xfada2b71cfef6dfc63b33a9681baa712699f12de05eaf91f635ed3387a304791"
+	"0x765f8d75f0a63f536ea3c68dd988c86a2d844ec6fb08baeabbe309578bb04a01"
	values.$implementation:
-	"taiko:0x95ae2918dcbc6aFF8B4c1F1BCC1bf819b6e08B83"
+	"taiko:0xF372Db3F06AcaB3347697866d2047a54D1BA8eB3"
	values.$pastUpgrades.8:
+	["2026-10-08T07:30:21.000Z","0xc61c925bbc9b815715c6bc009cfcb50c16e93904dc07e799c913953a2b6be095",["taiko:0xa200c2268d77737a8Fd2CA1698dA6eeab2a85CEb"]]
	values.$pastUpgrades.9:
+	["2026-10-12T01:07:17.000Z","0xe8c9d02693ed235dce16a36685a7d07f2929b6927054e07be41293cec00d194d",["taiko:0xF372Db3F06AcaB3347697866d2047a54D1BA8eB3"]]
	values.$upgradeCount:
-	8
+	10
	values.addressManager:
-	"taiko:0x1670000000000000000000000000000000000006"
	values.bridgeWatchdog:
-	"taiko:0x0000000000000000000000000000000000000000"
	values.chainWatchdog:
-	"taiko:0x0000000000000000000000000000000000000000"
	values.impl:
-	"taiko:0x95ae2918dcbc6aFF8B4c1F1BCC1bf819b6e08B83"
+	"taiko:0xF372Db3F06AcaB3347697866d2047a54D1BA8eB3"
	values.lastUnpausedAt:
-	0
	+++ severity: MEDIUM
	values.pauser:
+	"taiko:0x0000000000000000000000000000000000000000"
	+++ description: Immutable switch controlling failMessage, recallMessage and the failed branch of retryMessage. When false, failed deliveries must succeed on retry to release their funds.
	values.recallEnabled:
+	false
	+++ description: Immutable registry resolving the trusted counterpart bridge on each chain.
	values.resolver:
+	"taiko:0x2ea05A9CD06984Cf533a1829d8b0BE6289a43984"
	fieldMeta.addressManager:
-	{"severity":"HIGH"}
	fieldMeta.signalService.severity:
-	"HIGH"
	fieldMeta.signalService.description:
+	"Immutable signal service proving cross-chain message delivery and failure signals."
	fieldMeta.quotaManager.severity:
-	"HIGH"
	fieldMeta.quotaManager.description:
-	"only relevant if not zero address"
+	"Immutable quota manager limiting successful ETH releases. The zero address disables quotas."
	fieldMeta.chainWatchdog:
-	{"severity":"MEDIUM","description":"only relevant if not zero address"}
	fieldMeta.bridgeWatchdog:
-	{"severity":"MEDIUM","description":"only relevant if not zero address"}
	fieldMeta.owner:
+	{"severity":"MEDIUM"}
	fieldMeta.pauser:
+	{"severity":"MEDIUM"}
	fieldMeta.recallEnabled:
+	{"description":"Immutable switch controlling failMessage, recallMessage and the failed branch of retryMessage. When false, failed deliveries must succeed on retry to release their funds."}
	fieldMeta.resolver:
+	{"description":"Immutable registry resolving the trusted counterpart bridge on each chain."}
	implementationNames.taiko:0x95ae2918dcbc6aFF8B4c1F1BCC1bf819b6e08B83:
-	"Bridge"
	implementationNames.taiko:0xF372Db3F06AcaB3347697866d2047a54D1BA8eB3:
+	"Bridge"
	category:
+	{"name":"Shared Infrastructure","priority":4}
	}

	contract ERC20Vault (taiko:0x1670000000000000000000000000000000000002) [taiko/ERC20Vault] {
	+++ description: Vault for canonical ERC20 tokens and their bridged representations. Deposits support standing approvals, ERC-2612 permits and Permit2 signatures. Successful deliveries consume token quota when a quota manager is configured. The bridge controls access to the refund callback.
	template:
-	"taiko/L2ERC20Vault"
+	"taiko/ERC20Vault"
	sourceHashes.1:
-	"0x9cc2e724dd00141e1e07621839efbb2f8c96ed9f67d6fbe50664ea8b6531c118"
+	"0x3a8df12e5f7ee6611bebe6784bc06bdd7ff8cc3c63d230e0260ca7ef9c97ead8"
	description:
-	"Escrow for L2-native tokens sent to L1 via the canonical bridge."
+	"Vault for canonical ERC20 tokens and their bridged representations. Deposits support standing approvals, ERC-2612 permits and Permit2 signatures. Successful deliveries consume token quota when a quota manager is configured. The bridge controls access to the refund callback."
	values.$implementation:
-	"taiko:0xb96AbB41b01E3ad519D00E80355a1c3801910F62"
+	"taiko:0x25D8465fD0C8D89bfdE910E47c41f4E465672B5c"
	values.$pastUpgrades.4:
+	["2026-10-08T07:30:21.000Z","0xc61c925bbc9b815715c6bc009cfcb50c16e93904dc07e799c913953a2b6be095",["taiko:0xa01d464ca3982DAa97B19fa7F8a232eB11A9DDb3"]]
	values.$pastUpgrades.5:
+	["2026-10-12T01:07:17.000Z","0xe8c9d02693ed235dce16a36685a7d07f2929b6927054e07be41293cec00d194d",["taiko:0x25D8465fD0C8D89bfdE910E47c41f4E465672B5c"]]
	values.$upgradeCount:
-	4
+	6
	values.addressManager:
-	"taiko:0x1670000000000000000000000000000000000006"
	values.impl:
-	"taiko:0xb96AbB41b01E3ad519D00E80355a1c3801910F62"
+	"taiko:0x25D8465fD0C8D89bfdE910E47c41f4E465672B5c"
	values.lastUnpausedAt:
-	1716811943
	values.PERMIT2:
+	"taiko:0x000000000022D473030F116dDEE9F6B43aC78BA3"
	+++ description: Immutable quota manager limiting successful token deliveries. Refunds consume no quota. The zero address disables quotas.
	values.quotaManager:
+	"taiko:0x0000000000000000000000000000000000000000"
	+++ description: Immutable registry resolving the bridge, counterpart vaults and default bridged token implementation.
	values.resolver:
+	"taiko:0x2ea05A9CD06984Cf533a1829d8b0BE6289a43984"
	fieldMeta.addressManager:
-	{"severity":"HIGH"}
	fieldMeta.owner:
+	{"severity":"MEDIUM"}
	fieldMeta.resolver:
+	{"description":"Immutable registry resolving the bridge, counterpart vaults and default bridged token implementation."}
	fieldMeta.quotaManager:
+	{"description":"Immutable quota manager limiting successful token deliveries. Refunds consume no quota. The zero address disables quotas."}
	fieldMeta.btokenDenylist:
+	{"description":"Bridged tokens excluded from sends by token migration logic."}
	implementationNames.taiko:0xb96AbB41b01E3ad519D00E80355a1c3801910F62:
-	"ERC20Vault"
	implementationNames.taiko:0x25D8465fD0C8D89bfdE910E47c41f4E465672B5c:
+	"ERC20Vault"
	category:
+	{"name":"Shared Infrastructure","priority":4}
	}

	contract ERC721Vault (taiko:0x1670000000000000000000000000000000000003) [taiko/ERC721Vault] {
	+++ description: Escrows canonical ERC721 tokens and mints or burns their bridged representations. An immutable resolver selects the local bridge, counterpart vaults and default bridged token implementation. Releases authenticate the bridge and source vault.
	sourceHashes.1:
-	"0xdb576f6eacda08057701d15f09fa5c2b615ae34b565d935a56dc43245eb46703"
+	"0x783ac50fedc4522f4b68132d77dbab84b7738869e0c79eccc12ecca89e33be01"
	values.$implementation:
-	"taiko:0xd532f20a4751156C566Da7745db95E7f80145B36"
+	"taiko:0x4cAb75DBE321084fD15c7AA9f7398e073A7EaBd0"
	values.$pastUpgrades.3:
+	["2026-10-12T01:07:17.000Z","0xe8c9d02693ed235dce16a36685a7d07f2929b6927054e07be41293cec00d194d",["taiko:0x4cAb75DBE321084fD15c7AA9f7398e073A7EaBd0"]]
	values.$upgradeCount:
-	3
+	4
	values.addressManager:
-	"taiko:0x1670000000000000000000000000000000000006"
	values.impl:
-	"taiko:0xd532f20a4751156C566Da7745db95E7f80145B36"
+	"taiko:0x4cAb75DBE321084fD15c7AA9f7398e073A7EaBd0"
	values.lastUnpausedAt:
-	0
	+++ description: Immutable resolver selecting trusted bridge and vault counterparties and default token implementations.
	values.resolver:
+	"taiko:0x2ea05A9CD06984Cf533a1829d8b0BE6289a43984"
	errors:
-	{"proxiableUUID":"Processing error occurred."}
	implementationNames.taiko:0xd532f20a4751156C566Da7745db95E7f80145B36:
-	"ERC721Vault"
	implementationNames.taiko:0x4cAb75DBE321084fD15c7AA9f7398e073A7EaBd0:
+	"ERC721Vault"
	template:
+	"taiko/ERC721Vault"
	description:
+	"Escrows canonical ERC721 tokens and mints or burns their bridged representations. An immutable resolver selects the local bridge, counterpart vaults and default bridged token implementation. Releases authenticate the bridge and source vault."
	critical:
+	true
	fieldMeta:
+	{"owner":{"severity":"MEDIUM"},"pendingOwner":{"severity":"MEDIUM"},"paused":{"severity":"MEDIUM"},"resolver":{"description":"Immutable resolver selecting trusted bridge and vault counterparties and default token implementations."}}
	}

	contract ERC1155Vault (taiko:0x1670000000000000000000000000000000000004) [taiko/ERC1155Vault] {
	+++ description: Escrows canonical ERC1155 tokens and mints or burns their bridged representations. An immutable resolver selects the local bridge, counterpart vaults and default bridged token implementation. Releases authenticate the bridge and source vault.
	sourceHashes.1:
-	"0x7325669dd281de5a8bb65da63dfffe0a322aca151892bffa8464934fbfafaa31"
+	"0xf2cbbe079d267fc8e34c5014c14f0dd4269da004cf9c1dc223ac4cb9ec351163"
	values.$implementation:
-	"taiko:0xBBBC4ad39488b990E095042fa6c59A90d3817846"
+	"taiko:0xe148CceFFcd5494301c20e047634995C60611e57"
	values.$pastUpgrades.3:
+	["2026-10-12T01:07:17.000Z","0xe8c9d02693ed235dce16a36685a7d07f2929b6927054e07be41293cec00d194d",["taiko:0xe148CceFFcd5494301c20e047634995C60611e57"]]
	values.$upgradeCount:
-	3
+	4
	values.addressManager:
-	"taiko:0x1670000000000000000000000000000000000006"
	values.impl:
-	"taiko:0xBBBC4ad39488b990E095042fa6c59A90d3817846"
+	"taiko:0xe148CceFFcd5494301c20e047634995C60611e57"
	values.lastUnpausedAt:
-	0
	+++ description: Immutable resolver selecting trusted bridge and vault counterparties and default token implementations.
	values.resolver:
+	"taiko:0x2ea05A9CD06984Cf533a1829d8b0BE6289a43984"
	errors:
-	{"proxiableUUID":"Processing error occurred."}
	implementationNames.taiko:0xBBBC4ad39488b990E095042fa6c59A90d3817846:
-	"ERC1155Vault"
	implementationNames.taiko:0xe148CceFFcd5494301c20e047634995C60611e57:
+	"ERC1155Vault"
	template:
+	"taiko/ERC1155Vault"
	description:
+	"Escrows canonical ERC1155 tokens and mints or burns their bridged representations. An immutable resolver selects the local bridge, counterpart vaults and default bridged token implementation. Releases authenticate the bridge and source vault."
	critical:
+	true
	fieldMeta:
+	{"owner":{"severity":"MEDIUM"},"pendingOwner":{"severity":"MEDIUM"},"paused":{"severity":"MEDIUM"},"resolver":{"description":"Immutable resolver selecting trusted bridge and vault counterparties and default token implementations."}}
	}

-	Status: DELETED
	contract L2AddressManager (taiko:0x1670000000000000000000000000000000000006) [taiko/L2AddressManager]
	+++ description: Maps contract names to contract addresses. Changes in this mapping effectively act as contract upgrades.

	contract DelegateController (taiko:0xfA06E15B8b4c5BF3FC5d9cfD083d45c53Cbe8C7C) [taiko/DelegateController] {
	+++ description: Middleware contract that can maintain ownership of DAO-controlled assets and contracts. It can only be invoked by the TaikoDAOController on L1 through the L2 bridge.
	directlyReceivedPermissions.0:
+	{"permission":"interact","from":"taiko:0x1670000000000000000000000000000000000001","description":"pause and unpause bridge flows and run one-time message recovery initializers.","role":".owner"}
	directlyReceivedPermissions.1:
+	{"permission":"interact","from":"taiko:0x1670000000000000000000000000000000000002","description":"pause and unpause token flows and change a canonical token's bridged representation after the migration delay.","role":".owner"}
	directlyReceivedPermissions.2:
+	{"permission":"interact","from":"taiko:0x1670000000000000000000000000000000000003","description":"pause and unpause NFT deposits, releases and refunds.","role":".owner"}
	directlyReceivedPermissions.3:
+	{"permission":"interact","from":"taiko:0x1670000000000000000000000000000000000004","description":"pause and unpause NFT deposits, releases and refunds.","role":".owner"}
	directlyReceivedPermissions.1.description:
-	"can update the contract address for a given name"
+	"update the contract address registered for any chainId-name pair."
	directlyReceivedPermissions.1.from:
-	"taiko:0x1670000000000000000000000000000000000006"
+	"taiko:0x2ea05A9CD06984Cf533a1829d8b0BE6289a43984"
	directlyReceivedPermissions.7:
-	{"permission":"upgrade","from":"taiko:0x1670000000000000000000000000000000000006","role":"admin"}
	directlyReceivedPermissions.12:
+	{"permission":"upgrade","from":"taiko:0x2ea05A9CD06984Cf533a1829d8b0BE6289a43984","role":"admin"}
	}

+	Status: CREATED
	contract DefaultResolver (taiko:0x2ea05A9CD06984Cf533a1829d8b0BE6289a43984) [taiko/DefaultResolver]
	+++ description: Maps chainId-name pairs to contract addresses. Bridge and vault contracts resolve their counterparties through this registry, so changes in this mapping effectively act as contract upgrades. The pause function is intentionally disabled in this implementation.

New and verified contracts

+	Status: CREATED
	contract MainnetERC721Vault (eth:0x0b470dd3A0e1C41228856Fb319649E7c08f419Aa) [N/A]
	+++ description: None

+	Status: CREATED
	contract QuotaManager (eth:0x91f67118DD47d502B1f0C354D0611997B022f29E) [taiko/QuotaManager]
	+++ description: Defines withdrawal quotas for ETH and ERC20 releases from the shared bridge. A token quota of zero means unlimited withdrawals for that token.

+	Status: CREATED
	contract MainnetERC1155Vault (eth:0xaf145913EA4a56BE22E120ED9C24589659881702) [N/A]
	+++ description: None

+	Status: CREATED
	contract L1SharedAddressManager (eth:0xEf9EaA1dd30a9AA1df01c36411b5F082aA65fBaa) [taiko/L1SharedAddressManager]
	+++ description: Maps contract names to contract addresses. Changes in this mapping effectively act as contract upgrades.

+	Status: CREATED
	contract ERC721Vault (taiko:0x1670000000000000000000000000000000000003) [N/A]
	+++ description: None

+	Status: CREATED
	contract ERC1155Vault (taiko:0x1670000000000000000000000000000000000004) [N/A]
	+++ description: None

1 Oct 2026, 10:34 UTC

5changes

- Two new standard DAO proposals (25 and 26), both still open in their veto period: - veto ends 2026-10-04: upgrades MainnetBridge, MainnetERC20Vault, MainnetERC721Vault, MainnetERC1155Vault, registers addresses in DefaultResolver and sends an L1- L2 message. - veto ends 2026-10-10: upgrades MainnetInbox, changes trusted RISC Zero image IDs and SP1 programs, changes MrEnclave values in both AutomataDcapV3Attestation contracts and deletes SGX instances in both SecureSgxVerifiers. Reviewed here: https://gist.github.com/sekuba/fd963174c4054a34ffb8c49f2c8bbf29.

Two new standard DAO proposals (25 and 26), both still open in their veto period:
- veto ends 2026-10-04: upgrades MainnetBridge, MainnetERC20Vault, MainnetERC721Vault, MainnetERC1155Vault, registers addresses in DefaultResolver and sends an L1->L2 message.
- veto ends 2026-10-10: upgrades MainnetInbox, changes trusted RISC Zero image IDs and SP1 programs, changes MrEnclave values in both AutomataDcapV3Attestation contracts and deletes SGX instances in both SecureSgxVerifiers. Reviewed here: https://gist.github.com/sekuba/fd963174c4054a34ffb8c49f2c8bbf29.

	contract OptimisticTokenVotingPlugin (eth:0x989E348275b659d36f8751ea1c10D146211650BE) [taiko/OptimisticTokenVotingPlugin] {
	+++ description: An optimistic governance module. Standard proposals pass and can be executed unless 10% of votable TAIKO veto them within 7d. Emergency proposals can be executed without delay.
	values.proposalCount:
-	40
+	42
	values.proposalIds.40:
+	"609192021977025249345447570106396801273767657512"
	values.proposalIds.41:
+	"609381197194961808191081799941267350559458852905"
	}

	contract Multisig (eth:0xD7dA1C25E915438720692bC55eb3a7170cA90321) [taiko/Multisig] {
	+++ description: Modular Governance contract allowing for proposing, voting on and executing proposals (e.g. for Security Council standard proposals).
	+++ description: total standard proposal count.
	values.proposalCount:
-	25
+	27
	}

	contract PreconfWhitelist (eth:0xFD019460881e6EeC632258222393d5821029b2ac) [taiko/PreconfWhitelist] {
	+++ description: Contains the whitelist of addresses eligible to propose batches on L1 and issue preconfirmations. It dynamically selects a single active operator for each epoch using a delayed Ethereum beacon block root as randomness. There is no fallback proposer path in this contract: non-selected operators cannot propose for the current epoch.
	values.operatorMapping.1:
+	"eth:0x35376dD47C061Bc3b8c8e8d61987019e7ED58f06"
	}

Operator

The system uses whitelist-based sequencing and proving

The system uses a whitelist-based sequencingA sequencing strategy for L2s based on Ethereum's own block building pipeline, which gets reused to also build L2 blocks. This strategy is in contrast to centralized sequencing or decentralized sequencing mechanisms that use networks external to Ethereum. mechanism to allow for fast preconfirmations on the L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups.. On the L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development., batch proposing is permissioned through the PreconfWhitelist contract, which currently has 2 active operators registered. For each epoch, PreconfWhitelist selects a single active operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. that can propose to MainnetInbox. There is no fallback proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. path, and non-selected operators cannot propose for the current epoch. Proving is controlled separately by ProverWhitelist, which currently has 2 whitelisted provers. While the proverAn entity that generates the cryptographic proof to convince the verifier that the statement is true. In a ZK-Rollup, the prover generates the ZK (validity) proof to submit to the verifier contract. whitelist is non-empty, non-whitelisted actors cannot submit proofs. MainnetInbox currently sets minBond=0 and livenessBond=0. Proving a proposal range requires exactly two proofs and at least one of them must be a ZK proof. Accepted combinations are SGX (Geth or Reth) plus SP1 or RISC0, or SP1 plus RISC0.

MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.

Users can enqueue transactions

Users can submit a forced inclusion directly to MainnetInbox on L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. by publishing a blobThe data that a rollup publishes to its L1/data availability (DA) layer. They consist of the L2 transactions that are rolled up, along with some metadata. Blobs are introduced as a new transaction type within Ethereum with EIP-4844, and has rollup scaling specifically in mind. Blobs persist on Ethereum’s Beacon Chain ephemerally. containing one L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. manifest and calling saveForcedInclusion(). Requests are stored in a FIFO queue and cost a dynamic fee that starts at 0.001 ETH. The fee increases linearly with the queue size and doubles when 50 requests are pending. After 9m 36s, a request is due. Every subsequent proposal must process the due requests at the head of the queue, up to ten per proposal, before the proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block.’s own derivation source. This prevents an active proposer from advancing the chain while selectively skipping a due request. However, propose() still unconditionally checks PreconfWhitelist. The configured 1d 1h 36m permissionlessAnyone willing should be able to join and leave the network at any time, without causing significant disturbance to the network or being detrimental to the party in question. No single entity should have the power to allowlist or blocklist participants. inclusion threshold is not used, so users and other unpermissioned actors cannot process the queue themselves. If all whitelisted proposers stop, the queue and the whole chain stop progressing.

Users can be censored if the operator is offline or refuses to process the queue.

Withdrawals

Regular exit

Users initiate withdrawals on Taiko and claim them on Ethereum with a Merkle proof after state finalization. ETH and ERC20 releases consume configured withdrawal quotas. Failed deliveries remain retryable, but source-chain refunds are disabled on both bridges.

Funds can be frozen if a bridge message cannot be delivered successfully, because failed-message refunds are disabled.

Permissions

A dashboard to explore contracts and permissions

Go to Disco

Explore in Disco

Ethereum

Actors:

SignerList (Security Council)0x0F95…79c2

A Multisig with 4/5 threshold. A signer list for storing multisig members and their agents, stores the addresses of the Multisigs that use this signer list. Each signer delegates their permissions to their agent address that they can configure here.

Can upgrade with 7d delay
- ERC721Vault DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- AutomataDcapV3Attestation DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- Taiko Token DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- MainnetInbox DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- TaikoDAOController DAO with 7d delay (emergency proposals bypass the delay)
- AutomataDcapV3Attestation DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- DefaultResolver DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- ERC20Vault DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- DAO DAO with 7d delay (emergency proposals bypass the delay)
- SignalService DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- ERC1155Vault DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- ProverWhitelist DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- TaikoDAOController DAO with 7d delay (emergency proposals bypass the delay)
- PreconfWhitelist DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
- Bridge DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
- ERC20Vault DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
- ERC721Vault DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
- ERC1155Vault DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
- SignalService DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
- Anchor DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
- DefaultResolver DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
- DelegateController DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
Can interact with TaikoRisc0Verifier
- manage trusted RISC Zero image IDs with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
Can interact with ERC721Vault
- pause and unpause NFT deposits, releases and refunds with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
Can interact with SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- add/remove members from the Security Council and change its minimum size with 7d delay DAO with 7d delay (emergency proposals bypass the delay)
Can interact with AutomataDcapV3Attestation
- manage trusted SGX measurements, revoked certificate serial numbers, TCB info, QE identity, and local report checks with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
Can interact with EmergencyMultisig
- manage critical settings (e.g. threshold and multisig settings) for the emergency proposal governance path with 7d delay DAO with 7d delay (emergency proposals bypass the delay)
Can interact with SecureSgxVerifier
- add SGX instances without DCAP attestation and delete registered instances with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
Can interact with MainnetInbox
- pause and unpause the rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. system, activate the inbox, and execute the one-time state recovery path with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
Can interact with TaikoSP1Verifier
- manage trusted SP1 program verification keys with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
Can interact with AutomataDcapV3Attestation
- manage trusted SGX measurements, revoked certificate serial numbers, TCB info, QE identity, and local report checks with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
Can interact with DefaultResolver
- update the contract address registered for any chainId-name pair with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
Can interact with OptimisticTokenVotingPlugin
- manage critical settings (e.g. thresholds, delays and proposal acceptance criteria) for all governance proposals with 7d delay DAO with 7d delay (emergency proposals bypass the delay)
Can interact with ERC20Vault
- pause and unpause token flows and change a canonical token’s bridged representation after the migration delay with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
Can interact with DAO
- define all permissions of the central DAO smart contract with 7d delay DAO with 7d delay (emergency proposals bypass the delay)
Can interact with SecureSgxVerifier
- add SGX instances without DCAP attestation and delete registered instances with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
Can interact with SignalService
- pause and unpause signal proof verification with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
Can interact with ERC1155Vault
- pause and unpause NFT deposits, releases and refunds with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
Can interact with Bridge
- pause and unpause bridge flows and run one-time message recovery initializers with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
Can interact with Multisig
- manage critical settings (e.g. threshold and multisig settings) for the standard proposal governance path with 7d delay DAO with 7d delay (emergency proposals bypass the delay)
Can interact with ProverWhitelist
- manage the proverAn entity that generates the cryptographic proof to convince the verifier that the statement is true. In a ZK-Rollup, the prover generates the ZK (validity) proof to submit to the verifier contract. whitelist with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
Can interact with PreconfWhitelist
- pause/unpause, add or remove operators, and manage ejecter roles with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController
Can interact with Bridge
- pause and unpause bridge flows and run one-time message recovery initializers with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
Can interact with ERC20Vault
- pause and unpause token flows and change a canonical token’s bridged representation after the migration delay with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
Can interact with ERC721Vault
- pause and unpause NFT deposits, releases and refunds with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
Can interact with ERC1155Vault
- pause and unpause NFT deposits, releases and refunds with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
Can interact with SignalService
- pause and unpause signal proof verification with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController
Can interact with DefaultResolver
- update the contract address registered for any chainId-name pair with 7d delay DAO with 7d delay (emergency proposals bypass the delay) → TaikoDAOController → DelegateController

Participants (5):

Taiko Labs Agent Aragon Agent L2BEAT Agent Daniel Wang Gustavo Gonzalez

Taiko Multisig0x9CBe…9C7F

A Multisig with 4/6 threshold.

Can interact with SecureSgxVerifier
- register SGX instances after DCAP attestation verification
Can interact with SecureSgxVerifier
- register SGX instances after DCAP attestation verification
Can interact with SignalService
- pause and unpause signal proof verification
Can interact with QuotaManager
- update token withdrawal quotas and the quota refill period
Can interact with BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge.
- pause and unpause bridge flows and fund the bridge through direct ETH transfers
Can interact with ProverWhitelist
- manage the proverAn entity that generates the cryptographic proof to convince the verifier that the statement is true. In a ZK-Rollup, the prover generates the ZK (validity) proof to submit to the verifier contract. whitelist
Can interact with PreconfWhitelist
- manage the ejecter role

Participants (6):

0xFa92…CD44 0xDC4e…8a0a 0x0aED…50B3 0xCf76…c439 Safe 0x3b1D…d5F1

ERC20Vault0x9962…15Ab

Vault for canonical ERC20 tokens and their bridged representations. Deposits support standing approvals, ERC-2612 permits and Permit2 signatures. Successful deliveries consume token quota when a quota manager is configured. The bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. controls access to the refund callback.

Can interact with QuotaManager
- consume ERC20 withdrawal quota when tokens leave the vault

Bridge0xd602…d8EC

BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. escrow for ETH and cross-chain messages. Pausing stops all message flows. The immutable recallEnabled setting controls failed-message refunds. Successful ETH releases use the configured quota manager.

Can interact with QuotaManager
- consume ETH withdrawal quota when ETH leaves the bridge

SP1VerifierGatewayMultisig0xCafE…6878

A Multisig with 2/3 threshold.

Can interact with SP1VerifierGateway
- affect the livenessLiveness refers to the ability of a system to respond to requests and to process them in a timely manner. In the context of L2s, it refers to the ability of settling transactions, proofs and state roots to the base layer. and safety of the gateway - can transfer ownership, add and freeze verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. routes

Participants (3):

0xBaB2…1126 0x72Ff…4f54 0x9395…8885

Used in:

Taiko Foundation Treasury Multisig0x363e…B3Da

A Multisig with 3/5 threshold.

Participants (5):

0xA1D6…9d25 0xDC4e…8a0a 0x7A52…299A Safe 0x3b1D…d5F1

Safe0xF28C…8C10

A Multisig with 1/2 threshold. Member of Taiko Foundation Treasury Multisig, Taiko Multisig, Taiko Labs.

Participants (2):

0x4757…45c3 0x7057…595C

2 EOAs

EOA 2 EOA 5

Can interact with PreconfWhitelist
- add operators after a two-epoch activation delay and remove existing operators immediately

2 EOAs

EOA 3 EOA 6

Can interact with PreconfWhitelist
- eligible to propose batches on L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development.; only the selected current-epoch operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. can successfully propose

EOA 40x3D49…b5bB

Member of Sebastian Kugler.

Can interact with SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- configure an agent address that represents this entity in the Security Council Sebastian Kugler

2 EOAs

Gustavo Gonzalez Daniel Wang

Member of SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.).

Can interact with SignerList (Security Council)
- configure an agent address that represents this entity in the Security Council

EOA 70xF616…d412

Can interact with TimelockController
- cancel queued transactions
- execute transactions that are ready
- manage all access control roles with 3d delay TimelockController with 3d delay
- propose transactions
Can interact with RiscZeroVerifierEmergencyStop
- pause the verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover.
Can interact with RiscZeroVerifierEmergencyStop
- pause the verifier
Can interact with RiscZeroVerifierEmergencyStop
- pause the verifier
Can interact with RiscZeroVerifierEmergencyStop
- pause the verifier
Can interact with RiscZeroVerifierRouter
- add/remove verifiers and the selectors they are mapped to with 3d delay TimelockController with 3d delay
Can interact with RiscZeroVerifierEmergencyStop
- pause the verifier
Can interact with RiscZeroVerifierEmergencyStop
- pause the verifier
Can interact with RiscZeroVerifierEmergencyStop
- pause the verifier

Used in:

Taiko Alethia

Actors:

EOA 10x0000…0000

Can interact with BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge.
- pause and unpause bridge flows and fund the bridge through direct ETH transfers

Smart contracts

A dashboard to explore contracts and permissions

Go to Disco

Explore in Disco

A diagram of the smart contract architecture

Ethereum

TaikoRisc0Verifier0x059d…Cd8b

Gating router contract to verify batches using RISC Zero.

Roles:
- owner: TaikoDAOController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)

RiscZeroGroth16Verifier0x20ff…8E97

VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for RISC Zero Groth16A zk-SNARK proving system introduced by Groth in 2016 that proves arithmetic circuits and requires a separate trusted setup for each circuit. It allows extremely efficient proof verification. proofs (version 2.0.0-rc.3).

Implementation used in:

RiscZeroGroth16Verifier0x2a09…a84D

Implementation used in:

RiscZeroGroth16Verifier0x54aC…B9bF

Implementation used in:

MainnetInbox0x6f21…ef1f Implementation (Upgradable)Admin

The core Layer 1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. entrypoint for the Taiko rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. where L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. batches are proposed and their corresponding state transitions are proven. Users can enqueue forced inclusions by publishing an L1 blobThe data that a rollup publishes to its L1/data availability (DA) layer. They consist of the L2 transactions that are rolled up, along with some metadata. Blobs are introduced as a new transaction type within Ethereum with EIP-4844, and has rollup scaling specifically in mind. Blobs persist on Ethereum’s Beacon Chain ephemerally.. Once an inclusion is due, subsequent proposals must process it, but proposing remains restricted by the configured proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. checker. If the configured proverAn entity that generates the cryptographic proof to convince the verifier that the statement is true. In a ZK-Rollup, the prover generates the ZK (validity) proof to submit to the verifier contract. whitelist is non-empty, proofs from non-whitelisted provers revert.

Roles:
- admin: TaikoDAOController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: TaikoDAOController; ultimately SignerList (Security Council)

Can be upgraded by:

SignerList (Security Council) with 7d delay

ZkRequiredVerifier0x7284…4Eec

Immutable verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. policy contract for Taiko mainnet. Every accepted proof contains exactly two ordered sub-proofs and at least one must be a ZK proof. Accepted pairs are SGX-GETH or SGX-RETH with RISC0-RETH or SP1-RETH, and RISC0-RETH with SP1-RETH. The SGX-GETH plus SGX-RETH pair is not accepted.

TaikoSP1Verifier0x73A0…100F

Gating router contract to verify batches using SP1.

Roles:
- owner: TaikoDAOController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)

RiscZeroGroth16Verifier0x9538…2c9e

RiscZeroGroth16Verifier0xafB3…9df9

Implementation used in:

ProverWhitelist0xEa79…12Ae Implementation (Upgradable)Admin

Defines the proverAn entity that generates the cryptographic proof to convince the verifier that the statement is true. In a ZK-Rollup, the prover generates the ZK (validity) proof to submit to the verifier contract. whitelist queried by the inbox before accepting proofs. If the inbox is configured with this contract and the whitelist is non-empty, only whitelisted provers can prove proposals.

Roles:
- admin: TaikoDAOController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: TaikoDAOController; ultimately SignerList (Security Council)
- proverManager: Taiko Multisig

Can be upgraded by:

SignerList (Security Council) with 7d delay

RiscZeroGroth16Verifier0xf70a…E93C

Implementation used in:

QuotaManager0xBaCb…c6cC

Defines withdrawal quotas for ETH and ERC20 releases from the shared bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge.. A token quota of zero means unlimited withdrawals for that token.

Roles:
- bridge: Bridge
- erc20Vault: ERC20Vault
- owner: Taiko Multisig

TaikoDAOController0x75Ba…CD0a Implementation (Upgradable)Admin

Middleware contract that maintains ownership of DAO-controlled assets and contracts. Its token weight does not count towards the DAO quorum.

Roles:
- admin: DAO; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: DAO

Can be upgraded by:

SignerList (Security Council) with 7d delay

DAO0x9CDf…f261 Implementation (Upgradable)Admin

The main contract and entrypoint of the Aragon-based DAO governance framework. Fine-grained DAO permissions, proposals, voting and thresholds are configured here.

Roles:
- currentSignerListPermissions: SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.) (emergency proposals bypass the delay)
- daoPermissions: DAO; ultimately SignerList (Security Council)

Can be upgraded by:

SignerList (Security Council) with 7d delay

TaikoDAOController0xfC3C…b2D3 Implementation (Upgradable)Admin

Middleware contract that maintains ownership of DAO-controlled assets and contracts. Its token weight does not count towards the DAO quorum.

Roles:
- admin: DAO; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: DAO

Can be upgraded by:

SignerList (Security Council) with 7d delay

TimelockController0x0b14…b711

A timelock with access control. The current minimum delay is 3d.

Roles:
- canceller: EOA 7
- defaultAdmin: TimelockController; ultimately EOA 7
- executor: EOA 7
- proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block.: EOA 7

Implementation used in:

ERC721Vault0x0b47…19Aa Implementation (Upgradable)Admin

Escrows canonical ERC721 tokens and mints or burns their bridged representations. An immutable resolver selects the local bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge., counterpart vaults and default bridged token implementation. Releases authenticate the bridge and source vault.

Roles:
- admin: TaikoDAOController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: TaikoDAOController; ultimately SignerList (Security Council)

Can be upgraded by:

SignerList (Security Council) with 7d delay

AutomataDcapV3Attestation0x0ffa…9261 Implementation (Upgradable)Admin

Contract managing SGX DCAP attestation policy, trusted measurements, and certificate revocation data.

Roles:
- admin: TaikoDAOController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: TaikoDAOController; ultimately SignerList (Security Council)

Can be upgraded by:

SignerList (Security Council) with 7d delay

Taiko Token0x10de…d800 Implementation (Upgradable)Admin

ERC20 contract implementing the TAIKO token. It defines a list of addresses designated as non-voting.

Roles:
- admin: TaikoDAOController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)

Can be upgraded by:

SignerList (Security Council) with 7d delay

RiscZeroVerifierEmergencyStop

5 instances

0x1efD…D698 0x44c2…33e7 0x68dC…40E3 0x9F99…e696 0xDa8f…B2b1

A verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. wrapper for the RiscZeroGroth16Verifier that allows pausing (emergency stop) the verifier by its owner.

Roles:
- owner: EOA 7

Implementation used in:

EmergencyMultisig0x2Aff…7ECd Implementation (Upgradable)Admin

Modular Governance contract allowing for proposing, voting on and executing encrypted proposals (e.g. for Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. emergency proposals).

Roles:
- dao: DAO; ultimately SignerList (Security Council)

SecureSgxVerifier

2 instances

0x41e7…84Ee 0x9D3C…FFd8

VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for SGX proven blocksAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over.. Registered SGX instances can sign accepted proofs until their instance expiry.

Roles:
- owner: TaikoDAOController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- registrar: Taiko Multisig

RiscZeroSetVerifier0x5005…EB85

Set verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for RISC Zero proofs (version 0.9.0). It allows verifying a whole set of proofs identified with a Merkle root at once, afterwards each individual proof could be efficiently verified just by checking Merkle inclusion against the verified root.

Implementation used in:

RiscZeroVerifierEmergencyStop0x844D…F782

A verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. wrapper for the RiscZeroSetVerifier that allows pausing (emergency stop) the verifier by its owner.

Roles:
- owner: EOA 7

Implementation used in:

AutomataDcapV3Attestation0x8d7C…a8A3 Implementation (Upgradable)Admin

Contract managing SGX DCAP attestation policy, trusted measurements, and certificate revocation data.

Roles:
- admin: TaikoDAOController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: TaikoDAOController; ultimately SignerList (Security Council)

Can be upgraded by:

SignerList (Security Council) with 7d delay

RiscZeroVerifierRouter0x8EaB…D319

A router proxy that routes to verifiers based on selectors. The mapping can be changed by a permissioned owner (TimelockController).

Roles:
- owner: TimelockController; ultimately EOA 7

Implementation used in:

DefaultResolver0x8Efa…b43e Implementation (Upgradable)Admin

Maps chainId-name pairs to contract addresses. BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. and vault contracts resolve their counterparties through this registry, so changes in this mapping effectively act as contract upgrades. The pause function is intentionally disabled in this implementation.

Roles:
- admin: TaikoDAOController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: TaikoDAOController; ultimately SignerList (Security Council)

Can be upgraded by:

SignerList (Security Council) with 7d delay

RiscZeroVerifierEmergencyStop0x9660…9F50

Roles:
- owner: EOA 7

OptimisticTokenVotingPlugin0x989E…50BE Implementation (Upgradable)Admin

An optimistic governance module. Standard proposals pass and can be executed unless 10% of votable TAIKO veto them within 7d. Emergency proposals can be executed without delay.

Roles:
- dao: DAO; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)

SignalService0x9e0a…C77C Implementation (Upgradable)Admin

Facilitates secure cross-chain message passing by storing signals and state-root checkpoints. BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. escrows and other applications use it to prove that a specific L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development.<->L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. signal or checkpointed state transition occurred via Merkle proofsHashing the pairs of values at each level and climbing up the (Merkle) Tree until you obtain the root hash. Merkle proofs help check if the data belongs to a set without having to store the entire set.. Pausing disables signal proof verification.

Roles:
- admin: TaikoDAOController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: TaikoDAOController; ultimately SignerList (Security Council)
- pauser: Taiko Multisig

Can be upgraded by:

SignerList (Security Council) with 7d delay

ERC1155Vault0xaf14…1702 Implementation (Upgradable)Admin

Escrows canonical ERC1155 tokens and mints or burns their bridged representations. An immutable resolver selects the local bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge., counterpart vaults and default bridged token implementation. Releases authenticate the bridge and source vault.

Roles:
- admin: TaikoDAOController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: TaikoDAOController; ultimately SignerList (Security Council)

Can be upgraded by:

SignerList (Security Council) with 7d delay

Multisig0xD7dA…0321 Implementation (Upgradable)Admin

Modular Governance contract allowing for proposing, voting on and executing proposals (e.g. for Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. standard proposals).

Roles:
- dao: DAO; ultimately SignerList (Security Council)

PreconfWhitelist0xFD01…b2ac Implementation (Upgradable)Admin

Contains the whitelist of addresses eligible to propose batches on L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. and issue preconfirmations. It dynamically selects a single active operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. for each epoch using a delayed Ethereum beacon blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. root as randomness. There is no fallback proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. path in this contract: non-selected operators cannot propose for the current epoch.

Roles:
- _ejectorManager: Taiko Multisig
- admin: TaikoDAOController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- ejecters: EOA 2, EOA 5
- operatorMapping: EOA 3, EOA 6
- owner: TaikoDAOController; ultimately SignerList (Security Council)

Can be upgraded by:

SignerList (Security Council) with 7d delay

SP1VerifierGateway0x3B60…185e

This contract is the router for zk proof verification. It stores the mapping between identifiers and the address of onchain verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contracts, routing each identifier to the corresponding verifier contract.

Roles:
- owner: SP1VerifierGatewayMultisig

Implementation used in:

SP1Verifier0xc3c6…AF2A

VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for SP1 proofs (v6.1.0).

Implementation used in:

Taiko Alethia

Anchor0x1670…0001 Implementation (Upgradable)Admin

Stores L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. details on L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. as a cross-layer oracle and manages EIP-1559 gasA virtual fuel used to execute smart contracts on a rollup. The EVM (or other VM within the rollup) uses an accounting mechanism to correspond the consumption of gas to the consumption of computing resources, and to limit the consumption of computing resources. pricing for L2 operations.

Roles:
- admin: DelegateController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)

Can be upgraded by:

SignerList (Security Council) with 7d delay

Bridge0x1670…0001 Implementation (Upgradable)Admin

BridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge. escrow holding preminted ETH on Taiko. Failed messages remain retryable, but message failure and source-chain refunds are disabled.

Roles:
- admin: DelegateController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: DelegateController; ultimately SignerList (Security Council)
- pauser: EOA 1

Can be upgraded by:

SignerList (Security Council) with 7d delay

ERC20Vault0x1670…0002 Implementation (Upgradable)Admin

Roles:
- admin: DelegateController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: DelegateController; ultimately SignerList (Security Council)

Can be upgraded by:

SignerList (Security Council) with 7d delay

DelegateController0xfA06…8C7C Implementation (Upgradable)Admin

Middleware contract that can maintain ownership of DAO-controlled assets and contracts. It can only be invoked by the TaikoDAOController on L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development. through the L2Layer 2 (L2) is a category of technical solutions aimed to scale the base layer in a trust minimized way. This category includes solutions like rollups as well as state channels and plasma. Other solutions are able to scale further, but with the introduction of additional trust assumptions, which are therefore not trust minimized. Sometimes the term Layer 2 is used to refer to include these solutions too, like validiums and optimiums, but to distinguish between trust minimized and non trust minimized solutions they are often referred to as "light" L2s, opposed to "strong" L2s like rollups. bridgeA message-passing protocol between two blockchains. At its most basic, a token bridge consists of a smart contract which can escrow funds on one side of the bridge, and instruct the release or minting of corresponding assets on the other side, but bridges could also support arbitrary messages. How these instructions are validated is a critical factor in assessing the trust assumptions of a bridge..

Roles:
- admin: DelegateController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- daoController: TaikoDAOController

Can be upgraded by:

SignerList (Security Council) with 7d delay

ERC721Vault0x1670…0003 Implementation (Upgradable)Admin

Roles:
- admin: DelegateController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: DelegateController; ultimately SignerList (Security Council)

Can be upgraded by:

SignerList (Security Council) with 7d delay

ERC1155Vault0x1670…0004 Implementation (Upgradable)Admin

Roles:
- admin: DelegateController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: DelegateController; ultimately SignerList (Security Council)

Can be upgraded by:

SignerList (Security Council) with 7d delay

SignalService0x1670…0005 Implementation (Upgradable)Admin

Roles:
- admin: DelegateController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: DelegateController; ultimately SignerList (Security Council)

Can be upgraded by:

SignerList (Security Council) with 7d delay

DefaultResolver0x2ea0…3984 Implementation (Upgradable)Admin

Roles:
- admin: DelegateController; ultimately SignerList (Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and ETHBEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups.)
- owner: DelegateController; ultimately SignerList (Security Council)

Can be upgraded by:

SignerList (Security Council) with 7d delay

The current deployment carries some associated risks: