Search
Search for projects by name or address
Polygon PoS
Badges
About
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.
Badges
About
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.
Why is the project listed in others?
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.
2025 Jun 12 — 2026 Jun 12
The section shows the operating costs that L2s pay to Ethereum.
2025 Jun 12 — 2026 Jun 12
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.
2026 May 13 — Jun 12
Last 30 day anomalies
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 7h 47m 12s (from 2026 Jun 05, 13:36 UTC until 2026 Jun 05, 21:23 UTC). These typically occur every 30min 18s on average.
No State updates were performed for 7h 47m 12s (from 2026 Jun 05, 13:36 UTC until 2026 Jun 05, 21:23 UTC). These typically occur every 30min 18s on average.
No Tx data submissions were performed for 5h 57m 48s (from 2025 Jul 10, 12:49 UTC until 2025 Jul 10, 18:47 UTC). These typically occur every 30min 18s on average.
No State updates were performed for 5h 57m 48s (from 2025 Jul 10, 12:49 UTC until 2025 Jul 10, 18:47 UTC). These typically occur every 30min 18s on average.
Heimdall v2 upgrade
2025 Jul 10th
Major consensus upgrade replacing Heimdall v1 with Heimdall v2.
Funds can be stolen if
- destination token contract is maliciously upgraded,
- a contract receives a malicious code upgrade. There is no delay on code upgrades (CRITICAL),
- 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,
- validators submit a fraudulent checkpoint allowing themselves to withdraw all locked funds.
Although there is a sequencer set of 105 (called validators), if the cap of 105 is reached, no new stakers can join. A minimum of 100,000 POL stake is required to obtain block 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 L1. The canonical 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 roots. More details in project overview.
Data is guaranteed to be available by an external proof of stake network of validators. On Ethereum, DA is attested via signed block headers.
There is no window for users to exit in case of an unwanted upgrade since contracts are instantly upgradable.
The PoS network is composed of 105 validators. Blocks 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 consensus, withdrawals are frozen.
State updates are settled on Ethereum if signed by at least 2/3+1 of the Polygon PoS validators 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.
Past upgrades
The metrics include upgrades on the currently used proxy contracts. Historical proxy contracts and changes of such are not included.
2026 June 02, 13:21 UTC7changesVali added, cap hit (validator set closed).
Vali added, cap hit (validator set closed).
| contract StakeManager (eth:0x5e3Ef299fDDf15eAa0432E6e66473ace8c13D908) [polygon-pos/StakeManager] { | |
| +++ description: Manages the Polygon PoS validator set. | |
| values.currentValidatorSetSize: | |
| - | 104 |
| + | 105 |
| } |
| contract Polygon Labs Engineering/Security Multisig (eth:0x9d851f8b8751c5FbC09b9E74E6e68E9950949052) [GnosisSafe] { | |
| +++ description: None | |
| values.$members.0: | |
| + | "eth:0xf02BE0dA37dB50BEFA5a525158aa94b50F81D4B2" |
| values.$members.1: | |
| + | "eth:0xe0e8e6bBDef7bbcf8dF1F5Ac0ab9906BFe991d8B" |
| values.$members.2: | |
| + | "eth:0x6Ab87a62E250A5EB09a53Fca832B9Bda480c3890" |
| values.multisigThreshold: | |
| - | "2 of 5 (40%)" |
| + | "2 of 8 (25%)" |
| } |
2026 May 28, 10:19 UTC2changesvali added (permissioned).
vali added (permissioned).
| contract StakeManager (eth:0x5e3Ef299fDDf15eAa0432E6e66473ace8c13D908) [N/A] { | |
| +++ description: None | |
| values.currentValidatorSetSize: | |
| - | 103 |
| + | 104 |
| } |
2026 May 13, 13:43 UTC2changesadjust staking reward.
adjust staking reward.
| contract StakeManager (eth:0x5e3Ef299fDDf15eAa0432E6e66473ace8c13D908) [N/A] { | |
| +++ description: None | |
| values.CHECKPOINT_REWARD: | |
| - | "34695980000000000000000" |
| + | "29414916286149162861491" |
| } |
2026 May 05, 06:53 UTC6changesformatting and minimal refactor for the ERC20PredicateBurnOnly: https://disco.l2beat.com/diff/eth:0x626fb210bf50e201ED62cA2705c16DE2a53DC966/eth:0x4EeA1780c06709D7FA0BCaA6D0f1aB29673586c0 .
formatting and minimal refactor for the ERC20PredicateBurnOnly: https://disco.l2beat.com/diff/eth:0x626fb210bf50e201ED62cA2705c16DE2a53DC966/eth:0x4EeA1780c06709D7FA0BCaA6D0f1aB29673586c0 .
| contract Registry (eth:0x33a02E6cC863D393d6Bf231B697b82F6e499cA71) { | |
| +++ description: Maintains the addresses of the contracts used in the system, part of the old 'plasma bridge'. | |
| values.erc20Predicate: | |
| - | "eth:0x626fb210bf50e201ED62cA2705c16DE2a53DC966" |
| + | "eth:0x4EeA1780c06709D7FA0BCaA6D0f1aB29673586c0" |
| } |
| contract StakeManager (eth:0x5e3Ef299fDDf15eAa0432E6e66473ace8c13D908) { | |
| +++ description: None | |
| values.currentValidatorSetSize: | |
| - | 104 |
| + | 103 |
| } |
| - | Status: DELETED |
| contract ERC20PredicateBurnOnly (eth:0x626fb210bf50e201ED62cA2705c16DE2a53DC966) | |
| +++ description: None |
| + | Status: CREATED |
| contract ERC20PredicateBurnOnly (eth:0x4EeA1780c06709D7FA0BCaA6D0f1aB29673586c0) | |
| +++ description: None |
2026 April 22, 13:55 UTC2changesvali removed.
vali removed.
| contract StakeManager (eth:0x5e3Ef299fDDf15eAa0432E6e66473ace8c13D908) { | |
| +++ description: None | |
| values.currentValidatorSetSize: | |
| - | 105 |
| + | 104 |
| } |
Transactions are ordered by Polygon PoS validators
Polygon PoS is operated by a closed proof-of-stake validator set with 105 active validators. Block 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 | |
|---|---|
| Slot time (inclusion baseline) | 2s |
| Epoch time | 3h 33m |
| Number of block producers | 105 validators |
| Access to block production rights | |
| Stake per validator | 100,000 POL minimum, variable |
| Rate-limit to join | No (permissioned) |
| Deterministic CR gadget | No |
| Additional CR gadgets | No |
Inclusion delay by censorship fraction
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 validator-set changes, or blanket-censorship resistance gadgets.
Censorship resistance
The validator set (on Polygon PoS, validators are both proposers and sequencers) is closed and capped, but includes a diverse set of known entities who share block production rights. There are no specific censorship resistance gadgets built into the protocol.
Selective censorship
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.
Blanket censorship
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.
Walkaway
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.
Destination tokens are upgradeable
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.
Ethereum
Actors:
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.
Ethereum
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 Validators.
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 Plasma proofs is empty, meaning exits cannot be challenged.
Contract used to initiate ERC721 token withdrawals. The function to handle Plasma 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).