Comment on page
Proposal #4 - Polygon Staking Rewards Bug Fix

Summary
This proposal describes a bug fix to the new staking program on Polygon, to ensure fair distribution of rewards in accordance with DAO proposal #3, which was previously approved by 98.74% of voters.
The Panther team strongly recommends voting in favor of this proposed fix to anyone who wants the Polygon staking rewards to be distributed fairly as previously approved.
With the fix applied, stakers will receive the same high APYs which were previously displayed on the staking app. For example, for the first 30 minutes, APY was over 1,320%, and for the first 6 hours, it was over 290%.
It is also important to note that all staked tokens are completely safe and unaffected. The bug only affects distribution of rewards on Polygon. Nothing on the Ethereum mainnet is affected.
Background
The recent deployment of Panther’s staking program on the Polygon network was quickly followed by discovery of an unfortunate bug where the MaticRewardPool contract incorrectly computes the rewards to vest at any given moment, acting as if no rewards have ever been vested. This is problematic as it causes the contract to accrue rewards at a much higher and faster rate than initially planned, exhausting almost all of the 2 million ZKP pool by Thursday, March 10th.
Of course this goes against DAO proposal #3, whereby rewards should vest linearly over 56 days. The bug unfairly denies all ZKP holders the opportunity they should have had to accrue rewards at any time during the 56 day period.
As such, the Panther development team is proposing the below fix to ensure rewards are vested and redeemable at the schedule originally approved by the DAO.
Participation
Please review the proposed actions detailed below, and vote to accept or reject them. To participate in voting, you need to have staked $ZKP in Panther's "Traditional" staking solution, and/or had staked $ZKP delegated to you.
As per the existing DAO governance structure, voting power is calculated by snapshot.org taking a snapshot of the total number of ZKP tokens staked (and/or received via delegation) on both Ethereum and Polygon at the time when the proposal was created.
Proposed actions
The Panther team proposes a solution rescuing existing rewards, and "upgrading" the existing contracts to correct the bug, with the following actions:
1.Disable the existing StakeRewardAdviser contract for the unstake action, to prepare for a corrective contract and to ensure that the previously approved terms of DAO proposal #3 are not violated.
2.Create a fresh vesting pool of 2M ZKP tokens on the Ethereum Mainnet, minted from the total 450M $ZKP allocated for protocol rewards.
3.Bridge the newly minted 2M $ZKP to a new RewardTreasury contract on Polygon.
4.Configure RewardTreasury to allow its tokens to be spent by a new StakeRewardController contract.
5.Replace the existing StakeRewardAdviser contract for both stake / unstake actions with this new StakeRewardController contract, which automatically reclaims prematurely vested rewards, and distributes fairly accrued rewards to both existing and future stakers as specified by the previously approved terms of DAO proposal #3.
There will be a period for the switchover from the old contract to the new one. It ends if / when the proposal is executed, at which point any stakes newly created during this period will lose their accrued rewards. This will not affect stakes created before the switchover period commenced.
6.Reinstate display of (corrected) reward figures in the staking app UI.
Fallback safety mechanisms
Since the fix is both time-critical and complex to implement, it may prove impossible to reliably achieve the above via the Reality.eth mechanism used to execute previous proposals.
Therefore two fallback actions are proposed, to ensure the safety of the allocated reward tokens:
1.If necessary, add a temporary guard to the DAO multisig which would prevent execution of some or all of the steps above.
2.If necessary, execute some or all of the steps above via signers of the DAO multisig, rather than via Reality.eth, in accordance with point 8 of the DAO launch proposal, which states:
"To protect, take corrective actions, and minimize the risks caused by smart contract bugs, etc. This proposal will allow a set of signers of the DAO multisig to have an overrule power."
However, it is considered highly undesirable to invoke this overrule power without first seeking DAO approval via a democratic process. Therefore this proposal solicits the DAO's authorization to implement the above actions utilizing DAO multisig signers rather than an executable proposal, if that should be necessary.
Status
​This proposal was accepted with 98.69% of the vote on March 16th, 2022.​
Acceptance Criteria
Technical details
Last modified 1yr ago