Search

Search for projects by name

Zircuit logoZircuit

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
    $94.11 M5.01%
  • Past day UOPSDaily UOPS
    0.586.33%
  • Gas token
    ETH
  • Type
    Other

  • Purpose
    Universal
  • Chain ID
    48900

  • Tokens breakdown

    Value secured breakdown

    View TVS breakdown
    Sequencer failureState validationData availabilityExit windowProposer failure

    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.

    Why is the project listed in others?

    The proof system isn't fully functional

    Consequence: projects without a proper proof system fully rely on single entities to safely update the state. A malicious proposer can finalize an invalid state, which can cause loss of funds.

    Learn more about the recategorisation here.

    2024 Sep 07 — 2025 Sep 06


    Total
    $94.11 M5.01%
    Canonically BridgedCanonically Bridged ValueCanonical
    $67.61 M6.16%
    Natively MintedNatively Minted TokensNative
    $0.000.00%
    Externally BridgedExternally Bridged ValueExternal
    $26.49 M1.93%

    ETH & derivatives
    $40.79 M2.37%
    Stablecoins
    $1.00 M2.98%
    BTC & derivatives
    $382.44 K0.65%
    Other
    $51.92 M7.05%

    2024 Sep 06 — 2025 Sep 05

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


    2024 Sep 06 — 2025 Sep 05


    1 year total cost
    $475.83 K
    Avg cost per L2 UOP
    $0.099031
    Avg cost per day
    $1.30 K

    This section shows the amount of data the project has posted to the EthereumEthereum.


    2024 Sep 06 — 2025 Sep 05


    1 year data posted
    10.59 GiB
    Avg size per day
    29.64 MiB
    Avg size per L2 UOP
    2.31 KiB

    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 07 — Sep 06

    30D avg. tx data subs. interval
    15 minutes
    30D avg. proof subs. interval
    1 hour
    30D avg. state updates interval
    1 hour
    Past 30 days anomalies

    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
    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
    None

    Currently the system permits invalid state roots. More details in project overview.

    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 30d 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.

    ZircuitZircuit is not even a
    Stage 0
    project.
    The requirement for available node software is under review

    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.

    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
    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. Currently state updates do not require a proof if the last state update was made >= 4h ago and is optimistically considered to be valid.

    • Funds can be stolen if the published state is invalid and the Challenger does not react during the 4h finalization window.

    1. L2OutputOracle.sol - Etherscan source code - bootstrapL2Output() function
    2. VerifierV3 (SP1VerifierGateway) - Etherscan source code

    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

    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 30d, 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

    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
    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner

    Ethereum

    Roles:

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

    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 0xE8C2…7C65

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

    Sequencer 0xAF1E…F145

    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
      • VerifierV2
      • 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
    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

    Zircuit

    Actors:

    GnosisSafe 0xC463…AF38

    A Multisig with 6/8 threshold.

    • Can upgrade with no delay
      • L1Block
      • ProxyAdmin
    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner
    A diagram of the smart contract architecture
    A diagram of the smart contract architecture

    Ethereum

    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.

    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

    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, but there currently is a backdoor that lets this contract accept a state root without proof if the operator has not updated the state in 4h. Additionally, users can ‘escape’ their funds after 30d 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

    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
      • monitor: EOA 3

    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

    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.

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

    • Roles:
      • admin: ProxyAdmin; ultimately Zircuit Multisig 1
    SP1Verifier 0x50AC…f1e5

    Verifier contract for SP1 proofs (v5.0.0).

    Implementation used in:
    ProxyAdmin 0x5B1E…5257
    • Roles:
      • owner: Zircuit Multisig 1

    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

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

    • This contract stores the following tokens: wstETH.

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

    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:
    • Roles:
      • admin: ProxyAdmin; ultimately GnosisSafe
      • owner: GnosisSafe
    Can be upgraded by:

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

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

    Can be upgraded by:

    Main entry point for users depositing ETH.

    Can be upgraded by:

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

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