Search
Search for projects by name or address
ZKFair
The canonical 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. escrow was upgraded to an unverified implementation and user funds were moved to an EOA, then deposited to AAVE. They were subsequently withdrawn and moved to a new contract. Related tweet by the ZKFair team.
Badges
About
ZKFair is a Validium based on Polygon CDK and Celestia DA.
Badges
About
ZKFair is a Validium based on Polygon CDK and Celestia DA.
Why is the project listed in others?
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.
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.
Funds can be stolen if
Funds can be lost if
Funds can be frozen if
Users can be censored if
MEV can be extracted if
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. Although the functionality exists in the code, it is currently disabled.
SNARKs are succinct zero knowledge proofs that ensure state correctness, but require trusted setupGeneration of a piece of data that must then be used for some cryptographic protocol to run. Generating this data requires some secret information. The "trust" comes from the fact the secret must be destroyed after the ceremony, otherwise cryptographic properties of the protocol could be broken. Once the data is generated, and the secrets are forgotten, no further participation from the creators of the ceremony is required. There are two types of trusted setups for SNARKs: (i) trusted setup per circuit where it is generated from scratch for each circuit, (ii) trusted universal setup per proving system where it can be used for several circuits..
Proof construction relies fully on data that is NOT published onchain. There exists a Data Availability Committee (DAC)A set of members whose task is attesting and ensuring that the data is available for the public. An onchain DAC verifier checks that a threshold of signatures from the DAC members is reached before considering a data commitment as available and therefore valid to be used in the system. with a threshold of 3/5 that is tasked with protecting and supplying the data.
Even though there is a 1d Timelock for non-emergency upgrades, forced transactions are disabled. Even if they were to be enabled, user withdrawals can be censored up to 15d.
There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.
If the ProposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. fails, users can leverage the source available proverAn entity that generates the cryptographic proof to convince the verifier that the statement is true. In a ZK-Rollup, the prover generates the ZK (validity) proof to submit to the verifier contract. to submit proofs to the 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. 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.. There is a 5d delay for proving and a 5d delay for finalizing state proven in this way. These delays can only be lowered except during the emergency state.
Set of parties responsible for signing and attesting to the availability of data.
There are no onchain assets at risk of being slashed in case of a data withholding attack, and the committee members are not publicly known.
There is no fraud detection mechanism in place. A data withholding attack can only be detected by nodes downloading the full data from the DA layerAn infrastructure that is used to make publish data so that it's available to the public. They take the form of Data Availability Committees (DACs) or blockchains. Not to confuse with the layer responsible with ordering, since ordering and DA can be separated..
The committee does not meet basic security standards, either due to insufficient size, lack of member diversity, or poorly defined threshold parameters. The system lacks an effective DA bridgeSystem that verifies that data has been made available. It takes the form of a smart contract verifying a consensus or, if the data is verified directly by either downloading the full data or sampling, of an enshrined bridge. and it is reliant on the assumption of an honest 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., creating significant risks to data integrity and availability.
There is no delay in the upgradeabilityThe ability for rollup smart contracts and parameters used in a rollup to be updated by holders of an admin key. Upgradeability represents a vector of risk for users, and should be decentralized and combined with time delays for greater security guarantees. of 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.. Users have no time to exit the system before the bridge implementation update is completed.
The relayer role is permissioned, and the DA bridgeSystem that verifies that data has been made available. It takes the form of a smart contract verifying a consensus or, if the data is verified directly by either downloading the full data or sampling, of an enshrined bridge. does not have a Security CouncilA Security Council is a sufficiently decentralized set of members that is able to upgrade a system. A properly set up Security Council consists of at least 8 members with a threshold greater than 75%. What 'sufficiently decentralized' means is fundamentally subjective and L2BEAT evaluates each case individually. A Security Council is allowed to instantly upgrade Stage 1 rollups. or a governance mechanism to propose new relayers. In case of relayer failure, the DA bridge will halt and be unable to recover without the intervention of a centralized entity.
Architecture
Polygon CDK validiums utilize a data availabilityThe property of a rollup's data being reachable by any node retrieving the data that were rolled up and executed to reach the proposed state. Data availability (DA), specifically decoupling it from the rollup nodes themselves, is one of the preeminent factors which allows a rollup to scale securely. A rollup is faced with a decision of what to use as a DA layer to guarantee that any node can retrieve this data--permissionlessly under any circumstance. For this reason, using Ethereum for DA currently provides the strongest security guarantees. If data is stored somewhere other than a permissionless L1, then the project is not a rollup, but rather a validium or an optimium. solution that relies on a Data Availability Committee (DAC)A set of members whose task is attesting and ensuring that the data is available for the public. An onchain DAC verifier checks that a threshold of signatures from the DAC members is reached before considering a data commitment as available and therefore valid to be used in the system. to ensure data integrity and manage off-chain transaction data. This architecture comprises the following components:
- 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.: A trusted entity that collects transactions, computes hashA fixed-length fingerprint of variable-size input, produced by a hash function. values for the transaction batch, and then requests and collects signatures from Committee members.
- Data Availability Committee (DAC): A group of nodes responsible for validating batch data against the hash values provided by the operator (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.), ensuring the data accurately represents the transactions.
- PolygonCommittee Contract: Contract responsible for managing the data committee members list.
Each DAC nodeA software client that participates in the network. independently validates the batch data, ensuring it matches the received hash values. Upon successful validation, DAC members store the hash values locally and generate signatures endorsing the batch’s integrity. The sequencer collects these signatures and submits the transactions batch hash together with the aggregated signature on Ethereum. The PolygonCommittee contract is used during batch sequencing to verify that the signature posted by the sequencer was signed off by the DAC members stored in the contract.
DA BridgeSystem that verifies that data has been made available. It takes the form of a smart contract verifying a consensus or, if the data is verified directly by either downloading the full data or sampling, of an enshrined bridge. Architecture
The DA commitments are posted to the destination chain through the sequencer inbox, using the inbox as a DA bridge. The DA commitment consists of a data availability message provided as transaction input, made up of a byte array containing the signatures and all the addresses of the committee in ascending order. The sequencer distributes the data and collects signatures from Committee members offchain. Only the DA message is posted by the sequencer to the destination chain inbox (the DA bridge). A separate contract, the PolygonCommittee contract, is used to manage the committee members list and verify the signatures before accepting the DA commitment.
Funds can be lost if a malicious committee signs a data availability attestation for an unavailable transaction batch.
Funds can be lost if the bridge contract or its dependencies receive a malicious code upgrade. There is no delay on code upgrades.
Each update to the system state must be accompanied by a ZK proof that ensures that the new state was derived by correctly applying a series of valid user transactions to the previous state. These proofs are then verified on Ethereum by a smart contract.
Past upgrades
The metrics include upgrades on the currently used proxy contracts. Historical proxy contracts and changes of such are not included.
2025 July 14, 12:46 UTC10changesDiscovery rerun on the same block number with only config-related changes.
Discovery rerun on the same block number with only config-related changes.
New and verified contracts
| + | Status: CREATED |
| contract ZKFairAdmin (0x0110B1B231aA3b96a94c900eb3056297526AB725) | |
| +++ description: None | |
| + | Status: CREATED |
| contract ZKFairValidium (0x1CbC08bf0D48b18F9f97796c61352b192d1850A5) | |
| +++ description: None | |
| + | Status: CREATED |
| contract Timelock (0x52882c7564fAca480549145fAc4d0b09eD0D9c17) | |
| +++ description: None | |
| + | Status: CREATED |
| contract GlobalExitRoot (0x72abD6416Ea2d99ad30C86B90e7409Dc2d1ba40b) | |
| +++ description: None | |
| + | Status: CREATED |
| contract FflonkVerifier (0x769E285d2120472c3400A09684B82A842012F46d) | |
| +++ description: None | |
| + | Status: CREATED |
| contract ZKFairOwner (0x8933Fa0A97f39cd38f56b1887d5cc56cF04F3A88) | |
| +++ description: None | |
| + | Status: CREATED |
| contract ZKFairValidiumDAC (0x997CfB0838544f68E59f877EDc905001456F125b) | |
| +++ description: Committee attesting that data for a given dataRoot has been published. The DAC Owner can update the member set at any time. | |
| + | Status: CREATED |
| contract OldBridge (0x9cb4706e20A18E59a48ffa7616d700A3891e1861) | |
| +++ description: None | |
| + | Status: CREATED |
| contract Bridge (0xb10f60B4Ea978CA02aFBAC57fa84907e8439766e) | |
| +++ description: None | |
| + | Status: CREATED |
| contract ProxyAdmin (0xb57b9101dEc7dC1635B576fFf71F2f522C970EF3) | |
| +++ description: None | |
2025 April 22, 07:14 UTC1changeProvide description of changes. This section will be preserved.
Provide description of changes. This section will be preserved.
New and verified contracts
| + | Status: CREATED |
| contract Bridge (0xb10f60B4Ea978CA02aFBAC57fa84907e8439766e) | |
| +++ description: None | |
2025 March 31, 11:42 UTCHigh severity22changesBridge upgraded to an unverified implementation. Funds moved to an EOA and deposited to DeFi from there.
Bridge upgraded to an unverified implementation. Funds moved to an EOA and deposited to DeFi from there.
| contract Timelock (0x52882c7564fAca480549145fAc4d0b09eD0D9c17) { | |
| +++ description: None | |
| values.accessControl.PROPOSER_ROLE.members.1: | |
| + | "0x9412eCbEE1e8dd25F347D6d8002f62eF540ddDAa" |
| values.accessControl.EXECUTOR_ROLE.members.1: | |
| + | "0x9412eCbEE1e8dd25F347D6d8002f62eF540ddDAa" |
| } | |
| contract Bridge (0x9cb4706e20A18E59a48ffa7616d700A3891e1861) { | |
| +++ description: None | |
| sourceHashes: | |
| - | ["0x3f8d1d2461c05779ca5de685fd391f6a4c07e91953373effd46d11f72b025dc3","0x63f00c3d965d6858168ed7d73fd0c413524877b196c4c5e3cf8fbc6ba40846e8"] |
| values.$implementation: | |
| - | "0xEb80283EBc508CF6AaC5E054118954a2BD7fA006" |
| + | "0x58371687dc997A7A11154bBcA72aEb15e4Db8F46" |
| values.$pastUpgrades.1: | |
| + | ["2023-12-18T06:01:23.000Z","0x22ef364422913d82a57f2fb0b440655ced0178c3549491490edff4663389f511",["0xEb80283EBc508CF6AaC5E054118954a2BD7fA006"]] |
| values.$pastUpgrades.0.2: | |
| - | "0x22ef364422913d82a57f2fb0b440655ced0178c3549491490edff4663389f511" |
| + | "0xca7c847dde27f60d98b07ef29ba9e0a677f28dddd980bb20c52f660c0071e768" |
| values.$pastUpgrades.0.1: | |
| - | "2023-12-18T06:01:23.000Z" |
| + | ["0x58371687dc997A7A11154bBcA72aEb15e4Db8F46"] |
| values.$pastUpgrades.0.0: | |
| - | ["0xEb80283EBc508CF6AaC5E054118954a2BD7fA006"] |
| + | "2025-03-27T05:30:59.000Z" |
| values.$upgradeCount: | |
| - | 1 |
| + | 2 |
| values.admin: | |
| - | "0xcd14BE1959928BB8c160D11817E2BE2129e2F25F" |
| values.bridgeFee: | |
| - | 2500000000000000 |
| values.feeAddress: | |
| - | "0xfED4D68744115A50ed22a6DA32DBA42eCaB5CF8D" |
| values.gasTokenAddress: | |
| - | "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48" |
| values.gasTokenDecimalDiffFactor: | |
| - | 1000000000000 |
| values.gasTokenMetadata: | |
| - | "0x000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000120000000000000000000000000000000000000000000000000000000000000005457468657200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000034554480000000000000000000000000000000000000000000000000000000000" |
| values.globalExitRootManager: | |
| - | "0x72abD6416Ea2d99ad30C86B90e7409Dc2d1ba40b" |
| values.isEmergencyState: | |
| - | false |
| values.networkID: | |
| - | 0 |
| values.polygonZkEVMaddress: | |
| - | "0x1CbC08bf0D48b18F9f97796c61352b192d1850A5" |
| derivedName: | |
| - | "PolygonZkEVMBridge" |
| + | "" |
| unverified: | |
| + | true |
| } | |
| - | Status: DELETED |
| contract BridgeAdminMultiSig (0xcd14BE1959928BB8c160D11817E2BE2129e2F25F) | |
| +++ description: None | |
2024 September 09, 08:19 UTC5changesDAC member URLs have changed (to Tencent). (Onchain addresses stay the same)
DAC member URLs have changed (to Tencent). (Onchain addresses stay the same)
| contract ZKFairValidiumDAC (0x997CfB0838544f68E59f877EDc905001456F125b) { | |
| +++ description: Committee attesting that data for a given dataRoot has been published. The DAC Owner can update the member set at any time. | |
| +++ description: URL and address of the DAC member | |
| values.members.4.0: | |
| - | "http://ec2-54-219-14-189.us-west-1.compute.amazonaws.com:8444" |
| + | "http://43.129.158.203:8444" |
| +++ description: URL and address of the DAC member | |
| values.members.3.0: | |
| - | "http://ec2-18-144-4-166.us-west-1.compute.amazonaws.com:8444" |
| + | "http://119.28.1.197:8444" |
| +++ description: URL and address of the DAC member | |
| values.members.2.0: | |
| - | "http://ec2-52-53-165-158.us-west-1.compute.amazonaws.com:8444" |
| + | "http://43.155.22.171:8444" |
| +++ description: URL and address of the DAC member | |
| values.members.1.0: | |
| - | "http://ec2-54-153-117-150.us-west-1.compute.amazonaws.com:8444" |
| + | "http://129.226.185.196:8444" |
| +++ description: URL and address of the DAC member | |
| values.members.0.0: | |
| - | "http://ec2-13-57-35-237.us-west-1.compute.amazonaws.com:8444" |
| + | "http://43.129.159.5:8444" |
| } | |
2024 April 24, 15:27 UTC5changesThe URLs on amazon aws for all 5 DAC members are changed. Their onchain addresses remain the same.
The URLs on amazon aws for all 5 DAC members are changed. Their onchain addresses remain the same.
| contract DataAvailabilityCommittee (0x997CfB0838544f68E59f877EDc905001456F125b) { | |
| +++ description: Committee attesting that data for a given dataRoot has been published. The DAC Owner can update the member set at any time. | |
| +++ description: URL and address of the DAC member | |
| values.members.4.0: | |
| - | "http://ec2-18-163-127-148.ap-east-1.compute.amazonaws.com:8444" |
| + | "http://ec2-54-219-14-189.us-west-1.compute.amazonaws.com:8444" |
| +++ description: URL and address of the DAC member | |
| values.members.3.0: | |
| - | "http://ec2-18-167-116-200.ap-east-1.compute.amazonaws.com:8444" |
| + | "http://ec2-18-144-4-166.us-west-1.compute.amazonaws.com:8444" |
| +++ description: URL and address of the DAC member | |
| values.members.2.0: | |
| - | "http://ec2-43-198-25-156.ap-east-1.compute.amazonaws.com:8444" |
| + | "http://ec2-52-53-165-158.us-west-1.compute.amazonaws.com:8444" |
| +++ description: URL and address of the DAC member | |
| values.members.1.0: | |
| - | "http://ec2-18-163-181-171.ap-east-1.compute.amazonaws.com:8444" |
| + | "http://ec2-54-153-117-150.us-west-1.compute.amazonaws.com:8444" |
| +++ description: URL and address of the DAC member | |
| values.members.0.0: | |
| - | "http://ec2-18-166-77-46.ap-east-1.compute.amazonaws.com:8444" |
| + | "http://ec2-13-57-35-237.us-west-1.compute.amazonaws.com:8444" |
| } | |
The system has a centralized sequencer
Only a trusted 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 allowed to submit transaction batches. A mechanism for users to submit their own batches is currently disabled.
MEV can be extracted if the operator exploits their centralized position and frontruns user transactions.
Funds can be frozen if the sequencer refuses to include an exit transaction (CRITICAL).
Users can't force any transaction
The mechanism for allowing users to submit their own transactions is currently disabled.
Users can be censored if the operator refuses to include their transactions.
Regular messaging
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.
Ethereum
Actors:
Its sole purpose and ability is to submit transaction batches. In case they are unavailable users cannot rely on the force batch mechanism because it is currently disabled.
The trusted proposerIn the context of L2s, the actor that proposes a claimed state root on L1. The term is also used in the context of Ethereum to refer to the actor that proposes a new block. (called Aggregator) provides the ZKFairValidium contract with ZK proofs of the new system state. In case they are unavailable a mechanism for users to submit proofs on their own exists, but is behind a 5d delay for proving and a 5d delay for finalizing state proven in this way. These delays can only be lowered except during the emergency state.
A Multisig with 3/4 threshold. Admin of the ZKFairValidium, can set core system parameters like timeouts, 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. and aggregator as well as deactivate emergency state.
A Multisig with 3/4 threshold. The ZkFair Owner is a multisig that can be used to trigger the emergency state which pauses 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. functionality, restricts advancing system state and removes the upgradeabilityThe ability for rollup smart contracts and parameters used in a rollup to be updated by holders of an admin key. Upgradeability represents a vector of risk for users, and should be decentralized and combined with time delays for greater security guarantees. delay.
Members of the Data AvailabilityThe property of a rollup's data being reachable by any node retrieving the data that were rolled up and executed to reach the proposed state. Data availability (DA), specifically decoupling it from the rollup nodes themselves, is one of the preeminent factors which allows a rollup to scale securely. A rollup is faced with a decision of what to use as a DA layer to guarantee that any node can retrieve this data--permissionlessly under any circumstance. For this reason, using Ethereum for DA currently provides the strongest security guarantees. If data is stored somewhere other than a permissionless L1, then the project is not a rollup, but rather a validium or an optimium. Committee. The setup is equivalent to a 3/5 multisig.
The owner of the Data AvailabilityThe property of a rollup's data being reachable by any node retrieving the data that were rolled up and executed to reach the proposed state. Data availability (DA), specifically decoupling it from the rollup nodes themselves, is one of the preeminent factors which allows a rollup to scale securely. A rollup is faced with a decision of what to use as a DA layer to guarantee that any node can retrieve this data--permissionlessly under any circumstance. For this reason, using Ethereum for DA currently provides the strongest security guarantees. If data is stored somewhere other than a permissionless L1, then the project is not a rollup, but rather a validium or an optimium. Committee, can update the member set at any time.
Controls the upgrades to the ZKFairValidiumDAC and ZKFairValidium contracts through the Timelock.
Ethereum
The main contract of the Polygon CDK ValidiumAn off-chain solution that uses validity proofs for settlement and publishes the data offchain, therefore requiring an additional trust assumption.. It defines the rules of the system including core system parameters, permissioned actors as well as emergency procedures. The emergency state can be activated either by the ZkFair Owner, by proving a soundness error or by presenting a sequenced batch that has not been aggregated before a 7d timeout. This contract receives transaction roots, 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. state rootsA cryptographic hash succinctly representing a state using a Merkle tree. as well as ZK proofs. It also holds the address of ZKFairValidiumDAC.
The current escrow contract for user funds. The source code of this contract is not verified on Etherscan.
All supported tokens in this escrow are included in the value secured calculation.
Deprecated! Was the escrow contract for user funds. It is mirrored on the 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. side and can be used to transfer ERC20 assets. To transfer funds a user initiated transaction on both sides is required. The source code of this contract is not verified on Etherscan.
All supported tokens in this escrow are included in the value secured calculation.
Synchronizes deposit and withdraw merkle trees across 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. and 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.. The global root from this contract is injected into the L2 contract.
An autogenerated contract that verifies ZK proofs in the ZKFairValidium system.
Committee attesting that data for a given dataRoot has been published. The DAC Owner can update the member set at any time.
Contract upgrades have to go through a 1d timelock unless the Emergency State is activated. It is controlled by the TimelockExecutor.
The current deployment carries some associated risks:
Funds can be stolen if a contract receives a malicious code upgrade. There is a 1d delay on code upgrades.
Funds can be stolen if the source code of unverified contracts contains malicious code (CRITICAL).