PIP-42: Polygon 2.0 - Upgrade PoS Staking to Use POL

PIP-42: Polygon 2.0 - Upgrade PoS Staking to Use POL

Authors: Simon Dosch, @ZeroEkkusu, @oneski22, @pgpg, @pgo

Type: Contracts

Table of Contents:

  • Abstract
  • Motivation
  • Definitions
  • Specification
    • Frontier Roadmap
  • Security Considerations
  • Backward Compatibility

Abstract

This proposal calls for upgrading the staking contract for the Polygon PoS network to change from using MATIC (0x7d1afa7b718fb893db30a3abc0cfc608aacfebb0) as the primary staking token to POL (address) in a method that ensures maximum backward compatibility. The authors recommend this by upgrading the PoS Stake Manager Contract (0x5e3Ef299fDDf15eAa0432E6e66473ace8c13D908) to a new implementation at (address to be determined) that:

  • Converts all the MATIC in the Stake Manager to POL
  • Uses POL for all new staking and unstaking requests
  • Has legacy functions that allow for staking and unstaking using MATIC by leveraging the POL Migration Contract (0x29e7DF7b6A1B2b07b731457f499E1696c60E2C4e) to preserve maximum backward compatibility.

This proposed upgrade will not change any contracts on the Polygon PoS Network. Likewise, all other properties about staking (reward rate, unbonding period, slashing etc.) will remain unchanged.

Motivation

The staking token is the token which stakers and validators of the Polygon PoS network use to secure the network, and come to consensus on the state. The present staking token is MATIC which was set as the staking token upon genesis of the Polygon PoS network. Now that POL (0x455e53CBB86018Ac2B8092FdCd39d8444aFFC3F6) is live, the authors propose setting it as the staking token of the network via an upgrade of the Stake Manager in a maximally backward compatible manner.

Specification

Upgrade the Stake Manager contract to a new implementation at < address to be determined >.

Backward Compatibility

Systems that expect to stake and unstake MATIC from the PoS Staking system will be affected unless they move to using the new legacy functions.

Security Considerations

This upgrade adjusts a core contract of the Polygon PoS network. All proper security procedures including necessary audits will be taken, and should be carefully reviewed prior to activation.

References

Copyright

All copyrights and related rights in this work are waived under CC0 1.0 Universal.

5 Likes

Looks like a placeholder value is needed there unless the new stake manager is deployed via create2 so the address can be known given the existing bytecode.

TBD for now?

3 Likes

do the delegates need to do something, or will the transition happen automatically?

2 Likes

To help with testing / understanding the upgrade, an release candidate of the new implementations has been deployed on Sepolia.

Sepolia (Testnet)

Release Candidate:

StakeManager:

https://sepolia.etherscan.io/address/0x924562F8aE8BE16F777ae8076beC0215f62B8c23

ValidatorShare:

https://sepolia.etherscan.io/address/0x09a7d072ffd1bbf128d7d9da90decc0e1cbb9e91

1 Like

Instead of appending the Legacy suffix to the old methods, would you consider adding a POL suffix to the new methods? This will prevent any existing integrations from breaking.

2 Likes