Summary Value Secured Activity Onchain costs Milestones & Incidents Risk summary Risk analysis Data availability Upgrades & Governance Updates Operator Withdrawals Other considerations Permissions Smart contracts

Polygon zkEVM

Badges

About

Polygon zkEVM is an EVM-compatible L2 built by Polygon Labs.

Total Value SecuredTVS

$8.41 M7.28%

Past day UOPSDaily UOPS

No data

Gas token

ETH

Type

Other

Purpose

Universal

Chain ID

1101

Tokens breakdown

Value secured breakdown

18.1% with additional trust assumptions

View TVS breakdown

Sequencer failureState validationData availabilityExit windowProposer failure

Explore more in Discovery UI

Badges

About

Polygon zkEVM is an EVM-compatible L2 built by Polygon Labs.

Why is the project listed in others?

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.

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.

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

Onchain costs

Compare

The section shows the operating costs that L2s pay to Ethereum.

Total cost

Avg cost per L2 UOP

Avg cost per day

Compare with other projects

Milestones & Incidents

Migration to Pessimistic Proofs

3 Dec 2025

Polygon zkEVM stops validating the full 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 and moves to 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. accounting proofs.

Learn more

Polygon zkEVM Etrog upgrade

13 Feb 2024

Polygon zkEVM is upgraded to the Polygon Etrog version.

Learn more

Risk summary

Risk analysis

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.. ‘Pessimistic’ proofs only validate 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. accounting.

Data availability

External

Proof construction and state derivation rely fully on data that is NOT published onchain.

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

Data is not stored on chain

Transaction data is kept off-chain. 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. accounting is protected by pessimistic proofs while 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 transitions are not proven on Ethereum.

Upgrades & Governance

A diagram of the upgrades and governance

The regular upgrade process for shared system contracts 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.-specific validiumAn off-chain solution that uses validity proofs for settlement and publishes the data offchain, therefore requiring an additional trust assumption. contracts starts at the PolygonAdminMultisig. For the shared contracts, they schedule a transaction that targets the ProxyAdmin via the Timelock, wait for 3d and then execute the upgrade. An upgrade of the Layer 2 specific validium contract requires first adding a new rollupType through the Timelock and the AgglayerManager (defining the new implementation and verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contracts). Now that the rollupType is created, either the local admin or the PolygonAdminMultisig can immediately upgrade the local system contracts to it. Chains using pessimistic proofs often have completely sovereign upgrade paths from the ones described here, but the shared contracts still remain relevant to them because they use them as escrow.

The PolygonSecurityCouncil can expedite the upgrade process by declaring an emergency state. This state pauses both the shared 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. and the AgglayerManager and allows for instant upgrades through the timelock. Accordingly, instant upgrades for all system contracts are possible with the cooperation of the SecurityCouncil. The emergency state has been activated 1 time(s) since inception.

Furthermore, the PolygonAdminMultisig is permissioned to manage the shared trusted aggregator (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. and proverAn entity that generates the cryptographic proof to convince the verifier that the statement is true. In a ZK-Rollup, the prover generates the ZK (validity) proof to submit to the verifier contract.) for all participating Layer 2s, deactivate the emergency state, obsolete rollupTypes and manage operational parameters and fees in the AgglayerManager directly. The local admin of a specific Aggchain can manage their chain by choosing the 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., manage forced batches and set 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. config. For sovereign chains using pessimistic proofs they can manage any proof logic that might be used on top of the minimal pessimistic one. Creating new Layer 2s (of existing rollupType) is outsourced to the PolygonCreateRollupMultisig but can also be done by the PolygonAdminMultisig. Custom non-shared bridge escrows have their custom upgrade admins listed in the permissions section.

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

11mo 12d ago

Avg upgrade interval

8mo 6d

Updates

5 Dec 2025, 14:20 UTC

High severity

52changes

removal of the rollup proof system, leaving only the pessimistic proofs for the agglayer shared bridge.

	contract AggchainECDSAMultisig (eth:0x519E42c24163192Dca44CD3fBDCEBF6be9130987) {
	+++ description: System contract defining the polygon zkEVM Aggchain logic. It only enforces bridge accounting (pessimistic) proofs to protect the shared bridge while the Aggchain state transitions are not proven. They must instead be signed by 1 aggchainSigner(s).
	name:
-	"PolygonZkEVM"
+	"AggchainECDSAMultisig"
	template:
-	"polygon-cdk/PolygonZkEVM"
+	"polygon-cdk/AggchainECDSAMultisig"
	sourceHashes.1:
-	"0x5912938b92e53d8eb670cbaff45effa91dca7caafcb389b57bf161cdd7585fa3"
+	"0xa58b59f574674919f2c3fb755a6e3e369c0d5f734d8fcca6fe2664629ad8b25e"
	description:
-	"The main system contract defining the polygon zkEVM Layer 2 logic. Entry point for sequencing batches."
+	"System contract defining the polygon zkEVM Aggchain logic. It only enforces bridge accounting (pessimistic) proofs to protect the shared bridge while the Aggchain state transitions are not proven. They must instead be signed by 1 aggchainSigner(s)."
	values.$implementation:
-	"eth:0x7253F329302b1b5E774Ac641EA3743E9E3244f2E"
+	"eth:0x0D49fD0d79723e4D24AaC83f604ED2D3d5fC0f21"
	values.$pastUpgrades.5:
+	["2025-12-03T09:13:23.000Z","0xd8eb9f7bf7594d047e0c8b254b3893eb05daf692b1688adaacd21af144efe2a5",["eth:0x0D49fD0d79723e4D24AaC83f604ED2D3d5fC0f21"]]
	values.$upgradeCount:
-	5
+	6
	values.calculatePolPerForceBatch:
-	0
	values.GLOBAL_EXIT_ROOT_MANAGER_L2:
-	"eth:0xa40D5f56745a118D0906a34E69aeC8C0Db1cB8fA"
	values.INITIALIZE_TX_BRIDGE_LIST_LEN_LEN:
-	249
	values.INITIALIZE_TX_BRIDGE_PARAMS:
-	"0x80808401c9c38094"
	values.INITIALIZE_TX_BRIDGE_PARAMS_AFTER_BRIDGE_ADDRESS:
-	"0x80b9"
	values.INITIALIZE_TX_BRIDGE_PARAMS_AFTER_BRIDGE_ADDRESS_EMPTY_METADATA:
-	"0x80b8"
	values.INITIALIZE_TX_CONSTANT_BYTES:
-	32
	values.INITIALIZE_TX_CONSTANT_BYTES_EMPTY_METADATA:
-	31
	values.INITIALIZE_TX_DATA_LEN_EMPTY_METADATA:
-	228
	values.INITIALIZE_TX_EFFECTIVE_PERCENTAGE:
-	"0xff"
	values.SIGNATURE_INITIALIZE_TX_R:
-	"0x00000000000000000000000000000000000000000000000000000005ca1ab1e0"
	values.SIGNATURE_INITIALIZE_TX_S:
-	"0x000000000000000000000000000000000000000000000000000000005ca1ab1e"
	values.SIGNATURE_INITIALIZE_TX_V:
-	27
	values.TIMESTAMP_RANGE:
-	36
	values._legacypendingVKeyManager:
+	"eth:0x0000000000000000000000000000000000000000"
	values._legacyvKeyManager:
+	"eth:0x0000000000000000000000000000000000000000"
	values.AGGCHAIN_ECDSA_MULTISIG_VERSION:
+	"v1.0.0"
	values.AGGCHAIN_TYPE:
+	"0x0000"
	values.aggchainManager:
+	"eth:0x242daE44F5d8fb54B198D03a94dA45B5a4413e21"
	values.aggchainMetadataManager:
+	"eth:0x0000000000000000000000000000000000000000"
	+++ severity: HIGH
	values.aggchainMultisigHash:
+	"0xc0dac73cba4ff88501dbcab20fea961458322f918942474c014269419567e2c3"
	values.aggchainSigners:
+	["eth:0xD6f0FEEaAB8EAc205b182D51AE05B588a132Be5A"]
	values.aggLayerGateway:
+	"eth:0x046Bb8bb98Db4ceCbB2929542686B74b516274b3"
	+++ description: 0 - ECDSA sig verification, 1 - aggchainVkey verification (read by the pessimistic program)
	+++ severity: HIGH
	values.CONSENSUS_TYPE:
+	1
	values.getAggchainMultisigHash:
+	"0xc0dac73cba4ff88501dbcab20fea961458322f918942474c014269419567e2c3"
	values.getAggchainSignerInfos:
+	[{"addr":"eth:0xD6f0FEEaAB8EAc205b182D51AE05B588a132Be5A","url":"https://zkevm-rpc.com/"}]
	values.getAggchainSigners:
+	["eth:0xD6f0FEEaAB8EAc205b182D51AE05B588a132Be5A"]
	values.getAggchainSignersCount:
+	1
	values.getThreshold:
+	1
	values.MAX_AGGCHAIN_SIGNERS:
+	255
	values.pendingAggchainManager:
+	"eth:0x0000000000000000000000000000000000000000"
	values.threshold:
+	1
	+++ severity: HIGH
	values.useDefaultSigners:
+	false
	+++ severity: HIGH
	values.useDefaultVkeys:
+	false
	values.version:
+	"v1.0.0"
	fieldMeta.CONSENSUS_TYPE:
+	{"severity":"HIGH","description":"0 - ECDSA sig verification, 1 - aggchainVkey verification (read by the pessimistic program)"}
	fieldMeta.aggchainMultisigHash:
+	{"severity":"HIGH"}
	fieldMeta.useDefaultSigners:
+	{"severity":"HIGH"}
	fieldMeta.useDefaultVkeys:
+	{"severity":"HIGH"}
	implementationNames.eth:0x7253F329302b1b5E774Ac641EA3743E9E3244f2E:
-	"PolygonZkEVMEtrog"
	implementationNames.eth:0x0D49fD0d79723e4D24AaC83f604ED2D3d5fC0f21:
+	"AggchainECDSAMultisig"
	}

	EOA (eth:0xD6f0FEEaAB8EAc205b182D51AE05B588a132Be5A) {
	+++ description: None
	receivedPermissions.0.description:
+	"sign state transitions (replaces state validation for this aggchain)."
	receivedPermissions.0.role:
-	".trustedSequencer"
+	".aggchainSigners"
	receivedPermissions.0.permission:
-	"sequence"
+	"interact"
	}

+	Status: CREATED
	reference AgglayerGateway (eth:0x046Bb8bb98Db4ceCbB2929542686B74b516274b3)
	+++ description: None

2 Dec 2025, 09:49 UTC

1change

Rotated trusted sequencer.

	contract PolygonZkEVM (eth:0x519E42c24163192Dca44CD3fBDCEBF6be9130987) {
	+++ description: The main system contract defining the polygon zkEVM Layer 2 logic. Entry point for sequencing batches.
	values.trustedSequencer:
-	"eth:0x148Ee7dAF16574cD020aFa34CC658f8F3fbd2800"
+	"eth:0xD6f0FEEaAB8EAc205b182D51AE05B588a132Be5A"
	}

22 Jul 2025, 13:48 UTC

1change

Updated Fflonk verifier in the initial addresses to the correct one.

New and verified contracts

+	Status: CREATED
	contract Verifier (0x9B9671dB83CfcB4508bF361942488C5cA2b1286D)
	+++ description: Verifies ZK proofs for state roots of this Layer 2 via the PolygonRollupManager.

14 Jul 2025, 12:45 UTC

6changes

Discovery rerun on the same block number with only config-related changes.

New and verified contracts

+	Status: CREATED
	contract daiBridge (0x4A27aC91c5cD3768F140ECabDe3FC2B2d92eDb98)
	+++ description: Custom Bridge escrow for DAI bridged to PolygonZkEVM allowing for a custom L2 tokens contract.

+	Status: CREATED
	contract PolygonZkEVM (0x519E42c24163192Dca44CD3fBDCEBF6be9130987)
	+++ description: The main system contract defining the polygon zkEVM Layer 2 logic. Entry point for sequencing batches.

+	Status: CREATED
	contract usdcBridge (0x70E70e58ed7B1Cec0D8ef7464072ED8A52d755eB)
	+++ description: Custom Bridge escrow for USDC bridged to PolygonZkEVM allowing for a custom L2 tokens contract.

+	Status: CREATED
	contract Verifier (0xc521580cd8586Cc688A7430F9DcE0f6A803F2883)
	+++ description: Verifies ZK proofs for state roots of this Layer 2 via the PolygonRollupManager.

+	Status: CREATED
	contract wstETHBridge (0xf0CDE1E7F0FAD79771cd526b1Eb0A12F69582C01)
	+++ description: Custom Bridge escrow for wstETH bridged to PolygonZkEVM allowing for a custom L2 tokens contract.

+	Status: CREATED
	contract Polygon zkEVM Multisig (0xf694C9e3a34f5Fa48b6f3a0Ff186C1c6c4FcE904)
	+++ description: None

15 Jan 2025, 13:18 UTC

High severity

4changes

Polygon zkEVM upgraded to rollupTypeID 6 (prev 5), this is called the servicing update, and was deployed onchain in oct 2024. It adds minor changes like rollbackBatches() for batches that are not yet verified and allows local chain admins to upgrade to already-deployed new versions for their chain.

Polygon zkEVM upgraded to rollupTypeID 6 (prev 5), this is called the servicing update, and was deployed onchain in oct 2024. It adds minor changes like rollbackBatches() for batches that are not yet verified and allows local chain admins to upgrade to already-deployed new versions for their chain.

	contract PolygonZkEVMEtrog (0x519E42c24163192Dca44CD3fBDCEBF6be9130987) {
	+++ description: None
	sourceHashes.1:
-	"0xf303702e52579ed796873f92868d2ebedd55360bf53043519e6061b19df3eb4b"
+	"0x5912938b92e53d8eb670cbaff45effa91dca7caafcb389b57bf161cdd7585fa3"
	values.$implementation:
-	"0x2650a9a4fC64f63F573EF0F405064EF54BC46f71"
+	"0x7253F329302b1b5E774Ac641EA3743E9E3244f2E"
	values.$pastUpgrades.4:
+	["2025-01-15T12:16:11.000Z","0x9328cfd3d2833dca2d0ea16fbb34f8fc096c26ca8334476c5bf7107f32436029",["0x7253F329302b1b5E774Ac641EA3743E9E3244f2E"]]
	values.$upgradeCount:
-	4
+	5
	}

Operator

Users can't force any transaction

There is no general mechanism to force 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. to include the transaction.

Users can be censored if the operator refuses to include their transactions.

Withdrawals

Regular messaging

The user initiates 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.->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. messages by submitting a regular transaction on this chain. When the blockAn ordered list of transactions and chain-related metadata that gets bundled together and published to the L1/DA layer. Nodes execute the transactions contained within blocks to change the rollup chain’s state. Protocol rules dictate what constitutes a valid block, and invalid blocks are skipped over. containing that transaction is settled, the message becomes available for processing on L1. ZK proofs are required to settle blocks.

AgglayerBridge.sol - source code, claimAsset function

Other considerations

Shared bridge and Pessimistic Proofs

Polygon Agglayer uses a shared 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. escrow for Rollups, Validiums and external chains that opt in to participate in interoperabilityRefers to the capability of different blockchain networks to communicate and share data. It enables the transfer of assets and information between blockchains, facilitating functionality and collaboration between blockchain ecosystems.. Each participating chain needs to provide zk proofs to access any assets in the shared bridge. In addition to the full execution proofs that are used for the state validation of Rollups and Validiums, accounting proofs over the bridges state (Polygon calls them ‘Pessimistic Proofs’) are used by external chains (cdk-erigon-sovereign and cdk-opgeth-sovereign variants). Using the SP1 zkVMA special type of zk proving system that proves the correctness of state transitions of a virtual machine. Computation is represented by a program in a specific instruction language, it can have private and public inputs and public outputs. Most of zkVMs are STARKs. by Succinct, even projects without a full proof systemThe infrastructure that allows projects to verify their state transitions. It is composed by onchain verifiers and offchain provers. The main two flavors are optimistic and ZK proof systems, but they can be combined in a hybrid model. In general though, if a system is able to accept state roots optimistically, even if it has a ZK component, it is considered an optimistic proof system. on Ethereum are able to share the bridge with any other Aggchain without adding additional trust assumptions.

Funds can be lost if the accounting proof system for the bridge (pessimistic proofs, SP1) is implemented incorrectly.
Funds can be stolen if the operator manipulates the L2 state, which is not validated on Ethereum (CRITICAL).

Permissions

A dashboard to explore contracts and permissions

Go to Disco

Explore in Disco

Ethereum

Actors:

PolygonAdminMultisig0x242d…3e21

A Multisig with 5/9 threshold.

Can upgrade with 3d delay
- AgglayerGateway Timelock with 3d delay (no delay if in emergency state) → SharedProxyAdmin
- AgglayerBridge Timelock with 3d delay (no delay if in emergency state) → SharedProxyAdmin
- AgglayerManager Timelock with 3d delay (no delay if in emergency state) → SharedProxyAdmin
- AgglayerGER Timelock with 3d delay (no delay if in emergency state) → SharedProxyAdmin
Can interact with AgglayerGateway
- add new routes from proof selector to verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. / pessimisticVkey for pessimistic proofs with 3d delay Timelock with 3d delay (no delay if in emergency state)
- add or update default aggchain verification keys (aggchainVkey) for any given selectors
- change the aggchainSigners and threshold (a multisig used for permissioned state transitions)
- freeze routes from proof selector to verifier / pessimisticVkey for pessimistic proofs
Can interact with AgglayerBridge
- upgrade the implementation of wrapped tokens deployed by 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. with 3d delay Timelock with 3d delay (no delay if in emergency state)
Can interact with AgglayerManager
- deploy new projects that use predefined rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. types (implementations) and connect them or other Agglayer chains to the PolygonRollupManager
- manage all access control roles, add new rollup types (which are implementation contracts that can then be upgraded to by connected projects), update any connected projects to new rollup types, migrate to pessimistic proofs and rollback batches, connect existing rollups to the PolygonRollupManager with 3d delay Timelock with 3d delay (no delay if in emergency state)
- manage parameters like fees for all connected projects, set the trusted aggregator, stop the emergency state, update projects and obsolete rollup types
Can interact with AggchainECDSAMultisig
- replace the aggchainSigners and the signature threshold (which sign the state transitions of this aggchain), switch to the default signers of the AgglayerGateway, upgrade the aggchain to a newer rollup type of the same aggchain type registered in the AgglayerManager, set the aggchain metadata manager and transfer the aggchainManager role
- set the 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. address
- sole address that can force batches
Can interact with Timelock
- propose, cancel and execute transactions in the timelock, manage all access control roles and change the minimum delay with 6d delay or with 3d delay Timelock with 3d delay (no delay if in emergency state) with 3d delay (no delay if in emergency state) - or - acting directly with 3d delay (no delay if in emergency state)

Participants (9):

0xEB5E…EA72 0xAb35…235E 0xf02B…D4B2 0xdFEd…56Da 0xffbf…3238 0xeD44…dB37 0x516e…46B7 0x2161…d417 0x8B9F…782B

Used in:

AgglayerManager0x5132…7aB2

The central shared managing contract for Polygon Agglayer chains. This contract coordinates chain deployments and proof validation. All connected Layer 2s can be globally paused by activating the ‘Emergency State’. This can be done by the PolygonSecurityCouncil or by anyone after 1 week of inactive verifiers.

Can upgrade with no delay
- AggchainECDSAMultisig

Used in:

PolygonSecurityCouncil0x37c5…Dcb6

A Multisig with 6/8 threshold.

Can interact with AgglayerManager
- activate the emergency state in the PolygonRollupManager and in the shared 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. immediately, effectively pausing all projects connected to them and making system contracts instantly upgradable

Participants (8):

0xFe45…2e4b 0xaF46…261D 0xBDc2…FEFf 0x4c16…8891 0x3ab9…D622 0x49c1…0E86 0x9F7d…86A0 0x2188…1C28

Used in:

PolygonCreateRollupMultisig0xC74e…79dB

A Multisig with 3/5 threshold.

Can interact with AgglayerManager
- deploy new projects that use predefined rollupA blockchain that inherits consensus and data availability from another blockchain called L1. Rollups enable trust minimized bridges with the base layer via proof systems, either optimistic or zero-knowledge. A rollup without a bridge, or without considering the bridge, is called a sovereign rollup. types (implementations) and connect them or other Agglayer chains to the PolygonRollupManager

Participants (5):

0x516e…46B7 0x3038…D3b5 0xD947…fCFC 0xEB5E…EA72 0xFd6F…d56A

Used in:

Polygon zkEVM Multisig0xf694…E904

A Multisig with 5/10 threshold.

Can upgrade with no delay
- daiBridge
- usdcBridge
- wstETHBridge

Participants (10):

0x0991…42c3 0xb771…6ab5 0xD099…48D4 0xc459…5D1D 0xE6Ee…d43a 0xd1B8…5224 0xF53D…065F 0xf56A…7F8f 0x4DE4…44ed 0x4E83…032E

EOA 10xD6f0…Be5A

Can interact with AggchainECDSAMultisig
- sign state transitions (replaces state validation for this aggchain)

EOA 20x20A5…51dE

Can interact with AgglayerManager
- Permissioned to post new state rootsA cryptographic hash succinctly representing a state using a Merkle tree. and global exit roots accompanied by ZK proofs

Used in:

Smart contracts

A dashboard to explore contracts and permissions

Go to Disco

Explore in Disco

A diagram of the smart contract architecture

Ethereum

AggchainECDSAMultisig0x519E…0987 Implementation (Upgradable)Admin

System contract defining the polygon zkEVM Aggchain logic. It only enforces 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. accounting (pessimistic) proofs to protect the shared bridge while the Aggchain state transitions are not proven. They must instead be signed by 1 aggchainSigner(s).

Roles:
- admin: AgglayerManager, PolygonAdminMultisig
- aggchainManager: PolygonAdminMultisig
- aggchainSigners: EOA 1
- forceBatchAddress: PolygonAdminMultisig

Can be upgraded by:

AgglayerManager with no delay

Implementation used in:

AgglayerGateway0x046B…74b3 Implementation (Upgradable)Admin

A verifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. gateway for pessimistic proofs. Manages a map of chains and their verifier keys and is used to route proofs based on the first 4 bytes of proofBytes data in a proof submission. The SP1 verifier is used for all proofs.

Roles:
- addPpRoute: Timelock; ultimately PolygonAdminMultisig
- admin: SharedProxyAdmin; ultimately PolygonAdminMultisig
- aggchainDefaultVKey: PolygonAdminMultisig
- alMultisig: PolygonAdminMultisig
- freezePpRoute: PolygonAdminMultisig

Can be upgraded by:

PolygonAdminMultisig with 3d delay

Proxy used in:

AgglayerBridge

Escrow

0x2a3D…2EDe Implementation (Upgradable)Admin

The shared 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. contract, escrowing user funds sent to Agglayer chains. It is usually mirrored on each chain and can be used to transfer both ERC20 assets and arbitrary messages.

Roles:
- admin: SharedProxyAdmin; ultimately PolygonAdminMultisig
- proxiedTokensManager: Timelock; ultimately PolygonAdminMultisig

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

Can be upgraded by:

PolygonAdminMultisig with 3d delay

Proxy used in:

AgglayerGER0x580b…3CFb Implementation (Upgradable)Admin

A merkle treeA hash-based data structure in which each leaf node is a hash of a block of data, and each non-leaf node is a hash of its children. The root of the tree is a cryptographic fingerprint of the entire data structure. Merkle trees (Merkle Patricia Tries) are used in Ethereum to efficiently store key-value pairs. storage contract aggregating state rootsA cryptographic hash succinctly representing a state using a Merkle tree. of each participating Layer 2Layer 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., thus creating a single global merkle root representing the global state of the Agglayer, the ‘global exit root’. The global exit root is synchronized to all connected Layer 2s to help with their interoperabilityRefers to the capability of different blockchain networks to communicate and share data. It enables the transfer of assets and information between blockchains, facilitating functionality and collaboration between blockchain ecosystems..

Roles:
- admin: SharedProxyAdmin; ultimately PolygonAdminMultisig

Can be upgraded by:

PolygonAdminMultisig with 3d delay

Proxy used in:

Timelock0xEf14…A4EF

A timelock with access control. In the case of an activated emergency state in the AgglayerManager, all transactions through this timelock are immediately executable. The current minimum delay is 3d.

Roles:
- timelockAdmin: PolygonAdminMultisig (no delay if in emergency state), Timelock (no delay if in emergency state); ultimately PolygonAdminMultisig (no delay if in emergency state)

Implementation used in:

daiBridge

Escrow

0x4A27…Db98 Implementation (Upgradable)Admin

Custom 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. escrow for DAI bridged to PolygonZkEVM allowing for a custom 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. tokens contract.

Roles:
- admin: Polygon zkEVM Multisig

The following tokens are included in the value secured calculation:

Can be upgraded by:

Polygon zkEVM Multisig with no delay

usdcBridge

Escrow

0x70E7…55eB Implementation (Upgradable)Admin

Custom 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. escrow for USDC bridged to PolygonZkEVM allowing for a custom 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. tokens contract.

Roles:
- admin: Polygon zkEVM Multisig

The following tokens are included in the value secured calculation:

Can be upgraded by:

Polygon zkEVM Multisig with no delay

wstETHBridge

Escrow

0xf0CD…2C01 Implementation (Upgradable)Admin

Custom 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. escrow for wstETH bridged to PolygonZkEVM allowing for a custom 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. tokens contract.

Roles:
- admin: Polygon zkEVM Multisig

The following tokens are included in the value secured calculation:

Can be upgraded by:

Polygon zkEVM Multisig with no delay

SP1Verifier0x0459…C459

VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for SP1 proofs (v5.0.0).

Implementation used in:

SharedProxyAdmin0x0F99…CC4A

Roles:
- owner: Timelock

Implementation used in:

BridgeLib0x3622…8aB3

Extension contract of the AgglayerBridge for asset metadata…

Implementation used in:

SP1Verifier0xc3c6…AF2A

VerifierAn entity in a ZK-Rollup, often a smart contract, that verifies zero-knowledge proofs submitted by a prover. contract for SP1 proofs (v6.1.0).

Implementation used in: