Search for projects by name
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.
2024 Jun 15 — 2025 Jun 15
2024 Jun 15 — 2025 Jun 14
Users can submit transactions to an L1 queue, but can’t force them. The sequencers cannot selectively skip transactions but can stop processing the queue entirely. In other words, if the sequencers censor or are down, they are so for everyone. In Polygon PoS, the sequencers network corresponds to the PoS validators network, which is composed of 105 members.
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 regular 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.
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.
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.
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.
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).