Council Transparency Report: PIP 26 & 40

Polygon Improvement Proposals Council Transparency Report
1

Report Author: Mudit Gupta(on behalf of the Polygon Protocol Council)

Address: 0xf29722a899Aa9FD0836076CA1dA64212c451453C

Relating to:

  1. PIP-26: Transition from MATIC to POL Validator Rewards, and discussed on Polygon Protocol Governance Call 10 and Polygon Protocol Governance Call 21
  2. 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:

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

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

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

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

  1. 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.
  2. Read more about PIP-29: Polygon Protocol Council here: https://github.com/maticnetwork/Polygon-Improvement-Proposals/blob/main/PIPs/PIP-29.md
  3. Testnet Review: new implementation, upgrade transaction
  4. Mainnet Review: new implementation, upgrade transaction( in Safe)

Copyrights

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

5 Likes