Proposal #10: Launch Advanced Staking, Part 2: Configuration ============================================================ Summary ------- This proposal is the second out of two governing the launch of version 0.5 of the Panther Protocol, [known as *"Advanced Staking"*](https://docs.pantherprotocol.io/dao/token/staking/phase-2-advanced-staking). This PIP activates newly deployed software components by configuring both new and existing components of the Panther Protocol to work together. Furthermore this PIP executes rewarding deployers of newly deployed components as per [PIP-9][]. [PIP-9]: https://docs.pantherprotocol.io/dao/governance/proposal-9-launch-advanced-staking-part1 Finally it suggests a secure user-friendly URL to the front-end for version 0.5 as discussed by the community on [Panther's Discourse forum][Discourse]. [Discourse]: https://forum.pantherprotocol.io/t/asking-foundation-to-add-pantherprotocol-ens-name-to-ipfs-link/191 Background ---------- The approval of [PIP-9][] by the Panther DAO empowered the Panther community to deploy smart contracts and other software components for Panther's v0.5. The source code of these components was published and licensed for the deployment. Since then, community members have deployed these new components, making it possible to complete the integration and launch version 0.5. To achieve this, newly deployed components and ones which existed before [PIP-9][] need to be configured to work as a whole. This proposal authorizes and triggers execution of the attached blockchain transactions (via [Panther's space on snapshot.org][snapshot.org]), which configure the Panther Protocol's smart contracts. [snapshot.org]: https://snapshot.org/#/pantherprotocol.eth This proposal also covers rewarding the users that deployed Advanced Staking's components as per [PIP-9][]. In order to have a user-friendly URL pointing to the front-end for v0.5 deployed on IPFS, and also to safeguard access to the correct link/app, the community requests and makes a recommendation to Panther Foundation to configure the [`pantherprotocol.eth` ENS domain][pantherprotocol.eth] namespace in such a way that the user-friendly link [https://ipfs.io/ipns/pantherprotocol.eth][dApp] will point to the deployed front-end. [dApp]: https://ipfs.io/ipns/pantherprotocol.eth [pantherprotocol.eth]: https://app.ens.domains/name/pantherprotocol.eth Participation ------------- Please vote to accept or reject the proposed actions detailed below. As per the existing DAO governance structure, as the staking smart contracts are not currently issuing any rewards, you need to hold $ZKP, staked or not, on the Ethereum Mainnet or Polygon to participate in voting. Voting power is calculated by Snapshot.org taking a snapshot of the number of ZKP tokens per holder [*at the block within which the proposal was created.*](https://docs.snapshot.org/proposals/vote) Proposed actions ---------------- The following actions are proposed: - Authorize and execute on the Ethereum Mainnet the attached configuration transactions, to achieve the following: - Configure terms for the staking programs to be [those outlined by PIP-9][PIP-9]. - Advanced Staking will go live on 2022-12-08 18:00:00 UTC, and stakes will be accepted for 119 days (till 2023-04-06 18:00:00 UTC) if the 6,000,000 $ZKP reward pool is not depleted before or Panther's v1 is not launched earlier. - zAssets may be redeemed from 2023-04-07 18:00:00 UTC. - Send rewards to the deployers of smart contracts and Subgraph instances. - Request Panther Foundation to configure the [pantherprotocol.eth][] namespace so that the URL [https://ipfs.io/ipns/pantherprotocol.eth][dApp] will point to the v0.5 front-end deployed on IPFS. Description of blockchain transactions and further configuration details may be found in the [technical details section of PIP-10 in the Panther DAO GitBook](https://docs.pantherprotocol.io/dao/governance/proposal-10-launch-advanced-staking-part2/technical-details). Technical details ----------------- ### New smart contracts Extend the Panther Protocol with the following, newly deployed smart contracts: *On the Ethereum mainnet:* - at `0xFED599513aB078Edea7Cf46574154f92b0B9FCAB`: `AdvancedStakeRewardAdviserAndMsgSender` *On the Polygon network:* - at `0x8f15a43961c27C74CB4F55234A78802401614de3`: `AdvancedStakeRewardController` - at `0x47374FBE2289c0442f33a388590385A0b32a20Ff`: `AdvancedStakeActionMsgRelayer` - at `0x9a423671e9Cde99Ae88853B701f98ca9e136877B`: `PantherPoolV0` - at `0xE5da4955cBC480Eb9Bf9534def229F9D8339eE6d`: `PNftToken` - at `0xb658B085144a0BEd098620BB829b676371B9B48c`: `ZAssetsRegistry` ### Existing smart contract affected The following pre-existing smart contracts will be involved in the proposal transactions: *On the Ethereum mainnet:* - at `0x505796f5bc290269d2522cf19135ad7aa60dfd77`: `DAO_Multisig` - at `0xf4d06d72dACdD8393FA4eA72FdcC10049711F899`: `Staking` - at `0x347a58878D04951588741d4d16d54B742c7f60fC`: `RewardMaster` - at `0xb476104aa9D1f30180a01987FB09b1e96dDCF14B`: `VestingPools` - at `0x909E34d3f6124C324ac83DccA84b74398a6fa173`: `ZKPToken` *On the Polygon network:* - at `0x9A06Db14D639796B25A6ceC6A1bf614fd98815EC`: `PZkpToken` - at `0x4cEc451F63DBE47D9dA2DeBE2B734E4CB4000Eac`: `Staking` - at `0x09220DD0c342Ee92C333FAa6879984D63B4dff03`: `RewardMaster` *Smart contracts of the Mainnet-\>Polygon PoS Bridge:* - at `0x40ec5B33f54e0E8A33A975908C5BA1c14e5BbbDf`: `ERC20PredicateProxy` - at `0xA0c68C638235ee32657e8f720a23ceC1bFc77C77`: `RootChainManagerProxy` ### Subgraph instances The following Subgraph instances will be used to feed data to the front end dApp: - at [https://thegraph.com/hosted-service/subgraph/toxicehc/panther](https://thegraph.com/hosted-service/subgraph/toxicehc/panther) with the ID `QmTi7Z7YoUpzYqwGytPuKYu2FuYPEhtPTsXti5dRxn8wHR` - at [https://thegraph.com/hosted-service/subgraph/cryptoefelle/panther](https://thegraph.com/hosted-service/subgraph/cryptoefelle/panther) with the ID `QmZPs5CFi5vpZW73DmwF5VMzt5CYvFX7vD9Ez9gkZteuRd` (Some more instances may be added to this list.) ### Transactions This proposal triggers execution of the following blockchain transactions. These transactions are already encoded during submission of the proposal to snapshot.org, and can be independently verified via the snapshot.org web interface. ### Batch 1 transaction 1 Register $ZKP as an allowed zAsset: ZAssetsRegistry_Proxy@matic::addZAsset( [0, 0, 1, 0, 11, "0x9A06Db14D639796B25A6ceC6A1bf614fd98815EC"]) ### Batch 1 transaction 2 Register PNFT as an allowed zAsset: ZAssetsRegistry_Proxy@matic::addZAsset( [0, 0, 1, "0x10", 0, "0xE5da4955cBC480Eb9Bf9534def229F9D8339eE6d"]) ### Batch 1 transactions 3...5 Set existing contracts on Polygon to work with newly deployed contracts: RewardMaster@matic::addRewardAdviser( "0x4cEc451F63DBE47D9dA2DeBE2B734E4CB4000Eac", "0xcc995ce8", "0x8f15a43961c27C74CB4F55234A78802401614de3") RewardMaster@matic::addRewardAdviser( "0x47374FBE2289c0442f33a388590385A0b32a20Ff", "0xcc995ce8", "0x8f15a43961c27C74CB4F55234A78802401614de3") RewardMaster@matic::addRewardAdviser( "0x4cEc451F63DBE47D9dA2DeBE2B734E4CB4000Eac", "0xb8372e55", "0x8f15a43961c27C74CB4F55234A78802401614de3") ### Batch 1 transaction 6 Allow zAsset redemption since 2023-04-07T18:00:00.000Z: PantherPoolV0_Proxy@matic::updateExitTimes(1680890400, 86400) ### Batch 1 transaction 7 Allow AdvancedStakeRewardController to mint PNFT tokens: PNftToken@matic::setMinter("0x8f15a43961c27C74CB4F55234A78802401614de3") ### Batch 1 transaction 8 Set advance staking rewarding parameters - 15% APR to be effective since 2022-12-08T18:00:00.000Z for 180 days: AdvancedStakeRewardController@matic::updateRewardParams( [1670522400, 1680804000, 15, 15]) ### Batch 1 transaction 9 Accept advanced stakes on Polygon since 2022-12-08T18:00:00.000Z for 119 days: Staking@matic::addTerms( "0x7ec13a06", [true, true, 1000, 0, 1670522400, 1680804000, 0, 0, 5184000]) ### Batch 1 transaction 10 Reserve 2000 PNFT tokens for first 2000 stakes: AdvancedStakeRewardController@matic::setNftRewardLimit(2000) ### Batch 2 transactions 1...3 Mint 6,000,000 $ZKP as rewards for advanced stakes and send tokens to AdvancedStakeRewardController on Polygon via PoS bridge: VestingPools@eth::releaseTo( 16, "0x505796f5bc290269d2522cf19135ad7aa60dfd77", "6000000000000000000000000") ZKPToken@eth::approve( "0x40ec5B33f54e0E8A33A975908C5BA1c14e5BbbDf", "6000000000000000000000000") RootChainManagerProxy@eth::depositFor( "0x8f15a43961c27C74CB4F55234A78802401614de3", "0x909E34d3f6124C324ac83DccA84b74398a6fa173", "0x00000000000000000000000000000000000000000004f68ca6d8cd91c6000000") ### Batch 3 transactions 1 and 2 Set existing contracts on mainnet to work with newly deployed contracts: RewardMaster@eth::addRewardAdviser( "0xf4d06d72dACdD8393FA4eA72FdcC10049711F899", "0xcc995ce8", "0xFED599513aB078Edea7Cf46574154f92b0B9FCAB") RewardMaster@eth::addRewardAdviser( "0xf4d06d72dACdD8393FA4eA72FdcC10049711F899", "0xb8372e55", "0xFED599513aB078Edea7Cf46574154f92b0B9FCAB") ### Batch 3 transaction 3 Accept advanced stakes on mainnet since 2022-12-08T18:00:00.000Z for 119 days: Staking@eth::addTerms( "0x7ec13a06", [true, true, 1000, 0, 1670522400, 1680804000, 0, 0, 5184000]) ### Batch 4 transaction 1 Allow AdvancedStakeRewardController to send all $ZKPs from its balance as rewards: AdvancedStakeRewardController@matic::updateZkpRewardsLimit() ### Batch 5 transactions 1...3 Mint 14,000 $ZKP as rewards for deployment and send 10,000 out of this amount to deployers: VestingPools@eth::releaseTo( 17, "0x505796f5bc290269d2522cf19135ad7aa60dfd77", "14000000000000000000000") ZKPToken@eth::transfer( "0xf0886ac6B2E9A2A75C9537EAF1A3aa8398FB10e8", "8000000000000000000000") ZKPToken@eth::transfer( "0xdfE35156b65e90D3Fbf7E0D438fAb7b564668848", "2000000000000000000000") Community deployment rewards and compensation --------------------------------------------- Reimbursement shall be sourced out of the total 450M $ZKP allocated for protocol rewards. ### Deployment rewards As per [PIP-9][], the following rewards shall be sent: - 8000 $ZKP to `0xf0886ac6B2E9A2A75C9537EAF1A3aa8398FB10e8` for deployment of smart contracts and 1st subgraph instance - 2000 $ZKP to `0xdfE35156b65e90D3Fbf7E0D438fAb7b564668848` for deployment of the 2nd subgraph instance [PIP-9]: https://snapshot.org/#/pantherprotocol.eth/proposal/0x01942f584fe0c27aeef420207135be5ede279998da0a7839f22e2178b2d335ba ### Compensation for execution of proposal transactions The DAO will compensate for the cost of "gas" to any persons who execute 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](https://snapshot.org/#/pantherprotocol.eth/proposal/0x5b854f288f407562265f6fd701e8e50564e4e936d36fb3784664195f763434a0). It does *not* promise any compensation for normal staking / unstaking transactions, or other interactions with the smart contracts. 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), 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”.