Search for projects by name or address
ApeX Omni is an application-specific ZK rollup for order book trading. It uses zkLink X to aggregate liquidity deposited across multiple chains.
ApeX Omni is an application-specific ZK rollup for order book trading. It uses zkLink X to aggregate liquidity deposited across multiple chains.
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.
ApeX Pro sunset
2025 Feb 27th
ApeX Pro StarkEx chain is discontinuied in favor of zkLink X stack chain.
ApeX Omni launched on zkLink X
2024 Jun 10th
A launch of ApeX Omni chain build on zkLink X stack is announced.
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.
| SEQUENCER FAILURE | STATE VALIDATION | DATA AVAILABILITY | EXIT WINDOW | PROPOSER FAILURE | |
| Arbitrum One L2 | Self sequence | Fraud proofs (INT) | Onchain | None | Self propose |
| ApeX Omni L3 • Individual | No mechanism | Validity proofs (SN) | Onchain (SD) | None | Cannot withdraw |
| ApeX Omni L3 • Combined | No mechanism | Validity proofs | Onchain | None | Cannot withdraw |
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.
Zero knowledge cryptography is used to ensure state correctness. Proofs are first verified on Arbitrum One and finally on Ethereum.
All of the data needed for proof construction is published on the base chain, which ultimately gets published on Ethereum.
There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.
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.
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.
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.
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.
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" |
| } | |
| + | 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 | |
project is archived.
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 |
| } | |
Discovery rerun on the same block number with only config-related changes.
Discovery rerun on the same block number with only config-related changes.
| + | 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`). | |
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.
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 |
| } | |
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)
Minor upgrade to the StarkExchangeUSDC contract which is an implementation of StarkEx Perpetual.
Two new asset IDs are added:
| 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" |
| } | |
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.
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.
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).
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.

Controls upgrades to managed contracts. The master can schedule, cancel, and complete upgrades after the main contract’s notice period.
A Multisig with 4/6 threshold.
A Multisig with 4/6 threshold.
A Multisig with 4/6 threshold.
A Multisig with 4/6 threshold.
Controls upgrades to managed contracts. The master can schedule, cancel, and complete upgrades after the main contract’s notice period.
A Multisig with 4/7 threshold.
A Multisig with 4/6 threshold.


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.
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.
All supported tokens in this escrow are included in the value secured calculation.
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 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.
All supported tokens in this escrow are included in the value secured calculation.
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.
All supported tokens in this escrow are included in the value secured calculation.
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.
All supported tokens in this escrow are included in the value secured calculation.
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.
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.
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).