Polygon Staking rewards: proposed bug fix

Dear Panthers,

As you may have already heard from our Discord and Telegram channels, the recent deployment of the new staking program on the Polygon network was quickly followed by the discovery of an unfortunate bug.

As such, the Panther team is proposing a smart contract fix to ensure fair distribution of rewards in accordance with DAO proposal #3, which was previously approved by 98.74% of voters.

We strongly recommend 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 important to note that all staked and unstaked tokens are completely safe and unaffected. Similarly, the bug only affects the distribution of staking rewards on Polygon. Nothing on the Ethereum Mainnet is affected.

If the proposal is accepted, no further action will be required by stakers; the fix will ensure everything functions correctly as previously planned. Users who already staked on Polygon will not need to stake again, either.

Participation

Please visit DAO Proposal #4 to vote to accept or reject the proposed actions detailed below. To participate in voting, you need to have staked $ZKP, 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.

The problem

Our team found a bug in the MaticRewardPool smart contract (function _releasableAmount() line 105), a contract written to distribute 2 million ZKP rewards on Polygon to stakers. In short, the bug results in the contract incorrectly computing 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 higher and faster rate than initially planned, exhausting almost all of the rewards pool by Thursday, March 10th.

Of course, this goes against the proposal submitted to and approved by the Panther 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 in favor of early stakers.

Proposed solution

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

The Panther team also proposes a fallback option towards the execution of these same changes, in the eventuality that to avoid further issues and fast-track the fixes a more hands-on approach would be needed.

Fallback safety mechanisms

Since fixing this bug is both time-critical and complex to implement, it may prove impossible or impractical to achieve the above via Reality.eth, Panther’s decentralized execution mechanism used to execute previous proposals.

In this case, two fallback options are proposed, to ensure the safety of the allocated reward tokens and to ensure the terms of DAO Proposal #3 are upheld:

1. Add a temporary guard to the DAO multisig which would prevent execution of some or all of steps 2 to 5 above, if for any reason it emerges they would behave contrary to the stated objectives of this proposal.
2. 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.”

By requesting the DAO’s authorization to use the mechanisms described above, Panther retains its status as a decentralized autonomous organization with community governance, ensuring that changes are explicitly approved by the community.

(For more details on this multisig mechanism, please refer to the DAO governance documentation.)

Post-mortem

This bug slipped through Panther’s net despite several rounds of code reviews from multiple individuals, plus comprehensive coverage from our automated test suites and CI pipelines. It is ironic that after successfully executing many complex deployments such as the ZKP token and DAO smart contracts, Reality.eth modules, LaunchDAO, and Mainnet staking, it was a relatively simple component that caused this problem. It shows that one can never be too careful!

The Panther team has learned some lessons the hard way from this experience and hopes to share these learnings openly with the public in the future. As always, the DAO’s governance is what makes Panther possible, and even when mistakes are made, we can trust the community to make the right decisions in correcting our course.

We’ll see you over at Proposal #4 to fix this bug and continue to bootstrap privacy in DeFi together!

About Panther

Panther is a decentralized protocol that enables interoperable privacy in DeFi using zero-knowledge proofs.

Users can mint fully-collateralized, composable tokens called zAssets, which can be used to execute private, trusted DeFi transactions across multiple blockchains.

Panther helps investors protect their personal financial data and trading strategies, and provides financial institutions with a clear path to compliantly participate in DeFi.

Stay connected: Telegram | Twitter | LinkedIn | Website

Share this article on: