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

Phala

Badges

About

Phala is a cloud computing protocol which aims at offering developers a secure and efficient platform for deploying and managing AI-ready applications in a trusted environment (TEE). Phala rollup on Ethereum leverages the Op-Succinct stack, a... combination of OP stack contracts and Zero-Knowledge Proofs (ZK) using the SP1 zkVM.

Total Value SecuredTVS

$308.56 K20.4%

Past day UOPSDaily UOPS

0.000.00%

Gas token

ETH

Type

Other

Purpose

Universal

Chain ID

2035

Tokens breakdown

Value secured breakdown

0.00% with additional trust assumptions

View TVS breakdown

Sequencer failureState validationData availabilityExit windowProposer failure

Explore more in Discovery UI

Badges

About

Why is the project listed in others?

There are less than 5 external actors that can submit challenges

Consequence: projects without a sufficiently decentralized set of challengers rely on few entities to safely update the state. A small set of challengers can collude with the proposer to finalize an invalid state, which can cause loss of funds.

Learn more about the recategorisation here.

Value Secured 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

Activity

2025 Jun 05 — 2026 Jun 05

Past Day UOPS

0.000.00%

Past Day Ops count

Max. UOPS

<0.01

2025 Nov 21

Past day UOPS/TPS Ratio

1.00

Onchain costs

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

2025 Jun 06 — 2026 Jun 05

Total cost

$1.61 K

Avg cost per L2 UOP

$0.846786

Avg cost per day

$4.43

Data posted

This section shows how much data the project publishes to its data-availability (DA) layer over time. The project currently posts data toEthereum.

2025 Jun 06 — 2026 Jun 05

Data posted

924.13 MiB

Avg size per day

2.52 MiB

Avg size per L2 UOP

494.93 KiB

Liveness

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

2026 May 07 — Jun 05

Avg. tx data subs. interval

59 minutes

Avg. state updates interval

12 hours

Past 30 days anomalies

97% 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 7h 52m 48s (from 2026 Jun 05, 13:26 UTC until 2026 Jun 05, 21:19 UTC). These typically occur every 59min 37s on average.

No State updates were performed for 12h 24s (from 2026 May 10, 12:41 UTC until 2026 May 11, 00:41 UTC). These typically occur every 12h 11s on average.

Milestones & Incidents

Switched back to Validity Proofs

2026 Feb 2nd

Phala switched back to OPSuccinct (SP1 ZK proofs).

Learn more

Switched to Optimistic Proofs

2026 Jan 20th

Phala switched from OPSuccinct (SP1 ZK proofs) to PermissionedDisputeGame (optimistic fault proofs).

Learn more

Risk summary

Funds can be stolen if

a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).

MEV can be extracted if

the operator exploits their centralized position and frontruns user transactions.

Risk analysis

Sequencer failureState validationData availabilityExit windowProposer failure

Sequencer failure

Self sequence

In the event of a sequencer failure, users can force transactions to be included in the project’s chain by sending them to L1. There can be up to a 12h delay on this operation.

State validation

Fraud proofs (INT)

Fraud proofs allow actors watching the chain to prove that the state is incorrect. Interactive proofs (INT) require multiple transactions over time to resolve. Only one entity is currently allowed to propose and submit challenges, as only permissioned games are currently allowed.

Data availability

Onchain

All of the data needed for proof construction is published on Ethereum L1.

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 roots on L1, so in the event of failure the withdrawals are frozen.

Stage

Phala is not even a

Stage 0

project.

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 cheap blobs or calldata. This ensures that it will be available for enough time.

Learn more about the DA layer here:

Ethereum

State validation

Updates to the system state can be proposed and challenged by permissioned operators only. If a state root passes the challenge period, it is optimistically considered correct and made actionable for withdrawals.

State root proposals

Proposers submit state roots as children of the latest confirmed state root (called anchor state), by calling the create function in the DisputeGameFactory. A state root can have multiple conflicting children. Each proposal requires a stake, currently set to 0.0 ETH, that can be slashed if the proposal is proven incorrect via a fraud proof. Stakes can be withdrawn only after the proposal has been confirmed. A state root gets confirmed if the challenge period has passed and it is not countered.

OP stack specification: Fault Dispute Game

Challenges

Challenges are opened to disprove invalid state roots using bisection games. Each bisection move requires a stake that increases expontentially with the depth of the bisection, with a factor of 1.09493. The maximum depth is 73, and reaching it therefore requires a cumulative stake of 0.00 ETH from depth 0. Actors can participate in any challenge by calling the defend or attack functions, depending whether they agree or disagree with the latest claim and want to move the bisection game forward. Actors that disagree with the top-level claim are called challengers, and actors that agree are called defenders. Each actor might be involved in multiple (sub-)challenges at the same time, meaning that the protocol operates with full concurrency. Challengers and defenders alternate in the bisection game, and they pass each other a clock that starts with 3d 12h. If a clock expires, the claim is considered defeated if it was countered, or it gets confirmed if uncountered. Since honest parties can inherit clocks from malicious parties that play both as challengers and defenders (see freeloader claims), if a clock gets inherited with less than 3h, it generally gets extended by 3h with the exception of 6h right before depth 30, and 1d right before the last depth. The maximum clock extension that a top level claim can get is therefore 10d. Since unconfirmed state roots are independent of one another, users can decide to exit with a subsequent confirmed state root if the previous one is delayed. Winners get the entire losers’ stake, meaning that sybils can potentially play against each other at no cost. The final instruction found via the bisection game is then executed onchain in the MIPS one step prover contract who determines the winner. The protocol does not enforce valid bisections, meaning that actors can propose correct initial claims and then provide incorrect midpoints. The protocol can be subject to resource exhaustion attacks (Spearbit 5.1.3).

Fraud Proof Wars: OPFP

Program Hashes

Name	Hash	Repository	Verification	Used in

	0x0368...94b6	Github		Projects used in Search for projects used in

Upgrades & Governance

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

4mo 16d ago

Avg upgrade interval

2mo 25d

Updates

2026 June 02, 10:53 UTC

2changes

Conduit Multisig 1 rotated one signer (operator key 0x3840…fd5f → 0xcdC9…4853 ); same rotation propagated across Conduit Multisigs 1/2/3 on eth/arb1/base. New game name (aggregateVerifier) added to portal.

Conduit Multisig 1 rotated one signer (operator key 0x3840…fd5f → 0xcdC9…4853); same rotation propagated across Conduit Multisigs 1/2/3 on eth/arb1/base.

New game name (aggregateVerifier) added to portal.

	contract Conduit Multisig 1 (eth:0x4a4962275DF8C60a80d3a25faEc5AA7De116A746) [GnosisSafe] {
	+++ description: None
	values.$members.0:
+	"eth:0xcdC931935768c0562AfE989A366a3Dc4d52F4853"
	values.$members.8:
-	"eth:0x3840f487A17A41100DD1Bf0946c34f132a57Fd5f"
	}

2026 May 05, 15:18 UTC

3changes

Conduit Multisig 1 ( eth:0x4a496227... ) — signer 0x381624F7 removed. Threshold unchanged at 4; total signers 13 → 12 (31% → 33%). Shared multisig (referenced by multiple Conduit-managed chains).

Conduit Multisig 1 (eth:0x4a496227...) — signer 0x381624F7 removed. Threshold unchanged at 4; total signers 13 → 12 (31% → 33%). Shared multisig (referenced by multiple Conduit-managed chains).

	contract Conduit Multisig 1 (eth:0x4a4962275DF8C60a80d3a25faEc5AA7De116A746) {
	+++ description: None
	values.$members.1:
-	"eth:0x381624F7912BddD83dc67c6C53Ef6FE61B87Cf07"
	values.multisigThreshold:
-	"4 of 13 (31%)"
+	"4 of 12 (33%)"
	}

2026 March 24, 21:25 UTC

High severity

12changes

respectedGameType changed from 6 (OPSuccinctDisputeGame) to 1 (PermissionedDisputeGame) on both OptimismPortal2 and AnchorStateRegistry. This means Phala is no longer using ZK-verified state proofs (via Succinct's SP1) for withdrawal verification, and has switched back to the standard permissioned dispute game model.

respectedGameType changed from 6 (OPSuccinctDisputeGame) to 1 (PermissionedDisputeGame) on both OptimismPortal2 and AnchorStateRegistry. This means Phala is no longer using ZK-verified state proofs (via Succinct’s SP1) for withdrawal verification, and has switched back to the standard permissioned dispute game model.

	contract OptimismPortal2 (eth:0x96B124841Eff4Ab1b3C1F654D60402a1405fF51A) {
	+++ description: The OptimismPortal contract is the main entry point to deposit funds from L1 to L2. It also allows to prove and finalize withdrawals. It specifies which game type can be used for withdrawals, which currently is the PermissionedDisputeGame.
	description:
-	"The OptimismPortal contract is the main entry point to deposit funds from L1 to L2. It also allows to prove and finalize withdrawals. It specifies which game type can be used for withdrawals, which currently is the 6."
+	"The OptimismPortal contract is the main entry point to deposit funds from L1 to L2. It also allows to prove and finalize withdrawals. It specifies which game type can be used for withdrawals, which currently is the PermissionedDisputeGame."
	values.RespectedGameString:
-	6
+	"PermissionedDisputeGame"
	+++ severity: HIGH
	values.respectedGameType:
-	6
+	1
	}

	contract AnchorStateRegistry (eth:0xDeF9B23dAE7769004e80f579f9d3aF0D7a29E4aD) {
	+++ description: Contains the latest confirmed state root that can be used as a starting point in a dispute game. It specifies which game type can be used for withdrawals, which currently is the PermissionedDisputeGame.
	description:
-	"Contains the latest confirmed state root that can be used as a starting point in a dispute game. It specifies which game type can be used for withdrawals, which currently is the 6."
+	"Contains the latest confirmed state root that can be used as a starting point in a dispute game. It specifies which game type can be used for withdrawals, which currently is the PermissionedDisputeGame."
	values.RespectedGameString:
-	6
+	"PermissionedDisputeGame"
	+++ severity: HIGH
	values.respectedGameType:
-	6
+	1
	}

2026 February 03, 10:55 UTC

High severity

16changes

Phala switched back to op-succinct dispute game type 6: https://etherscan.io/address/0xDeF9B23dAE7769004e80f579f9d3aF0D7a29E4aD events (full validity proofs). Games of type 6 are being created now: https://etherscan.io/address/0x2157F4d5934c4b12193C4983E99b9D6418798a2E events. Previous version of op-succinct upgraded to v4.0.0-rc.1: https://github.com/succinctlabs/op-succinct/releases/tag/v4.0.0-rc.1. Diff is here: https://disco.l2beat.com/diff/eth:0xb476cC5ECF2472A040DC381552B7a9bd7951A470/eth:0x2c2dA5EFfAbDA3a9ffe8e3D526C5b1F3B42FEa6D. (Contract itself still claims that it has verison v3.0.0, but it is lies: https://github.com/succinctlabs/op-succinct/blob/v4.0.0-rc.1/contracts/src/validity/OPSuccinctDisputeGame.sol L37).

Phala switched back to op-succinct dispute game type 6: https://etherscan.io/address/0xDeF9B23dAE7769004e80f579f9d3aF0D7a29E4aD#events (full validity proofs). Games of type 6 are being created now: https://etherscan.io/address/0x2157F4d5934c4b12193C4983E99b9D6418798a2E#events.

Previous version of op-succinct upgraded to v4.0.0-rc.1: https://github.com/succinctlabs/op-succinct/releases/tag/v4.0.0-rc.1. Diff is here: https://disco.l2beat.com/diff/eth:0xb476cC5ECF2472A040DC381552B7a9bd7951A470/eth:0x2c2dA5EFfAbDA3a9ffe8e3D526C5b1F3B42FEa6D. (Contract itself still claims that it has verison v3.0.0, but it is lies: https://github.com/succinctlabs/op-succinct/blob/v4.0.0-rc.1/contracts/src/validity/OPSuccinctDisputeGame.sol#L37).

	contract DisputeGameFactory (eth:0x2157F4d5934c4b12193C4983E99b9D6418798a2E) {
	+++ description: The dispute game factory allows the creation of dispute games, used to propose state roots and eventually challenge them.
	+++ severity: HIGH
	values.gameImpls.6:
-	"eth:0xb476cC5ECF2472A040DC381552B7a9bd7951A470"
+	"eth:0x2c2dA5EFfAbDA3a9ffe8e3D526C5b1F3B42FEa6D"
	}

	contract OptimismPortal2 (eth:0x96B124841Eff4Ab1b3C1F654D60402a1405fF51A) {
	+++ description: The OptimismPortal contract is the main entry point to deposit funds from L1 to L2. It also allows to prove and finalize withdrawals. It specifies which game type can be used for withdrawals, which currently is the 6.
	description:
-	"The OptimismPortal contract is the main entry point to deposit funds from L1 to L2. It also allows to prove and finalize withdrawals. It specifies which game type can be used for withdrawals, which currently is the PermissionedDisputeGame."
+	"The OptimismPortal contract is the main entry point to deposit funds from L1 to L2. It also allows to prove and finalize withdrawals. It specifies which game type can be used for withdrawals, which currently is the 6."
	values.RespectedGameString:
-	"PermissionedDisputeGame"
+	6
	+++ severity: HIGH
	values.respectedGameType:
-	1
+	6
	}

-	Status: DELETED
	contract OPSuccinctDisputeGame (eth:0xb476cC5ECF2472A040DC381552B7a9bd7951A470)
	+++ description: A dispute game wrapper around OPSuccinctL2OutputOracle. It is needed to comply with OptimismPortal2 requirement to have a DisputeGameFactory. Whenever a new game is created, an SP1 proof is immediately verified, so in fact there is no optimistic dispute game happening.

	contract AnchorStateRegistry (eth:0xDeF9B23dAE7769004e80f579f9d3aF0D7a29E4aD) {
	+++ description: Contains the latest confirmed state root that can be used as a starting point in a dispute game. It specifies which game type can be used for withdrawals, which currently is the 6.
	description:
-	"Contains the latest confirmed state root that can be used as a starting point in a dispute game. It specifies which game type can be used for withdrawals, which currently is the PermissionedDisputeGame."
+	"Contains the latest confirmed state root that can be used as a starting point in a dispute game. It specifies which game type can be used for withdrawals, which currently is the 6."
	values.RespectedGameString:
-	"PermissionedDisputeGame"
+	6
	+++ severity: HIGH
	values.respectedGameType:
-	1
+	6
	}

+	Status: CREATED
	contract OPSuccinctDisputeGame (eth:0x2c2dA5EFfAbDA3a9ffe8e3D526C5b1F3B42FEa6D)
	+++ description: A dispute game wrapper around OPSuccinctL2OutputOracle. It is needed to comply with OptimismPortal2 requirement to have a DisputeGameFactory. Whenever a new game is created, an SP1 proof is immediately verified, so in fact there is no optimistic dispute game happening.

2026 January 27, 16:55 UTC

High severity

17changes

Phala switched from ZK validity proofs to optimistic fault proofs. respectedGameType changed from 6 (OPSuccinctDisputeGame) to 1 (PermissionedDisputeGame) via setRespectedGameType(1) . New state proposals now use PermissionedDisputeGame instead of OPSuccinct ZK proofs. OPSuccinctL2OutputOracle is now idle (last ZK proposal was game 276). Both game implementations remain registered in DisputeGameFactory. Also added new member to Conduit Multisig 1 (now 4 of 13).

Phala switched from ZK validity proofs to optimistic fault proofs. respectedGameType changed from 6 (OPSuccinctDisputeGame) to 1 (PermissionedDisputeGame) via setRespectedGameType(1). New state proposals now use PermissionedDisputeGame instead of OPSuccinct ZK proofs. OPSuccinctL2OutputOracle is now idle (last ZK proposal was game #276). Both game implementations remain registered in DisputeGameFactory.

Also added new member to Conduit Multisig 1 (now 4 of 13).

	contract DisputeGameFactory (eth:0x2157F4d5934c4b12193C4983E99b9D6418798a2E) {
	+++ description: The dispute game factory allows the creation of dispute games, used to propose state roots and eventually challenge them.
	values.permissionedGamesTotal:
-	0
+	3
	}

	contract Conduit Multisig 1 (eth:0x4a4962275DF8C60a80d3a25faEc5AA7De116A746) {
	+++ description: None
	values.$members.0:
+	"eth:0xA9FCCc53F1c9095DA867Bd648683F8bdCcc78d09"
	values.multisigThreshold:
-	"4 of 12 (33%)"
+	"4 of 13 (31%)"
	}

	contract OptimismPortal2 (eth:0x96B124841Eff4Ab1b3C1F654D60402a1405fF51A) {
	+++ description: The OptimismPortal contract is the main entry point to deposit funds from L1 to L2. It also allows to prove and finalize withdrawals. It specifies which game type can be used for withdrawals, which currently is the PermissionedDisputeGame.
	description:
-	"The OptimismPortal contract is the main entry point to deposit funds from L1 to L2. It also allows to prove and finalize withdrawals. It specifies which game type can be used for withdrawals, which currently is the 6."
+	"The OptimismPortal contract is the main entry point to deposit funds from L1 to L2. It also allows to prove and finalize withdrawals. It specifies which game type can be used for withdrawals, which currently is the PermissionedDisputeGame."
	values.RespectedGameString:
-	6
+	"PermissionedDisputeGame"
	+++ severity: HIGH
	values.respectedGameType:
-	6
+	1
	}

	contract AnchorStateRegistry (eth:0xDeF9B23dAE7769004e80f579f9d3aF0D7a29E4aD) {
	+++ description: Contains the latest confirmed state root that can be used as a starting point in a dispute game. It specifies which game type can be used for withdrawals, which currently is the PermissionedDisputeGame.
	description:
-	"Contains the latest confirmed state root that can be used as a starting point in a dispute game. It specifies which game type can be used for withdrawals, which currently is the 6."
+	"Contains the latest confirmed state root that can be used as a starting point in a dispute game. It specifies which game type can be used for withdrawals, which currently is the PermissionedDisputeGame."
	values.RespectedGameString:
-	6
+	"PermissionedDisputeGame"
	+++ severity: HIGH
	values.respectedGameType:
-	6
+	1
	}

Operator

The system has a centralized operator

The operator is the only entity that can propose blocks. A live and trustworthy operator is vital to the health of the system.

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

Users can force any transaction

Because the state of the system is based on transactions submitted on the underlying host chain and anyone can submit their transactions there it allows the users to circumvent censorship by interacting with the smart contract on the host chain directly.

Withdrawals

Regular exits

The user initiates the withdrawal by submitting a regular transaction on this chain. When a state root containing such transaction is settled, the funds become available for withdrawal on L1 after 3d 12h. Withdrawal inclusion can be proven before state root settlement, but a 7d period has to pass before it becomes actionable. The process of state root settlement takes a challenge period of at least 3d 12h to complete. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.

Forced messaging

If the user experiences censorship from the operator with regular L2->L1 messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages, including forced withdrawals from L1 and regular messages initiated on L2. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.

Forced withdrawal from an OP Stack blockchain

Other considerations

EVM compatible smart contracts are supported

OP stack chains are pursuing the EVM Equivalence model. No changes to smart contracts are required regardless of the language they are written in, i.e. anything deployed on L1 can be deployed on L2.

Introducing EVM Equivalence

Permissions

A dashboard to explore contracts and permissions

Go to Disco

Explore in Disco

Ethereum

Roles:

ChallengerConduit Multisig 1

Allowed to challenge or delete state roots proposed by a Proposer.

Used in:

GuardianConduit Multisig 1

Allowed to pause withdrawals. In op stack systems with a proof system, the Guardian can also blacklist dispute games and set the respected game type (permissioned / permissionless).

Used in:

ProposerEOA 2

Allowed to post new state roots of the current layer to the host chain.

SequencerEOA 1

Allowed to commit transactions from the current layer to the host chain.

Actors:

Conduit Multisig 10x4a49…A746

A Multisig with 4/12 threshold.

Can upgrade with no delay
- SuperchainConfig ProxyAdmin
- L1CrossDomainMessenger ProxyAdmin
- DisputeGameFactory ProxyAdmin
- L1StandardBridge ProxyAdmin
- OptimismPortal2 ProxyAdmin
- L1ERC721Bridge ProxyAdmin
- OPSuccinctL2OutputOracle ProxyAdmin
- DelayedWETH ProxyAdmin
- AnchorStateRegistry ProxyAdmin
- SystemConfig ProxyAdmin
- OptimismMintableERC20Factory ProxyAdmin
Can interact with AddressManager
- set and change address mappings ProxyAdmin
Can interact with OPSuccinctL2OutputOracle
- can toggle between the optimistic mode and not optimistic (ZK) mode
Can interact with SystemConfig
- it can update the preconfer address, the batch submitter (Sequencer) address and the gas configuration of the system
A Challenger - acting directly
A Guardian - acting directly

Participants (12):

0xcdC9…4853 0xA9FC…8d09 0x6BB4…83A6 0x2103…911c 0x65D1…6007 0x8117…E7Ac 0xA073…bda2 0xF331…647D 0xa400…e6e4 0xa0C6…9038 0xefCf…dD5C 0x4D80…5BAe

Used in:

SP1VerifierGatewayMultisig0xCafE…6878

A Multisig with 2/3 threshold.

Can interact with SP1VerifierGateway
- affect the liveness and safety of the gateway - can transfer ownership, add and freeze verifier routes

Participants (3):

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

Used in:

EOA 10x9Fb2…C761

A Sequencer - acting directly

EOA 20xF579…f8F2

A Proposer - acting directly

Arbitrum One

Actors:

SP1VerifierGatewayMultisig0xCafE…6878

A Multisig with 2/3 threshold.

Can interact with SP1VerifierGatewayArb
- affect the liveness and safety of the gateway - can transfer ownership, add and freeze verifier routes

Participants (3):

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

Used in:

Base Chain

Actors:

SP1VerifierGatewayMultisig0xCafE…6878

A Multisig with 2/3 threshold.

Can interact with SP1VerifierGatewayBase
- affect the liveness and safety of the gateway - can transfer ownership, add and freeze verifier routes

Participants (3):

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

Used in:

Smart contracts

A dashboard to explore contracts and permissions

Go to Disco

Explore in Disco

A diagram of the smart contract architecture

Ethereum

DisputeGameFactory0x2157…8a2E Implementation (Upgradable)Admin

The dispute game factory allows the creation of dispute games, used to propose state roots and eventually challenge them.

Roles:
- admin: ProxyAdmin; ultimately Conduit Multisig 1

Can be upgraded by:

Conduit Multisig 1 with no delay

Implementation used in:

OptimismPortal2

Escrow

0x96B1…F51A Implementation (Upgradable)Admin

The OptimismPortal contract is the main entry point to deposit funds from L1 to L2. It also allows to prove and finalize withdrawals. It specifies which game type can be used for withdrawals, which currently is the PermissionedDisputeGame.

Roles:
- admin: ProxyAdmin; ultimately Conduit Multisig 1

The following tokens are included in the value secured calculation:

Can be upgraded by:

Conduit Multisig 1 with no delay

Implementation used in:

SystemConfig0xeBf5…2571 Implementation (Upgradable)Admin

Contains configuration parameters such as the Sequencer address, gas limit on this chain and the unsafe block signer address.

Roles:
- admin: ProxyAdmin; ultimately Conduit Multisig 1
- batcherHash: EOA 1
- owner: Conduit Multisig 1

Can be upgraded by:

Conduit Multisig 1 with no delay

Implementation used in:

SuperchainConfig0x097f…53cC Implementation (Upgradable)Admin

This is NOT the shared SuperchainConfig contract of the OP stack Superchain but rather a local fork. It manages pause states for each chain connected to it, as well as a global pause state for all chains. The guardian role can pause either separately, but each pause expires after 3mo 1d if left untouched.

Roles:
- admin: ProxyAdmin; ultimately Conduit Multisig 1
- guardian: Conduit Multisig 1

Can be upgraded by:

Conduit Multisig 1 with no delay

Proxy used in:

Implementation used in:

L1CrossDomainMessenger0x1549…1544 Implementation (Upgradable)Admin

Sends messages from host chain to this chain, and relays messages back onto host chain. In the event that a message sent from host chain to this chain is rejected for exceeding this chain’s epoch gas limit, it can be resubmitted via this contract’s replay function.

Roles:
- admin: ProxyAdmin; ultimately Conduit Multisig 1

Can be upgraded by:

Conduit Multisig 1 with no delay

Implementation used in:

L1StandardBridge

Escrow

0x6A34…1521 Implementation (Upgradable)Admin

The main entry point to deposit ERC20 tokens from host chain to this chain.

Roles:
- admin: ProxyAdmin; ultimately Conduit Multisig 1

All supported tokens in this escrow are included in the value secured calculation.

Can be upgraded by:

Conduit Multisig 1 with no delay

Implementation used in:

L1ERC721Bridge0xa010…36AF Implementation (Upgradable)Admin

Used to bridge ERC-721 tokens from host chain to this chain.

Roles:
- admin: ProxyAdmin; ultimately Conduit Multisig 1

Can be upgraded by:

Conduit Multisig 1 with no delay

Implementation used in:

ProxyAdmin0x198A…Ab2E

Roles:
- owner: Conduit Multisig 1

PreimageOracle0x1fb8…aDD3

The PreimageOracle contract is used to load the required data from L1 for a dispute game.

Implementation used in:

OPSuccinctDisputeGame0x2c2d…Ea6D

A dispute game wrapper around OPSuccinctL2OutputOracle. It is needed to comply with OptimismPortal2 requirement to have a DisputeGameFactory. Whenever a new game is created, an SP1 proof is immediately verified, so in fact there is no optimistic dispute game happening.

PermissionedDisputeGame0x46e0…c824

Same as FaultDisputeGame, but only two permissioned addresses are designated as proposer and challenger.

Roles:
- challenger: Conduit Multisig 1
- proposer: EOA 2

MIPS0x6463…B908

The MIPS contract is used to execute the final step of the dispute game which objectively determines the winner of the dispute.

Implementation used in:

OPSuccinctL2OutputOracle0xb454…55d8 Implementation (Upgradable)Admin

Contains a list of proposed state roots which Proposers assert to be a result of block execution. The SuccinctL2OutputOracle modifies the L2OutputOracle to support whenNotOptimistic mode, in which a validity proof can be passed as input argument to the proposeL2Output function.

Roles:
- admin: ProxyAdmin; ultimately Conduit Multisig 1
- owner: Conduit Multisig 1
- proposer: EOA 2

Can be upgraded by:

Conduit Multisig 1 with no delay

ProxyAdmin0xb489…d0b5

Roles:
- owner: Conduit Multisig 1

Implementation used in:

DelayedWETH0xC89A…E166 Implementation (Upgradable)Admin

Contract designed to hold the bonded ETH for each game. It is designed as a wrapper around WETH to allow an owner to function as a backstop if a game would incorrectly distribute funds.

Roles:
- admin: ProxyAdmin; ultimately Conduit Multisig 1

Can be upgraded by:

Conduit Multisig 1 with no delay

Implementation used in:

AnchorStateRegistry0xDeF9…E4aD Implementation (Upgradable)Admin

Contains the latest confirmed state root that can be used as a starting point in a dispute game. It specifies which game type can be used for withdrawals, which currently is the PermissionedDisputeGame.

Roles:
- admin: ProxyAdmin; ultimately Conduit Multisig 1

Can be upgraded by:

Conduit Multisig 1 with no delay

Implementation used in:

OptimismMintableERC20Factory0xF8e8…515e Implementation (Upgradable)Admin

A helper contract that generates OptimismMintableERC20 contracts on the network it’s deployed to. OptimismMintableERC20 is a standard extension of the base ERC20 token contract designed to allow the L1StandardBridge contracts to mint and burn tokens. This makes it possible to use an OptimismMintableERC20 as this chain’s representation of a token on the host chain, or vice-versa.

Roles:
- admin: ProxyAdmin; ultimately Conduit Multisig 1

Can be upgraded by:

Conduit Multisig 1 with no delay

Implementation used in:

SP1Verifier0x0459…C459

Verifier contract for SP1 proofs (v5.0.0).

Implementation used in:

SP1VerifierGateway0x3B60…185e

This contract is the router for zk proof verification. It stores the mapping between identifiers and the address of onchain verifier contracts, routing each identifier to the corresponding verifier contract.