It is proposed to use the following new smart contract on the Ethereum Mainnet:
All other contracts remain as documented in previous proposals.
StakeRewardAdviser
replacementThe previous StakeRewardAdviser
, which is tightly coupled with the buggy RewardPool
contract, will be replaced by calling the removeRewardAdviser
function of the existing RewardMaster
contract, followed by addRewardAdviser
to configure its replacement.
This replacement only needs to be done for the unstake
action, not for stake
, since the classic staking program already closed for new stakes.
StakeRewardController2
This contract returns modified advice with zero shares of the reward pool, effectively bypassing the need for RewardMaster
to attempt to invoke the buggy RewardPool
contract to redeem shares.
vestingPools::addVestingPools([wallet], [poolParams])
will be called on the existing VestingPools
contract on the Ethereum Mainnet, where:
wallet
is the address of the DAO multi-sig address on Ethereum (0x505796f5Bc290269D2522cf19135aD7Aa60dfd77).
Final poolParams
will be:
This will result in a poolId
of 15 (since 0--12 were created during TGE, and 13 and 14 in previous proposals).
This new pool is required in order to cover the total rewards which were earned via Mainnet classic staking but have not yet been claimed.
The newly minted reward tokens will be immediately released into the StakeRewardController2
contract. In order to protect against any further mishaps, this contract has a rescueErc20
method which would allow the DAO to recover any funds accidentally locked in that contract. It is certainly expected that this emergency rescue mechanism will never be needed as a result of further bugs; however to provide extra assurance to stakers with unclaimed rewards, the contract has been configured so that this mechanism cannot be used prior to 2022-08-15T00:00:00.000Z.
It is also important to note that all staked tokens are completely safe and unaffected. The bug only affects users’ ability to unstake and claim rewards on the Ethereum Mainnet since the rewards program ended. Nothing on Polygon is affected. Users who have already claimed all their rewards are also unaffected.
This situation denies all current $ZKP stakers on Mainnet the opportunity to access their rewards. As such, the Panther development team is proposing the following fix to ensure that users are able to receive their earned rewards as originally approved by the DAO.
The Panther team proposes a solution to mint new tokens and allow them to be claimed to match the existing rewards earned. This solution also involves “upgrading” the existing contracts to correct the bug, with the following actions:
Mint a new pool of 3.556M $ZKP on the Ethereum Mainnet, to cover previously earned but still unclaimed rewards to stakers. This will be minted from the total 450M $ZKP allocated for Protocol rewards.
Release the full 3.556M $ZKP to the StakeRewardController2
contract, so that existing stakers can claim their rewards.
Contract | Address |
---|---|
This proposal describes a bug fix to the staking program on the Ethereum Mainnet, to ensure fair access to any remaining unclaimed rewards in accordance with , which launched the Panther Protocol and its smart contracts (including ) and was . This proposal will allow for any staking rewards on Ethereum Mainnet which were not yet redeemed to be claimed as previously approved.
With the proposed fix applied, stakers will receive the rewards that they already accumulated through staking and that are displayed on .
The recent completion of Panther’s Classic Staking program on the Ethereum Mainnet was followed by the discovery of an unfortunate bug where the contract throws an exception at the time of unstaking tokens, making it impossible for users to unstake them. 3.555M $ZKP issues as rewards are irretrievably locked in the contract because of this.
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 , 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 .
Also on Mainnet, replace the existing contract for the unstake
action with a new contract, which bypasses the buggy code in , distributes fairly accrued rewards to existing stakers as specified by .
StakeRewardController2
0x1B316635a9Ed279995c78e5a630e13aaD7C0086b
The Panther Foundation will compensate for the cost of "gas" on the Ethereum network to any person who executes the Reality.eth transactions which fulfill this proposal, by sending a number of ZKP tokens with the equivalent market value to the Ethereum address(es) from which the transactions were sent.
To clarify, this only applies to the Reality.eth transactions directly associated with this DAO proposal, which are listed at the corresponding page on Snapshot.org. It does not promise any compensation for normal staking / unstaking transactions, or other interactions with the smart contracts.
In order for "Zodiac Reality Module" (further referred to as the "Module") to execute a transaction, any corresponding proposal must have passed, as reported by Reality.eth.
The Reality.eth question should conform to this template (the required template ID is defined by the installed Module):
Reality.eth should resolve the question to “yes” only for proposals that:
had a minimum quorum of 4% of the $ZKP token total supply, returned by the $ZKP smart contract deployed on Ethereum network at the address stated by the zkpaddress
record at PantherProtocol.eth (https://app.ens.domains/name/pantherprotocol.eth/details), having cast votes to approve execution of the transactions;
had a voting period of at least 3 days;
had no significant service outages or availability issues that could have reasonably restricted $ZKP token holders from casting their votes in the proposal;
have a minimum bond on the Reality question of at least 0.5ETH;
the module transaction hash in the Reality.eth question is the keccak hash of the concatenation of the individual EIP-712 hashes of the module transactions defined in the Snapshot proposal;
the plain description of the transactions, and their intended result, in the proposal is complete and accurate;
do not occur during, in, or as a result of any unauthorized or malicious changes to the PantherProtocol.eth Snapshot space;
were not filtered from the default view in the PantherProtocol.eth Snapshot space during the voting period.
Reality.eth should resolve the question to “invalid” if:
the Reality.eth question meets the above requirements but was created prior to the end of the proposal vote period and/or the Snapshot block for the vote (i.e. the final results of the vote are not yet known).
In all other cases, the Reality.eth question should be resolved to “no”.