Technical details

Smart contracts

It is proposed to use the following new smart contracts on the Polygon PoS chain:

Contract	Address
RewardTreasury	0x20AD9300BdE78a24798b1Ee2e14858E5581585Bc
StakeRewardController	0xdCd54b9355F60A7B596D1B7A9Ac10E6477d6f1bb

All other contracts remain as documented in previous proposals.

As mentioned in the previous section, due to the time-critical nature of the fix, if any issues are discovered by further auditing during the voting period, it may be necessary to deploy amended versions of the above two contracts, and invoke the fallback mechanisms in order to activate those instead. If so, amendments will be kept to a minimum as much as possible, to preserve the original intention of the above contracts as described below.

StakeRewardAdviser replacement

The previous StakeRewardAdviser, which is tightly coupled with the buggy MaticRewardPool contract, will be replaced by calling the removeRewardAdviser function of the existing RewardMaster contract, followed by addRewardAdviser to configure its replacement.

Removal and addition needs to be done for both the stake and unstake actions.

New StakeRewardController

For "old" stakes created before the replacement, this contract returns modified advice with "old" amounts of rewards (shares of the reward pool), but with the address of the RewardTreasury contract as the recipient of rewards. This allows reclamation of the incorrectly vested rewards, which it can then use to distribute in the corrected manner.

To achieve this, StakeRewardController is preprogrammed with sufficient historical data of all previous staking activity to be able to calculate the corrected distribution of previously accrued rewards.

For "new" stakes created, it returns advice to RewardMaster with zero rewards (zero "shares"), preventing RewardMaster from distributing incorrect amounts, and instead assumes responsibility for reward distribution.

New Polygon Staking Rewards vesting pool

vestingPools::addVestingPools([wallet], [poolParams]) will be called on the existing VestingPools contract on the Ethereum Mainnet, where:

• wallet is the address of the DAO Multisig address on Ethereum (0x505796f5Bc290269D2522cf19135aD7Aa60dfd77).

• Final poolParams will be:

  {
    isPreMinted: true,
    isAdjustable: true,
    start: 2022-03-15T00:00:00Z,
    vestingDays: 1,
    sAllocation: 2e12, // 2M tokens
    sUnlocked: 2e12, // 2M tokens
    vested: 0
  }

This will result in a poolId of 14 (since 0--12 were created during TGE, and 13 in the previous proposal).

This new pool is required to serve as a temporary "advance loan" from one part of the Protocol to another, since the prematurely vested rewards from the previous 2M pool can only be recovered as the final part of execution of an unstake operation, after the corrected rewards are distributed by StakeRewardController to the account performing the unstaking.

Bridging of these 2M tokens will be performed in a similar manner to DAO proposal #3, except that the final recipient will be the RewardTreasury contract instead of the buggy MaticRewardPool.

Activation of StakeRewardController

When other contracts are configured correctly as described above, StakeRewardController will be activated, allowing further staking and unstaking with the fully corrected reward calculations.