Search

Search for projects by name

Value SecuredActivityOnchain costsData postedLivenessMilestones & IncidentsRisk summaryRisk analysisRollup stageData availabilityState validationOperatorWithdrawalsOther considerationsPermissionsSmart contracts

Zircuit logo
Zircuit

Badges

About

Zircuit is a universal ZK Rollup. It is based on the Optimism Bedrock architecture, employing AI to identify and stop malicious transactions at the sequencer level.

  • Total Value SecuredTVS
    $35.75 M1.24%
  • Past day UOPSDaily UOPS
    0.585.00%
  • Stage
  • Gas token
    ETH
  • Type
    ZK Rollup
  • Purpose
    Universal
  • Chain ID
    48900

    • Tokens breakdown

    Value secured breakdown

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

    Badges

    About

    Zircuit is a universal ZK Rollup. It is based on the Optimism Bedrock architecture, employing AI to identify and stop malicious transactions at the sequencer level.

    Value SecuredView TVS breakdown
    Total
    Canonically BridgedCanonically Bridged ValueCanonical
    Natively MintedNatively Minted TokensNative
    Externally BridgedExternally Bridged ValueExternal
    ETH & derivatives
    Stablecoins
    BTC & derivatives
    Other
    View TVS breakdown
    Activity

    2024 Nov 28 — 2025 Nov 28

    Past Day UOPS
    0.58
    Past Day Ops count
    49.90 K
    Max. UOPS
    2.14
    2024 Nov 25
    Past day UOPS/TPS Ratio
    <1.01
    Onchain costs

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

    Data in this section may be temporarily out of date due to third-party provider issues. We're working to resolve this.

    2024 Nov 28 — 2025 Nov 28

    Total cost
    $293.80 K
    Avg cost per L2 UOP
    $0.036060
    Avg cost per day
    $816.12
    Data posted

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

    2024 Nov 28 — 2025 Nov 28

    Data posted
    7.50 GiB
    Avg size per day
    20.91 MiB
    Avg size per L2 UOP
    958.17 B
    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.

    Data in this section may be temporarily out of date due to third-party provider issues. We're working to resolve this.
    No ongoing anomalies detected
    Avg. tx data subs. interval
    Avg. proof subs. interval
    Avg. state updates interval
    Past 30 days anomalies
    No data
    Milestones & Incidents

    Proof system migrated to SP1

    2025 Aug 25th

    Zircuit deprecates its in-house proof system in favor of SP1.

    Learn more

    Escape mechanism

    2025 Aug 5th

    Zircuit introduces a custom escape mechanism.

    Learn more
    Risk summary

    Funds can be stolen if

    1. a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL),
    2. the validity proof cryptography is broken or implemented incorrectly.

    Funds can be frozen if

    1. the centralized validator goes down. Users cannot produce blocks themselves and exiting the system requires new block production (CRITICAL),
    2. the SP1VerifierGateway is unable to route proof verification to a valid verifier.

    Users can be censored if

    1. the operator explicitly censors their forced transaction, possible through a modification in the smart contracts.

    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
    No mechanism

    There is no mechanism to have transactions be included if the sequencer is down or censoring. The L2 code has been modified to allow the sequencer to explicitly censor selected L1->L2 transactions.

    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
    Use escape hatch

    Users are able to trustlessly exit by submitting a Merkle proof of funds after 1mo with no new state proposals have passed. The escape of ETH and ERC-20 balances is permissionless while the escape of DeFi contract balances is trusted.

    Rollup stage
    Zircuit
    Zircuit 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. Derivation: Batch submission - OP Mainnet specs
    2. BatchInbox - address
    3. OptimismPortal.sol - source code, depositTransaction function
    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.

    • Funds can be stolen if the validity proof cryptography is broken or implemented incorrectly.

    • Funds can be frozen if the SP1VerifierGateway is unable to route proof verification to a valid verifier.

    1. VerifierV3 (SP1VerifierGateway) - Etherscan source code
    PROVER
    SP1SP1

    Trusted Setups

    Used in

    Projects used in

    Search for projects used in

    Verifiers

    1by
    •
    1

    Used in

    Verifiers

    1

    Used in

    Projects used in

    Search for projects used in

    Verifiers

    1by
    •
    1

    Used in

    Verifiers

    1

    Program Hashes

    Name
    Hash
    Repository
    Verification
    Used in
    0x0050...2605
    		Code unknown
    None
    0x0441...e7a1
    		Code unknown
    None
    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. The L2 code has been modified to allow the sequencer to explicitly censor selected L1->L2 transactions.

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

    1. L1Block.sol - Sourcify explorer source code

    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.

    1. Sequencing Window - OP Mainnet Specs
    2. OptimismPortal.sol - source code, depositTransaction function
    Withdrawals

    Regular messaging

    The user initiates L2->L1 messages by submitting a regular transaction on this chain. When the block containing that transaction is settled, the message becomes available for processing on L1. The process of block finalization takes a challenge period of 4h to complete.

    • Funds can be frozen if the centralized validator goes down. Users cannot produce blocks themselves and exiting the system requires new block production (CRITICAL).

    1. OptimismPortal.sol - source code, proveWithdrawalTransaction function
    2. OptimismPortal.sol - source code, finalizeWithdrawalTransaction function
    3. L2OutputOracle.sol - source code, PROPOSER check

    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.

    • Users can be censored if the operator explicitly censors their forced transaction, possible through a modification in the smart contracts.

    1. Forced withdrawal from an OP Stack blockchain

    Escape mechanism

    Zircuit employs a custom escape mechanism that can help users exit the system in certain situations. If the operator disappears or is down for more than 1mo, users can submit a merkle proof to the L1 contracts to withdraw any ETH or ERC-20 balance they have on L2. L2 DeFi contracts and their deployers can manually distribute their pooled L2 balance using ‘Resolver’ contracts on L1 in case of an escape. In contrast to individual account escapes, the redistribution of these contract balances to users is permissioned.

    1. Etherscan - OptimismPortal - escapeEth() function
    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.

    1. Introducing EVM Equivalence
    Permissions
    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner
    Disco UI BannerExplore in Disco

    Ethereum

    Roles:

    Challenger Zircuit Multisig 1

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

    Guardian Zircuit Multisig 2

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

    Proposer EOA 2

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

    Sequencer EOA 1

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

    Actors:

    Zircuit Multisig 1 0xC463…AF38

    A Multisig with 6/8 threshold.

    • Can upgrade with no delay
      • OptimismPortal
      • L1CrossDomainMessenger
      • SystemConfig
      • L1StandardBridge
      • ResolverRegistry
      • ZircuitSuperchainConfig
      • L2OutputOracle
      • L1ERC721Bridge
      • OptimismMintableERC20Factory
    • Can interact with SystemConfig
      • it can update the preconfer address, the batch submitter (Sequencer) address and the gas configuration of the system
    • Can interact with SP1VerifierGateway
      • affect the liveness and safety of the gateway - can transfer ownership, add and freeze verifier routes
    • A Challenger - acting directly

    Participants (8):

    0xD839…0BD40xf5B2…c1ae0x63cb…a3550x5E2a…17d40x2F90…8Cec0x0D5e…0CAb0x62C6…85670x3880…8679
    Zircuit Multisig 2 0x2c0B…B276

    A Multisig with 2/5 threshold.

    • Can interact with ZircuitSuperchainConfig
      • manage roles including the guardian role
    • A Guardian - acting directly

    Participants (5):

    0x5E2a…17d40x63cb…a3550x62C6…85670x0D5e…0CAb0x3880…8679
    EOA 1 0xAF1E…F145
    EOA 2 0xE8C2…7C65

    Zircuit

    Actors:

    GnosisSafe 0xC463…AF38

    A Multisig with 6/8 threshold.

    • Can upgrade with no delay
      • L1Block
      • ProxyAdmin

    Participants (8):

    0xD839…0BD40xf5B2…c1ae0x63cb…a3550x5E2a…17d40x2F90…8Cec0x0D5e…0CAb0x62C6…85670x3880…8679
    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

    OptimismPortal 0x17bf…3fb1Implementation (Upgradable)Admin

    The main entry point to deposit funds from the host chain to this chain. It also allows to prove and finalize withdrawals. This fork of the standard OP stack contract allows for permissionless ‘escaping’ of assets with merkle proofs or a resolver if there were no state updates for a time defined by the L2OutputOracle.

    • Roles:
      • admin: ProxyAdmin; ultimately Zircuit Multisig 1
      • guardian: Zircuit Multisig 2
    • This contract stores the following tokens: ETH.
    Can be upgraded by:
    Zircuit Multisig 1 with no delay
    SystemConfig 0x30F8…28ffImplementation (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 Zircuit Multisig 1
      • batcherHash: EOA 1
      • owner: Zircuit Multisig 1
    Can be upgraded by:
    Zircuit Multisig 1 with no delay
    L2OutputOracle 0x92Ef…45A4Implementation (Upgradable)Admin

    Entrypoint for permissioned proposers to propose new L2 outputs (state roots). New proposals have to be accompanied by a zk-SNARK proof of a correct state transition. Users can ‘escape’ their funds after 1mo of no state updates by supplying merkle proofs or using a resolver.

    • Roles:
      • admin: ProxyAdmin; ultimately Zircuit Multisig 1
      • challenger: Zircuit Multisig 1
      • proposer: EOA 2
    Can be upgraded by:
    Zircuit Multisig 1 with no delay
    ZircuitSuperchainConfig 0x7453…3Da0Implementation (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 access control for configuring actors who can pause and unpause the system.

    • Roles:
      • admin: ProxyAdmin; ultimately Zircuit Multisig 1
      • defaultAdmin: Zircuit Multisig 2
    Can be upgraded by:
    Zircuit Multisig 1 with no delay
    L1CrossDomainMessenger 0x2a72…A091Implementation (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 Zircuit Multisig 1
    Can be upgraded by:
    Zircuit Multisig 1 with no delay
    L1StandardBridge 0x386B…6dd8Implementation (Upgradable)Admin

    The main entry point to deposit ERC20 tokens from the host chain to this chain. This fork of the standard OP stack contract allows for permissionless ‘escaping’ of assets with merkle proofs or a resolver if there were no state updates for a configurable time.

    • Roles:
      • admin: ProxyAdmin; ultimately Zircuit Multisig 1
    • This contract can store any token.
    Can be upgraded by:
    Zircuit Multisig 1 with no delay
    L1ERC721Bridge 0x994e…d244Implementation (Upgradable)Admin

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

    • Roles:
      • admin: ProxyAdmin; ultimately Zircuit Multisig 1
    Can be upgraded by:
    Zircuit Multisig 1 with no delay
    SP1Verifier 0x0459…C459

    Verifier contract for SP1 proofs (v5.0.0).

    Implementation used in:
    SP1Verifier 0x50AC…f1e5

    Verifier contract for SP1 proofs (v5.0.0).

    Implementation used in:
    ProxyAdmin 0x5B1E…5257
    • Roles:
      • owner: Zircuit Multisig 1
    ResolverRegistry 0x6c89…cF0EImplementation (Upgradable)Admin

    Registers ‘resolvers’ which are allowed to supply authoritative data for blockchain balances to support escapes without merkle proofs from e.g. DeFi smart contracts on L2. A resolver can either be registered directly by the respective contract on L2 or by its deployer from L1, using deterministic deployment derivation.

    • Roles:
      • admin: ProxyAdmin; ultimately Zircuit Multisig 1
    Can be upgraded by:
    Zircuit Multisig 1 with no delay
    L1ERC20TokenBridge 0x912C…6C79Implementation (Upgradable)Admin

    Escrow for custom external tokens that use the canonical bridge for messaging but are governed externally.

    • This contract stores the following tokens: wstETH.
    OptimismMintableERC20Factory 0xc77e…E932Implementation (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 Zircuit Multisig 1
    Can be upgraded by:
    Zircuit Multisig 1 with no delay
    SP1VerifierGateway 0xf35A…1f67

    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: Zircuit Multisig 1

    Zircuit

    L1Block 0x4200…0015Implementation (Upgradable)Admin

    Simple contract that returns information about the latest L1 block, which is derived permissionlessly from the L1 chain. This version though also contains a storage slot for depositExclusions.

    • Roles:
      • admin: ProxyAdmin; ultimately GnosisSafe
    Can be upgraded by:
    GnosisSafe with no delay
    ProxyAdmin 0x4200…0018Implementation (Upgradable)Admin
    • Roles:
      • admin: ProxyAdmin; ultimately GnosisSafe
      • owner: GnosisSafe
    Can be upgraded by:
    GnosisSafe with no delay

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

    Generic escrow 0x386B…6dd8Implementation (Upgradable)Admin

    Main entry point for users depositing ERC20 token that do not require custom gateway.

    Can be upgraded by:
    ProxyAdmin with no delay
    Escrow for wstETH 0x912C…6C79Implementation (Upgradable)Admin

    custom wstETH Vault controlled by Lido governance, using the canonical bridge for messaging.

    Escrow for ETH 0x17bf…3fb1Implementation (Upgradable)Admin

    Main entry point for users depositing ETH.

    Can be upgraded by:
    ProxyAdmin with no delay

    The current deployment carries some associated risks:

    • Funds can be stolen if a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).

    Program Hashes

    Name
    Hash
    Repository
    Verification
    Used in
    0x0050...2605
    		Code unknown
    None
    0x0441...e7a1
    		Code unknown
    None