Search

Search for projects by name or address

Polygon PoS logo
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...


  • Total Value SecuredTVS
    $4.06 B0.83%
  • Past day UOPSDaily UOPS
    64.667.96%
  • Type
    Other
  • Purpose
    Universal

  • Chain ID
    137

  • Tokens breakdown


    Sequencer failureState validationData availabilityExit windowProposer failure

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

    Why is the project listed in others?

    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.


    Total
    Canonically BridgedCanonically Bridged ValueCanonical
    Natively MintedNatively Minted TokensNative
    Externally BridgedExternally Bridged ValueExternal

    ETH & derivatives
    Stablecoins
    BTC & derivatives
    Other
    Compare with other projects
    Chain stats
    Transfer size
    Under $100
    $100-$1K
    $1K-$10K
    $10K-$100K
    Over $100K
    Transfer type distribution

    Past Day UOPS
    Past Day Ops count
    Max. UOPS
    Past day UOPS/TPS Ratio
    Compare with other projects

    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

    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.

    No ongoing anomalies detected

    Avg. tx data subs. interval
    Avg. state updates interval
    Past 30 days anomalies
    100% normal uptime

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

    Learn more

    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.

    Learn more
    Sequencer failureState validationData availabilityExit windowProposer failure
    Sequencer failure
    Decentralized Sequencer Set

    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.

    State validation
    None

    Currently the system permits invalid state rootsA cryptographic hash succinctly representing a state using a Merkle tree.. More details in project overview.

    Data availability
    PoS network

    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.

    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

    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.

    No state validation

    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.

    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
    21
    Last upgrade
    1y 1mo ago
    Avg upgrade interval
    9mo
    2026 September 15, 11:45 UTC
    1change

    MS signer change.

    contract GnosisSafe (eth:0x424bDE99FCfB68c5a1218fd3215caFfD031f19C4) [GnosisSafe] {
    +++ description: None
    values.$members.3:
    - "eth:0x1319279d6d54dB0883F7bAF822191c7184Db0c3d"
    + "eth:0x28260fD38F737e98F1599eCd385d4eB13C5A7A1f"
    }
    2026 July 29, 11:41 UTC
    3changes

    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%)"
    }
    2026 July 23, 14:06 UTC
    8changes

    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%)"
    }
    2026 July 21, 08:55 UTC
    5changes

    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%)"
    }
    2026 July 17, 07:49 UTC
    2changes

    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
    }

    Transactions are ordered by Polygon PoS validators

    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 time2s
    Proposer rotation
    Number of block producers105 validators
    3.56 B POL
    Access to block production rights
    Stake per validator
    Rate-limit to joinNo (permissioned)
    Deterministic CR gadgetNo
    Additional CR gadgetsNo

    Inclusion delay by censorship fraction

    T99 inclusion delay in a static sequencer set by censoring fraction of sequencers/validators

    Top 1: Upbit Staking
    Top 2: +Coinbase
    Top 3: +Luganodes
    Top 4: +Anonymous 194

    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.

    Censorship resistance

    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.

    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.

    1. Polygon PoS architecture documentation

    Destination tokens are upgradeable

    Note: This section requires more research and might not present accurate information.

    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 dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner

    Ethereum

    Actors:

    PolygonMultisig0xFa7D…b74c

    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.

    A dashboard to explore contracts and permissions
    Go to Disco
    Disco UI Banner
    A diagram of the smart contract architecture
    A diagram of the smart contract architecture

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

    StateSender0x28e4…bFbE

    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.

    StakingInfo0xa59C…512B

    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.

    ERC20PredicateBurnOnly0x4EeA…86c0

    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.

    ERC721PredicateBurnOnly0x36C2…1d1b

    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.

    Generic escrow
    Escrow
    0x21ad…D3E4

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

    The following tokens are included in the value secured calculation:
    ETH token logo
    Escrow for ETH
    Escrow
    0xa45b…DDe8
    The following tokens are included in the value secured calculation:
    ETH token logo

    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).