Summary Value Secured Activity Milestones & Incidents Risk summary Risk analysis Data availability State validation Upgrades & Governance Updates Operator Withdrawals Permissions Smart contracts

ZKFair

Name: ZKFair
Creator: L2BEAT

1 recent update

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. withdrawals require a signature from one configured address. An administrator can withdraw all escrow funds directly. ValidiumAn off-chain solution that uses validity proofs for settlement and publishes the data offchain, therefore requiring an additional trust assumption. proofs constrain neither path.

Badges

About

ZKFair uses Polygon CDK for validium state proofs and a separate signature-authorized bridge for asset transfers.

Total Value SecuredTVS

$63.31 K0.18%

Past day UOPSDaily UOPS

<0.0114.2%

Type

Other

Purpose

Universal

Chain ID

42766

Tokens breakdown

Value secured breakdown

0.00% with additional trust assumptions

View TVS breakdown

Sequencer failureState validationData availabilityExit windowProposer failure

Explore more in Discovery UI

Badges

About

ZKFair uses Polygon CDK for validium state proofs and a separate signature-authorized bridge for asset transfers.

Why is the project listed in others?

The proof system isn't fully functional

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

There is no data availability bridge

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.

Value Secured

Compare View TVS breakdown

Exclude restricted RWA tokens

Total

Canonically BridgedCanonically Bridged ValueCanonical

Natively MintedNatively Minted TokensNative

Externally BridgedExternally Bridged ValueExternal

ETH & derivatives

Stablecoins

BTC & derivatives

Other

View TVS breakdown

Compare with other projects

Activity

Compare

Past Day UOPS

Past Day Ops count

Max. UOPS

Past day UOPS/TPS Ratio

Compare with other projects

Milestones & Incidents

ZKFair Mainnet is Live

2023 Dec 20th

ZKFair launched.

Learn more

Risk summary

Forced transactions are disabled. The validium contracts use a data availability committee, and the token bridge uses separate signature validation.

Risk analysis

Bridge withdrawals require a signature from one configured address. An administrator can withdraw all escrow funds directly. Validium proofs constrain neither path.

Forced transactions are disabled. The validium contracts use a data availability committee, and the token bridge uses separate signature validation.

Sequencer failureState validationData availabilityExit windowProposer failure

Sequencer failure

No mechanism

There is no mechanism to have transactions be included if the sequencerA party responsible for ordering and executing transactions on the rollup. The sequencer verifies transactions, compresses the data into a block, and submits the data related to it to enable state reconstruction to Ethereum L1 as a single transaction. The data can be either transaction data or state diffs. is down or censoring. Although the functionality exists in the code, it is currently disabled.

State validation

None

Currently the system permits invalid state rootsA cryptographic hash succinctly representing a state using a Merkle tree.. More details in project overview.

Data availability

External (DAC)

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.

Exit window

None

There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.

Proposer failure

Cannot withdraw

Only the whitelisted proposers can publish state rootsA cryptographic hash succinctly representing a state using a Merkle tree. on L1Layer 1 (L1) is a blockchain that is self-reliant on its validator set for its security and consensus properties. Ethereum is an example of a layer 1. Blockchains started receiving the moniker of layer 1 once layer 2 became a meaningful area of development., so in the event of failure the withdrawals are frozen.

Data availability

Set of parties responsible for signing and attesting to the availability of data.

6.1

Risk analysis

Economic security

None

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.

Fraud detection

None

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

Committee security

3/5

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.

Upgradeability

No delay

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.

Relayer failure

No mechanism

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.

6.2

Technology

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.

Polygon CDK Validium Documentation

State validation

No state validation

The token 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. accepts an EIP-712 signature recovering to its configured address. It checks no source-chain proof or threshold of distinct signers. A used source-domain nonce prevents replay. The escrow also accepts unrestricted withdrawals instructed by the bridge administration.

Funds can be stolen if the bridge signing key authorizes an arbitrary token release.
Funds can be stolen if the bridge withdrawal authority sends escrow funds to itself.

Validity proofs

ZKFairValidium verifies proofs of state transitions using an Fflonk verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover.. Its verified state and exit roots do not authorize releases from the current token escrow.

ZKFairValidium.sol#L758 - Etherscan source code, _verifyAndRewardBatches function

Upgrades & Governance

Past upgrades

The metrics include upgrades on the currently used proxy contracts. Historical proxy contracts and changes of such are not included.

Count of upgrades

Last upgrade

1y 6mo ago

Avg upgrade interval

1y 5mo

Updates

2026 October 12, 07:14 UTC

30changes

New source verification confirms that the current escrow trusts one ECDSA signing address. Separate administrators can withdraw funds without bridge signatures or validium proofs.

New and verified contracts

	contract OldBridge (eth:0x9cb4706e20A18E59a48ffa7616d700A3891e1861) [N/A] {
	+++ description: None
	unverified:
-	true
	values.admin:
+	"eth:0xcd14BE1959928BB8c160D11817E2BE2129e2F25F"
	values.bridgeFee:
+	2500000000000000
	values.feeAddress:
+	"eth:0xfED4D68744115A50ed22a6DA32DBA42eCaB5CF8D"
	values.gasTokenAddress:
+	"eth:0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48"
	values.gasTokenDecimalDiffFactor:
+	1000000000000
	values.gasTokenMetadata:
+	"0x000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000120000000000000000000000000000000000000000000000000000000000000005457468657200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000034554480000000000000000000000000000000000000000000000000000000000"
	values.globalExitRootManager:
+	"eth:0x72abD6416Ea2d99ad30C86B90e7409Dc2d1ba40b"
	values.isEmergencyState:
+	false
	values.networkID:
+	0
	values.polygonZkEVMaddress:
+	"eth:0x1CbC08bf0D48b18F9f97796c61352b192d1850A5"
	implementationNames.eth:0x58371687dc997A7A11154bBcA72aEb15e4Db8F46:
-	""
+	"PolygonZkEVMBridge"
	sourceHashes:
+	["0x3f8d1d2461c05779ca5de685fd391f6a4c07e91953373effd46d11f72b025dc3","0x9435648db8821f142e34edf2f081caac9606cb70cdc1186184324c5db48ecf78"]
	}

	contract Bridge (eth:0xb10f60B4Ea978CA02aFBAC57fa84907e8439766e) [chainsafe/ERC20Handler] {
	+++ description: Escrow holding ERC20 tokens and ETH for the configured bridge. Only that bridge can execute releases, withdraw funds or configure token mappings. Its own admin can set deposit limits.
	unverified:
-	true
	+++ description: Bridge authorized to release or withdraw all escrow funds and configure token mappings.
	values._bridgeAddress:
+	"eth:0xB66bbf236CE102A1De692f2A034b9dB245986671"
	values.accessControl:
+	{"DEFAULT_ADMIN_ROLE":{"adminRole":"DEFAULT_ADMIN_ROLE","members":["eth:0xFA12a0567fa25fB45405Efd3786b565941E3E84b"]}}
	values.DEFAULT_ADMIN_ROLE:
+	"0x0000000000000000000000000000000000000000000000000000000000000000"
	values.defaultAdminAC:
+	["eth:0xFA12a0567fa25fB45405Efd3786b565941E3E84b"]
	values.defaultDecimals:
+	18
	values.startTime:
+	1742988323
	implementationNames.eth:0xb10f60B4Ea978CA02aFBAC57fa84907e8439766e:
-	""
+	"ERC20Handler"
	template:
+	"chainsafe/ERC20Handler"
	sourceHashes:
+	["0xa697494f19ebcebaa1da9ce4932e84eab588af0f3f92468fc196e40d80f1582a"]
	description:
+	"Escrow holding ERC20 tokens and ETH for the configured bridge. Only that bridge can execute releases, withdraw funds or configure token mappings. Its own admin can set deposit limits."
	critical:
+	{"sinceTimestamp":1744292087}
	fieldMeta:
+	{"_bridgeAddress":{"description":"Bridge authorized to release or withdraw all escrow funds and configure token mappings."}}
	}

+	Status: CREATED
	contract FeeHandlerRouter (eth:0x899b97352c91cC21384944350Ba8bf00fCAbCd53) [chainsafe/FeeHandlerRouter]
	+++ description: Routes bridge deposit fees to a configured fee handler for each token resource.

+	Status: CREATED
	contract AccessControlSegregator (eth:0x8E1b1B3Be901eF8efACe4767097a75976Ce7d512) [chainsafe/AccessControlSegregator]
	+++ description: Stores one authorized address per bridge function selector. The authority for grantAccess can replace any function's authority, including unrestricted escrow withdrawal and access-control replacement.

+	Status: CREATED
	contract TokenBridge (eth:0xB66bbf236CE102A1De692f2A034b9dB245986671) [chainsafe/Bridge]
	+++ description: Routes token deposits and releases to asset handlers. Releases require an EIP-712 signature recovering to the configured signing address. The contract checks no source-chain proof or signer threshold. Per-function authorities can withdraw escrow funds, remap handlers and replace access control.

+	Status: CREATED
	contract BridgeAdminMultiSig (eth:0xcd14BE1959928BB8c160D11817E2BE2129e2F25F) [GnosisSafe]
	+++ description: None

2025 July 14, 12:46 UTC

10changes

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 UTC

1change

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 UTC

High severity

22changes

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 UTC

5changes

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

Operator

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

ZKFairValidium.sol#L61 - Etherscan source code, onlyTrustedSequencer modifier

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.

ZKFairValidium.sol#L475 - Etherscan source code, isForceBatchAllowed modifier

Withdrawals

Signature-authorized withdrawal

Users depend on 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. signing address to authorize withdrawals. Anyone can submit its valid signature and proposal to release tokens from the escrow. A validiumAn off-chain solution that uses validity proofs for settlement and publishes the data offchain, therefore requiring an additional trust assumption. proof cannot replace the signature.

Funds can be frozen if the bridge signing address stops authorizing withdrawals or the administration pauses the token bridge.

TokenBridge - executeProposal and executeProposals

Permissions

A dashboard to explore contracts and permissions

Go to Disco

Explore in Disco

Ethereum

Actors:

Bridge signing address0xb2A2…9a0e

Its ECDSA signature can authorize arbitrary releases from the current token escrow. The contract enforces no threshold of distinct signers.

Bridge permissions administrator0xFA12…E84b

Can replace every per-function 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. authority, including withdrawal and access-control replacement authorities, without delay.

Bridge withdrawal authority0xcd14…F25F

Can withdraw all escrow funds directly through the token 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., without a validiumAn off-chain solution that uses validity proofs for settlement and publishes the data offchain, therefore requiring an additional trust assumption. proof or bridge signature.

Sequencer0x9eed…Db6c

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.

Proposer0xd688…A027

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.

ZKFairAdmin0x0110…B725

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.

Participants (4):

0x39Fc…0953 0x3226…BDBc 0x4dba…0295 0xe122…c7aF

ZKFairOwner0x8933…3A88

A Multisig with 3/4 threshold. The ZkFair Owner is a multisig that can be used to trigger the emergency state which 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.

Participants (4):

0x9fAe…e6C7 0x540C…25Ba 0xcf62…5b87 0x4B7f…9976

5 EOAs

0x033A…3ca2 0x061D…97ae 0x9231…bA17 0x9d86…1a13 0xFe1d…118d

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.

DAC Owner0xa57c…0c70

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.

2 EOAs

0x7557…C527 0x9412…dDAa

Controls the upgrades to the ZKFairValidiumDAC and ZKFairValidium contracts through the Timelock.

Smart contracts

A dashboard to explore contracts and permissions

Go to Disco

Explore in Disco

Ethereum

ZKFairValidium0x1CbC…50A5 Implementation (Upgradable)Admin

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.

Can be upgraded by:

ZKFairAdmin with 1d delay

State injections - stateRoot and exitRoot are part of the validity proof input.

Bridge

Escrow

0xb10f…766e

ERC20Handler escrow holding ERC20 tokens and ETH. Only TokenBridge can release or withdraw funds. ValidiumAn off-chain solution that uses validity proofs for settlement and publishes the data offchain, therefore requiring an additional trust assumption. proofs do not constrain these releases.

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

TokenBridge0xB66b…6671

AccessControlSegregator0x8E1b…d512

FeeHandlerRouter0x899b…Cd53

OldBridge

Escrow

0x9cb4…1861 Implementation (Upgradable)Admin

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.

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

Can be upgraded by:

ZKFairAdmin with 1d delay

GlobalExitRoot0x72ab…a40b Implementation (Upgradable)Admin

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.

Can be upgraded by:

ZKFairAdmin with 1d delay

FflonkVerifier0x769E…F46d

An autogenerated contract that verifies ZK proofs in the ZKFairValidium system.

ZKFairValidiumDAC0x997C…125b Implementation (Upgradable)Admin

Committee attesting that data for a given dataRoot has been published. The DAC Owner can update the member set at any time.

Can be upgraded by:

ZKFairAdmin with 1d delay

Timelock0x5288…9c17

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: