Search
Search for projects and tokens by name or address
Polygon PoSPolygon 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.
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.
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 20s 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 20s on average.
Permissioned validator entry
2026 Oct 13th
Each new 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 needs approval from governance or a permissioned EOA.
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.
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.
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 104 (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), capped at 105. Validator entry is permissioned. 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 104 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.
Past upgrades
The metrics include upgrades on the currently used proxy contracts. Historical proxy contracts and changes of such are not included.
2026 October 16, 09:53 UTCHigh severity12changesStakeManager upgrade (PIP-91): joining the validator set now needs a single-use pass from the ValidatorPass module registered in the Registry. The pass binds the validator address, consensus key and delegation choice, and expires. Polygon governance (Polygon Multisig via Timelock and Governance, no delay) and the EOA eth:0x4580559314cbBd84B595a6EC52e4dF5cdD54EFc4 can issue and revoke passes. Entry stays capped at validatorThreshold . Validator auctions ( startAuction , confirmAuctionBid , dethroneAndStake ), slash , unjail , the SlashingManager path in transferFunds and the initializers are removed. Removing the ValidatorPass from the Registry makes entry below the cap permissionless again. - https://disco.l2beat.com/diff/eth:0x3AD88467E40399dc6Ae10427f8B0842348d9076c/eth:0x428D1067b33B2bCa826cF66344dbEcBd5AA6506e
StakeManager upgrade (PIP-91): joining the validator set now needs a single-use pass from the ValidatorPass module registered in the Registry. The pass binds the validator address, consensus key and delegation choice, and expires. Polygon governance (Polygon Multisig via Timelock and Governance, no delay) and the EOA eth:0x4580559314cbBd84B595a6EC52e4dF5cdD54EFc4 can issue and revoke passes. Entry stays capped at validatorThreshold. Validator auctions (startAuction, confirmAuctionBid, dethroneAndStake), slash, unjail, the SlashingManager path in transferFunds and the initializers are removed. Removing the ValidatorPass from the Registry makes entry below the cap permissionless again.
- https://disco.l2beat.com/diff/eth:0x3AD88467E40399dc6Ae10427f8B0842348d9076c/eth:0x428D1067b33B2bCa826cF66344dbEcBd5AA6506e
| contract StakeManager (eth:0x5e3Ef299fDDf15eAa0432E6e66473ace8c13D908) [polygon-pos/StakeManager] { | |
| +++ description: Manages the Polygon PoS validator set. | |
| sourceHashes.1: | |
| - | "0xc1bf1e1ffffdb1c23aebc663048d79f349bed55ade9d09b835d75d291c6d4f61" |
| + | "0x8d3d310e7641961f0013dcc2f82e93a2956413df438a44b49c3f084f0167a0d9" |
| values.$implementation: | |
| - | "eth:0x3AD88467E40399dc6Ae10427f8B0842348d9076c" |
| + | "eth:0x428D1067b33B2bCa826cF66344dbEcBd5AA6506e" |
| values.$pastUpgrades.9: | |
| + | ["2026-10-13T09:57:59.000Z","0x53ddccd09c36bde3691fc33282b54679019dad1f4f8aa9fdee0d44cd45b1ab65",["eth:0x428D1067b33B2bCa826cF66344dbEcBd5AA6506e"]] |
| values.$upgradeCount: | |
| - | 9 |
| + | 10 |
| values.implementation: | |
| - | "eth:0x3AD88467E40399dc6Ae10427f8B0842348d9076c" |
| + | "eth:0x428D1067b33B2bCa826cF66344dbEcBd5AA6506e" |
| +++ description: Validator entry gate read from the Registry on every new stake. While set, a new validator must redeem a pass from it. The zero address makes entry permissionless up to the validator cap. | |
| +++ severity: HIGH | |
| values.validatorPass: | |
| - | "eth:0x0000000000000000000000000000000000000000" |
| + | "eth:0x938529C189525e9a03c66C417D337BE9B5762bA4" |
| implementationNames.eth:0x3AD88467E40399dc6Ae10427f8B0842348d9076c: | |
| - | "StakeManager" |
| implementationNames.eth:0x428D1067b33B2bCa826cF66344dbEcBd5AA6506e: | |
| + | "StakeManager" |
| } | |
| contract Governance (eth:0x6e7a5820baD6cebA8Ef5ea69c0C92EbbDAc9CE48) [polygonposbridge/Governance] { | |
| +++ description: Simple contract that allows the owner to call an `update` function on arbitrary contracts. | |
| directlyReceivedPermissions: | |
| + | [{"permission":"interact","from":"eth:0x938529C189525e9a03c66C417D337BE9B5762bA4","description":"grant and revoke the role that issues validator passes.","role":".defaultAdminAC"},{"permission":"interact","from":"eth:0x938529C189525e9a03c66C417D337BE9B5762bA4","description":"issue and revoke the single-use passes that new Polygon PoS validators need to join the validator set.","role":".passIssuerAC"}] |
| } | |
| contract Timelock (eth:0xCaf0aa768A3AE1297DF20072419Db8Bb8b5C8cEf) [N/A] { | |
| +++ description: None | |
| receivedPermissions.2: | |
| + | {"permission":"interact","from":"eth:0x938529C189525e9a03c66C417D337BE9B5762bA4","description":"grant and revoke the role that issues validator passes.","role":".defaultAdminAC","via":[{"address":"eth:0x6e7a5820baD6cebA8Ef5ea69c0C92EbbDAc9CE48"}]} |
| receivedPermissions.3: | |
| + | {"permission":"interact","from":"eth:0x938529C189525e9a03c66C417D337BE9B5762bA4","description":"issue and revoke the single-use passes that new Polygon PoS validators need to join the validator set.","role":".passIssuerAC","via":[{"address":"eth:0x6e7a5820baD6cebA8Ef5ea69c0C92EbbDAc9CE48"}]} |
| } | |
| + | Status: CREATED |
| contract ValidatorPass (eth:0x938529C189525e9a03c66C417D337BE9B5762bA4) [polygon-pos/ValidatorPass] | |
| +++ description: Validator entry gate registered in the Registry under `validatorPass`. The StakeManager only admits a new validator who redeems a single-use pass bound to their address, consensus key and delegation choice. | |
2026 October 01, 10:41 UTC2changesStakeManager CHECKPOINT REWARD raised by the PolygonMultisig (via Governance) from ~25,213 to 64,500 POL per checkpoint (tx 0x2f5cad77ffd2601301287b7644cea34fe0d5b5424e620791c2aff83db484ae2c). The active validator set shrank from 105 to 104.
StakeManager CHECKPOINT_REWARD raised by the PolygonMultisig (via Governance) from ~25,213 to 64,500 POL per checkpoint (tx 0x2f5cad77ffd2601301287b7644cea34fe0d5b5424e620791c2aff83db484ae2c). The active validator set shrank from 105 to 104.
| contract StakeManager (eth:0x5e3Ef299fDDf15eAa0432E6e66473ace8c13D908) [polygon-pos/StakeManager] { | |
| +++ description: Manages the Polygon PoS validator set. | |
| values.CHECKPOINT_REWARD: | |
| - | "25212785388127853881278" |
| + | "64500000000000000000000" |
| values.currentValidatorSetSize: | |
| - | 105 |
| + | 104 |
| } | |
2026 September 15, 11:45 UTC1changeMS signer change.
MS signer change.
| contract GnosisSafe (eth:0x424bDE99FCfB68c5a1218fd3215caFfD031f19C4) [GnosisSafe] { | |
| +++ description: None | |
| values.$members.3: | |
| - | "eth:0x1319279d6d54dB0883F7bAF822191c7184Db0c3d" |
| + | "eth:0x28260fD38F737e98F1599eCd385d4eB13C5A7A1f" |
| } | |
2026 July 29, 11:41 UTC3changesTwo 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%)" |
| } | |
2026 July 23, 14:06 UTC8changesTwo 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%)" |
| } | |
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 104 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 | 104 validators 3.61 B POL |
| Access to block production rights | |
| Stake per validator | |
| 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 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 joining the validator set is gated by permissioned actors 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 upgrade with no delay
- ERC1155Predicate Timelock
- WithdrawManager Timelock
- MintableERC1155Predicate Timelock
- DepositManager Timelock
- ERC20Predicate Timelock
- StakeManager Timelock
- EventsHub Timelock
- Governance Timelock
- EtherPredicate Timelock
- RootChain Timelock
- MintableERC721Predicate Timelock
- MintableERC20Predicate Timelock
- RootChainManager Timelock
- ChainExitERC1155Predicate
- ERC721Predicate Timelock
- Can interact with ERC1155Predicate
- assign any access control roles that can access the escrow
- Can interact with CustomPredicate
- manage the roles of the predicate
- Can interact with MintableERC1155Predicate
- assign any access control roles that can access the escrow
- move any tokens to or from the escrow
- Can interact with DepositManager
- can update the root chain it references Timelock
- Can interact with ERC20Predicate
- assign any access control roles that can access the escrow
- Can interact with EtherPredicate
- assign any access control roles that can access the escrow
- Can interact with RootChain
- can delete arbitrary checkpoints Timelock
- Can interact with MintableERC721Predicate
- assign any access control roles that can access the escrow
- Can interact with ValidatorPass
- approve new 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 to join the Polygon PoS validator set Timelock → Governance
- grant and revoke the role that approves new validators Timelock → Governance
- Can interact with MintableERC20Predicate
- assign any access control roles that can access the escrow
- Can interact with RootChainManager
- can migrate the canonically bridged USDT token to a native or external version
- map new root tokens to child tokens and token types
- replace the checkpoint manager and the state sender, register predicates, remap or unmap tokens and manage all roles. A malicious checkpoint manager can authorize arbitrary exits from all escrows
- Can interact with Timelock
- execute transactions that are ready
- manage all access control roles and change the minimum delay Timelock
- propose and cancel transactions
- Can interact with ERC721Predicate
- assign any access control roles that can access the escrow
Main configuration contract to manage tokens, token types and the escrows (predicates) for each token type. It is the entry point for deposits and withdrawals and verifies exits against the checkpoints of the checkpoint manager.
- Can interact with ERC1155Predicate
- move any tokens to or from the escrow
- Can interact with CustomPredicate
- forward exit data to root contracts
- Can interact with MintableERC1155Predicate
- move any tokens to or from the escrow
- Can interact with ERC20Predicate
- move any tokens to or from the escrow
- Can interact with EtherPredicate
- move any tokens to or from the escrow
- Can interact with MintableERC721Predicate
- move any tokens to or from the escrow
- Can interact with MintableERC20Predicate
- move any tokens to or from the escrow
- Can interact with ChainExitERC1155Predicate
- move any tokens to or from the escrow
- Can interact with ERC721Predicate
- move any tokens to or from the escrow
A Multisig with 4/12 threshold.
- Can interact with RootChainManager
- map new root tokens to child tokens and token types
A Multisig with 2/5 threshold. Member of PolygonMultisig.
A Multisig with 2/7 threshold. Member of PolygonMultisig.
- Can interact with ChainExitERC1155Predicate
- assign any access control roles that can access the escrow
- move any tokens to or from the escrow
- Can interact with ValidatorPass
- approve new 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 to join the Polygon PoS validator set
Ethereum
Escrow (predicate) for one token type. The RootChainManager locks deposits here and releases them on proven exits.
- Roles:
- admin: Timelock; ultimately PolygonMultisig
- defaultAdmin: PolygonMultisig
- managers: RootChainManager
Immutable escrow (predicate) for one token type. Only the RootChainManager can lock deposits and release them on proven exits.
All supported tokens in this escrow are included in the value secured calculation.
Smart contract allowing whitelisted addresses to send messages to contracts on the child chain.
Contract handling users’ withdrawal finalization for tokens escrowed in DepositManager.
- Roles:
- owner: Timelock; ultimately PolygonMultisig
Escrow (predicate) for one token type. The RootChainManager locks deposits here and releases them on proven exits.
- Roles:
- admin: Timelock; ultimately PolygonMultisig
- defaultAdmin: PolygonMultisig
- managers: PolygonMultisig, RootChainManager
Maintains the addresses of the contracts used in the system, part of the old ‘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. 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.’.
Legacy 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. exit predicate of the WithdrawManager. Users start withdrawals of burnt tokens here. Its exit challenge function is empty, so exits cannot be challenged.
Contract to deposit and escrow ETH, ERC20 or ERC721 tokens.
- Roles:
- owner: Timelock; ultimately PolygonMultisig
All supported tokens in this escrow are included in the value secured calculation.
Escrow (predicate) for one token type. The RootChainManager locks deposits here and releases them on proven exits.
- Roles:
- admin: Timelock; ultimately PolygonMultisig
- defaultAdmin: PolygonMultisig
- managers: RootChainManager
All supported tokens in this escrow are included in the value secured calculation.
Immutable predicate that burns deposited tokens and mints them again on proven exits. It holds no tokens. Only the RootChainManager can call it.
Legacy 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. exit predicate of the WithdrawManager. Users start withdrawals of burnt tokens here. Its exit challenge function is empty, so exits cannot be challenged.
Manages 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, stakes and rewards. The RootChain uses it to check that each checkpoint is signed by more than 2/3 of the stake.
- Roles:
- admin: Timelock; ultimately PolygonMultisig
Simple contract that allows the owner to call an update function on arbitrary contracts.
- Roles:
- owner: Timelock; ultimately PolygonMultisig
Escrow (predicate) for one token type. The RootChainManager locks deposits here and releases them on proven exits.
- Roles:
- admin: Timelock; ultimately PolygonMultisig
- defaultAdmin: PolygonMultisig
- managers: RootChainManager
Contract storing chain checkpoints. Note that validity of these checkpoints is not verified, it is assumed to be valid if signed by 2/3 of the 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.
- Roles:
- owner: Timelock; ultimately PolygonMultisig
Escrow (predicate) for one token type. The RootChainManager locks deposits here and releases them on proven exits.
- Roles:
- admin: Timelock; ultimately PolygonMultisig
- defaultAdmin: PolygonMultisig
- managers: RootChainManager
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 entry gate registered in the Registry under validatorPass. The StakeManager only admits new validators approved here.
- Roles:
- defaultAdmin: Governance; ultimately PolygonMultisig
- passIssuer: EOA 2, Governance; ultimately PolygonMultisig
Escrow (predicate) for one token type. The RootChainManager locks deposits here and releases them on proven exits.
- Roles:
- admin: Timelock; ultimately PolygonMultisig
- defaultAdmin: PolygonMultisig
- managers: RootChainManager
All supported tokens in this escrow are included in the value secured calculation.
Wrapped ETH of the legacy 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. 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.. The DepositManager wraps ETH deposits here, so this contract holds that ETH.
Escrow (predicate) for one token type. The RootChainManager locks deposits here and releases them on proven exits.
- Roles:
- admin: PolygonMultisig
- defaultAdmin: EOA 1
- managers: EOA 1, RootChainManager
Escrow (predicate) for one token type. The RootChainManager locks deposits here and releases them on proven exits.
- Roles:
- admin: Timelock; ultimately PolygonMultisig
- defaultAdmin: PolygonMultisig
- managers: RootChainManager
Logic that the StakeManager delegatecalls to update checkpoint reward parameters and commission rates and to migrate 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 data. Its own storage is unused.
Predicate that forwards proven exit data to the root contract instead of moving tokens. It holds no tokens.
- Roles:
- defaultAdmin: PolygonMultisig
- managers: RootChainManager
Emits staking events on behalf of the StakeManager and 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 share contracts.
- Roles:
- admin: Timelock; ultimately PolygonMultisig
Contains logging and getter functions about staking.
Deploys the ValidatorShare proxy through which delegators stake with a 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.
A standard timelock with access control. Proposers can also cancel queued transactions. The current minimum delay is 0s.
- Roles:
- executor: PolygonMultisig
- 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.: PolygonMultisig
- timelockAdmin: Timelock; ultimately PolygonMultisig
NFTs used to represent a withdrawal in the withdrawal PriorityQueue (Only used for tokens initially deposited via DepositManager).
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).