Polygon zkEVM Mainnet Beta is Live

2023 Mar 27th

Polygon zkEVM public beta launched.

Learn more
Show more

Knowledge Nuggets


The forced transaction mechanism is currently disabled.

Polygon zkEVM is aiming to become a decentralized Ethereum Layer 2 scalability solution that uses cryptographic zero-knowledge proofs to offer validity and finality of off-chain transactions. Polygon zkEVM wants to be equivalent with the Ethereum Virtual Machine.

If you find something wrong on this page you can submit an issue or edit the information.

Risk Analysis

Sequencer failureState validationData availabilityUpgradeabilityProposer failure

State validation

ZK proofs (SN)

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


10d or no delay

There is a 10d delay for upgrades initiated by the Admin. The Security Council can switch on EmergencyState in which there is no upgrade delay. Currently rollup emergency state is set to false, bridge emergency state is set to false.

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 open source 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. Once the proof is processed on the Ethereum blockchain the L2 block is instantly finalized.

  1. PolygonZkEvm.sol#L817 - Etherscan source code, _verifyAndRewardBatches 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. PolygonZkEvm.sol#L186 - Etherscan source code, sequencedBatches mapping


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. PolygonZkEvm.sol#L454 - 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. PolygonZkEvm.sol#L468 - Etherscan source code, isForceBatchAllowed modifier


Regular exit

The user initiates the withdrawal by submitting a transaction on L2. 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


The system uses the following set of permissioned addresses:

AdminMultisig 0x242d…3e21

Admin of the PolygonZkEvm rollup, can set core system parameters like timeouts, sequencer and aggregator as well as deactivate emergency state. They can also upgrade the PolygonZkEvm 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.

Aggregator 0xdA87…86eA

The trusted aggregator provides the PolygonZkEvm 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.

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.

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 rollup. 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 transaction batches, L2 state roots as well as zk proofs.

Can be upgraded by: AdminMultisig

Upgrade delay: 10d or no delay

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: 10d or no delay

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: AdminMultisig

Upgrade delay: 10d or no delay

FflonkVerifier 0x4F9A…E6e9

An autogenerated contract that verifies zk proofs in the PolygonZkEvm system.

TVL 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 10d delay on code upgrades.

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