# Proposal #3 - Polygon Staking and Governance This proposal involves extending Panther's existing DAO governance / voting structure and the ongoing Traditional staking program to Polygon. ## Background It follows on from [Proposal #2](../proposal-2-polygon-bridging), which concerns extending the ZKP token to the Polygon PoS network over the Polygon bridge. This proposal #3 is subject to the approval of Proposal #2, since governance and staking are not possible on Polygon unless the token and bridge are deployed. If Proposal #2 is not accepted, Proposal #3 becomes null and void. You can see the rationale behind Proposal #2 [here](https://blog.pantherprotocol.io/moving-to-polygon-1cf95ddb1aa6). ## Participation Please vote to accept or reject the proposed conditions detailed below. To participate in voting, you need to have [staked $ZKP](../../token/staking/how-to-stake.md) in [Panther's "Traditional" staking solution](../../token/staking/). As per the existing DAO governance structure, [voting power is calculated by snapshot.org taking a snapshot of the number of ZKP tokens staked at the block within which the proposal was created](https://docs.snapshot.org/proposals/vote). ## Proposed actions (Note: Some items in this proposal will have corresponding transactions, but not all. You can see the transactions at the bottom of the proposal's page on [snapshot.org](https://snapshot.org/#/pantherprotocol.eth).) The following actions are proposed: * Initialize "Traditional" staking contracts on Polygon, which operate in essentially the same way as the existing "Traditional" staking contracts already active on Ethereum mainnet. * Bridge a total of 2M $ZKP immediately vested from a new Polygon Staking Rewards Pool for "Traditional" Staking rewards on Polygon. The total of 2M $ZKP aims to create a fair balance between the rewards available for stakers on both networks (although it should be noted that all $ZKP holders are free to stake on either/both networks). * Extend DAO governance and voting to the Polygon network by switching [https://snapshot.org/#/pantherprotocol.eth](https://snapshot.org/#/pantherprotocol.eth) to a multi-chain strategy which uses a combination (i.e. sum) of voting power from $ZKP staked on both Mainnet and Polygon. * Add new "no rewards" staking terms to the existing staking contract on the Ethereum mainnet, for the Foundation or anyone else who wishes to be able to stake for governance without earning rewards. ## Staking Enable staking contracts on Polygon PoS chain to essentially mirror the behavior of [the existing Ethereum mainnet staking rewards program](https://docs.pantherprotocol.io/launchdao/voting-proposals/3-launch/staking), using the following parameters: * Individual stakes will be locked for 7 days, then can be unstaked any time after. * Staking rewards will begin Monday 7th March 23:59:59 UTC 2022, and end on Monday 2nd May 23:59:59 UTC 2022. Staking will be allowed until Wednesday 27th April 00:00:00 UTC 2022. * Total rewards will be fixed at 2M $ZKP. These will come out of the total 450M $ZKP allocated for protocol rewards, via a new Polygon Staking Rewards vesting pool on the Ethereum mainnet. These tokens will be bridged across to a `MaticRewardPool` on Polygon (see below). * Initialise the `MaticRewardPool` contract to act as the Polygon counterpart of the [Staking Rewards pool on the Ethereum mainnet (pool #12)](https://docs.pantherprotocol.io/launchdao/voting-proposals/3-launch/mint-and-vest#staking-rewards-pool-pool-12). Rewards will vest from this pool contract. The following values will be used for initialisation: * `recipient`: `RewardMaster` contract * `startTime`: Mon 7 Mar 23:59:59 UTC 2022 * `endTime`: Mon 2 May 23:59:59 UTC 2022 * The following values will be used for the `addTerms()` call on the `Staking` contract: * `isEnabled`: `true` * `isRewarded`: `true` * minAmount (before scaling): 100 $ZKP * maxAmount (before scaling): not applicable (0) * `allowedSince`: Mon 7 Mar 23:59:59 UTC 2022 * `allowedTill`: Wed 27 Apr 00:00:00 UTC 2022 * `lockedTill`: not applicable * `exactLockPeriod`: not applicable * `minLockPeriod`: 7 days This does not cover future rewards for protocol users, such as Privacy Staking and transacting within Shielded Pools, which will be covered by separate vesting pools, when those aspects of the main protocol are released after the TGE. ## Technical details ### Smart contracts The following smart contracts on the Polygon PoS chain will be used: * at 0x9a06db14d639796b25a6cec6a1bf614fd98815ec - ZKPToken * at 0x773d49309c4e9fc2e9254e7250f157d99efe2d75 - MaticRewardPool * at 0x09220dd0c342ee92c333faa6879984d63b4dff03 - RewardMaster * at 0x4cec451f63dbe47d9da2debe2b734e4cb4000eac - Staking * at 0xAa943954eB256cc8C170C1bacF538D65D9eb9069 - StakeRewardAdviser ### Polygon Staking Rewards vesting pool `vestingPools::addVestingPools([wallet], [poolParams])` will be called on the existing `VestingPool` 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-06T00:00:00Z, vestingDays: 1, sAllocation: 2e12, // 2M tokens sUnlocked: 2e12, // 2M tokens vested: 0 } ### Non-rewarding staking terms on Ethereum mainnet The following values will be used to add new staking terms to the existing `Staking` contract at 0xf4d06d72dacdd8393fa4ea72fdcc10049711f899 on the Ethereum mainnet: * `isEnabled`: `true` * `isRewarded`: `false` * minAmount (before scaling): not applicable (0 ZKP) * maxAmount (before scaling): not applicable (0 ZKP) * `allowedSince`: not applicable * `allowedTill`: not applicable * `lockedTill`: not applicable * `exactLockPeriod`: not applicable * `minLockPeriod`: 7 days These new staking terms are additional, and have no impact on [the existing (rewarded) staking terms](https://docs.pantherprotocol.io/launchdao/voting-proposals/3-launch/staking). ## Compensation The Panther Foundation will compensate for the cost of "gas" on the Ethereum network to any person who executes the transaction which fulfills this proposal, by sending 500 $ZKP tokens to the Ethereum address the transaction was sent from. ## Acceptance Criteria 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): ```json { "title": "Did the Snapshot proposal with the id %s in the PantherProtocol.eth space pass the execution of the array of Module transactions that have the hash 0x%s and does it meet the requirements of the document referenced in the daorequirements record at PantherProtocol.eth? The hash is the keccak of the concatenation of the individual EIP-712 hashes of the Module transactions. If this question was asked before the corresponding Snapshot proposal was resolved, it should ALWAYS be resolved to INVALID!", "lang": "en", "type": "bool", "category": "DAO proposal" } ``` Reality.eth should resolve the question to “yes” only for proposals that: * were initiated as a Snapshot proposal in the PantherProtocol.eth space (at [https://snapshot.org/#/pantherprotocol.eth](https://snapshot.org/#/pantherprotocol.eth)); * 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](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”.