ZKFair
$71.76 M
28.34%
| Website | zkfair.io |
|---|---|
| App | wallet.zkfair.io |
| Docs | docs.zkfair.io |
| Explorer | scan.zkfair.io |
| Repository | github.com/ZKFair |
| Social | @ZKFCommunity |
...
Choose token
ZKF (ZKF)
Ether (ETH)
Wrapped BTC (WBTC)
USD Coin (USDC)
Tether USD (USDT)
Dai Stablecoin (DAI)
Zks (ZKS)
0x Protocol Token (ZRX)
10Set Token (10SET)
1INCH Token (1INCH)
Aave Token (AAVE)
Across Protocol Token (ACX)
Alchemix USD (alUSD)
Alchemy (ACH)
aleph.im v2 (ALEPH)
Amp (AMP)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
State validation
ZK proofs (SN)zkSNARKS are zero knowledge proofs that ensure state correctness, but require trusted setup.
Data availability
External (DAC)Proof construction relies fully on data that is NOT published on chain. There exists a Data Availability Committee (DAC) with a threshold of 3/5 that is tasked with protecting and supplying the data.
Exit window
NoneEven though there is a 1d Timelock for upgrades, forced transactions are disabled. Even if they were to be enabled, user withdrawals can be censored up to 15d.
Sequencer failure
No mechanismThere is no mechanism to have transactions be included if the sequencer is down or censoring. Although the functionality exists in the code, it is currently disabled.
Proposer failure
Self proposeIf the Proposer fails, users can leverage the source available prover to submit proofs to the L1 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.
Validity proofs ensure state correctness
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.
Data is not stored on chain
The transaction data is not recorded on the Ethereum main chain.
Funds can be lost if the external data becomes unavailable (CRITICAL).
The system has a centralized sequencer
Only a trusted sequencer 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 exit
The user initiates the withdrawal by submitting a regular transaction on this chain. When the block containing that transaction is proven the funds become available for withdrawal on L1. Finally the user submits an L1 transaction to claim the funds. This transaction requires a merkle proof.
The system uses the following set of permissioned addresses:
Admin of the CDKValidium, can set core system parameters like timeouts, sequencer and aggregator as well as deactivate emergency state. They can also upgrade the CDKValidium contracts, but are restricted by a 10d delay unless rollup is put in the Emergency State. This is a Gnosis Safe with 3 / 4 threshold.
Those are the participants of the ZkFairAdmin.
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 proposer (called Aggregator) provides the CDKValidium 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.
The ZkFair Owner is a multisig that can be used to trigger the emergency state which pauses bridge functionality, restricts advancing system state and removes the upgradeability delay. This is a Gnosis Safe with 3 / 4 threshold.
Those are the participants of the ZkFairOwner.
The Bridge Admin is a multisig that can be used to set bridge fees and an address into which fees are transferred. This is a Gnosis Safe with 3 / 4 threshold.
Those are the participants of the BridgeAdminMultiSig.
Members of the Data Availability Committee. The setup is equivalent to a 3/5 multisig.
The owner of the Data Availability Committee, can update the member set at any time.
The system consists of the following smart contracts:
The main contract of the Polygon CDK Validium. 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, L2 state roots as well as ZK proofs. It also holds the address of DataAvailabilityCommittee.
Can be upgraded by: ZkFairAdmin
Upgrade delay: None
The escrow contract for user funds. It is mirrored on the L2 side and can be used to transfer ERC20 assets. To transfer funds a user initiated transaction on both sides is required. This contract can store any token.
Can be upgraded by: ZkFairAdmin
Upgrade delay: None
Synchronizes deposit and withdraw merkle trees across L1 and L2. The global root from this contract is injected into the L2 contract.
Can be upgraded by: ZkFairAdmin
Upgrade delay: None
An autogenerated contract that verifies ZK proofs in the CDKValidium system.
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
Upgrade delay: None
Value Locked is calculated based on these smart contracts and tokens:
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.
