Search for projects by name or address
Critical contracts can be upgraded by an EOA which could result in the loss of all funds.
zkLink Nova is a Layer 3 zkEVM Validium network leveraging ZK Stack that allows for scattered assets across Ethereum Layer 2s to be aggregated for interoperable trade and transactions.
zkLink Nova is a Layer 3 zkEVM Validium network leveraging ZK Stack that allows for scattered assets across Ethereum Layer 2s to be aggregated for interoperable trade and transactions.
Consequence: projects without a data availability bridge fully rely on single entities (the sequencer) to honestly rely available data roots on Ethereum. A malicious sequencer can collude with the proposer to finalize an unavailable state, which can cause loss of funds.
Learn more about the recategorisation here.
| SEQUENCER FAILURE | STATE VALIDATION | DATA AVAILABILITY | EXIT WINDOW | PROPOSER FAILURE | |
| Linea L2 | No mechanism | Validity proofs (SN) | Onchain | None | Cannot withdraw |
| zkLink Nova L3 • Individual | Enqueue via L2 | Validity proofs (ST, SN) | External | None | Cannot withdraw |
| zkLink Nova L3 • Combined | No mechanism | Validity proofs | External | 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 Linea and finally on Ethereum.
Proof construction and state derivation rely fully on data that is ultimately NOT 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 transaction data is not recorded on the Ethereum main chain.
Funds can be lost if the external data becomes unavailable (CRITICAL).
The metrics include upgrades on the currently used proxy contracts. Historical proxy contracts and changes of such are not included.
Include deployer address
Include deployer address
| contract EraL1ERC20Bridge (zksync:0xaB3DDB86072a35d74beD49AA0f9210098ebf2D08) { | |
| +++ description: None | |
| unverified: | |
| - | true |
| values.l2Bridge: | |
| + | "zksync:0x7187DB8AB8F65450a74dD40474bE778CF468C44a" |
| values.l2TokenBeacon: | |
| + | "zksync:0x2140d3e4008592E1a6c106ACCfc24335A49AeC8C" |
| values.l2TokenProxyBytecodeHash: | |
| + | "0x010001211b0c33353cdf7a320f768e3dc40bce1326d639fcac099bba9ecd8e34" |
| implementationNames.zksync:0xdBA32e62e929a7e2Fa65782F812416CA65208E40: | |
| - | "" |
| + | "L1ERC20Bridge" |
| sourceHashes: | |
| + | ["0x993403059c5620e6c91110514f9f4a2f2331c55dab587699c67c19edddab92ad","0xcabc91ee17e9a771bb999a95f4705966cf206325fc82ac15d440c8b6086f9679"] |
| } | |
| contract ErazkLink (zksync:0xaFe8C7Cf33eD0fee179DFF20ae174C660883273A) { | |
| +++ description: None | |
| unverified: | |
| - | true |
| values.feeParams: | |
| + | {"pubdataPricingMode":0,"batchOverheadL1Gas":1000000,"maxPubdataPerBatch":120000,"maxL2GasPerBatch":80000000,"priorityTxMaxPubdata":99000,"minimalL2GasPrice":250000000} |
| values.FORWARD_REQUEST_TYPE_HASH: | |
| + | "0xe0aaca1722ef50bb0c9b032e5b16ce2b79fa9f23638835456b27fd6894f8292c" |
| values.forwardFeeAllocator: | |
| + | "zksync:0x3334552599C9aA1FE08CfF276A02033FF37646ca" |
| values.gateway: | |
| + | "zksync:0xC203a2DF4DDFF9eDE2200F1F02054fD721182535" |
| values.getGateway: | |
| + | "zksync:0xC203a2DF4DDFF9eDE2200F1F02054fD721182535" |
| values.getGovernor: | |
| + | "zksync:0x3334552599C9aA1FE08CfF276A02033FF37646ca" |
| values.getPriorityTxMaxGasLimit: | |
| + | 72000000 |
| values.IS_ETH_GAS_TOKEN: | |
| + | true |
| values.owner: | |
| + | "zksync:0x3334552599C9aA1FE08CfF276A02033FF37646ca" |
| values.paused: | |
| + | false |
| values.txGasPrice: | |
| + | 40000000000 |
| implementationNames.zksync:0xC9bBbdCf1778A4aA86544F02CccBf09fd3A0706E: | |
| - | "" |
| + | "ZkLink" |
| template: | |
| + | "zklinknova/secondaryZkLink" |
| sourceHashes: | |
| + | ["0xc44a84c18fe7660acbe7750e0a14401b3a0a0ad97d8c81305bd879dca88d873b","0x9d3b6cf7c8756dc6cce424dc754ed146f84d3201e5223d47b0a4fcd994a76a7f"] |
| } | |
| + | Status: CREATED |
| contract EraL2Gateway (zksync:0xC203a2DF4DDFF9eDE2200F1F02054fD721182535) | |
| +++ description: None | |
mantaOwner verified as Safe.
mantaOwner verified as Safe.
| contract MantaOwner (0x6ed8745d9ad0EE1fEeB060d63c7cf78A7E4c2dE3) { | |
| +++ description: None | |
| unverified: | |
| - | true |
| values.domainSeparator: | |
| + | "0x18545ad9a8a62c02c41b6d1d5de3b7341bc049e1fd253978d8d7e6ec7faecfa1" |
| values.getChainId: | |
| + | 169 |
| values.VERSION: | |
| + | "1.3.0" |
| implementationNames.manta:0x6ed8745d9ad0EE1fEeB060d63c7cf78A7E4c2dE3: | |
| - | "" |
| + | "GnosisSafeProxy" |
| implementationNames.manta:0x3E5c63644E683549055b9Be8653de26E0B4CD36E: | |
| - | "" |
| + | "GnosisSafeL2" |
| template: | |
| + | "GnosisSafe" |
| sourceHashes: | |
| + | ["0x81a7349eebb98ac33b0bc6842e3cb258034a8f2a4ba004570bb8e2e25947f9ff","0x59fe14e95a8aa7f52213f18bae5c9329cf583a7ba31194698b15eddb97d5e825"] |
| } | |
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 LineaOwner (0x0Bff4B38792a95314b3463E1Bf9831BDa1995391) | |
| +++ description: None | |
| + | Status: CREATED |
| contract ValidatorTimelock (0x509ff56c152315EdeE91A2e0f059195519507e01) | |
| +++ description: None | |
| + | Status: CREATED |
| contract zkLink (0x5Cb18b6e4e6F3b46Ce646b0f4704D53724C5Df05) | |
| +++ description: None | |
| + | Status: CREATED |
| contract L1ERC20Bridge (0x62cE247f34dc316f93D3830e4Bf10959FCe630f8) | |
| +++ description: None | |
| + | Status: CREATED |
| contract LineaL2Gateway (0x7b5780d6df85A7dF96a3e1A019639a1dbDe937dB) | |
| +++ description: None | |
| + | Status: CREATED |
| contract Verifier (0x902C3806A84f4e855a8746e92d7F1C9a51400458) | |
| +++ description: None | |
| + | Status: CREATED |
| contract Governance (0xeF528a8Ca4B6aFDB6716Ef9f11bCa0c5C47454ec) | |
| +++ description: None | |
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 BaseL2Gateway (0x1054Ff8B3B7B9F68d2e55C4A42E8952332c69011) | |
| +++ description: None | |
| + | Status: CREATED |
| contract L1ERC20Bridge (0x80d12A78EfE7604F00ed07aB2f16F643301674D5) | |
| +++ description: None | |
| + | Status: CREATED |
| contract BaseProxyAdmin (0x85F0d9da054C5FE399E079Cc0b47de74be5b22AE) | |
| +++ description: None | |
| + | Status: CREATED |
| contract zkLink (0xE473ce141b1416Fe526eb63Cf7433b7B8d7264Dd) | |
| +++ description: None | |
| + | Status: CREATED |
| contract BaseOwner (0xEf1c84A2fdCE663b75dB3F822cBe1cFddaaa162C) | |
| +++ description: None | |
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 Arbitrator (0x1Ee09A2cAa0813A5183f90F5a6d0E4871f4C6002) | |
| +++ description: None | |
| + | Status: CREATED |
| contract ArbitrumL1Gateway (0x273D59aed2d793167c162E64b9162154B07583C0) | |
| +++ description: None | |
| + | Status: CREATED |
| contract EthereumProxyAdmin (0x315255c1bA35A1DdAc48CF054bc4e3a0929160b2) | |
| +++ description: None | |
| + | Status: CREATED |
| contract BlastL1Gateway (0x41FaF46Ca4Dfd912B65B66D29BdD432782BB1158) | |
| +++ description: None | |
| + | Status: CREATED |
| contract BaseL1Gateway (0x4eEA93966AA5cd658225E0D43b665A5a491d2b7E) | |
| +++ description: None | |
| + | Status: CREATED |
| contract zkLink (0x5fD9F73286b7E8683Bab45019C94553b93e015Cf) | |
| +++ description: None | |
| + | Status: CREATED |
| contract MantaL1Gateway (0x649Dfa2c4d09D877419fA1eDC4005BfbEF7CD82D) | |
| +++ description: None | |
| + | Status: CREATED |
| contract OptimismL1Gateway (0x668e8F67adB8219e1816C2E5bBEa055A78AF3026) | |
| +++ description: None | |
| + | Status: CREATED |
| contract LineaL1Gateway (0x803460416C2682Ac54FccF03eF77b10A12f2809b) | |
| +++ description: None | |
| + | Status: CREATED |
| contract EthereumL1Gateway (0x83Bc7394738A7A084081aF22EEC0051908c0055c) | |
| +++ description: None | |
| + | Status: CREATED |
| contract ScrollL1Gateway (0x986c905087a663db3C81ad319b94c1E9dd388e92) | |
| +++ description: None | |
| + | Status: CREATED |
| contract L1ERC20Bridge (0xAd16eDCF7DEB7e90096A259c81269d811544B6B6) | |
| +++ description: None | |
| + | Status: CREATED |
| contract EthereumOwner (0xdb4D755E3b8735314147b9bB146327C269701E2D) | |
| +++ description: None | |
| + | Status: CREATED |
| contract MantleL1Gateway (0xdE1Ce751405Fe6D836349226EEdCDFFE1C3BE269) | |
| +++ description: None | |
| + | Status: CREATED |
| contract EraL1Gateway (0xeCD189e0f390826E137496a4e4a23ACf76c942Ab) | |
| +++ description: None | |
The 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 are the only entities that can propose 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 process transactions. Moreover, they are trusted to only relay valid messages using the fast path. Fast path messages are eventually checked against the slow path, and if they are invalid, the system halts.
MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.
Funds can be lost if the operator relays invalid messages using the fast path (CRITICAL).
If a user is censored by 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. 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., they can try to force transaction via 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. queue. Right now there is no mechanism that forces L3 Sequencer to include transactions from L2 queue in an L3 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..
Users can be censored if the operator refuses to include their transactions.
The user initiates 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.->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. messages by submitting a regular transaction on this chain. When 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. containing that transaction is settled, the message becomes available for processing on L1. ZK proofs are required to settle blocks.
If the user experiences censorship from the operatorAn operator is the entity charged with managing a rollup and progressing its state. A rollup operator can be a centralized sequencer, proposer, prover, challenger, pauser of admin that is able to perform upgrades. with regular 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.->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. messaging they can submit their messages directly on L1. The system is then obliged to service this request or halt all messages from L1, including all forced withdrawals and deposits. Once the force operation is submitted and if the request is serviced, the operation follows the flow of a regular message.
zkLink allows users to 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. assets from multiple chains, not just the base chain Linea. To do this, messages are sent through the canonical bridges of each respective chain to the main zkLink contract on Linea. To withdraw, state updates are relayed back to each chain with the respective canonical bridges. Since deposits in this way are processed quite slowly, the system allows 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 to relay messages directly to the main zkLink contract in a trusted way. These messages are then checked against the slow path, and if they are invalid, the system eventually halts.
Funds can be lost if the canonical bridges of the secondary chains are compromised.

A Multisig with 5/8 threshold. Admin of the main zkLink contract, meaning it can upgrade the 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. implementation and potentially gain access to all funds.
Permissioned actors that can commit, prove 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.. It can also “fast” relay messages to zkLink Nova without going through the canonical bridges, meaning it can potentially relay invalid messages and mint tokens out of thin airAlgebraic intermediate representation (AIR) is a type of arithmetization commonly used in zkVMs. It represents a trace of zkVM state transitions with low degree polynomial constraints that enforce the correct relation between previous and current states of the computation. Several variations of AIR are used in practice, with slight differences among them.. In that case, since the system checks such messages against the slow path, after some time the system would halt.
Owner of the L1ERC20Bridge on OP Mainnet.
A Multisig with 5/8 threshold. Admin of the zkLink contract on OP Mainnet and the ProxyAdmin, meaning it can upgrade the 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. implementation and potentially gain access to all funds.
Owner of the L1ERC20Bridge on Arbitrum One.
A Multisig with 5/8 threshold. Admin of the zkLink contract on Arbitrum One and the ProxyAdmin, meaning it can upgrade the 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. implementation and potentially gain access to all funds.
Owner of the L1ERC20Bridge on Base.
A Multisig with 5/8 threshold. Admin of the zkLink contract on Base and the ProxyAdmin, meaning it can upgrade the 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. implementation and potentially gain access to all funds.
Owner of the L1ERC20Bridge on Manta Pacific.
Admin of the zkLink contract on Manta Pacific and the ProxyAdmin, meaning it can upgrade the 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. implementation and potentially gaining access to all funds.
Owner of the L1ERC20Bridge on Mantle.
A Multisig with 5/8 threshold. Admin of the zkLink contract on Mantle and the ProxyAdmin, meaning it can upgrade the 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. implementation and potentially gain access to all funds.
Owner of the L1ERC20Bridge on Scroll.
A Multisig with 5/7 threshold. Admin of the zkLink contract on Scroll and the ProxyAdmin, meaning it can upgrade the 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. implementation and potentially gain access to all funds.
Owner of the L1ERC20Bridge on Blast.
A Multisig with 6/8 threshold. Admin of the zkLink contract on Blast and the ProxyAdmin, meaning it can upgrade the 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. implementation and potentially gain access to all funds.
Owner of the L1ERC20Bridge on ZKsync Era.
A Multisig with 5/8 threshold. Admin of the zkLink contract on ZKsync Era and the ProxyAdmin, meaning it can upgrade the 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. implementation and potentially gain access to all funds.
Owner of the L1ERC20Bridge on Ethereum.
A Multisig with 5/8 threshold. Admin of the zkLink contract on Ethereum and the ProxyAdmin, meaning it can upgrade the 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. implementation and potentially gain access to all funds.


Main entry point for depositing ERC20 tokens from Linea to zkLink Nova. Outgoing messages and incoming withdrawal validation is delegated to the zkLink contract.
Main contract of the system where 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. are committed, proven and executed. It syncs messages from secondary chains (“slow” path) and accepts “fast” forwarded requests from permissioned 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 that are later cross-checked with the slow path. ETH coming from secondary chains are transferred and escrowed here. State rootsA cryptographic hash succinctly representing a state using a Merkle tree. are then synced back to the secondary chains. The source code of this contract is not verified on Etherscan.
High level interface between the main zkLink contract and Linea’s message service.
Intermediary contract between the one of the 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 the ZKsync Era diamond that can delay 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. execution (ie withdrawals and other 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. --> 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. messages). Currently, the delay is set to 0s.
Intermediary governance contract with two roles and a customizable delay. This delay is only mandatory for transactions scheduled by the Owner role and can be set by the SecurityCouncil role. The SecurityCouncil role can execute arbitrary upgrade transactions immediately. Currently the delay is set to 0s and the SecurityCouncil role is not used.
Main entry point for depositing ERC20 tokens from Ethereum to zkLink Nova. Outgoing messages and incoming withdrawal validation is delegated to the zkLink contract.
Main messaging contract on Ethereum and ETH escrow. Outgoing messages (like deposits) are sent through the EthereumL2Gateway which ultimately makes use of Ethereum’s canonical messaging 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. to reach the Arbitrator 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.. Only whitelisted 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 can sync messages with zkLink Nova, which also transfer the ETH to it via the respective canonical bridges. Incoming messages (like withdrawals) are validated on Linea first and then sent to this contract through the same path. Whitelisted validators can also relay messages to zkLink without going through the canonical bridge (fast path), which are later cross-checked with the slow path. If the check fails, the system halts.
High level interface between the local zkLink contract and Ethereum’s message service.
Contract storing the mapping between secondary chain bridges and acts as an intermediary to receive and relay messages to and from the main zkLink contract.
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. counterpart receiving messages from the LineaL2Gateway on Linea. It redirects them to the Arbitrator contract.
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. counterpart receiving messages from the MantaL2Gateway on Manta Pacific. It redirects them to the Arbitrator contract.
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. counterpart receiving messages from the MantleL2Gateway on Mantle. It redirects them to the Arbitrator contract.
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. counterpart receiving messages from the EraL2Gateway on ZKsync Era. It redirects them to the Arbitrator contract.
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. counterpart receiving messages from the ArbitrumL2Gateway on Arbitrum One. It redirects them to the Arbitrator contract.
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. counterpart receiving messages from the BlastL2Gateway on Blast. It redirects them to the Arbitrator contract.
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. counterpart receiving messages from the OptimismL2Gateway on OP Mainnet. It redirects them to the Arbitrator contract.
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. counterpart receiving messages from the BaseL2Gateway on Base. It redirects them to the Arbitrator contract.
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. counterpart receiving messages from the ScrollL2Gateway on Scroll. It redirects them to the Arbitrator contract.
Main entry point for depositing ERC20 tokens from OP Mainnet to zkLink Nova. Outgoing messages and incoming withdrawal validation is delegated to the zkLink contract.
Main messaging contract on OP Mainnet and ETH escrow. Outgoing messages (like deposits) are sent through the OptimismL2Gateway which ultimately makes use of OP Mainnet’s canonical messaging 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. to reach the Arbitrator 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.. Only whitelisted 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 can sync messages with zkLink Nova, which also transfer the ETH to it via the respective canonical bridges. Incoming messages (like withdrawals) are validated on Linea first and then sent to this contract through the same path. Whitelisted validators can also relay messages to zkLink without going through the canonical bridge (fast path), which are later cross-checked with the slow path. If the check fails, the system halts.
High level interface between the local zkLink contract and OP’s message service.
Main entry point for depositing ERC20 tokens from Arbitrum One to zkLink Nova. Outgoing messages and incoming withdrawal validation is delegated to the zkLink contract.
Main messaging contract on Arbitrum One and ETH escrow. Outgoing messages (like deposits) are sent through the ArbitrumL2Gateway which ultimately makes use of Arbitrum One’s canonical messaging 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. to reach the Arbitrator 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.. Only whitelisted 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 can sync messages with zkLink Nova, which also transfer the ETH to it via the respective canonical bridges. Incoming messages (like withdrawals) are validated on Linea first and then sent to this contract through the same path. Whitelisted validators can also relay messages to zkLink without going through the canonical bridge (fast path), which are later cross-checked with the slow path. If the check fails, the system halts.
High level interface between the local zkLink contract and Arbitrum’s message service.
Main entry point for depositing ERC20 tokens from Base to zkLink Nova. Outgoing messages and incoming withdrawal validation is delegated to the zkLink contract.
Main messaging contract on Base and ETH escrow. Outgoing messages (like deposits) are sent through the BaseL2Gateway which ultimately makes use of Base’s canonical messaging 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. to reach the Arbitrator 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.. Only whitelisted 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 can sync messages with zkLink Nova, which also transfer the ETH to it via the respective canonical bridges. Incoming messages (like withdrawals) are validated on Linea first and then sent to this contract through the same path. Whitelisted validators can also relay messages to zkLink without going through the canonical bridge (fast path), which are later cross-checked with the slow path. If the check fails, the system halts.
High level interface between the local zkLink contract and Base’s message service.
Main entry point for depositing ERC20 tokens from Manta Pacific to zkLink Nova. Outgoing messages and incoming withdrawal validation is delegated to the zkLink contract.
Main messaging contract on Manta Pacific and ETH escrow. Outgoing messages (like deposits) are sent through the MantaPacificL2Gateway which ultimately makes use of Manta Pacific’s canonical messaging 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. to reach the Arbitrator 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.. Only whitelisted 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 can sync messages with zkLink Nova, which also transfer the ETH to it via the respective canonical bridges. Incoming messages (like withdrawals) are validated on Linea first and then sent to this contract through the same path. Whitelisted validators can also relay messages to zkLink without going through the canonical bridge (fast path), which are later cross-checked with the slow path. If the check fails, the system halts.
High level interface between the local zkLink contract and Manta Pacific’s message service.
Main entry point for depositing ERC20 tokens from Mantle to zkLink Nova. Outgoing messages and incoming withdrawal validation is delegated to the zkLink contract.
Main messaging contract on Mantle and ETH escrow. Outgoing messages (like deposits) are sent through the MantleL2Gateway which ultimately makes use of Mantle’s canonical messaging 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. to reach the Arbitrator 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.. Only whitelisted 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 can sync messages with zkLink Nova, which also transfer the ETH to it via the respective canonical bridges. Incoming messages (like withdrawals) are validated on Linea first and then sent to this contract through the same path. Whitelisted validators can also relay messages to zkLink without going through the canonical bridge (fast path), which are later cross-checked with the slow path. If the check fails, the system halts.
High level interface between the local zkLink contract and Mantle’s message service.
Main entry point for depositing ERC20 tokens from Scroll to zkLink Nova. Outgoing messages and incoming withdrawal validation is delegated to the zkLink contract.
Main messaging contract on Scroll and ETH escrow. Outgoing messages (like deposits) are sent through the ScrollL2Gateway which ultimately makes use of Scroll’s canonical messaging 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. to reach the Arbitrator 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.. Only whitelisted 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 can sync messages with zkLink Nova, which also transfer the ETH to it via the respective canonical bridges. Incoming messages (like withdrawals) are validated on Linea first and then sent to this contract through the same path. Whitelisted validators can also relay messages to zkLink without going through the canonical bridge (fast path), which are later cross-checked with the slow path. If the check fails, the system halts.
High level interface between the local zkLink contract and Scroll’s message service.
Main entry point for depositing ERC20 tokens from Blast to zkLink Nova. Outgoing messages and incoming withdrawal validation is delegated to the zkLink contract.
Main messaging contract on Blast and ETH escrow. Outgoing messages (like deposits) are sent through the BlastL2Gateway which ultimately makes use of Blast’s canonical messaging 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. to reach the Arbitrator 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.. Only whitelisted 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 can sync messages with zkLink Nova, which also transfer the ETH to it via the respective canonical bridges. Incoming messages (like withdrawals) are validated on Linea first and then sent to this contract through the same path. Whitelisted validators can also relay messages to zkLink without going through the canonical bridge (fast path), which are later cross-checked with the slow path. If the check fails, the system halts.
High level interface between the local zkLink contract and Blast’s message service.
Main entry point for depositing ERC20 tokens from ZKsync Era to zkLink Nova. Outgoing messages and incoming withdrawal validation is delegated to the zkLink contract.
Main messaging contract on ZKsync Era and ETH escrow. Outgoing messages (like deposits) are sent through the ZKsync2L2Gateway which ultimately makes use of ZKsync Era’s canonical messaging 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. to reach the Arbitrator 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.. Only whitelisted 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 can sync messages with zkLink Nova, which also transfer the ETH to it via the respective canonical bridges. Incoming messages (like withdrawals) are validated on Linea first and then sent to this contract through the same path. Whitelisted validators can also relay messages to zkLink without going through the canonical bridge (fast path), which are later cross-checked with the slow path. If the check fails, the system halts.
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).
Funds can be stolen if the source code of unverified contracts contains malicious code (CRITICAL).