Search for projects by name or address
Polygon PoS is an EVM-compatible, proof of stake sidechain for Ethereum, planning to become a Validium with a state validating bridge. The bridge is currently validated by Polygon validators and allows for asset as well as data movement between Polygon and... Ethereum.
Polygon PoS is an EVM-compatible, proof of stake sidechain for Ethereum, planning to become a Validium with a state validating bridge. The bridge is currently validated by Polygon validators and allows for asset as well as data movement between Polygon and... Ethereum.
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.
The section shows the operating costs that L2s pay to Ethereum.
This section shows how "live" the project's operators are by displaying how frequently they submit transactions of the selected type. It also highlights anomalies - significant deviations from their typical schedule.
All liveness anomalies detected for this project in the last 30 days, helping you review recent downtime and availability issues.
No Tx data submissions were performed for 5h 57m (from 2025 Jul 10, 12:49 UTC until 2025 Jul 10, 18:47 UTC). These typically occur every 26m 40s on average.
No State updates were performed for 5h 57m (from 2025 Jul 10, 12:49 UTC until 2025 Jul 10, 18:47 UTC). These typically occur every 26m 40s on average.
Rio upgrade
2025 Oct 8th
Performance-focused Polygon PoS upgrade improving 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. production and networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes. efficiency.
Heimdall v2 upgrade
2025 Jul 10th
Major consensusAn agreement on the latest and correct state of a blockchain. Unlike L1 blockchains which coordinate participating nodes with consensus rules, rollups rely on L1s for reaching consensus by checking the state of the rollup smart contract deployed thereon. upgrade replacing Heimdall v1 with Heimdall v2.
Although there is a 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. set of 105 (called validatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier), if the cap of 105 is reached, no new stakers can join. A minimum of 100,000 POL stake is required to obtain 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. production rights. There is no specific censorship resistance mechanism against selective censorship by parts of the active validator set nor a way to force transactions from Ethereum 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.. The canonical 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. between Polygon PoS and Ethereum allows for queuing transactions from the Ethereum and Polygon PoS sides, which cannot be skipped, except for halting the queue entirely.
Currently the system permits invalid state rootsA cryptographic hash succinctly representing a state using a Merkle tree.. More details in project overview.
Data is guaranteed to be available by an external proof of stake networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes. of validatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier. On Ethereum, DA is attested via signed 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. headers.
There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.
The PoS networkA constellation of nodes (peers) that communicate via a peer-to-peer protocol, for example, in propagating transactions and blocks to other nodes. is composed of 105 validatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier. BlocksAn 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. are included in the chain only if signed by 2/3+1 of the network stake. It’s currently not possible to join the set if the validator cap is reached. The current validator cap is set to 105. In the event of a failure in reaching consensusAn agreement on the latest and correct state of a blockchain. Unlike L1 blockchains which coordinate participating nodes with consensus rules, rollups rely on L1s for reaching consensus by checking the state of the rollup smart contract deployed thereon., withdrawals are frozen.
State updates are settled on Ethereum if signed by at least 2/3+1 of the Polygon PoS validatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier stake. Contracts on Ethereum do not check whether the state transitions are valid.
Users can be censored if validators on Polygon decide to not mint tokens after observing an event on Ethereum.
Funds can be stolen if validators decide to mint more tokens than there are locked on Ethereum thus preventing some existing holders from being able to bring their funds back to Ethereum.
Funds can be stolen if validators submit a fraudulent checkpoint allowing themselves to withdraw all locked funds.
The metrics include upgrades on the currently used proxy contracts. Historical proxy contracts and changes of such are not included.
MS signer change.
MS signer change.
| contract GnosisSafe (eth:0x424bDE99FCfB68c5a1218fd3215caFfD031f19C4) [GnosisSafe] { | |
| +++ description: None | |
| values.$members.3: | |
| - | "eth:0x1319279d6d54dB0883F7bAF822191c7184Db0c3d" |
| + | "eth:0x28260fD38F737e98F1599eCd385d4eB13C5A7A1f" |
| } | |
Two members were removed from the Safe that holds the Polygon RootChainManager's token-mapping role. The threshold remains 4, leaving a 4-of-12 Safe instead of 4-of-14.
Two members were removed from the Safe that holds the Polygon RootChainManager’s token-mapping role. The threshold remains 4, leaving a 4-of-12 Safe instead of 4-of-14.
| contract GnosisSafe (eth:0x424bDE99FCfB68c5a1218fd3215caFfD031f19C4) [GnosisSafe] { | |
| +++ description: None | |
| values.$members.7: | |
| - | "eth:0xF045025C845E786E343Df30cC6f67ec6BB822b34" |
| values.$members.9: | |
| - | "eth:0xe76c5A6DA94Ed348a80869f26eBd0e5e082664b9" |
| values.multisigThreshold: | |
| - | "4 of 14 (29%)" |
| + | "4 of 12 (33%)" |
| } | |
Two signers were rotated in one Safe. The Polygon Labs Engineering/Security Multisig rotated one signer and removed another, while the validator set grew from 102 to 105 (max).
Two signers were rotated in one Safe. The Polygon Labs Engineering/Security Multisig rotated one signer and removed another, while the validator set grew from 102 to 105 (max).
| contract GnosisSafe (eth:0x424bDE99FCfB68c5a1218fd3215caFfD031f19C4) [GnosisSafe] { | |
| +++ description: None | |
| values.$members.0: | |
| + | "eth:0x2100482bc290716DE46e38046EeD343cfb1aC740" |
| values.$members.1: | |
| + | "eth:0x61Cb29AF9E503f0e2d88717f388931f1d10DE768" |
| values.$members.5: | |
| - | "eth:0xdEb97974dfCC73178672205A1eadDc2BDeAc1Bd4" |
| values.$members.8: | |
| - | "eth:0x6624307a4f672ec5C289fBA196952902BB518dc0" |
| } | |
| contract StakeManager (eth:0x5e3Ef299fDDf15eAa0432E6e66473ace8c13D908) [polygon-pos/StakeManager] { | |
| +++ description: Manages the Polygon PoS validator set. | |
| values.currentValidatorSetSize: | |
| - | 102 |
| + | 105 |
| } | |
| contract Polygon Labs Engineering/Security Multisig (eth:0x9d851f8b8751c5FbC09b9E74E6e68E9950949052) [GnosisSafe] { | |
| +++ description: None | |
| values.$members.1: | |
| - | "eth:0xe0e8e6bBDef7bbcf8dF1F5Ac0ab9906BFe991d8B" |
| + | "eth:0xFB2a738AE435610354b132c4a4ee647558f663eb" |
| values.$members.6: | |
| - | "eth:0xED7cC82235A7757702475c8f77c7830c095FB5a2" |
| values.multisigThreshold: | |
| - | "2 of 8 (25%)" |
| + | "2 of 7 (29%)" |
| } | |
Add 4 signers to Multisig.
Add 4 signers to Multisig.
| contract GnosisSafe (eth:0x424bDE99FCfB68c5a1218fd3215caFfD031f19C4) [GnosisSafe] { | |
| +++ description: None | |
| values.$members.0: | |
| + | "eth:0x9f02595fBFD199C4cBC02878fc9B2b2E07b0840C" |
| values.$members.1: | |
| + | "eth:0x1319279d6d54dB0883F7bAF822191c7184Db0c3d" |
| values.$members.2: | |
| + | "eth:0x6Ab87a62E250A5EB09a53Fca832B9Bda480c3890" |
| values.$members.3: | |
| + | "eth:0x573D7a729cfcF20B81D70732d625Ae31549B8b91" |
| values.multisigThreshold: | |
| - | "4 of 10 (40%)" |
| + | "4 of 14 (29%)" |
| } | |
Vali added, signer rotated.
Vali added, signer rotated.
| contract GnosisSafe (eth:0x424bDE99FCfB68c5a1218fd3215caFfD031f19C4) [GnosisSafe] { | |
| +++ description: None | |
| values.$members.0: | |
| - | "eth:0x6c20ea7778EA9F3Afd74Ce4538bc4D9d61E6ABb1" |
| + | "eth:0xFAc88BB6229F47A31A78F0Ba91E5a541Cb1866a3" |
| } | |
| contract StakeManager (eth:0x5e3Ef299fDDf15eAa0432E6e66473ace8c13D908) [polygon-pos/StakeManager] { | |
| +++ description: Manages the Polygon PoS validator set. | |
| values.currentValidatorSetSize: | |
| - | 101 |
| + | 102 |
| } | |
Polygon PoS is operated by a closed proof-of-stake validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier set with 105 active validators. 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. production rights are given to validators randomly (stake-weighted) for the duration of a span. In practice, validators delegate the block production further to centralised validator-elected block producers (VeBloPs). Ethereum smart contracts accept checkpoints signed by more than two thirds of Polygon PoS validator stake.
| Sequencer set spec sheet | |
|---|---|
| L2 block time | 2s |
| Proposer rotation | |
| Number of block producers | 105 validators 3.56 B POL |
| Access to block production rights | |
| Stake per validator | |
| Rate-limit to join | No (permissioned) |
| Deterministic CR gadget | No |
| Additional CR gadgets | No |
T99 inclusion delay in a static sequencer set by censoring fraction of sequencers/validators
The chart models live-chain selective censorship only. Since proposing is stake-weighted, the x-axis represents the censoring POL stake, and does not cover validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier-set changes, or blanket-censorship resistance gadgets.
The validatorIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier set (on Polygon PoS, validators are both proposers and sequencers) is closed and capped, but includes a diverse set of known entities who share 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. production rights. There are no specific censorship resistance gadgets built into the protocol.
As long as the Polygon PoS blockchain is producing blocks, users can expect to include their transactions due to the rotating, diverse block producers, even if they are censored by some of them. Unfortunately, the rotation is very slow (see span time) and even just a few entities censoring can cause long inclusion delays.
Validators holding more than 1/3 of Polygon PoS stake among them can censor users if they actively refuse to attest to blocks with their transactions. Polygon Multisig controls the core smart contracts on Ethereum and can administer the validator set (including malicious changes) as a consequence.
If validators holding more than 1/3 of the stake on Polygon PoS stop block production, the chain stops and there is no way for users to include any transactions. As the validator set is currently closed by a permissioned smart contract setting on ethereum, walkaway of the permissioned actor would require social coordination and a hard fork to progress the chain.
Users can be censored if the active span proposer censors them, or if at least one third of Polygon PoS stake refuses to attest blocks that include their transactions.
Tokens transferred end up as wrapped ERC20 proxies, some of them are upgradable. The contract is named UChildERC20Proxy.
Funds can be stolen if destination token contract is maliciously upgraded.

A Multisig with 5/9 threshold. Can propose and execute code upgrades. Can arbitrarily moves tokens out of the ERC20 escrow without a contract upgrade.


Contract storing Polygon PoS chain checkpoints. Note that validity of these checkpoints is not verified, it is assumed to be valid if signed by 2/3 of the Polygon ValidatorsIn the context of L2s, a Validator is an actor that validates the correctness of state transitions. For optimistic rollups this corresponds to challengers, and for ZK rollups this corresponds to the onchain verifier.
Smart contract allowing whitelisted addresses to send messages to contracts on Polygon PoS chain.
Main configuration contract to manage tokens, token types, escrows (predicates) for given token types. It also serves as an entry point for deposits and withdrawals effectively acting as a token router.
Main configuration contract to manage stakers and their voting power and validate checkpoint signatures.
Contains logging and getter functions about staking on Polygon.
Maintains the addresses of the contracts used in the system.
Contract to deposit and escrow ETH, ERC20 or ERC721 tokens. Currently only used for POL.
All supported tokens in this escrow are included in the value secured calculation.
Contract handling users’ withdrawal finalization for tokens escrowed in DepositManager.
Contract used to initiate ERC20 token withdrawals. The function to handle PlasmaPlasma is an offchain scaling solution that is able to support offchain data availability by allowing users to exit even when the data is unavailable. Usually, though, Plasma projects require users to frequently monitor the chain (e.g. at least once per week) to ensure that they can exit in time if necessary. There are attempts to support general smart contracts, but the exit mechanism is often limited to simpler applications. proofs is empty, meaning exits cannot be challenged.
Contract used to initiate ERC721 token withdrawals. The function to handle PlasmaPlasma is an offchain scaling solution that is able to support offchain data availability by allowing users to exit even when the data is unavailable. Usually, though, Plasma projects require users to frequently monitor the chain (e.g. at least once per week) to ensure that they can exit in time if necessary. There are attempts to support general smart contracts, but the exit mechanism is often limited to simpler applications. proofs is empty, meaning exits cannot be challenged.
Contains events used by other contracts in the system.
NFTs used to represent a withdrawal in the withdrawal PriorityQueue (Only used for tokens initially deposited via DepositManager).
Contract enforcing delay on code upgrades. The current delay is 0s.
All supported tokens in this escrow are included in the value secured calculation.
All supported tokens in this escrow are included in the value secured calculation.
All supported tokens in this escrow are included in the value secured calculation.


The current deployment carries some associated risks:
Funds can be stolen if a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL).