Polygon zkEVM logoPolygon zkEVM

Polygon zkEVM is a EVM-compatible ZK Rollup built by Polygon Labs.
Value Locked

$147.14 M

9.68%

Canonically Bridged
$147.14 M
Externally Bridged
$0.00
Natively Minted
$0.00
  • Tokens
  • Daily TPS
    0.1427.09%
  • 30D tx count
    292.55 K
  • Stage
    Stage 0
  • Type
    ZK Rollup
  • Purpose
    Universal
  • ...

    ...

    ...

    Milestones

    Polygon zkEVM Etrog upgrade

    2024 Feb 13th

    Polygon zkEVM is upgraded to the Polygon Etrog version.

    Learn more

    Polygon zkEVM Mainnet Beta is Live

    2023 Mar 27th

    Polygon zkEVM public beta launched.

    Learn more
    Risk summary
    The forced transaction mechanism is currently disabled.
    Risk analysis
    The forced transaction mechanism is currently disabled.
    Sequencer failureState validationData availabilityExit windowProposer failure

    State validation

    ZK proofs (SN)

    zkSNARKS are zero knowledge proofs that ensure state correctness, but require trusted setup.

    Data availability

    On chain

    All of the data needed for proof construction is published on chain. Unlike most ZK rollups transactions are posted instead of state diffs.

    Exit window

    None
    The Security Council can remove the delay on upgrades.

    Even though there is a 10d 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 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.

    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.

    Rollup stage
    Polygon zkEVMPolygon zkEVM is a
    Stage 0
    ZK Rollup.
    Learn more about Rollup stages
    Please keep in mind that these stages do not reflect rollup security, this is an opinionated assessment of rollup maturity based on subjective criteria, created with a goal of incentivizing projects to push toward better decentralization. Each team may have taken different paths to achieve this goal.
    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. PolygonRollupManager.sol - Etherscan source code, _verifyAndRewardBatches function

    Zero knowledge STARK and SNARK cryptography is used

    Despite their production use zkSTARKs and zkSNARKs proof systems are still relatively new, complex and they rely on the proper implementation of the polynomial constraints used to check validity of the Execution Trace. In addition zkSNARKs require a trusted setup to operate.

    • Funds can be lost if the proof system is implemented incorrectly.

    1. PolygonZkEVMEtrog.sol - Etherscan source code, verifyBatches function

    All transaction data is recorded on chain

    All executed transactions are submitted to an on chain smart contract. The execution of the rollup is based entirely on the submitted transactions, so anyone monitoring the contract can know the correct state of the rollup chain.

    1. PolygonZkEVMEtrog.sol - Etherscan source code, sequenceBatches function
    State derivation
    Node software

    Node software can be found here.

    Compression scheme

    No compression scheme yet.

    Genesis state

    The genesis state, whose corresponding root is accessible as Batch 0 root in the _legacyBatchNumToStateRoot variable of PolygonRollupManager, is available here.

    Data format

    The trusted sequencer batches transactions according to the specifications documented here.

    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. PolygonZkEVMEtrog.sol - 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. PolygonZkEVMEtrog.sol - Etherscan source code, forceBatchAddress address
    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. PolygonZkEvmBridgeV2.sol - Etherscan source code, claimAsset function
    Upgrades & Governance
    A diagram of the upgrades and governance
    A diagram of the upgrades and governance

    All main contracts and the verifier are upgradable by the 2 / 3 AdminMultisig through a timelock that owns ProxyAdmin. Addresses of trusted sequencer, aggregator and operational parameters (like fees) on the PolygonRollupManager can be instantly set by the AdminMultisig. Escrow contracts are upgradable by the EscrowsAdmin 5 / 10 multisig.

    PolygonZkEVMTimelock is a modified version of TimelockController that disables delay in case of a manually enabled or triggered emergency state in the PolygonRollupManager. It otherwise has a 10d delay.

    The process to upgrade the PolygonRollupManager-implementation and / or the verifier has two steps: 1) A newRollupType-transaction is added by the AdminMultisig to the timelock, which in turn can call the addNewRollupType() function in the PolygonRollupManager. In a non-emergency state, this allows potential reviews of the new rollup type while it sits in the timelock. 2) After the delay period, the rollup implementation can be upgraded to the new rollup type by the AdminMultisig calling the updateRollup()-function in the PolygonRollupManager directly.

    The critical roles in the PolygonRollupManager can be changed through the timelock, while the trusted Aggregator role can be granted by the AdminMultisig directly.

    The 6 / 8 SecurityCouncil multisig can manually enable the emergency state in the PolygonRollupManager.

    Permissions

    The system uses the following set of permissioned addresses:

    AdminMultisig 0x242d…3e21

    Admin of the PolygonZkEVMEtrog rollup, can set core system parameters like timeouts, sequencer and aggregator as well as deactivate emergency state. They can also upgrade the PolygonZkEVMEtrog contracts, but are restricted by a 10d delay unless rollup is put in the Emergency State. This is a Gnosis Safe with 2 / 3 threshold.

    AdminMultisig participants 0x4c16…88910xA0B0…f2270xEad7…9dB2

    Those are the participants of the AdminMultisig.

    Sequencer 0x148E…2800

    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 (Trusted Aggregator) 0x6329…f7ab0x20A5…51dE

    The trusted proposer (called Aggregator) provides ZK proofs for all the supported systems. 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.

    SecurityCouncil 0x37c5…Dcb6

    The Security Council 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 6 / 8 threshold.

    Those are the participants of the SecurityCouncil.

    Forced Batcher 0x242d…3e21

    Sole account allowed to submit forced transactions. If this address is the zero address, anyone can submit forced transactions.

    RollupManagerAdminMultisig 0x242d…3e21

    Admin of the Polygon Rollup Manager contract, can set core system parameters like timeouts and aggregator as well as deactivate emergency state. This is a Gnosis Safe with 2 / 3 threshold.

    RollupManagerAdminMultisig participants 0x4c16…88910xA0B0…f2270xEad7…9dB2

    Those are the participants of the RollupManagerAdminMultisig.

    EscrowsAdmin 0xf694…E904

    Escrows Admin can instantly upgrade wstETH, DAI and USDC bridges. This is a Gnosis Safe with 5 / 10 threshold.

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

    The system consists of the following smart contracts:

    The main contract of the Polygon zkEVM. Contains sequenced transaction batch hashes and forced transaction logic.

    Can be upgraded by: AdminMultisig

    Upgrade delay: None

    PolygonzkEVMVerifier 0x0775…Df81

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

    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 Security Council, by proving a soundness error or by presenting a sequenced batch that has not been aggregated before a 7d timeout. This contract receives L2 state roots as well as ZK proofs.

    Can be upgraded by: AdminMultisig

    Upgrade delay: None

    The escrow contract for user funds. It is mirrored on the L2 side and can be used to transfer both ERC20 assets and arbitrary messages. To transfer funds a user initiated transaction on both sides is required. This contract can store any token.

    Can be upgraded by: AdminMultisig

    Upgrade delay: None

    Synchronizes deposit and withdraw merkle trees across L1 and the L2s. The global root from this contract is injected into the L2 contracts.

    Can be upgraded by: AdminMultisig

    Upgrade delay: None

    Timelock 0xEf14…A4EF

    Contract upgrades have to go through a 10d timelock unless the Emergency State is activated. It can also add rollup types that can be used to upgrade verifier contracts of existing systems. It is controlled by the AdminMultisig.

    Value Locked is calculated based on these smart contracts and tokens:

    Escrow for DAI

    Can be upgraded by: EscrowAdmin

    Escrow for wstETH

    Can be upgraded by: EscrowAdmin

    Escrow for USDC

    Can be upgraded by: EscrowAdmin

    The current deployment carries some associated risks:

    • Funds can be stolen if a contract receives a malicious code upgrade. There is a 10d delay on code upgrades.

    1. State injections - stateRoot and exitRoot are part of the validity proof input.
    Knowledge nuggets
    If you find something wrong on this page you can submit an issue or edit the information