Report Author: Mudit Gupta(on behalf of the Polygon Protocol Council)
Address: 0xf29722a899Aa9FD0836076CA1dA64212c451453C
Relating to:
- PIP-26: Transition from MATIC to POL Validator Rewards, and discussed on Polygon Protocol Governance Call 10 and Polygon Protocol Governance Call 21
- PIP-40: Support for upgraded Community Treasury Board contracts discussed on Polygon Protocol Governance Call 21
Change type: Regular change via the emergency track with PC Consensus: 10/13
Introduction
This document is an official communication between the Polygon Protocol Council and the community. It aims to provide transparency to all community members regarding upcoming regular network changes.
In this transparency report, the Protocol Council (āPCā) outlines the execution details of an upgrade to the POL DefaultEmissionManager.sol contract.
The upgrade contains 3 distinct changes:
- PIP-26 Execution
In accordance with the POL emission schedule in PIP-26: Transition from MATIC to POL Validator Rewards, discussed in Polygon Protocol Governance Call 11 and Polygon Protocol Governance Call 21, validator rewards will be reduced from 2% to 1.5%.
- PIP-40: Execution (New CT contracts)
Also discussed on Polygon Protocol Governance Call 21, this change will redirect treasury emissions to the new CT setup detailed in PFP-2.
After evaluating the efficacy, impact, execution specifications, and security considerations, the PC has reached a supermajority consensus of 10/13, thereby executing the change without timelock.
Motivation
- PIP-26 Execution
Executed an upgrade to the EmissionManager.sol to schedule POL emissions inline with the original commitments of the genesis MATIC Validator Rewards Schedule before commencing the aforementioned Polygon 2.0 validator reward schedule.
- PIP-40: Execution (New CTB contracts)
This change redirects treasury emissions to a new upgraded set up for the Community Treasury Board.
Execution
The subsequent section of the code provides a detailed overview of the execution specifications related to the proposed system smart contract change. These specifications are essential to understand the functioning and implementation of the upgrade:
Part 1: Deploy New DefaultEmissionManager implementation
The new version of the DefaultEmissionManager will be deployed using an EOA.
In its constructor, the new treasury address (0x86380e136a3aad5677a210ad02713694c4e6a5b9)
will be set.
Result: 0x5e875267f65537768435C3C6C81cd313a570B422
Part 2: Call mint()
on existing DefaultEmissionManagerProxy
A payload containing calling the mint()
method on the existing DefaultEmissionManagerProxy:
To: 0xbC9f74b3b14f460a6c47dCdDFd17411cBc7b6c53
Payload: 0x1249c58b
Value: 0
Part 3: Tell ProxyAdmin to updateAndCall
A payload will then be created that contains the function call.āupgradeAndCallā on the ProxyAdmin (0xEBea33f2c92D03556b417F4F572B2FbbE62C39c3)
Inputs
proxy: 0xbC9f74b3b14f460a6c47dCdDFd17411cBc7b6c53 (DefaultEmissionManagerProxy)
Implementation: 0x5e875267f65537768435C3C6C81cd313a570B422 (address of the new deployed DefaultEmissionManager implementation)
data: 0x6c2eb350 (encoded function call to the āreinitializeā function of our new implementation)
Calling this function will result in the ProxyAdmin calling the āupgradeToAndCallā function on the TransparentUpgradeableProxy (proxy from the inputs), which will upgrade the implementation and execute the āreinitializeā function.
This will set the START_SUPPLY_1_2_0 to the current supply and startTimestamp to the current blocktime.
The result is the payload that is pasted below. It will be provided to the Emergency Security Council to execute the transaction on June 30th.
To:
0xEBea33f2c92D03556b417F4F572B2FbbE62C39c3
Value:
0
Payload:
0x9623609d000000000000000000000000bc9f74b3b14f460a6c47dcddfd17411cbc7b6c530000000000000000000000005e875267f65537768435c3c6c81cd313a570b422000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000046c2eb35000000000000000000000000000000000000000000000000000000000
Part 3: Execution (in Safe)
The scheduled proposal can be executed by calling the function āexecuteā
https://app.safe.global/transactions/queue?safe=eth:0x37D085ca4a24f6b29214204E8A8666f12cf19516
Part 4: Validation
Once the upgrade is done, we can check the following things:
INTEREST_PER_YEAR_LOG2 should now be 0.03562390973072122e18; // log2(1.025)
START_SUPPLY_1_2_0 should be the last totalSupply before the upgrade.
startTimestamp should be equal to the blocktime of the upgrade transaction.
treasury should now be 0x86380e136a3aad5677a210ad02713694c4e6a5b9
Resources and References
- Polygon Forum: https://forum.polygon.technology/ is a discourse forum for governance related discussions. Community members must register for an account before sharing their views.
- Read more about PIP-29: Polygon Protocol Council here: https://github.com/maticnetwork/Polygon-Improvement-Proposals/blob/main/PIPs/PIP-29.md
- Testnet Review: new implementation, upgrade transaction
- Mainnet Review: new implementation, upgrade transaction( in Safe)
Copyrights
All copyrights and related rights in this work are waived under CC0 1.0 Universal.