Search

Search for projects by name

SummaryValue SecuredActivityOnchain costsLivenessMilestones & IncidentsRisk summaryRisk analysisRollup stageData availabilityState validationOperatorWithdrawalsPermissionsSmart contracts

Phala logoPhala

Badges

About

Phala is 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...

  • Total Value SecuredTVS
    $4.60 K5.49%
  • Past day UOPSDaily UOPS
    0.000.00%
  • Stage
  • Gas token
    ETH
  • Type
    ZK Rollup
  • Purpose
    Universal
  • Chain ID
    2035

    • Tokens breakdown

    Value secured breakdown

    View TVS breakdown
    Sequencer failureState validationData availabilityExit windowProposer failure
    Explore more in Discovery UI

    Badges

    About

    Phala is 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...

    Value SecuredView TVS breakdown

    2024 Dec 17 — 2025 Sep 17

    Total
    $4.60 K5.49%
    Canonically BridgedCanonically Bridged ValueCanonical
    $4.60 K5.49%
    Natively MintedNatively Minted TokensNative
    $0.000.00%
    Externally BridgedExternally Bridged ValueExternal
    $0.000.00%
    ETH & derivatives
    $4.60 K5.49%
    Stablecoins
    $0.000.00%
    BTC & derivatives
    $0.000.00%
    Other
    $0.110.00%
    View TVS breakdown
    Activity

    2024 Dec 16 — 2025 Sep 16

    Onchain costs

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

    2024 Dec 16 — 2025 Sep 16

    1 year total cost
    $30.86 K
    Avg cost per L2 UOP
    $45.121335
    Avg cost per day
    $112.63
    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

    2025 Aug 18 — Sep 17

    30D avg. tx data subs. interval
    1 hour
    30D avg. state updates interval
    14 hours
    Past 30 days anomalies
    Milestones & Incidents

    Plonky3 vulnerability patch

    2025 Jun 4th

    SP1 verifier is patched to fix critical vulnerability in Plonky3 proof system (SP1 dependency).

    Learn more

    Phala Network Launch

    2025 Jan 8th

    Phala Network is live on Ethereum mainnet.

    Learn more
    Risk summary

    Funds can be stolen if

    1. the contracts or their dependencies (e.g. SuccinctGateway) receive a malicious code upgrade. There is no delay on upgrades,
    2. in non-optimistic mode, the validity proof cryptography is broken or implemented incorrectly,
    3. optimistic mode is enabled and no challenger checks the published state,
    4. the proposer routes proof verification through a malicious or faulty verifier by specifying an unsafe route id.

    Funds can be frozen if

    1. the permissioned proposer fails to publish state roots to the L1,
    2. in non-optimistic mode, the SuccinctGateway is unable to route proof verification to a valid verifier.

    MEV can be extracted if

    1. 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
    Validity proofs (ST, SN)

    STARKs and SNARKs are zero knowledge proofs that ensure state correctness. STARKs proofs are wrapped in SNARKs proofs for efficiency. SNARKs require a trusted setup.

    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 regular 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.

    Rollup stage
    PhalaPhala is a
    Stage 0
    ZK Rollup.

    Learn more about Rollup stages
    Please keep in mind that these stages do not reflect rollup security, this is an opinionated assessment of rollup 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.

    1. BatchInbox - Etherscan address
    Learn more about the DA layer here: Ethereum logoEthereum
    State validation
    Validity proofs

    Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract. Through the SuccinctL2OutputOracle, the system also allows to switch to an optimistic mode, in which no proofs are required and a challenger can challenge the proposed output state root within the finalization period.

    • Funds can be stolen if in non-optimistic mode, the validity proof cryptography is broken or implemented incorrectly.

    • Funds can be stolen if optimistic mode is enabled and no challenger checks the published state.

    • Funds can be stolen if the proposer routes proof verification through a malicious or faulty verifier by specifying an unsafe route id.

    • Funds can be frozen if the permissioned proposer fails to publish state roots to the L1.

    • Funds can be frozen if in non-optimistic mode, the SuccinctGateway is unable to route proof verification to a valid verifier.

    1. Op-Succinct architecture
    Learn more about the proof system here: SP1 logoSP1
    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.

    1. SuccinctL2OutputOracle.sol - Etherscan source code, CHALLENGER address
    2. SuccinctL2OutputOracle.sol - Etherscan source code, PROPOSER address
    Withdrawals

    Regular exit

    The user initiates the withdrawal by submitting a regular transaction on this chain. When the block containing that transaction is settled the funds become available for withdrawal on L1. Once funds are added to the withdrawal queue, operator must ensure there is enough liquidity for withdrawals. If not, they need to reclaim tokens from Yield Providers.

    1. OptimismPortal.sol - Etherscan source code, proveWithdrawalTransaction function
    2. OptimismPortal.sol - Etherscan source code, finalizeWithdrawalTransaction function
    3. SuccinctL2OutputOracle.sol - Etherscan source code, PROPOSER check
    Permissions
    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner
    Disco UI BannerExplore in Disco

    Ethereum

    Roles:

    Guardian Conduit 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:
    Sequencer 0x9Fb2…C761

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

    Actors:

    Conduit Multisig 1 0x4a49…A746

    A Multisig with 4/11 threshold.

    • Can upgrade with no delay
      • SuperchainConfig
      • L1CrossDomainMessenger
      • DisputeGameFactory
      • L1StandardBridge
      • OptimismPortal2
      • L1ERC721Bridge
      • DelayedWETH
      • OPSuccinctL2OutputOracle
      • SystemConfig
      • AnchorStateRegistry
      • OptimismMintableERC20Factory
    • Can interact with AddressManager
      • set and change address mappings
    • Can interact with DelayedWETH
      • can pull funds from the contract in case of emergency
    • 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 Guardian - acting directly

    Participants (11):

    0xFe0a…e2d40x8117…E7Ac0x5093…66280xA073…bda20xF331…647D0xF0B7…A4f00xa400…e6e40x3840…Fd5f0xa0C6…90380xefCf…dD5C0x4D80…5BAe
    Used in:
    SP1VerifierGatewayMultisig 0xCafE…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…11260x72Ff…4f540x9395…8885
    Used in:

    Arbitrum One

    Actors:

    SP1VerifierGatewayMultisig 0xCafE…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…11260x72Ff…4f540x9395…8885
    Used in:

    Base Chain

    Actors:

    SP1VerifierGatewayMultisig 0xCafE…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…11260x72Ff…4f540x9395…8885
    Used in:
    Smart contracts
    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner
    Disco UI BannerExplore in Disco
    A diagram of the smart contract architecture
    A diagram of the smart contract architecture

    Ethereum

    DisputeGameFactory 0x2157…8a2EImplementation (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 0x96B1…F51AImplementation (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 6.

    • Roles:
      • admin: ProxyAdmin; ultimately Conduit Multisig 1
    • This contract stores the following tokens: ETH.
    Can be upgraded by:
    Conduit Multisig 1 with no delay
    SystemConfig 0xeBf5…2571Implementation (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:
    SuperchainConfig 0x097f…53cCImplementation (Upgradable)Admin

    This is NOT the shared SuperchainConfig contract of the OP stack Superchain but rather a local fork. It manages the PAUSED_SLOT, a boolean value indicating whether the local chain is paused, and GUARDIAN_SLOT, the address of the guardian which can pause and unpause the system.

    • 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:
    L1CrossDomainMessenger 0x1549…1544Implementation (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 0x6A34…1521Implementation (Upgradable)Admin

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

    • Roles:
      • admin: ProxyAdmin; ultimately Conduit Multisig 1
    • This contract can store any token.
    Can be upgraded by:
    Conduit Multisig 1 with no delay
    Implementation used in:
    L1ERC721Bridge 0xa010…36AFImplementation (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:
    PermissionedDisputeGame 0x06B5…9690

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

    ProxyAdmin 0x198A…Ab2E
    • Roles:
      • owner: Conduit Multisig 1
    PreimageOracle 0x1fb8…aDD3

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

    Implementation used in:
    DelayedWETH 0xa2ba…6EaAImplementation (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
      • owner: Conduit Multisig 1
    Can be upgraded by:
    Conduit Multisig 1 with no delay
    Implementation used in:
    OPSuccinctL2OutputOracle 0xb454…55d8Implementation (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
    Can be upgraded by:
    Conduit Multisig 1 with no delay
    OPSuccinctDisputeGame 0xb476…A470

    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.

    ProxyAdmin 0xb489…d0b5
    • Roles:
      • owner: Conduit Multisig 1
    Implementation used in:
    MIPS 0xF027…5Dc1

    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:
    AnchorStateRegistry 0xf463…0a5FImplementation (Upgradable)Admin

    Contains the latest confirmed state root that can be used as a starting point in a dispute game.

    • Roles:
      • admin: ProxyAdmin; ultimately Conduit Multisig 1
    Can be upgraded by:
    Conduit Multisig 1 with no delay
    Implementation used in:
    OptimismMintableERC20Factory 0xF8e8…515eImplementation (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:
    SP1Verifier 0x0459…C459

    Verifier contract for SP1 proofs (v5.0.0).

    Implementation used in:
    SP1VerifierGateway 0x3B60…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.

    • Roles:
      • owner: SP1VerifierGatewayMultisig
    Implementation used in:

    Arbitrum One

    SP1Verifier 0x0459…C459

    Verifier contract for SP1 proofs (v5.0.0).

    Implementation used in:
    SP1VerifierGateway 0x3B60…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.

    • Roles:
      • owner: SP1VerifierGatewayMultisig
    Implementation used in:

    Base Chain

    SP1Verifier 0x0459…C459

    Verifier contract for SP1 proofs (v5.0.0).

    Implementation used in:
    SP1VerifierGateway 0x3B60…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.

    • Roles:
      • owner: SP1VerifierGatewayMultisig
    Implementation used in:

    Value Secured is calculated based on these smart contracts and tokens:

    Generic escrow 0x6A34…1521Implementation (Upgradable)Admin
    Implementation used in:

    The current deployment carries some associated risks:

    • Funds can be stolen if the contracts or their dependencies (e.g. SuccinctGateway) receive a malicious code upgrade. There is no delay on upgrades.