Search

Search for projects by name

SummaryValue LockedActivityMilestones & IncidentsRisk summaryRisk analysisTechnologyOperatorWithdrawalsPermissionsSmart contracts

ZKFair logoZKFair

Badges

About

ZKFair is a Validium based on Polygon CDK and Celestia DA.

Value Locked
$14.91 M11.6%
Canonically Bridged
$8.90 M
Externally Bridged
$0.00
Natively Minted
$6.00 M
View TVL Breakdown
  • Tokens
  • Daily TPS
    0.120.58%
  • 30D tx count
    296.06 K
  • Type
    Validium
  • Purpose
    Universal
    • Sequencer failureState validationData availabilityExit windowProposer failure

    Badges

    About

    ZKFair is a Validium based on Polygon CDK and Celestia DA.

    Value Locked
    Activity
    Milestones & Incidents

    ZKFair Mainnet is Live

    2023 Dec 20th

    ZKFair launched.

    Learn more
    Risk summary
    The forced transaction mechanism is currently disabled. The project claims to use CelestiaDA but smart contracts on L1 use DAC. Arbitrary messaging passing is removed from the bridge.

    Funds can be lost if

    1. the external data becomes unavailable (CRITICAL).

    Funds can be frozen if

    1. the sequencer refuses to include an exit transaction (CRITICAL).

    Users can be censored if

    1. the operator refuses to include their transactions.

    MEV can be extracted if

    1. the operator exploits their centralized position and frontruns user transactions.
    Risk analysis
    The forced transaction mechanism is currently disabled. The project claims to use CelestiaDA but smart contracts on L1 use DAC. Arbitrary messaging passing is removed from the bridge.
    Sequencer failureState validationData availabilityExit windowProposer failure

    Sequencer failure

    No mechanism

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

    State validation

    ZK proofs (SN)

    SNARKs 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 onchain. There exists a Data Availability Committee (DAC) with a threshold of 3/5 that is tasked with protecting and supplying the data.

    Exit window

    None
    The ZkFair Owner can upgrade with no delay.

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

    Proposer failure

    Self propose

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

    Technology

    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.

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

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

    1. ZKFairValidium.sol#L494 - Etherscan source code, sequencedBatches mapping
    Operator

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

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

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

    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.

    1. PolygonZkEvmBridge.sol#L311 - Etherscan source code, claimAsset function
    Permissions

    The system uses the following set of permissioned addresses:

    Sequencer 0x9eed…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.

    Proposer 0xd688…A027

    The trusted proposer (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.

    ZKFairAdmin 0x0110…B725

    This is a Gnosis Safe with 3 / 4 threshold. Admin of the ZKFairValidium, can set core system parameters like timeouts, sequencer and aggregator as well as deactivate emergency state.

    ZKFairAdmin participants (4) 0x39Fc…09530x3226…BDBc0x4dba…02950xe122…c7aF

    Those are the participants of the ZKFairAdmin.

    ZKFairOwner 0x8933…3A88

    This is a Gnosis Safe with 3 / 4 threshold. 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.

    ZKFairOwner participants (4) 0x9fAe…e6C70x540C…25Ba0xcf62…5b870x4B7f…9976

    Those are the participants of the ZKFairOwner.

    BridgeAdminMultiSig 0xcd14…F25F

    This is a Gnosis Safe with 3 / 4 threshold. The Bridge Admin is a multisig that can be used to set bridge fees and an address into which fees are transferred.

    BridgeAdminMultiSig participants (4) 0x4Ea1…df3e0x44fb…52920x6897…8c25DAC Owner

    Those are the participants of the BridgeAdminMultiSig.

    DAC members (5) 0x033A…3ca20x061D…97ae0x9231…bA170x9d86…1a130xFe1d…118d

    Members of the Data Availability Committee. The setup is equivalent to a 3/5 multisig.

    DAC Owner 0xa57c…0c70

    The owner of the Data Availability Committee, can update the member set at any time.

    TimelockExecutor 0x7557…C527

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

    Smart contracts
    A diagram of the smart contract architecture
    A diagram of the smart contract architecture

    The system consists of the following smart contracts on the host chain (Ethereum):

    ZKFairValidium 0x1CbC…50A5Implementation (Upgradable)Admin

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

    Can be upgraded by:
    ZKFairAdmin

    Upgrade delay: None

    Bridge 0x9cb4…1861Implementation (Upgradable)Admin

    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

    GlobalExitRoot 0x72ab…a40bImplementation (Upgradable)Admin

    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

    FflonkVerifier 0x769E…F46d

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

    ZKFairValidiumDAC 0x997C…125bImplementation (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

    Upgrade delay: None

    Timelock 0x5288…9c17

    Contract upgrades have to go through a 1d timelock unless the Emergency State is activated. It is controlled by the TimelockExecutor.

    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.

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