Search

Search for projects by name or address

ApeX Omni logo
ApeX Omni

Badges

About

ApeX Omni is an application-specific ZK rollup for order book trading. It uses zkLink X to aggregate liquidity deposited across multiple chains.


  • Total Value SecuredTVS
    $28.35 M5.03%
  • Past day UOPSDaily UOPS
    No data
  • Type
    Other
  • Purpose
    Exchange

  • Host chain
    Arbitrum One

  • Tokens breakdown

    Sequencer failureState validationData availabilityExit windowProposer failure

    Badges

    About

    ApeX Omni is an application-specific ZK rollup for order book trading. It uses zkLink X to aggregate liquidity deposited across multiple chains.

    Why is the project listed in others?

    The proof system isn't fully functional

    ApeX's proof system does not authenticate deposits on external chains. Users must additionally trust the 2/2 validator set and LayerZero bridge not to forge non-existent deposits, which allows draining rollup escrows.

    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.


    Total
    Canonically BridgedCanonically Bridged ValueCanonical
    Natively MintedNatively Minted TokensNative
    Externally BridgedExternally Bridged ValueExternal

    ETH & derivatives
    Stablecoins
    BTC & derivatives
    Other
    Compare with other projects

    ApeX Pro sunset

    2025 Feb 27th

    ApeX Pro StarkEx chain is discontinuied in favor of zkLink X stack chain.

    Learn more

    ApeX Omni launched on zkLink X

    2024 Jun 10th

    A launch of ApeX Omni chain build on zkLink X stack is announced.

    Learn more

    ApeX Omni is an application-specific ZK 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. for order book trading. It uses zkLink X to aggregate liquidity deposited across multiple chains.

    ApeX Omni is a non-EVM L3Intuitively, L3s are projects that follow a similar structure to the L2 <> L1 structure but with an L2 underneath. It's not entirely defined yet if this implies that the token escrow must be on the L2, or the proof system. Also, certain cases like projects using aggregation layers make the distinction between L2 and L3 fuzzy as certain components start to look less like a traditional blockchain. How to properly define what is a layer in the first place is still an open question. on Arbitrum One. Its primary zkLink deployment verifies state transition proofs and publishes state differences on Arbitrum, while secondary deployments escrow assets deposited on other chains and synchronize their local state with the primary deployment through LayerZero.

    The L3 risks depend on the individual properties of L3 and those of the host chain combined.
    SEQUENCER
    FAILURE
    STATE
    VALIDATION
    DATA
    AVAILABILITY
    EXIT WINDOWPROPOSER
    FAILURE
    Arbitrum One
    L2
    Self sequenceFraud proofs (INT)OnchainNoneSelf propose
    ApeX Omni
    L3 • Individual
    No mechanismValidity proofs (SN)Onchain (SD)NoneCannot withdraw
    ApeX Omni
    L3 • Combined
    No mechanismValidity proofsOnchainNoneCannot withdraw
    L2 & L3 individual risks
    Sequencer failureState validationData availabilityExit windowProposer failure
    L3 combined risks
    Sequencer failureState validationData availabilityExit windowProposer failure

    L3 combined risks
    The information below reflects combined L2 & L3 risks.
    Sequencer failure
    No mechanism

    There is no mechanism to have transactions be included if the 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. is down or censoring.

    State validation
    Validity proofs

    Zero knowledge cryptography is used to ensure state correctness. Proofs are first verified on Arbitrum One and finally on Ethereum.

    Data availability
    Onchain

    All of the data needed for proof construction is published on the base chain, which ultimately gets published on Ethereum.

    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.

    ApeX Omni
    ApeX Omni is not even a
    Stage 0
    Appchain
    project.
    There is no available nodeA software client that participates in the network. software that can reconstruct the state from 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. data, hence there is no way to verify that this system is a 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..

    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.

    State differences are published on Arbitrum One

    The data needed to reconstruct the ApeX state is included in commitBlocks calldata on Arbitrum One. Secondary deployments additionally commit their local onchain operations and send synchronization hashes to the primary deployment.

    1. See CommitBlockInfo in commitBlock function on ZkLink.sol
    Learn more about the DA layer here: Arbitrum One logoArbitrum One
    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 Arbitrum One by a smart contract. Deposits on secondary chains are not verified with these validity proofs and rely on LayerZero bridges instead. Deposits could be stolen if bridges are compromized.

    1. Function proveBlocks on ZkLinkPeriphery.sol calls verifier.verifyAggregatedBlockProof

    Trusted Setups

    Onchain verifier

    Used in

    ApeX Omni logo

    Onchain verifier

    Used in

    ApeX Omni logo
    2026 July 22, 10:24 UTC
    27changes

    Completely new discovery of ApeX project (ApeX Omni instead of older ApeX Pro). Now it is a zkLink X cross-chain deployment with settlement on Arbitrum One (as L3) and deposits on several other chains.

    contract GnosisSafe (eth:0x374632e7D48B7872d904524FdC5Dd4516F42cDFF) [GnosisSafe] {
    +++ description: None
    values.$members.5:
    - "eth:0x824C9364A6CF8f5EB542ad2ca8F5705561C8b1db"
    + "eth:0x522b8Df4c9965934654CFebbf20882005c33cE18"
    }

    New and verified contracts

    + Status: CREATED
    contract Verifier (arb1:0x235118AfB54B6d6c7b48F1B5434c25CD6Eb6B68F) [N/A]
    +++ description: PLONK verifier used to validate aggregated L2 block proofs and zero-knowledge exit proofs.
    + Status: CREATED
    contract UpgradeGatekeeper (arb1:0x2e8AD1434663b209EE59eF1a6612114239F4a190) [N/A]
    +++ description: Controls upgrades to managed contracts. The master can schedule, cancel, and complete upgrades after the main contract's notice period.
    + Status: CREATED
    contract ZkLink Main (arb1:0x3169844a120C0f517B4eB4A750c08d8518C8466a) [apex-omni/ZkLink_main]
    +++ description: The main rollup contract. It processes L3 blocks submitted by validators and settles L3 state, handles deposits and withdrawals, and synchronizes block data with other zkLink chains.
    + Status: CREATED
    contract GnosisSafeL2 (arb1:0xba3852Ea9b72DE82AF343f7e3F09c86fdea912ED) [GnosisSafe]
    +++ description: None
    + Status: CREATED
    contract LayerZeroBridge (arb1:0xfC5c2b3E615cF12e86E6dA8eF6C76fAbae5F2B7D) [apex-omni/LZSyncHashBridge]
    +++ description: A LayerZero bridge that relays synchronization hashes and block confirmations between zkLink chains.
    + Status: CREATED
    contract EmptyVerifier (base:0x4c5629AEA0B419d26C780dD78d5671e2Ce27c563) [N/A]
    +++ description: None
    + Status: CREATED
    contract UpgradeGatekeeper (base:0x72343e8e448Fa539A1F118f870A1De1132f2fcaD) [N/A]
    +++ description: None
    + Status: CREATED
    contract GnosisSafeL2 (base:0xba3852Ea9b72DE82AF343f7e3F09c86fdea912ED) [GnosisSafe]
    +++ description: None
    + Status: CREATED
    contract LayerZeroBridge (base:0xeD5D1e1320720CAe8Bb40275550A7D307A082AC3) [apex-omni/LZSyncHashBridge]
    +++ description: A LayerZero bridge that relays synchronization hashes and block confirmations between zkLink chains.
    + Status: CREATED
    contract ZkLink Base (base:0xeE7981C4642dE8d19AeD11dA3bac59277DfD59D7) [apex-omni/ZkLink_LZEscrow]
    +++ description: A secondary cross-chain ZkLink rollup contract. It only escrows user deposits, and synchronizes deposit data with the main zkLink chain.
    + Status: CREATED
    contract EmptyVerifier (bnb:0x1202e0557A23531D09015C802e993d6423685FfB) [N/A]
    +++ description: None
    + Status: CREATED
    contract UpgradeGatekeeper (bnb:0x81DEE5B8BfFa75Cc1ec729533EeD30CfE4F81F8C) [N/A]
    +++ description: None
    + Status: CREATED
    contract ZkLink BNB (bnb:0xb8D9F005654b7b127b34dae8F973Ba729ca3A2D9) [apex-omni/ZkLink_LZEscrow]
    +++ description: A secondary cross-chain ZkLink rollup contract. It only escrows user deposits, and synchronizes deposit data with the main zkLink chain.
    + Status: CREATED
    contract GnosisSafeL2 (bnb:0xba3852Ea9b72DE82AF343f7e3F09c86fdea912ED) [GnosisSafe]
    +++ description: None
    + Status: CREATED
    contract LayerZeroBridge (bnb:0xc271a8e9eB2b10FCDe1709D76de6681249669D2e) [apex-omni/LZSyncHashBridge]
    +++ description: A LayerZero bridge that relays synchronization hashes and block confirmations between zkLink chains.
    + Status: CREATED
    contract ZkLink Ethereum (eth:0x35D173cdfE4d484BC5985fDa55FABad5892c7B82) [apex-omni/ZkLink_LZEscrow]
    +++ description: A secondary cross-chain ZkLink rollup contract. It only escrows user deposits, and synchronizes deposit data with the main zkLink chain.
    + Status: CREATED
    contract GnosisSafe (eth:0x374632e7D48B7872d904524FdC5Dd4516F42cDFF) [GnosisSafe]
    +++ description: None
    + Status: CREATED
    contract LayerZeroBridge (eth:0x3D70dc86dC8099D8a4c86C18839C7e84a13a441E) [apex-omni/LZSyncHashBridge]
    +++ description: A LayerZero bridge that relays synchronization hashes and block confirmations between zkLink chains.
    + Status: CREATED
    contract EmptyVerifier (eth:0xe38f8bc093a1f76f0A444bA6B75F46d6dC686dba) [N/A]
    +++ description: Placeholder verifier for chains without pairing support. It rejects all block and exit proofs.
    + Status: CREATED
    contract GnosisSafe (eth:0xF9f8794A2D9885C36D06aA25fc25a8cAda276B94) [GnosisSafe]
    +++ description: None
    + Status: CREATED
    contract UpgradeGatekeeper (eth:0xFBD68679271fDa6ca9bf6F20993Cd39E20072753) [N/A]
    +++ description: Controls upgrades to managed contracts. The master can schedule, cancel, and complete upgrades after the main contract's notice period.
    + Status: CREATED
    contract LayerZeroBridge (mantle:0x04C6a52f3bf9F73618cD70F234AdB95a73325D1e) [apex-omni/LZSyncHashBridge]
    +++ description: A LayerZero bridge that relays synchronization hashes and block confirmations between zkLink chains.
    + Status: CREATED
    contract EmptyVerifier (mantle:0x0c0F729c74c9AC41F9C702dAd11011F40D4190B0) [N/A]
    +++ description: None
    + Status: CREATED
    contract UpgradeGatekeeper (mantle:0x2B9BA259F24965a81Fa0c4E477e3791673744059) [N/A]
    +++ description: None
    + Status: CREATED
    contract ZkLink Mantle (mantle:0x3C7c0ebFCD5786ef48df5ed127cdDEb806db976c) [apex-omni/ZkLink_LZEscrow]
    +++ description: A secondary cross-chain ZkLink rollup contract. It only escrows user deposits, and synchronizes deposit data with the main zkLink chain.
    + Status: CREATED
    contract GnosisSafeL2 (mantle:0xba3852Ea9b72DE82AF343f7e3F09c86fdea912ED) [GnosisSafe]
    +++ description: None
    2025 July 22, 16:06 UTC
    1change

    project is archived.

    contract StarkPerpetualUSDC (0xA1D5443F2FB80A5A55ac804C948B45ce4C52DCbb) {
    +++ description: Central Validium contract. Receives (verified) state roots from the Operator, allows users to consume L2 -> L1 messages and send L1 -> L2 messages. Critical configuration values for the L2's logic are defined here by various governance roles.
    values.isFrozen:
    - false
    + true
    }
    2025 July 14, 12:44 UTC
    8changes

    Discovery rerun on the same block number with only config-related changes.

    New and verified contracts

    + Status: CREATED
    contract CommitteeUSDC (0x23Cab3CF1aa7B929Df5e9f3712aCA3A6Fb9494E4)
    +++ description: Data Availability Committee (DAC) contract verifying and storing data availability claims from DAC Members (via a multisignature check). The threshold of valid signatures is 3.
    + Status: CREATED
    contract FinalizableGpsFactAdapterUSDT (0x40e1e5Ece49A878062fA9F87eA6dc81281098B22)
    +++ description: Adapter between the core contract and the eth:0x47312450B3Ac8b5b8e247a6bB6d523e7605bDb60. Stores the Cairo programHash (`770346231394331402493200980986217737662224545740427952627288191358999988146`).
    + Status: CREATED
    contract CommitteeUSDT (0x7249082BfAFE9BCA502d38a686Ef3df37A0cf800)
    +++ description: Data Availability Committee (DAC) contract verifying and storing data availability claims from DAC Members (via a multisignature check). The threshold of valid signatures is 3.
    + Status: CREATED
    contract StarkPerpetualUSDC (0xA1D5443F2FB80A5A55ac804C948B45ce4C52DCbb)
    +++ description: Central Validium contract. Receives (verified) state roots from the Operator, allows users to consume L2 -> L1 messages and send L1 -> L2 messages. Critical configuration values for the L2's logic are defined here by various governance roles.
    + Status: CREATED
    contract PerpetualEscapeVerifier (0xaadFdB9CAc145c65f2284fBe24600d07fb37F7BD)
    +++ description: Special verifier for the escape() function.
    + Status: CREATED
    contract ApexAdminMultisig (0xC532d2976209A56DdF4a99B844130f7c0daCa7B6)
    +++ description: None
    + Status: CREATED
    contract StarkPerpetualUSDT (0xe53A6eD882Eb3f90cCe0390DDB04c876C5482E6b)
    +++ description: Central Validium contract. Receives (verified) state roots from the Operator, allows users to consume L2 -> L1 messages and send L1 -> L2 messages. Critical configuration values for the L2's logic are defined here by various governance roles.
    + Status: CREATED
    contract FinalizableGpsFactAdapterUSDC (0xE741e26573782ae3C0ea9EC710FA99Fcd27fB953)
    +++ description: Adapter between the core contract and the eth:0x47312450B3Ac8b5b8e247a6bB6d523e7605bDb60. Stores the Cairo programHash (`2530337539466159944237001094809327283009177793361359619481044346150483328860`).
    2025 July 09, 09:25 UTC
    2changes

    USDT StarkEx instance frozen, project archived. Apex Pro, the app on this StarkEx Validium, is EOL: https://www.apex.exchange/blog/detail/ApeX-Pro-Sunset-Delisting-Timeline-for-Trading-Pairs.

    contract PerpetualEscapeVerifier (0xaadFdB9CAc145c65f2284fBe24600d07fb37F7BD) {
    +++ description: Special verifier for the escape() function.
    values.hasRegisteredFact:
    - false
    + true
    }
    contract StarkPerpetualUSDT (0xe53A6eD882Eb3f90cCe0390DDB04c876C5482E6b) {
    +++ description: Central Validium contract. Receives (verified) state roots from the Operator, allows users to consume L2 -> L1 messages and send L1 -> L2 messages. Critical configuration values for the L2's logic are defined here by various governance roles.
    values.isFrozen:
    - false
    + true
    }
    2025 February 18, 09:12 UTC
    High severity
    14changes

    Minor upgrade to the StarkExchangeUSDC contract which is an implementation of StarkEx Perpetual. Two new asset IDs are added: - NON UNIQUE MINTABLE ASSET ID FLAG (ERC-1155) - MINTABLE ERC20 ASSET ID FLAG (ERC-20)

    contract StarkExchangeUSDC (0xA1D5443F2FB80A5A55ac804C948B45ce4C52DCbb) {
    +++ description: None
    sourceHashes.5:
    - "0x0c38b010717f86413abfb52412e5eb50b689b8d172e8c39ef81fc428fe5a1e52"
    + "0xe29824efd6d907d93d9b4b2b0737630ab974bce5e0017cb1459975c66a798280"
    sourceHashes.4:
    - "0xb8c0122f24ea2e559e908278def38aa80b6cd27b39b2d74402dbf5ba2585c7c5"
    + "0xdfa7b8bf4884e9f9933980cec5bcf744d2e522c291ed2a383c140cfb8c795f29"
    sourceHashes.3:
    - "0x473fc9765112e835124640cb91a4642354e09e94f92462929139d9ab5b6ddcf4"
    + "0xb5161e812087e15dd53a4c29ab296ade613b540445f7d1eb470de4f81a9c555c"
    sourceHashes.2:
    - "0x5ebd3f192c54b3d36f0d57e1cb14f418ae69a1694f7dc7d19d006883fc89e525"
    + "0xf6d00f2bc5db71a79b854049b38819f78c8fbbd98dcc2e4555f70946f6e58069"
    sourceHashes.1:
    - "0x758db67adde840068b01898c25f007a0d0549aaf9d431c2e0ae77ae4c2c56b33"
    + "0xc8c9c0e9c5171cb82b707e7e4b4ea80d427ba6f1dc21fc604efdce0ffa40323d"
    values.$implementation.4:
    - "0x34E7cfedF99995A47B3e3D0AB88ba67072B55035"
    + "0x31e2d974BaC547101413c24C23443AD488423f64"
    values.$implementation.3:
    - "0xdD5f42B087C1D2F73a2b443249b7D3DbE148a859"
    + "0x45de249eEa8f9CDB70943B17CceDeb42F5BA0175"
    values.$implementation.2:
    - "0x564EA75a26Dc0Bb5c5033B4752f88953A25AD058"
    + "0x1BC9C618B7FA6b5EfAAD31DC801eB55c608B9310"
    values.$implementation.1:
    - "0x533a7f4bE5453513049EB94A2b115F2CcE161dce"
    + "0x540Ad8576d2F90f28994ab001622F964945854A8"
    values.$implementation.0:
    - "0xdD813397b79f8df581eEb0c4B8aB72304c528396"
    + "0x8C43C9bec15d82D153C52518030e0a9590ABD35d"
    values.$pastUpgrades.4:
    + ["2025-02-17T09:39:23.000Z","0x7c6ca54630321bc1f0e2ad0b68972ec3f6efaab449f09839ef612f90d4292bdd",["0x8C43C9bec15d82D153C52518030e0a9590ABD35d","0x540Ad8576d2F90f28994ab001622F964945854A8","0x1BC9C618B7FA6b5EfAAD31DC801eB55c608B9310","0x45de249eEa8f9CDB70943B17CceDeb42F5BA0175","0x31e2d974BaC547101413c24C23443AD488423f64"]]
    values.$upgradeCount:
    - 4
    + 5
    values.implementation:
    - "0xdD813397b79f8df581eEb0c4B8aB72304c528396"
    + "0x8C43C9bec15d82D153C52518030e0a9590ABD35d"
    values.VERSION:
    - "3.1.0"
    + "3.2.0"
    }
    The section considers only the L3 properties. For more details please refer to Arbitrum One logoArbitrum One

    The system has a centralized operator

    A single permissioned validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier can commit and execute 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.. Proof submission is 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., but only blocks committed by the validator can be proven and executed.

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

    Users can't force any transaction

    There is no general mechanism to force the 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. to include transactions. Deposits create priority requests, but users cannot submit forced withdrawal requests. Although the contracts contain an exodus mode, the secondary deployments use EmptyVerifier contracts that reject all exit proofs, so this does not provide a system-wide escape hatchThe facility for any user of a rollup to exit the system with their assets under any circumstance. Most relevant in rollups with a centralized proposer, wherein users do not have the ability to propose blocks, but can nonetheless exit the rollup by interacting with a smart contract on L1..

    • Users can be censored if the operator refuses to include their transactions.

    The section considers only the L3 properties. For more details please refer to Arbitrum One logoArbitrum One

    Regular exit

    Users initiate withdrawals through regular ApeX transactions. After the 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. is proven, synchronized across the participating deployments, and executed, the user can claim funds from the zkLink escrow on the chain where the assets are held.

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

    Multichain state synchronization

    Deposits remain escrowed in the zkLink contract on their origin chain. Secondary deployments send synchronization hashes through LayerZero to the primary deployment on Arbitrum One. The primary deployment only synchronizes a 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. when the received hashes match the hashes committed as part of the primary block, and then sends block confirmations back to the secondary deployments.

    • Funds can be lost if the 2/2 validator set or LayerZero bridge forges a non-existent deposit.

    • Funds can be frozen if cross-chain synchronization messages are not delivered.

    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner

    Arbitrum One

    Actors:

    UpgradeGatekeeper0x2e8A…a190

    Controls upgrades to managed contracts. The master can schedule, cancel, and complete upgrades after the main contract’s notice period.

    • Can upgrade with no delay
      • VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover.
      • ZkLink Main
    • Can interact with ZkLink Main
      • transfer mastership
    GnosisSafeL20xba38…12ED

    A Multisig with 4/6 threshold.

    • Can interact with ZkLink Main
      • add tokens, pause and unpause token deposits
      • change the networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes. governor, validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier set, 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. gateway and cross-chain synchronization services
    • Can interact with ZkLink Main
      • commit, execute, and revert 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. 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., and send block confirmations to other zkLink chains

    Base Chain

    Actors:

    UpgradeGatekeeper0x7234…fcaD
    • Can upgrade with no delay
      • EmptyVerifier
      • ZkLink Base
    • Can interact with ZkLink Base
      • transfer mastership
    GnosisSafeL20xba38…12ED

    A Multisig with 4/6 threshold.

    • Can interact with ZkLink Base
      • add tokens, pause and unpause token deposits
      • change the networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes. governor, validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier set, 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. gateway and cross-chain synchronization services
    • Can interact with ZkLink Base
      • commit, execute, and revert 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. 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., and send block confirmations to other zkLink chains

    Binance Smart Chain

    Actors:

    UpgradeGatekeeper0x81DE…1F8C
    • Can upgrade with no delay
      • EmptyVerifier
      • ZkLink BNB
    • Can interact with ZkLink BNB
      • transfer mastership
    GnosisSafeL20xba38…12ED

    A Multisig with 4/6 threshold.

    • Can interact with ZkLink BNB
      • add tokens, pause and unpause token deposits
      • change the networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes. governor, validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier set, 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. gateway and cross-chain synchronization services
    • Can interact with ZkLink BNB
      • commit, execute, and revert 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. 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., and send block confirmations to other zkLink chains

    Ethereum

    Actors:

    GnosisSafe0xF9f8…6B94

    A Multisig with 4/6 threshold.

    • Can interact with ZkLink Ethereum
      • add tokens, pause and unpause token deposits
      • change the networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes. governor, validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier set, 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. gateway and cross-chain synchronization services
    UpgradeGatekeeper0xFBD6…2753

    Controls upgrades to managed contracts. The master can schedule, cancel, and complete upgrades after the main contract’s notice period.

    • Can upgrade with no delay
      • ZkLink Ethereum
      • EmptyVerifier
    • Can interact with ZkLink Ethereum
      • transfer mastership
    • Can interact with ZkLink Ethereum
      • commit, execute, and revert 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. 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., and send block confirmations to other zkLink chains

    Mantle

    Actors:

    UpgradeGatekeeper0x2B9B…4059
    • Can upgrade with no delay
      • EmptyVerifier
      • ZkLink Mantle
    • Can interact with ZkLink Mantle
      • transfer mastership
    GnosisSafeL20xba38…12ED

    A Multisig with 4/6 threshold.

    • Can interact with ZkLink Mantle
      • add tokens, pause and unpause token deposits
      • change the networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes. governor, validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier set, 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. gateway and cross-chain synchronization services
    • Can interact with ZkLink Mantle
      • commit, execute, and revert 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. 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., and send block confirmations to other zkLink chains
    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

    Arbitrum One

    PLONKA zk-SNARK proving system introduced by Gabizon, Williamson and Ciobotaru in 2019 that allows proving custom circuits. Plonk is based on KZG polynomial commitments and thus requires a universal trusted setup. verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. used to validate aggregated 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. proofs and zero-knowledgeA cryptographic technology and sub-discipline of cryptography that allows an individual to prove that a statement or computation is true without revealing any additional information. exit proofs.

    • Roles:
      • admin: UpgradeGatekeeper

    The main 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. contract. It processes L3Intuitively, L3s are projects that follow a similar structure to the L2 <> L1 structure but with an L2 underneath. It's not entirely defined yet if this implies that the token escrow must be on the L2, or the proof system. Also, certain cases like projects using aggregation layers make the distinction between L2 and L3 fuzzy as certain components start to look less like a traditional blockchain. How to properly define what is a layer in the first place is still an open question. 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. submitted by validatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier and settles L3 state, handles deposits and withdrawals, and synchronizes block data with other zkLink chains.

    • Roles:
      • getMaster: UpgradeGatekeeper
      • networkGovernor: GnosisSafeL2
      • validators: EOA 1

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

    LayerZeroBridge0xfC5c…2B7D

    A LayerZero 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. that relays synchronization hashes and 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. confirmations between zkLink chains.

    Base Chain

    • Roles:
      • admin: UpgradeGatekeeper
    LayerZeroBridge0xeD5D…2AC3

    A LayerZero 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. that relays synchronization hashes and 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. confirmations between zkLink chains.

    A secondary cross-chain ZkLink 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. contract. It only escrows user deposits, and synchronizes deposit data with the main zkLink chain.

    • Roles:
      • getMaster: UpgradeGatekeeper
      • networkGovernor: GnosisSafeL2
      • validatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier: EOA 2

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

    Binance Smart Chain

    • Roles:
      • admin: UpgradeGatekeeper

    A secondary cross-chain ZkLink 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. contract. It only escrows user deposits, and synchronizes deposit data with the main zkLink chain.

    • Roles:
      • getMaster: UpgradeGatekeeper
      • networkGovernor: GnosisSafeL2
      • validatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier: EOA 3

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

    LayerZeroBridge0xc271…9D2e

    A LayerZero 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. that relays synchronization hashes and 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. confirmations between zkLink chains.

    Ethereum

    A secondary cross-chain ZkLink 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. contract. It only escrows user deposits, and synchronizes deposit data with the main zkLink chain.

    • Roles:
      • getMaster: UpgradeGatekeeper
      • networkGovernor: GnosisSafe
      • validatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier: EOA 4

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

    LayerZeroBridge0x3D70…441E

    A LayerZero 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. that relays synchronization hashes and 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. confirmations between zkLink chains.

    Placeholder verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. for chains without pairing support. It rejects all 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. and exit proofs.

    • Roles:
      • admin: UpgradeGatekeeper

    Mantle

    LayerZeroBridge0x04C6…5D1e

    A LayerZero 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. that relays synchronization hashes and 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. confirmations between zkLink chains.

    • Roles:
      • admin: UpgradeGatekeeper

    A secondary cross-chain ZkLink 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. contract. It only escrows user deposits, and synchronizes deposit data with the main zkLink chain.

    • Roles:
      • getMaster: UpgradeGatekeeper
      • networkGovernor: GnosisSafeL2
      • validatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier: EOA 5

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

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