Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Batch 1 transaction 1:
Deploy the AdvancedStakeV4ActionMsgTranslator smart contract on the Polygon network by invoking the DeterministicDeploymentProxy on the Polygon Network.
The transaction will initiate a call to FxRoot on the Ethereum mainnet, which will bridge the contract bytecode to the Polygon network through the MaticBridgeModule.
Batch 2 transaction 1:
Deploy the AdvancedStakeV4ActionMsgTranslator smart contract on the Ethereum mainnet using the DeterministicDeploymentProxy.
Batch 2 transaction 2…5:
Configure the Staking and RewardMaster smart contracts on the Ethereum mainnet to work with the newly deployed AdvancedStakeV4ActionMsgTranslator.
Batch 2 transaction 6:
Re-enable Advanced Stakes on the Ethereum mainnet from Friday, November 10, 2023, at 12:00:00 PM UTC until Sunday, March 10, 2024 at 12:00:00 AM UTC, with a lock period of 60 days.
Batch 3 transactions 1…4:
Configure the Staking and RewardMaster contracts on the Polygon network to interact with the newly deployed AdvancedStakeV4ActionMsgTranslator.
Calls to FxRoot on the Ethereum network will trigger the corresponding calls on the Polygon network. This is done through the bridging mechanism provided by the MaticBridgeModule.
Batch 3 transaction 5:
Re-enable advanced stakes on Polygon starting from Friday, November 10, 2023, at 12:00:00 PM UTC until Sunday, March 10, 2024 at 12:00:00 AM UTC, with a lock period of 60 days.
The transaction will call FxRoot on the Ethereum mainnet to bridge the configuration data to the Polygon network through MaticBridgeModule.
Batch 3 transaction 6:
Update the advanced staking reward parameters by changing the end time to Friday, May 09, 2024 12:00:00 AM UTC.
The transaction will invoke the call to FxRoot on the mainnet to facilitate the transfer of the configuration call across the Polygon bridge.
Batch 4 transaction 1:
Mint and release 15685 $ZKPs and transfer them to the community member who deployed and configured Contracts by executing the Pip 18 transactions and deployed Front end codes.
Batch 5 transaction 1…3:
Topping up the advanced stake v4 rewards by withdrawing 2m $ZKP from RewardTreasury on Polygon and transferring them to the AdvanceStakeRewardController.
These 2M tokens are recovered by the Polygon bug fix PIP (https://snapshot.org/#/pantherprotocol.eth/proposal/0x5b854f288f407562265f6fd701e8e50564e4e936d36fb3784664195f763434a0).
The transaction will call FxRoot on the Ethereum mainnet to bridge the transaction data to the Polygon network through MaticBridgeModule.
Members of the Panther community submit DAO Proposals for consideration as a part of the Protocol's decision-making process.
This section covers the proposals that have been submitted and approved by the DAO, from newest to oldest.
This proposal introduces the initiative of extending the “Advanced Staking” program for another two months, with stakes accepted till October 28, 2023 and rewards accrued at an APR of 15% for the locking period of 60 days.
The new staking cycle will be started with the parameters stated in the “Terms for smart contracts” section.
The initial “Advanced Staking” program was launched via PIP-9, PIP-10, and prolonged via PIP-13. The extended Advanced Staking program was valid till August 22, 2023 and the corresponding rewards were calculated for the same period.
The community proposes to launch the new cycle (“program”) given the completion of the previous program (activated via PIP-13).
The remaining $ZKP tokens originally allocated as staking rewards according to proposal PIP-9 shall be used to source rewards under the new program.
As discussed on Panther’s Discourse forum, the community recommends running a new cycle of the “Advanced Staking” program (AS3), with the parameters stated below in the “Terms for smart contracts” section.
This proposal (1) authorizes updates to the current UI which introduce the new staking terms as described below, (2) autorizes and triggers the execution (via Panther’s space on Snapshot.org and the Reality.eth oracle) of the attached blockchain transactions listed below under Annex, deploying and configuring Panther’s smart contracts to launch AS3.
It is proposed to follow the below parameters for extending the “Advanced Staking” program:
Approve all parameters included in the sections “Terms for smart contracts” and “Community Deployment Rewards”.
Authorize UI code updates to implement new terms,
Authorize and execute on the Ethereum Mainnet and Polygon network the deployment and configuration transactions described in the Annex, to achieve the terms for the AS3 program to be those outlined in the section “Terms for smart contracts”,
Request the Panther Foundation to configure the pantherprotocol.eth namespace so that the URL https://ipfs.io/ipns/pantherprotocol.eth will point to the updated UI deployed on IPFS.
Please vote to accept or reject the proposed actions detailed above.
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.
The full details of this proposal are visible also in raw Markdown format.
The complete list of transactions can be found under the following URL:
Batch 1 transaction 1
Deploy the AdvancedStakeV3ActionMsgTranslator smart contract on the Polygon network by invoking the DeterministicDeploymentProxy on the Polygon Network.
The transaction will initiate a call to FxRoot on the Ethereum mainnet, which will bridge the contract bytecode to the Polygon network through the MaticBridgeModule.
Batch 2 transaction 1
Deploy the AdvancedStakeV3ActionMsgTranslator smart contract on the Ethereum mainnet using the DeterministicDeploymentProxy.
Batch 2 transaction 2…5
Configure the Staking and RewardMaster smart contracts on the Ethereum mainnet to work with the newly deployed AdvancedStakeV3ActionMsgTranslator.
Batch 2 transaction 6
Re-enable Advanced Stakes on the Ethereum mainnet from Thursday, August 22, 2023, at 12:00:00 PM UTC until Sunday, October 22, 2023 at 12:00:00 AM UTC, with a lock period of 60 days.
Batch 3 transactions 1…4
Configure the Staking and RewardMaster contracts on the Polygon network to interact with the newly deployed AdvancedStakeV3ActionMsgTranslator.
Calls to FxRoot on the Ethereum network will trigger the corresponding calls on the Polygon network. This is done through the bridging mechanism provided by the MaticBridgeModule.
Batch 3 transaction 5
Re-enable advanced stakes on Polygon starting from Thursday, August 22, 2023, at 12:00:00 PM UTC until Sunday, October 22, 2023 at 12:00:00 AM UTC, with a lock period of 60 days.
The transaction will call FxRoot on the Ethereum mainnet to bridge the configuration data to the Polygon network through MaticBridgeModule.
Batch 3 transaction 6
Update the advanced staking reward parameters by changing the end time to Thursday, December 21, 2023 12:00:00 AM UTC.
The transaction will invoke the call to FxRoot on the mainnet to facilitate the transfer of the configuration call across the Polygon bridge.
Parameter | Description |
---|---|
This proposal triggers the execution of the following blockchain transactions. These transactions are already encoded during the submission of the proposal to , and can be independently verified via the web interface.
First day stakes are accepted
As soon as the PIP is passed and executed.
Last day stakes are accepted
October 28, 2023, 12:00 am UTC, or earlier if “Amount of $ZKP allocated for rewards to all stakers” below has been already depleted, or earlier if Panther’s mainnet beta is launched beforehand.
Amount of $ZKP allocated for rewards to all stakers
The remaining part of rewards, which were allocated according to PIP-9 and used during two cycles of the Advanced Staking program.
Number of days the staked $ZKP remains locked after stake creation
60 days
Reward formula, where: Reward - reward for a stake ($zZKP) Amount - amount staked ($ZKP) APR - Annual Percentage Rate (%) Period - rewarded period (days)
Reward = AmountAPRPeriod / 365 APR - 15%,Period - 60 days
Minimum $ZKP amount per stake
1000
Time since for a staker to withdraw rewards from the MASP (but forfeiting the right to accumulate PRPs)
Immediately after the stake is created.
This proposal extends the “Advanced Staking” program for another four months, with stakes accepted till March 10, 2024 and rewards accrued at an APR of 15% (same as a prior period) with the locking period of 60 days.
The new staking cycle will be started with the parameters stated in the “Terms for smart contracts” section.
The initial “Advanced Staking” program was launched via PIP-9, PIP-10, and prolonged via PIP-13 and PIP-18. The extended Advanced Staking program was valid till October 28, 2023 and the corresponding rewards were calculated for the same period.
The community proposes to launch the new cycle (“program”) given the completion of the previous program (activated via PIP-18). As discussed on Panther’s Discourse forum, the community recommends running a new cycle of the “Advanced Staking” program (AS4), with the parameters stated below in the “Terms for smart contracts” section.
The remaining $ZKP tokens originally allocated as staking rewards according to proposal PIP-9 shall be used to source rewards under the new program.
This proposal (1) authorizes updates to the current UI which introduce the new staking terms as described below, (2) authorizes and triggers the execution (via Panther’s space on Snapshot.org and the Reality.eth oracle) of the attached blockchain transactions listed below under Annex, deploying and configuring Panther’s smart contracts to launch Advance Staking - 4 (AS4).
It is proposed to follow the below parameters for extending the “Advanced Staking” program:
Approve all parameters included in the sections “Terms for smart contracts” and “Community Deployment Rewards”.
Authorize UI code updates to implement new terms,
Authorize and execute on the Ethereum Mainnet and Polygon network the deployment and configuration transactions described in the Annex, to achieve the terms for the AS4 program to be those outlined in the section “Terms for smart contracts”, including the adding funds to the rewards pool.
Send the deployment rewards according to points 1, 2, and 3 of the ''Community Deployment Rewards'' section of PIP-18, namely:
The distribution of 2000 $ZKP towards the following address for deploying the updated frontend (v0.5.4) onto IPFS:0xE1B583De9cB37196031b771686734a31ec365768
The distribution of 6000 $ZKP to the following address who executed the blockchain transactions to deploy and configure the smart contracts on the Ethereum Mainnet and Polygon network:0xE1B583De9cB37196031b771686734a31ec365768
The distribution of $146 USD in $ZKP tokens - which is $ZKP 7685 at the rate $ZKP=0.019 USD - as a gas fee compensation for the community member who executed point 3 of the Proposed Actions section, PIP-18: :0xE1B583De9cB37196031b771686734a31ec365768
Please vote to accept or reject the proposed actions detailed above.
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.
The full details of this proposal are visible in raw Markdown format.
This proposal triggers the execution of the following blockchain transactions. These transactions are already encoded during the submission of the proposal to Snapshot.org, and can be independently verified via the snapshot.org web interface.
The complete list of transactions can be found under the following URL: https://docs.pantherprotocol.io/docs/dao-proposals/proposal-19-extend-advanced-staking/technical-details.
Users who execute blockchain transactions listed in the Annex shall be rewarded as follows:
2,000 $ZKP shall be rewarded to the first deployer of the updated UI to IPFS.
3,000 $ZKP shall be rewarded to the user(s) who execute the blockchain transactions to deploy and configure smart contracts on the Ethereum Mainnet and Polygon network. There are 3 transactions to execute, each one will award a user 1,000 $ZKP reward.
Users who execute the above-mentioned blockchain transactions shall be given extra rewards as compensation for the gas costs incurred by these users on the Ethereum Mainnet.
Users who execute blockchain transactions listed in the Annex shall be rewarded as follows:
2,000 $ZKP shall be rewarded to the first deployer of the updated UI to IPFS.
3,000 $ZKP shall be rewarded to the user(s) who execute the blockchain transactions to deploy and configure smart contracts on the Ethereum Mainnet and Polygon network. There are 3 transactions to execute, each one will award a user 1,000 $ZKP reward.
Users who execute the mentioned above blockchain transactions shall be given extra rewards as compensation for the gas costs incurred by these users on the Ethereum Mainnet.
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):
{
“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:
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”.
To clarify, this only applies to the Reality.eth transactions directly associated with this DAO proposal, which are described in the Annex and listed on the corresponding page on . This does not promise any compensation for normal staking/unstaking transactions, or other interactions with the smart contracts.
To clarify, this only applies to the Reality.eth transactions directly associated with this DAO proposal, which are described in the Annex and listed at the corresponding page on . This does not promise any compensation for normal staking/unstaking transactions, or other interactions with the smart contracts.
were initiated as a Snapshot proposal in the PantherProtocol.eth space (at);
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 , having cast votes to approve execution of the transactions;
Parameter
Description
First day stakes are accepted
As soon as the PIP is passed and executed.
Last day stakes are accepted
March 10, 2024, 12:00 am UTC, or earlier if “Amount of $ZKP allocated for rewards to all stakers” below has been already depleted, or earlier if Panther’s mainnet beta is launched beforehand.
Amount of $ZKP allocated for rewards to all stakers
1) The remaining part of rewards, which were allocated according to PIP-9 and used during three cycles of the Advanced Staking program. 2) The additional $ZKP 2M, which are the tokens recovered by the Polygon bug fix PIP.
Number of days the staked $ZKP remains locked after stake creation
60 days
Reward formula, where: Reward - reward for a stake ($zZKP) Amount - amount staked ($ZKP) APR - Annual Percentage Rate (%) Period - rewarded period (days)
Reward = AmountAPRPeriod / 365, APR - 15%, Period - 60 days
Minimum $ZKP amount per stake
1000
Time since for a staker to withdraw rewards from the MASP (but forfeiting the right to accumulate PRPs)
Immediately after the stake is created.
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):
{
“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 (athttps://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 atpantherprotocol.eth, 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”.
This proposal triggers the execution of the following blockchain transactions. These transactions are already encoded during the submission of the proposal to Snapshot.org, and can be independently verified via the Snapshot.org web interface.
Batch 1 transaction 1
Deploy the AdvancedStakeV3ActionMsgTranslator smart contract on the Polygon network by invoking the DeterministicDeploymentProxy on the Polygon Network.
The transaction will initiate a call to FxRoot on the Ethereum mainnet, which will bridge the contract bytecode to the Polygon network through the MaticBridgeModule.
Batch 2 transaction 1
Deploy the AdvancedStakeV3ActionMsgTranslator smart contract on the Ethereum mainnet using the DeterministicDeploymentProxy.
Batch 2 transaction 2..5
Configure the Staking and RewardMaster smart contracts on the Ethereum mainnet to work with the newly deployed AdvancedStakeV3ActionMsgTranslator.
Batch 2 transaction 6
Re-enable Advanced Stakes on the Ethereum mainnet from Thursday, August 22, 2023, at 12:00:00 PM UTC until Sunday, October 22, 2023 at 12:00:00 AM UTC, with a lock period of 60 days.
Batch 3 transactions 1..4
Configure the Staking and RewardMaster contracts on the Polygon network to interact with the newly deployed AdvancedStakeV3ActionMsgTranslator.
Calls to FxRoot on the Ethereum network will trigger the corresponding calls on the Polygon network. This is done through the bridging mechanism provided by the MaticBridgeModule.
Batch 3 transaction 5
Re-enable advanced stakes on Polygon starting from Thursday, August 22, 2023, at 12:00:00 PM UTC until Sunday, October 22, 2023 at 12:00:00 AM UTC, with a lock period of 60 days.
The transaction will call FxRoot on the Ethereum mainnet to bridge the configuration data to the Polygon network through MaticBridgeModule.
Batch 3 transaction 6
Update the advanced staking reward parameters by changing the end time to Thursday, December 21, 2023 12:00:00 AM UTC.
The transaction will invoke the call to FxRoot on the mainnet to facilitate the transfer of the configuration call across the Polygon bridge.
This proposal introduces the initiative of extending the “Advanced Staking” program for another two months, with stakes to be accepted till October 22, 2023 and rewards to be accrued at the APR of 15% for the locking period of 60 days.
Therefore, the new staking cycle to be started with parameters stated in the “Terms for smart contracts” section.
It is proposed to follow the below parameters for extending the “Advanced Staking” program:
Approve all parameters included in the sections “Terms for smart contracts” and “Community Deployment Rewards”.
Authorize UI code updates to implement new terms,
Authorize and execute on the Ethereum Mainnet and Polygon network the deployment and configuration transactions described in the Annex, to achieve the terms for the AS3 program to be those outlined in the section “Terms for smart contracts”,
Request the Panther Foundation to configure the pantherprotocol.eth namespace so that the URL https://ipfs.io/ipns/pantherprotocol.eth will point to the updated UI deployed on IPFS.
Please vote to accept or reject the proposed actions detailed above.
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.
The initial “Advanced Staking” program was launched via , , and prolonged via . The extended Advanced Staking program is valid till August 22, 2023 and the corresponding rewards are to be calculated for the same period.
The community proposes to launch the new cycle ("program") prior the completion of the previous program (activated via ) that will be stopped simultaneously with the start of the new one.
The remaining $ZKP tokens originally allocated as staking rewards according to proposals shall be used to source rewards under the new program.
As discussed on , the community recommends running a new cycle of the “Advanced Staking” program (AS3), with parameters stated below in the “Terms for smart contracts” section.
This proposal (1) authorizes updates of which introduce the new staking terms as described below, (2) autorizes and triggers the execution (via on Snapshot.org and the Reality.eth oracle) of the attached blockchain transactions listed below under Annex, deploying and configuring Panther's smart contracts to launch AS3.
Parameter | Description |
---|
The full details of this proposal are visible in .
This proposal introduces PureFi, a compliance vendor, to the Panther Protocol ecosystem. Through this integration proposal, the community proposes a solution for Panther Protocol users to compliantly interact with the Protocol and external parties providing financial services.
During the last few months, the Panther community has been discussing compliance-related topics on the Panther forum [1]. During this discussion, multiple compliance vendors have been mentioned and, through this proposal, PureFi is proposed as the best solution for Panther Protocol based on, but not limited to, the following criteria:
Decentralization
Protocol-level integrations
On-chain support for ZK-compatible attestations and signatures
Fees paid (in $ZKP) on-chain by the Protocol
The aim of this integration is to engage with regulatory compliance and normalize the use of privacy tools by removing malicious actors at the best of Panther’s efforts.
If this proposal passes, PureFi becomes the first issuer of compliance credentials for Panther Protocol.
The “Compliance Provider” (PureFi and the KYC provider they integrate with) performs the following duties:
Maintains an on-chain list of valid of cryptographic key(s) (i.e. certificates) of Compliance Provider(s)
including the EdDSA public key available on Polygon
Escrows the Compliance Provider’s (backup) keys with a reliable 3rd party
e.g. a law firm
in case the Compliance Provider goes offline
Runs KYC and similar verification processes as required
at off-chain (HTTPS) requests from users
issuing a ZK-friendly KYC attestation without disclosing users’ identity data to anyone else.
signed by the Compliance Provider (EdDSA on the babyJubJub curve)
supporting the “Master External Owned Account (EoA)”
an EoA, unique for each user
Runs KYT checks (aka “wallet screening”)
performs ongoing blockchain analytics screening against sanctions lists & for illicit activity of every deposit / withdrawal
for stated “from”/”to” external address(es), token and amount
at off-chain (HTTPS) requests from users
Issuing a ZK-friendly KYT attestation
signed by the Compliance Provider (EdDSA on the babyJubJub curve)
Charges a compliance fee
Users pay a fee to the compliance provider to get the verification done as per the Protocol’s acceptance criteria. PureFi will provide details on the fee structure after the successful testing of the integration itself. The expectation is that fees should be very economical for a user to run a transaction. The Protocol onboarding reward can be viewed as compensating for this cost and hence the cost of compliance checks will be zero or very low for users.
The goal of the Protocol design is to enable multiple Compliance tiers for different classes of users with different transaction limits. The compliance tiers will be tied to a ‘Zone’, where every Zone has a ‘Zone Manager which defines compliance procedures and configures rules for the Zone they operate. “Tier 1000”, as it is initially called, is the first Tier where the Zone Manager is proposed to be the Panther DAO. Other tiers for higher transaction limits and/or operated by VASP will be introduced in later phases.
Tier1000 will have:
Simplified verification ( name, email, country)
Sanctions checks against major sanctions lists (US, UK, UN, EU)
Geofencing
KYT for every deposit/withdrawal amount (to/from addresses, token and amount transferred)
Max $1000 daily withdrawal per user
Please vote to accept or reject the proposed actions detailed above.
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.
The full details of this proposal are visible in raw Markdown format.
Users who execute blockchain transactions listed in the Annex shall be rewarded as follows:
2,000 $ZKP shall be rewarded to the first deployer of the updated UI to IPFS.
3,000 $ZKP shall be rewarded to the user(s) who execute the blockchain transactions to deploy and configure smart contracts on the Ethereum Mainnet and Polygon network. There are 3 transactions to execute, each one will award a user 1,000 $ZKP reward.
Users who execute the mentioned above blockchain transactions shall be given extra rewards as compensation for the gas costs incurred by these users on the Ethereum Mainnet.
To clarify, this only applies to the Reality.eth transactions directly associated with this DAO proposal, which are described in the Annex and listed at the corresponding page on Snapshot.org. This does not promise any compensation for normal staking/unstaking transactions, or other interactions with the smart contracts.
First day stakes are accepted | As soon as relevant PIP is passed and executed.
|
Last day stakes are accepted | October 22, 2023, 12:00 am UTC, or earlier if “Amount of $ZKP allocated for rewards to all stakers” below has been already depleted, or earlier if Panther’s mainnet beta is launched beforehand. |
Amount of $ZKP allocated for rewards to all stakers |
Number of days the staked $ZKP remains locked after stake creation | 60 days |
Reward formula, where: Reward - reward for a stake ($zZKP) Amount - amount staked ($ZKP)APR - Annual Percentage Rate (%) Period - rewarded period (days) | Reward = AmountAPRPeriod / 365 APR - 15%, Period - 60 days |
Minimum $ZKP amount per stake | 1000 |
Time since when a staker might withdraw rewards from the MASP (but forfeiting the right to accumulate PRPs | Immediately after the stake is created. |
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):
{
"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:
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”.
The remaining part of rewards, which were allocated according to and used during two cycles of the Advanced Staking program.
were initiated as a Snapshot proposal in the PantherProtocol.eth space (at);
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, having cast votes to approve execution of the transactions;
This proposal triggers the execution of the following blockchain transactions. These transactions are already encoded during the submission of the proposal to Snapshot.org, and can be independently verified through the Snapshot.org web interface.
Mint 14100e18 $ZKP as rewards for deployment:
VestingPools@eth::releaseTo(18, "0x505796f5bc290269d2522cf19135ad7aa60dfd77", "14100000000000000000000")
Transfer 16100e18 $ZKP to the community member who deployed and configured point 4.1 and 4.2 of the proposed actions section of this proposal:
ZKPToken@eth::transfer("0xE1B583De9cB37196031b771686734a31ec365768", "16100000000000000000000")
1.1 - Mint 14100e18 $ZKPs as rewards for deployment according to PIP-13:
VestingPools@eth::releaseTo(18, "0x505796f5bc290269d2522cf19135ad7aa60dfd77", "14100000000000000000000")
1.2. - Send 16100e18 $ZKPs as rewards for deployment according to PIP-13:
ZKPToken@eth::transfer("0xE1B583De9cB37196031b771686734a31ec365768", "16100000000000000000000")
Batch #1:
========
Tx #1.1.
To:
0xb476104aa9D1f30180a01987FB09b1e96dDCF14B // VestingPools@eth
Call:
VestingPools@eth::releaseTo(18, "0x505796f5bc290269d2522cf19135ad7aa60dfd77", "14100000000000000000000")
ABI:
[{"inputs":[{"internalType":"uint256","name":"poolId","type":"uint256"},{"internalType":"address","name":"account","type":"address"},{"internalType":"uint256","name":"amount","type":"uint256"}],"name":"releaseTo","outputs":[{"internalType":"uint256","name":"released","type":"uint256"}],"stateMutability":"nonpayable","type":"function"}]
params:
- uint256 poolId: 18
- address account: 0x505796f5bc290269d2522cf19135ad7aa60dfd77 // DAO_Multisig@eth,
- uint256 amount: 14100000000000000000000 // 14100e18 tokens (=0x2FC5CCEDEFF8FD00000)
txData:
0x2a7d7bc50000000000000000000000000000000000000000000000000000000000000012000000000000000000000000505796f5bc290269d2522cf19135ad7aa60dfd770000000000000000000000000000000000000000000002fc5ccedeff8fd00000
Tx #1.2.
To:
0x909E34d3f6124C324ac83DccA84b74398a6fa173 // ZKPToken@eth
Call:
ZKPToken@eth::transfer("0xE1B583De9cB37196031b771686734a31ec365768", "16100000000000000000000")
ABI:
[{"inputs":[{"internalType":"address","name":"recipient","type":"address"},{"internalType":"uint256","name":"amount","type":"uint256"}],"name":"transfer","outputs":[{"internalType":"bool","name":"","type":"bool"}],"stateMutability":"nonpayable","type":"function"}]
params:
- address recipient: 0xE1B583De9cB37196031b771686734a31ec365768
- uint256 amount: 16100000000000000000000 // 16100e18 tokens (=0x368C8623A8B4D100000)
txData:
0xa9059cbb000000000000000000000000e1b583de9cb37196031b771686734a31ec365768000000000000000000000000000000000000000000000368c8623a8b4d100000
Users who (1) deploy the v0.5.3 frontend to IPFS and (2) execute blockchain transactions listed in the Annex shall be rewarded as follows:
2,000 $ZKP shall be rewarded to each of the first 2 deployers of the updated frontend (v0.5.3) to IPFS.
6,000 $ZKP shall be rewarded to the user(s) who execute the blockchain transactions to deploy and configure smart contracts on the Ethereum Mainnet and Polygon network. There are 6 transactions to execute, each one will award a user 1,000 $ZKP reward.
Users who execute the mentioned above blockchain transactions shall be given extra rewards as compensation for the gas costs incurred by these users on the Ethereum Mainnet.
To clarify, this only applies to the Reality.eth transactions directly associated with this DAO proposal, which are described in the Annex and listed at the corresponding page on Snapshot.org. This does not promise any compensation for normal staking/unstaking transactions, or other interactions with the smart contracts.
To source the rewards described above and similar rewards which may be proposed in the future, 100,000 $ZKP shall be allocated out of the total 450M $ZKP allocated for Protocol rewards.
This proposal introduces updates and upgrades to the frontend (“UI”) of the Panther Protocol version 0.5, known as Advanced Staking. A comprehensive list of the introduced changes can be found below in the Annex.
Through PIP-9 and PIP-10, the Panther Protocol version 0.5 was deployed and activated. After the launch of version 0.5, users witnessed minor frontend (UI) related issues. After the launch, contributors to the Protocol prepared, tested and published source code of the new frontend version that resolves found issues and optimizes performance.As discussed by the community on the Panther’s Discourse forum, the community recommends using the v0.5 upgraded frontend instead of the previous one.In order to have a user-friendly URL pointing to the v0.5 upgraded frontend, and also to safeguard access to the correct link/app, the community requests and makes a recommendation to configure the pantherprotocol.eth ENS domain namespace in such a way that the user-friendly link https://ipfs.io/ipns/pantherprotocol.eth will point to the v0.5 upgraded frontend (dApp) deployed frontend.
The following action(s) are proposed:
Allocate the unused 2,000 $ZKP out of 4,000 $ZKP previously allocated in accordance with the PIP-9 for front-nd deployments, to be used for rewards to a community member who will have build and deploy the v0.5 upgraded frontend on IPFS.
Configure the PantherProtocol.eth ENS domain namespace so that the URL https://ipfs.io/ipns/PantherProtocol.eth will point to the v0.5 upgraded frontend (UI) deployed on IPFS.
Please vote to accept or reject the proposed actions detailed above. Voting power is calculated by Snapshot taking a Snapshot of the number of $ZKP tokens staked per holder at the block within which the proposal was created.
Following changes are introduced by the new frontend (dApp) version:
Optimize UI performance if multiple stakes (40+) are created by a user.
Correct the broken layout for the AssetsCardRow on mobile.
Show an error notification card when there is an error refreshing the balance.- Show APR when the user is disconnected.
Correct Balance card layout, when the user is disconnected.
Correct the link on the Staking page/ Staking tab/Privacy Reward Points field tooltip and introduce other text fixes for clarity.
Update the MATIC balance upon the refresh button push. The source code is available on GitHub.
The full details of this proposal are visible in raw Markdown format on IPFS.
This proposal gives Panther Foundation Limited authority to spend an estimate of $300k for the MEXC listing of $ZKP. These funds are to be used on listing fees, marketing costs, and liquidity/market making costs, and should be pulled from Foundation funds.
The Panther community has asked for additional exchange listings. Through MEXC we hope to improve the trading experience. MEXC concern both the Ethereum and Polygon network. The community would like The Foundation to aim to execute most of the tasks before the end of February 2023.
The listing fees, marketing expenditure, and requisite liquidity should come from the Foundation budget.
Improve the on and offramps for the advanced staking Protocol.
Fairer prices for buyers and sellers on MEXC due to improved trading volumes on the exchange.
Expose Panther to a large audience of potential traders.
Higher trader volume and market stability.
The main infrastructure for Panther is on polygon currently therefore it only makes sense to have the option to withdraw on polygon from MEXC.
The following actions are proposed:
Give the Foundation authority to:
Earmark up to $300000 of Foundation funds for listing fees, marketing costs, and initial liquidity / market making funds for listing on MEXC.
Sign listing agreements and transfer the funds.
Determine the best date in the future to list $ZKP, create a marketing plan, and announce and promote the listing accordingly.
Engage a market maker to manage the liquidity and trading.
Please vote to accept or reject the proposed actions detailed above.
As per the existing DAO governance structure, you need to hold staked $ZKP 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.
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:
were initiated as a Snapshot proposal in the PantherProtocol.eth space (at 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
, 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”.
New smart contracts
The Panther Protocol will be extended with the following newly deployed smart contracts:
On the Ethereum mainnet:
at 0x39ed49B3cEA4796E669f2542a41B876646c1BBe7
: AdvancedStakeV2ActionMsgTranslator
On the Polygon network:
at 0x7f076D64055E19d0f9E84160748c6c3CED9c28aC
: AdvancedStakeV2ActionMsgTranslator
Existing smart contract affected or involved
The proposal transactions will involve the following pre-existing smart contracts:
On the Ethereum mainnet:
at 0x505796f5bc290269d2522cf19135ad7aa60dfd77
: DAO_Multisig
at 0xf4d06d72dACdD8393FA4eA72FdcC10049711F899
: Staking
at 0x347a58878D04951588741d4d16d54B742c7f60fC
: RewardMaster
at 0xFED599513aB078Edea7Cf46574154f92b0B9FCAB
: AdvancedStakeRewardAdviserAndMsgSender
at 0x909E34d3f6124C324ac83DccA84b74398a6fa173
: ZKPToken
at 0xb476104aa9D1f30180a01987FB09b1e96dDCF14B
: VestingPools
at 0xfe5e5D361b2ad62c541bAb87C45a0B9B018389a2
: FxRoot
at 0x4A4FC40d2475f493EcA3Ec436b924237AA1b0a76
: MaticBridgeModule
at 0x4e59b44847b379578588920cA78FbF26c0B4956C
: DeterministicDeploymentProxy
(github.com/Arachnid/deterministic-deployment-proxy
On the Polygon network:
at 0x4cEc451F63DBE47D9dA2DeBE2B734E4CB4000Eac
: Staking
at 0x09220DD0c342Ee92C333FAa6879984D63B4dff03
: RewardMaster
at 0x4e59b44847b379578588920cA78FbF26c0B4956C
: DeterministicDeploymentProxy
(github.com/Arachnid/deterministic-deployment-proxy
Transactions
This proposal initiates the execution of several blockchain transactions. These transactions have been pre-encoded during the submission of the proposal to snapshot.org and can be independently verified using the snapshot.org web interface.
Batch 1 transaction 1
Deploy the AdvancedStakeV2ActionMsgTranslator
on the Polygon network by invoking the DeterministicDeploymentProxy
on the Polygon Network. The transaction will initiate a call to FxRoot
on the Ethereum mainnet, which will bridge the contract bytecode to the Polygon network through the MaticBridgeModule
:FxRoot@eth::sendMessageToChild(0x4A4FC40d2475f493EcA3Ec436b924237AA1b0a76, 0x0000000000000000000000004e59b44847b379578588920ca78fbf26c0b4956c000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001500000000000000000000000000000000000000000000000000000000000005248484806d0109ded292adb1e26b7422b1a421b02e037a04defec1d1ac2d98413660a060405234801561001057600080fd5b506040516104e43803806104e483398101604081905261002f91610089565b6001600160a01b0381166100785760405162461bcd60e51b815260206004820152600c60248201526b5a65726f206164647265737360a01b604482015260640160405180910390fd5b6001600160a01b03166080526100b9565b60006020828403121561009b57600080fd5b81516001600160a01b03811681146100b257600080fd5b9392505050565b6080516104096100db6000396000818161010101526101af01526104096000f3fe608060405234801561001057600080fd5b506004361061002b5760003560e01c8063e9cb032414610030575b600080fd5b61004361003e3660046102cc565b6100be565b6040516100b59190600060a08201905073ffffffffffffffffffffffffffffffffffffffff80845116835260208401516bffffffffffffffffffffffff808216602086015282604087015116604086015280606087015116606086015250508060808501511660808401525092915050565b60405180910390f35b6040805160a0810182526000808252602082018190529181018290526060810182905260808101919091523373ffffffffffffffffffffffffffffffffffffffff7f000000000000000000000000000000000000000000000000000000000000000016146101735760405162461bcd60e51b815260206004820152601160248201527f414d543a20756e617574686f72697a656400000000000000000000000000000060448201526064015b60405180910390fd5b63e6ab1cdf60e01b6001600160e01b031984160161022457604051630dc3282360e11b815273ffffffffffffffffffffffffffffffffffffffff7f00000000000000000000000000000000000000000000000000000000000000001690631b865046906101ed906319932b9d60e31b90869060040161039d565b600060405180830381600087803b15801561020757600080fd5b505af115801561021b573d6000803e3d6000fd5b50505050610284565b6001600160e01b03198316636a8ecb8160e01b146102845760405162461bcd60e51b815260206004820152601760248201527f414d543a20756e737570706f7274656420616374696f6e000000000000000000604482015260640161016a565b506040805160a08101825260008082526020820181905291810182905260608101829052608081019190915292915050565b634e487b7160e01b600052604160045260246000fd5b600080604083850312156102df57600080fd5b82356001600160e01b0319811681146102f757600080fd5b9150602083013567ffffffffffffffff8082111561031457600080fd5b818501915085601f83011261032857600080fd5b81358181111561033a5761033a6102b6565b604051601f8201601f19908116603f01168101908382118183101715610362576103626102b6565b8160405282815288602084870101111561037b57600080fd5b8260208601602083013760006020848301015280955050505050509250929050565b63ffffffff60e01b8316815260006020604081840152835180604085015260005b818110156103da578581018301518582016060015282016103be565b506000606082860101526060601f19601f83011685010192505050939250505056fea164736f6c6343000810000a00000000000000000000000009220dd0c342ee92c333faa6879984d63b4dff0300000000000000000000000000000000000000000000000000000000)
Batch 2 transaction 1
Deploy the AdvancedStakeV2ActionMsgTranslator
on the Ethereum mainnet using the DeterministicDeploymentProxy
:DeterministicDeploymentProxy@eth::call( 0x8484806d0109ded292adb1e26b7422b1a421b02e037a04defec1d1ac2d98413660a060405234801561001057600080fd5b506040516104e43803806104e483398101604081905261002f91610089565b6001600160a01b0381166100785760405162461bcd60e51b815260206004820152600c60248201526b5a65726f206164647265737360a01b604482015260640160405180910390fd5b6001600160a01b03166080526100b9565b60006020828403121561009b57600080fd5b81516001600160a01b03811681146100b257600080fd5b9392505050565b6080516104096100db6000396000818161010101526101af01526104096000f3fe608060405234801561001057600080fd5b506004361061002b5760003560e01c8063e9cb032414610030575b600080fd5b61004361003e3660046102cc565b6100be565b6040516100b59190600060a08201905073ffffffffffffffffffffffffffffffffffffffff80845116835260208401516bffffffffffffffffffffffff808216602086015282604087015116604086015280606087015116606086015250508060808501511660808401525092915050565b60405180910390f35b6040805160a0810182526000808252602082018190529181018290526060810182905260808101919091523373ffffffffffffffffffffffffffffffffffffffff7f000000000000000000000000000000000000000000000000000000000000000016146101735760405162461bcd60e51b815260206004820152601160248201527f414d543a20756e617574686f72697a656400000000000000000000000000000060448201526064015b60405180910390fd5b63e6ab1cdf60e01b6001600160e01b031984160161022457604051630dc3282360e11b815273ffffffffffffffffffffffffffffffffffffffff7f00000000000000000000000000000000000000000000000000000000000000001690631b865046906101ed906319932b9d60e31b90869060040161039d565b600060405180830381600087803b15801561020757600080fd5b505af115801561021b573d6000803e3d6000fd5b50505050610284565b6001600160e01b03198316636a8ecb8160e01b146102845760405162461bcd60e51b815260206004820152601760248201527f414d543a20756e737570706f7274656420616374696f6e000000000000000000604482015260640161016a565b506040805160a08101825260008082526020820181905291810182905260608101829052608081019190915292915050565b634e487b7160e01b600052604160045260246000fd5b600080604083850312156102df57600080fd5b82356001600160e01b0319811681146102f757600080fd5b9150602083013567ffffffffffffffff8082111561031457600080fd5b818501915085601f83011261032857600080fd5b81358181111561033a5761033a6102b6565b604051601f8201601f19908116603f01168101908382118183101715610362576103626102b6565b8160405282815288602084870101111561037b57600080fd5b8260208601602083013760006020848301015280955050505050509250929050565b63ffffffff60e01b8316815260006020604081840152835180604085015260005b818110156103da578581018301518582016060015282016103be565b506000606082860101526060601f19601f83011685010192505050939250505056fea164736f6c6343000810000a000000000000000000000000347a58878d04951588741d4d16d54b742c7f60fc )
Batch 2 transaction 2…5
Configure the Staking
and AdvancedStakeRewardAdviserAndMsgSender
contracts on the Ethereum mainnet to work with the newly deployed AdvancedStakeV2ActionMsgTranslator
:RewardMaster@eth::addRewardAdviser( “0xf4d06d72dACdD8393FA4eA72FdcC10049711F899”, “0x1954e321”, “0x39ed49B3cEA4796E669f2542a41B876646c1BBe7”)RewardMaster@eth::addRewardAdviser( “0xf4d06d72dACdD8393FA4eA72FdcC10049711F899”, “0x6a8ecb81”, “0x39ed49B3cEA4796E669f2542a41B876646c1BBe7”)RewardMaster@eth::addRewardAdviser( “0x39ed49B3cEA4796E669f2542a41B876646c1BBe7”, “0xcc995ce8”, “0xFED599513aB078Edea7Cf46574154f92b0B9FCAB”)RewardMaster@eth::addRewardAdviser( “0x39ed49B3cEA4796E669f2542a41B876646c1BBe7”, “0xb8372e55”, “0xFED599513aB078Edea7Cf46574154f92b0B9FCAB”)
Batch 2 transaction 6
Enable Advanced Stakes V2 on the Ethereum mainnet from Thursday, April 6, 2023, at 6:00:00 PM UTC until Tuesday, August 22, 2023, at 12:00:00 PM UTC, with a lock period of 60 days:Staking@eth::addTerms( “0x8496de05”, [true,true,1000,0,1680804000,1692705600,0,0,5184000])
Batch 3
Configure the Staking
and AdvancedStakeRewardAdviserAndMsgSender
contracts on the Polygon network to interact with the newly deployed AdvancedStakeV2ActionMsgTranslator
.FxRoot@eth::sendMessageToChild( 0x4A4FC40d2475f493EcA3Ec436b924237AA1b0a76, 0x00000000000000000000000009220dd0c342ee92c333faa6879984d63b4dff03000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000016000000000000000000000000000000000000000000000000000000000000006499ff97360000000000000000000000004cec451f63dbe47d9da2debe2b734e4cb4000eac1954e321000000000000000000000000000000000000000000000000000000000000000000000000000000007f076d64055e19d0f9e84160748c6c3ced9c28ac00000000000000000000000000000000000000000000000000000000)FxRoot@eth::sendMessageToChild( 0x4A4FC40d2475f493EcA3Ec436b924237AA1b0a76, 0x00000000000000000000000009220dd0c342ee92c333faa6879984d63b4dff03000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000017000000000000000000000000000000000000000000000000000000000000006499ff97360000000000000000000000004cec451f63dbe47d9da2debe2b734e4cb4000eac6a8ecb81000000000000000000000000000000000000000000000000000000000000000000000000000000007f076d64055e19d0f9e84160748c6c3ced9c28ac00000000000000000000000000000000000000000000000000000000)FxRoot@eth::sendMessageToChild( 0x4A4FC40d2475f493EcA3Ec436b924237AA1b0a76, 0x00000000000000000000000009220dd0c342ee92c333faa6879984d63b4dff03000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000018000000000000000000000000000000000000000000000000000000000000006499ff97360000000000000000000000007f076d64055e19d0f9e84160748c6c3ced9c28accc995ce8000000000000000000000000000000000000000000000000000000000000000000000000000000008f15a43961c27c74cb4f55234a78802401614de300000000000000000000000000000000000000000000000000000000)FxRoot@eth::sendMessageToChild( 0x4A4FC40d2475f493EcA3Ec436b924237AA1b0a76, 0x00000000000000000000000009220dd0c342ee92c333faa6879984d63b4dff03000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000019000000000000000000000000000000000000000000000000000000000000006499ff97360000000000000000000000007f076d64055e19d0f9e84160748c6c3ced9c28acb8372e55000000000000000000000000000000000000000000000000000000000000000000000000000000008f15a43961c27c74cb4f55234a78802401614de300000000000000000000000000000000000000000000000000000000)FxRoot@eth::sendMessageToChild
calls on the Ethereum network represents encoded transactions that will trigger the corresponding calls on the Polygon network. This is done through the bridging mechanism provided by the MaticBridgeModule
. Once the transactions are executed on the Ethereum network, they will be relayed to the Polygon network, where they will be decoded and executed as the intended calls. The transactions mentioned above represent the following calls on the Polygon network:RewardMaster@matic::addRewardAdviser( “0x4cEc451F63DBE47D9dA2DeBE2B734E4CB4000Eac”, “0x1954e321”, “0x7f076D64055E19d0f9E84160748c6c3CED9c28aC”)RewardMaster@matic::addRewardAdviser( “0x4cEc451F63DBE47D9dA2DeBE2B734E4CB4000Eac”, “0x6a8ecb81”, “0x7f076D64055E19d0f9E84160748c6c3CED9c28aC”)RewardMaster@matic::addRewardAdviser( “0x7f076D64055E19d0f9E84160748c6c3CED9c28aC”, “0xcc995ce8”, “0x8f15a43961c27C74CB4F55234A78802401614de3”)RewardMaster@matic::addRewardAdviser( “0x7f076D64055E19d0f9E84160748c6c3CED9c28aC”, “0xb8372e55”, “0x8f15a43961c27C74CB4F55234A78802401614de3”)
Batch 3 transaction 5
Enable advanced stakes V2 on Polygon starting from Thursday, April 6, 2023 at 6:00:00 PM UTC until Tuesday, August 22, 2023 at 12:00:00 PM UTC, with a lock period of 60 days:FxRoot@eth::sendMessageToChild( 0x4A4FC40d2475f493EcA3Ec436b924237AA1b0a76, 0x0000000000000000000000004cec451f63dbe47d9da2debe2b734e4cb4000eac000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001a00000000000000000000000000000000000000000000000000000000000001445391dff58496de05000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000100000000000000000000000000000000000000000000000000000000000003e8000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000642f08a00000000000000000000000000000000000000000000000000000000064e4a3400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004f1a0000000000000000000000000000000000000000000000000000000000)The transaction will call FxRoot
on the mainnet to bridge the following configuration data to the Polygon network through MaticBridgeModule
:Staking@matic::addTerms( “0x8496de05”, [true,true,1000,0,1680804000,1692705600,0,0,5184000])
Batch 3 transaction 6
Update the advanced staking reward parameters by changing the end time to Tuesday, August 22, 2023 at 4:00:00 PM GMT:FxRoot@eth::sendMessageToChild( 0x4A4FC40d2475f493EcA3Ec436b924237AA1b0a76, 0x0000000000000000000000008f15a43961c27c74cb4f55234a78802401614de3000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000001b0000000000000000000000000000000000000000000000000000000000000084bfa6946000000000000000000000000000000000000000000000000000000000639226200000000000000000000000000000000000000000000000000000000064e4db80000000000000000000000000000000000000000000000000000000000000000f000000000000000000000000000000000000000000000000000000000000000f00000000000000000000000000000000000000000000000000000000)The transaction will invoke the FxRoot
on the mainnet to facilitate the transfer of the following configuration call across the Polygon bridge:AdvancedStakeRewardController@matic::updateRewardParams( [1670522400,1692720000,15,15] )
Batch 4 transaction 1
Transfer ZKP reward to the community member for executing the PIP-11:ZKPToken@eth::transfer( “0xE1B583De9cB37196031b771686734a31ec365768”, “2000000000000000000000”)
Batch 4 transaction 2…3
Add and configure a 100,000 $ZKP Vesting Pool designated for Community Deployment rewards:VestingPools@eth::addVestingPools( [“0x505796f5bc290269d2522cf19135ad7aa60dfd77”], [[false,true,1683450000,1,100000000000,100000000000,0]])VestingPools@eth::updatePoolTime(18, 1681732800, 1)
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 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”.
The following actions are proposed:
Authorize and execute on the Ethereum Mainnet the attached configuration transactions, to achieve the following:
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 mainnet beta 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.
were initiated as a Snapshot proposal in the PantherProtocol.eth space (at );
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 , having cast votes to approve execution of the transactions;
This proposal is the second out of two governing the launch of version 0.5 of the Panther Protocol, . 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 .Finally it suggests a secure user-friendly URL to the frontend for version 0.5 as discussed by the community on .
The approval of 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 need to be configured to work as a whole. This proposal authorizes and triggers execution of the attached blockchain transactions (via ), which configure the Panther Protocol's smart contracts. This proposal also covers rewarding the users that deployed Advanced Staking's components as per .In order to have a user-friendly URL pointing to the frontend 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 namespace in such a way that the user-friendly link will point to the deployed frontend.
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
Configure terms for the staking programs to be .
Request Panther Foundation to configure the namespace so that the URL will point to the v0.5 frontend deployed on IPFS.
Description of blockchain transactions and further configuration details may be found .
This proposal is the first one out of two governing the launch of version 0.5 of the Panther Protocol, known as “Advanced Staking”. It defines the parameters for the Advanced Staking program and procedures for software components deployment, which were discussed by the community on Panther’s Discourse forum [1] [2]. The second proposal, which is to be submitted and voted after execution of this one, will activate newly deployed software components by configuring newly and existing components of the Panther Protocol to work together. This proposal also features an Annex, which details the different parts of the Advanced Staking process.
After extensive rounds of community testing, discussion of terms, and with tested, audited, open-sourced code, Advanced Staking can now be deployed to the Ethereum Mainnet and Polygon network. You can read the specifications for it in Panther’s documentation.
Panther’s Advanced Staking is a progressive step towards the development of the core technologies surrounding the Multi Asset Shielded Pool, in particular the way UTXOs are created, managed and tracked.
Advanced Staking acts as a step to deploy and test the above capabilities by issuing staking rewards within the MASP, without users having the ability to transact within the MASP or privately withdraw rewards from the MASP in this version. The version which will allow this functionality is further referred to as the “Panther’s mainnet beta”.
Only $ZKP issued as staking rewards (unlike $ZKP users staked) will be automatically added to the MASP (as $zZKP) in this version. Its mechanisms also involve minting a “stake proof” NFT with each stake, and adding this token to the MASP (as a zNFT) that qualifies users to receive Panther Reward Points (PRPs, see the Annex) upon the mainnet beta launch.
The following terms resulted from multiple rounds of community discussions on Discourse and other channels:
The above value indicates that there is an active program for 6 months with stakes being accepted until 4 months from the beginning of the Staking Program.The stakes are locked for 2 months only, which means that:
Users can unstake after 2 months.
Users may restake for another 2 months after this.
Rewards are based on the locking period. Users will instantly earn a Staking reward calculated for a 2 months period. The rewards won't continue to accrue if the user leaves his tokens staked after 2 months. Therefore, to make the most of the whole staking duration, users must unstake and stake again to get the rewards for the next 2 months period. In summary, this Staking program is designed to be flexible and configurable which allows two terms of Staking within the whole duration of the program. Stakers get the same fixed % APR for both terms.
Costs of deploying Advanced Staking’s components shall be compensated to deployers (anyone who is technically capable of deploying components can choose to do so) as follows:
a. For smart contracts deployment - 6,000 $ZKP to the 1st deployer of the smart contracts on the Ethereum Mainnet and Polygon network.
b. For subgraph components deployment - 2,000 $ZKP to each of the first 2 first deployers of the subgraph on the Hosted Service
c. For frontend deployment - 2,000 $ZKP to each of the first 2 deployers of the frontend code to IPFS
Reimbursement shall be sourced out of the total 450M $ZKP allocated for Protocol rewards.
The following actions are proposed:
Approve all parameters included in the section “Terms for smart contracts”.
Allocate 6.0M $ZKP, out of the total 450M $ZKP allocated for Protocol rewards, to be used for staking rewards (i.e. send to the VestingPools smart contract a blockchain transaction which registers the allocation).
Allocate 14,000 $ZKP out of the total 450M $ZKP allocated for Protocol rewards, to be used for rewards to community members who will have deployed the Advanced Staking components as outlined in the Community Deployment section (i.e. send to the VestingPools smart contract a blockchain transaction which registers this allocation).
Please vote to accept or reject the proposed actions detailed above. 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.
The full details of this proposal available in raw Markdown format on IPFS.
The following are the definitions of the multiple functions present in the Staking process. Note that specific terms and variables have been discussed by the Panther community prior to being introduced on this proposal.
Staking: Users’ stakes are securely locked in the Staking smart contracts on Ethereum Mainnet and on Polygon (same smart contracts users staked with before). Users can stake on both networks.
Unstaking: Users can unstake their principal amount from the Staking Contract after a locked time period (the two months since creation of a stake).
Staking Reward: The Protocol will issue staking rewards in the form of $zZKP inside the MASP deployed on Polygon. Stakers on Mainnet will also see their rewards on Polygon even though their stakes will remain locked on Mainnet.
Reward Redemption: Users can redeem (withdraw) their $zZKP rewards from the MASP before the mainnet beta launch by using the “Redeem” function. By doing this, they will forfeit their ability to accumulate accrued PRP rewards (see below).
Alternatively, users may wait for the launch of Panther’s mainnet beta to use (withdraw, or transact inside the MASP) both $zZKP and entire PRP rewards.
Panther Reward Points (PRP) Rewards: To further test the Protocol and the utilization of PRP, early stakers are eligible for PRP Rewards.
!!! Please note:
- PRP rewards will only be generated when Panther’s mainnet beta launches.
- The following terms are subject to further approval through PIPs.
Panther’s smart contracts will allow conversion of PRP into $ZKP (or $zZKP) at a rate driven by the supply and demand. The rate will be initially set at “10 PRPs for 1 $ZKP”, but this value is not guaranteed to last unchanged even for a minute after the launch.
There will be two types of PRP rewards resulted from Advanced Staking:
a. Flat PRP rewards for holders of “stake proof” NFTs. The first 2000 stakers will receive 2000 NFTs. Each NFT will be eligible for the reward of 2000 PRPs. Holders of “stake proof” NFTs will be able to get the “flat PRP” reward after the mainnet beta launch no matter if they have withdrawn $zZKPs or not.
b. Accrued PRP rewards. These are created by default as per the Privacy Reward logic of Panther Core. The reward amount is proportional to the $zZKP amount and the time it remains shielded in the MASP. To get the accrued PRP reward a user has to spend a $zZKP UTXO inside the MASP. It means, if a user redeems/withdraws his $zZKP before the mainnet beta launch, the one loses this type of PRP rewards.
This proposal aims to improve Panther's Snapshot governance process and degree of decentralization.
It proposes the introduction of an improved voting logic at times where tokens staked are not sufficient for the community to be thoroughly represented. This change will come into play when the staking contract is not releasing rewards to users. The new logic will take into account user $ZKP balances instead of only staked tokens.
Currently, only around 8% of the total $ZKP supply is staked. This means that most users will not be able to vote on this and future governance proposal.
Moreover, in order a proposal to pass at least 4% of the $ZKP token total supply should cast votes, which may prevent obtaining the quorum when no active staking program is running.
To cover the cases when the staking smart contract is not releasing rewards to users (a situation likely to happen in initial phases of the project), improved voting rules must be proposed and applied.
This proposal intends for the Panther DAO to define an alternate mechanism that considers users’ $ZKP balances together with their staked amounts in the staking contract on any supported network (currently the Mainnet and Polygon) as a secondary go-to in these cases. In these cases, the voting power of $ZKP tokens holders will be calculated as "one owned or staked token = one vote".
Whenever the smart contract releases rewards to users, the system will default back to the original mechanism (one staked token = one vote).
If this proposal passes, the admin of the Panther Protocol space on Snapshot.org will update the settings of the space so that the voting power for further voting will be computed according to the rule stated above.
Please vote to accept or reject the proposed actions detailed above.
As per the existing DAO governance structure, to participate in voting, you need to have staked $ZKP in Panther's staking contract on the Ethereum Mainnet or Polygon.
This proposal covers the introduction of new Snapshot Authors, accounts with the ability to write proposals, onboarding two Panther contributors and six community members.
It introduces two new Admin accounts, community members, to play a role within a two-out-of-three multisig that can change the Snapshot settings for Panther's Snapshot space. Both of these actions will be applied during a timeframe of six months, after which the community is to nominate a new list of Admins and Authors.
This proposal aims to increase Panther’s degree of decentralization. This will be achieved by:
Increasing the number of accounts with the ability to publish proposals on the Panther Protocol space on Snapshot.org (Authors).
Setting up a Gnosis Safe multisig wallet, with 3 signers and a "2-out-of-3" signing policy as the only admin account for the Panther’s Snapshot.org space.
Adding two new community members additional to the current Admin as signers on the multisig.
The identities of the nominees are available in the proposal’s Description section. If this proposal passes, Panther’s Snapshot.org space will have eight new Authors and two new Admins, allowlisted for the next six months. The community will propose a list of nominees every six months and vote on their appointment. Furthermore, the Snapshot.org space’s settings will be set so that future changes to its settings will require approval from two of three allowlisted Admins.
Increasing the number of allowlisted addresses, appointing additional Admins, and setting up a multisig for Admin actions increases the community’s presence in the Protocol’s governance and eliminates single points of failure.
If this proposal passes, Panther Protocol’s space on the Snapshot.org cloud service will have eight new allowlisted Authors and two new Admins. Changes in settings of the space following the approval of this proposal will require the signature of two of the three allowlisted Admins. The permissions for this set of Authors and Admins are proposed to last for six months, after which we expect the community will propose its own list of nominees and vote on their appointment. This is part of Panther’s decentralized governance process with a focus on community governance. The new addresses allowlisted as Authors will belong to:
Victor, (Discord: Black322#9757), Russian Community Ambassador. Address: 0xDC885850D72c3269aa2d2bCB32C70E2080b3ACF1
Quentin, (Discord: qqorq#0903), Social Content Ambassador. Address: 0xac9Ff68Ff1F377CD62B63Bcc500025F81EFBCab0
Luka, (Discord: Luka de la Team Hermione#0085), French Community Ambassador and Discord Moderator. Address: 0xBaA5A9b673003481972A97eB5593C8D1818843af
Akin, (Discord: Akin#6560), Turkish Community Ambassador and Discord Moderator. Address: 0xFd9b55948Abb2C0e2137eCF951EB03117153130D
Sam, (Discord: 666Sam999#2082), Telegram and Discord Channel Moderator. Address: 0xF66268c5E9075223E32a364E321c74f4c0264BC8
Toxic Entity, (Discord: toxicehc#5599), well-known Community member. Address: 0xE1B583De9cB37196031b771686734a31ec365768
Saif, (Discord: Saifonblock#3283), early Panther Product Contributor. Address: 0x56dd80C22A375a53f3d11223fEe10C40A4b32d6F
Joris, (Discord: Joris#1585), early Panther Contributor. Address: 0xB86DB7690887207209cC1a0F26E80d46f081B0a9
The new addresses that will be part of the Admin multisig will belong to:
Anton (Discord: antonie#1798), well-known Web3 enthusiast and Panther community member. Address: 0xeC88b933a75F961Ce55d7EaF6CDD6CEd103A4AD8
Dan P (Discord: DanP#0547), well-known Panther community member, active on Telegram and the Panther forum. Address: 0x3f6Dd0C54c0F86F85c5bB6Cc5a82538f702bF103
Neither Admins nor Authors hold any privilege in Panther’s governance mechanism. PIPs can only be published by the addresses above. Signers of the Admin multisig must maintain the settings in strict accordance with this and future governance proposals.
Per , to participate in voting, users need to have staked $ZKP in Panther's staking smart contract on the Ethereum Mainnet or Polygon.
The contents of this proposal are identical to those presented in Section #3 of , which didn’t reach voting quorum, though it gathered an overwhelming majority of your votes (98%+). As such, this proposal presents Section #3 as a standalone vote, with the objective of introducing rules for wider community voting that will govern the DAO subsequently.
Voting power is calculated by Snapshot.org taking a Snapshot of the number of ZKP tokens staked .
The full details of this proposal are available in .
Please vote to accept or reject the proposed actions detailed above. 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 .
The full details of this proposal are visible in a more human-readable form in .
Parameter
Description
First day stakes are accepted
As soon as all relevant PIPs are passed and executed.
Last day stakes are accepted
119th day since “first day stakes are accepted”, or earlier if “Amount of $ZKP allocated for rewards to all stakers” below has been already depleted, or earlier if Panther’s mainnet beta is launched beforehand.
Amount of $ZKP allocated for rewards to all stakers
6,000,000 $ZKP
Number of days the staked $ZKP remains locked after stake creation
60 days
Reward formula, where: Reward - reward for a stake ($zZKP), Amount - amount staked ($ZKP), APR - Annual Percentage Rate (%), Period - rewarded period (days)
Reward = Amount * APR * Period / 365, where: APR - 15%, Period - 60 days
Number of “stake proof” NFTs issued
1 NFT per stake, but no more than 2000 NFTs in total (i.e. first 2000 stakes rewarded)
Minimum $ZKP amount per stake
1000
Time since when a staker might withdraw rewards from the MASP (but forfeiting the right to accumulate PRPs)
120th day since the “First day stakes are accepted”
Background
This proposal aims to increase Panther’s degree of decentralization by increasing the number of authors with the ability to publish proposals.
Increasing the number of allowlisted addresses increases the community’s presence in the Protocol’s governance.
Description
This proposal involves granting the right to introduce Panther Improvement Proposals (PIPs) in Panther’s Snapshot.org page to six community members and two Panther Product contributors.
If this proposal passes, Panther Protocol’s space on the Snapshot.org cloud service will have eight new allowlisted authors. The permissions for this set of authors are proposed to last for six months, after which we expect the community will propose its own list of nominees and vote on their appointment. This is part of Panther’s decentralized governance process with a focus on community governance.
The new addresses allowlisted will belong to:
Victor, (Discord: Black322#9757), Russian Community Ambassador. Address: 0xDC885850D72c3269aa2d2bCB32C70E2080b3ACF1
Quentin, (Discord: qqorq#0903), Social Content Ambassador. Address: 0xac9Ff68Ff1F377CD62B63Bcc500025F81EFBCab0
Luka, (Discord: Luka de la Team Hermione#0085), French Community Ambassador and Discord Moderator. Address: 0xBaA5A9b673003481972A97eB5593C8D1818843af
Akin, (Discord: Akin#6560), Turkish Community Ambassador and Discord Moderator. Address: 0xFd9b55948Abb2C0e2137eCF951EB03117153130D
Sam, (Discord: 666Sam999#2082), Telegram and Discord Channel Moderator. Address: 0xF66268c5E9075223E32a364E321c74f4c0264BC8
Toxic Entity, (Discord: toxicehc#5599), well-known Community member. Address: 0xE1B583De9cB37196031b771686734a31ec365768
Saif, (Discord: Saifonblock#3283), early Panther Product Contributor. Address: 0x56dd80C22A375a53f3d11223fEe10C40A4b32d6F
Joris, (Discord: Joris#1585), early Panther Contributor. Address: 0xB86DB7690887207209cC1a0F26E80d46f081B0a9
The power to introduce PIPs does not come associated with any other privilege in Panther’s governance mechanism. PIPs can only be published by the addresses above.
This proposal involves granting the right to adjust settings of the Panther Protocol space on Snapshot.org to another admin who represents the community.
The address of the new admin will be 0xeC88b933a75F961Ce55d7EaF6CDD6CEd103A4AD8, belonging to Anton, a well-known Web3 enthusiast and Panther community member. This address will be an Admin for six months, after which the community is expected to nominate and appoint a new Admin.
If this proposal passes, the above stated account will be added to the list of the Panther Protocol space Admins, so that two equally authorized admin accounts will be listed.
The power to update Panther’s Snapshot.org settings does not come associated with any other privilege in Panther’s governance mechanism. Admins must maintain the settings in strict accordance with this and future governance proposals.
Background
Per proposal #3, to participate in voting, users need to have staked $ZKP in Panther's "Classic" staking solution on the Ethereum Mainnet or Polygon.
Currently, only 8.3% of the total $ZKP supply is staked. This means that most users will not be able to vote on this and future governance proposal.
Moreover, in order a proposal to pass at least 4% of the $ZKP token total supply should cast votes, which may prevent obtaining the quorum when no active staking program is running.
Description
To cover the cases when the staking smart contract is not releasing rewards to users (a situation likely to happen in initial phases of the project), alternate voting rules must be proposed and applied.
This proposal intends for the Panther DAO to define an alternate mechanism that considers users’ token balances together with their staked amounts on any supported network (currently the Mainnet and Polygon) as a secondary go-to in these cases. In these cases, the voting power of $ZKP tokens holders will be calculated as "one owned or staked token = one vote".
Whenever the smart contract releases rewards to users, the system will default back to the original mechanism (one staked token = one vote).
If this proposal passes, the admin of the Panther Protocol space on Snapshot.org will update the settings of the space so that the voting power for further votings will be computed according to the rule stated above.
Please vote to accept or reject the proposed actions detailed above.
As per the existing DAO governance structure, to participate in voting, you need to have staked $ZKP in Panther’s “Classic” staking solution](../staking/classic-staking.md) on Ethereum Mainnet or Polygon. 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.
The full details of this proposal are available in raw Markdown format on IPFS.
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”.
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.
It is proposed to use the following new smart contracts on the Polygon PoS chain:
All other contracts remain as documented in previous proposals.
As mentioned in the previous section, due to the time-critical nature of the fix, if any issues are discovered by further auditing during the voting period, it may be necessary to deploy amended versions of the above two contracts, and invoke the fallback mechanisms in order to activate those instead. If so, amendments will be kept to a minimum as much as possible, to preserve the original intention of the above contracts as described below.
StakeRewardAdviser
replacementThe previous StakeRewardAdviser
, which is tightly coupled with the buggy MaticRewardPool
contract, will be replaced by calling the removeRewardAdviser
function of the existing RewardMaster
contract, followed by addRewardAdviser
to configure its replacement.
Removal and addition needs to be done for both the stake
and unstake
actions.
StakeRewardController
For "old" stakes created before the replacement, this contract returns modified advice with "old" amounts of rewards (shares of the reward pool), but with the address of the RewardTreasury
contract as the recipient of rewards. This allows reclamation of the incorrectly vested rewards, which it can then use to distribute in the corrected manner.
To achieve this, StakeRewardController
is preprogrammed with sufficient historical data of all previous staking activity to be able to calculate the corrected distribution of previously accrued rewards.
For "new" stakes created, it returns advice to RewardMaster
with zero rewards (zero "shares"), preventing RewardMaster
from distributing incorrect amounts, and instead assumes responsibility for reward distribution.
vestingPools::addVestingPools([wallet], [poolParams])
will be called on the existing VestingPools
contract on the Ethereum Mainnet, where:
wallet
is the address of the DAO Multisig address on Ethereum (0x505796f5Bc290269D2522cf19135aD7Aa60dfd77).
Final poolParams
will be:
This will result in a poolId
of 14 (since 0--12 were created during TGE, and 13 in the previous proposal).
This new pool is required to serve as a temporary "advance loan" from one part of the Protocol to another, since the prematurely vested rewards from the previous 2M pool can only be recovered as the final part of execution of an unstake
operation, after the corrected rewards are distributed by StakeRewardController
to the account performing the unstaking.
Bridging of these 2M tokens will be performed in a similar manner to DAO proposal #3, except that the final recipient will be the RewardTreasury
contract instead of the buggy MaticRewardPool
.
StakeRewardController
When other contracts are configured correctly as described above, StakeRewardController
will be activated, allowing further staking and unstaking with the fully corrected reward calculations.
Contract | Address |
---|---|
RewardTreasury
0x20AD9300BdE78a24798b1Ee2e14858E5581585Bc
StakeRewardController
0xdCd54b9355F60A7B596D1B7A9Ac10E6477d6f1bb
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:
were initiated as a Snapshot proposal in the PantherProtocol.eth space
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”.
Enable staking contracts on Polygon PoS chain to essentially mirror the behavior of the existing Ethereum mainnet staking rewards program, 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). 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.
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.
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.
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
vestingPools::addVestingPools([wallet], [poolParams])
will be called on the existing VestingPools
contract on the Ethereum Mainnet, where:
wallet
is the address of the DAO Multisig address on Ethereum (0x505796f5Bc290269D2522cf19135aD7Aa60dfd77).
Final poolParams
will be:
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.
This proposal involves extending Panther's existing DAO governance / voting structure and the ongoing Traditional staking program to Polygon.
It follows on from Proposal #2, 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.
Please vote to accept or reject the proposed conditions detailed below. To participate in voting, you need to have staked $ZKP in Panther's "Traditional" staking solution. 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.
(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.)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 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.
This proposal was accepted with 98.74% of the vote in March 7th, 2022.
This document proposes the initial steps of extending the Panther Protocol, DAO, and ecosystem to the Polygon PoS network:
Launch a ZKP token contract at 0x9A06Db14D639796B25A6ceC6A1bf614fd98815EC
on the Polygon PoS mainnet, to operate in parallel alongside the existing ZKP token contract at 0x909e34d3f6124c324ac83dcca84b74398a6fa173
on the Ethereum mainnet.
Request the Polygon team to set up a mapping between these two contracts, so that anyone will be able to use the existing Polygon PoS bridge to move tokens between the two networks in either direction, subject to execution of item 4 below.
Approve the Panther DAO multisig contract (Gnosis Safe) at 0x208Fb9169BBec5915722e0AfF8B0eeEdaBf8a6f0
on the Polygon PoS mainnet, configured in a manner which effectively extends the DAO’s control from the Ethereum mainnet to Polygon (see below for technical details).
Execute a transaction on the Ethereum mainnet via Reality.eth. It will use the Polygon Arbitrary Message Bridge to send a transaction from the Ethereum Mainnet to Polygon PoS to transfer control of the minter role within the new Polygon ZKP token contract to the Polygon bridge.
This proposal was accepted with 99.92% of the vote on March 4th, 2022.
The proposal on the previous page is based on the intention that a follow-on DAO proposal should be made very soon after this proposal is approved and executed, most likely within a matter of days, to finalize the implementation of this Polygon package.
The purpose of this follow-on proposal will be to extend DAO governance and staking (including rewards) to Polygon, so that the utility of $ZKP on Polygon is much the same as it currently is on Ethereum mainnet:
Holders of $ZKP on Polygon will be able to stake on Polygon as part of the existing “traditional” staking program.
Holders of $ZKP who have staked on Polygon will have the ability to participate in Panther Governance proposals, with the same voting powers as those who have staked on the Ethereum mainnet.
Add configuration to the existing Ethereum mainnet staking contracts to allow an alternative option of staking without rewards. This will allow the Panther Foundation to stake without taking rewards from the existing “traditional” staking program.
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.
To clarify, this only applies to the Reality.eth transactions directly associated with this DAO proposal, which are listed at . It does not promise any compensation for normal staking / unstaking transactions, or other interactions with the smart contracts.
The new DAO multisig Gnosis Safe contract on Polygon PoS will have the following properties:
It will be configured with an implementation of the Zodiac Reality Module, enhanced for compatibility with Polygon. This will allow it to receive and execute transactions which come from DAO proposals executed on the Ethereum mainnet and are passed over the Polygon AMB (Arbitrary Message Bridge).
It will be configured with the same DAO multisig signers as the existing DAO multisig on the Ethereum mainnet.
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):
"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!",
"category": "DAO proposal"
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”.
Reimbursement shall be sourced out of the total 450M $ZKP allocated for Protocol 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
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. It does not promise any compensation for normal staking / unstaking transactions, or other interactions with the smart contracts.
This proposal aims to increase Panther’s degree of decentralization by updating the current authors and administrators with the ability to publish proposals in Panther Protocol’s space on the Snapshot.org cloud service and update settings of the space (further referred to as Snapshot Authors and Snapshot Admins) as was voted in last year, through PIP-8.
Updating the current allowlisted addresses of Snapshot Authors and Admins increases the community’s presence in the Protocol’s governance as well as increasing the representation of active Panther community members in Panther Protocol’s space.
If this proposal passes, Panther Protocol’s space will have 3 new allowlisted Snapshot Authors and one new Snapshot Admin.
This proposal involves removing the right to introduce Panther Improvement Proposals (PIPs) in Panther's Snapshot.org space from the following Snapshot Authors:
Luka, (Discord: Luka de la Team Hermione#0085), French Community Ambassador and Discord Moderator. Address: 0xBaA5A9b673003481972A97eB5593C8D1818843af
Saif, (Discord: Saifonblock#3283), early Panther Product Contributor. Address: 0x56dd80C22A375a53f3d11223fEe10C40A4b32d6F
Joris, (Discord: Joris#1585), early Panther Contributor. Address: 0xB86DB7690887207209cC1a0F26E80d46f081B0a9
Quentin, (Discord: qqorq#0903), Social Content Ambassador. Address: 0xac9Ff68Ff1F377CD62B63Bcc500025F81EFBCab0
Akin, (Discord: Akin#6560), Turkish Community Ambassador and Discord Moderator. Address: 0xFd9b55948Abb2C0e2137eCF951EB03117153130D
Sam, (Discord: 666Sam999#2082), Telegram and Discord Channel Moderator. Address: 0xF66268c5E9075223E32a364E321c74f4c0264BC8
This proposal involves adding the right to introduce Panther Improvement Proposals (PIPs) in Panther's Snapshot.org space to the following Panther Community members:
Mibrody (Discord: MIBrody#2617), well-known Community member. Address: 0x9E2A8e8Be6a0049D14C10be4a1854a06A72e25d0
Marcus, (Discord: marcusrc#0226), well-known Community member. Address: 0xdfc8cE21F67FBC4115DAddCdC740948BD8fAe317
Markus, (Discord: Markus_KK#6674), well-known Community member. Address: 0xF68813feF24Ae1CE7000f0f1771Cd3042d5702be
This proposal involves removing the right to update settings of the Panther's Snapshot.org space, via the the Admin multisig wallet, from the following Snapshot Admin:
Vadim, (Discord: vkonst#6108), early Panther Product Contributor. Address: 0x8aE64A31E7574f4beeE193Ce98Ea2827Bc0665E8
This proposal involves involves adding the right to update settings of the Panther's Snapshot.org space, via the the Admin multisig wallet, to the following new Snapshot Admin:
Frank, (Discord: cryptoefelle#1117), well-known Community member. Address: 0xdfE35156b65e90D3Fbf7E0D438fAb7b564668848
This will update the current Snapshot Authors to:
Victor, (Discord: Black322#9757), Russian Community Ambassador. Address: 0xDC885850D72c3269aa2d2bCB32C70E2080b3ACF1
Toxic Entity, (Discord: toxicehc#5599), well-known Community member. Address: 0xE1B583De9cB37196031b771686734a31ec365768
Mibrody (Discord: MIBrody#2617), well-known Community member. Address: 0x9E2A8e8Be6a0049D14C10be4a1854a06A72e25d0
Marcus, (Discord: marcusrc#0226), well-known Community member. Address: 0xdfc8cE21F67FBC4115DAddCdC740948BD8fAe317
Markus, (Discord: Markus_KK#6674 ), well-known Community member. Address: 0xF68813feF24Ae1CE7000f0f1771Cd3042d5702be
Furthermore, this proposal will update the current Snapshot Admins to:
Frank, (Discord: cryptoefelle#1117), well-known Community member. Address: 0xdfE35156b65e90D3Fbf7E0D438fAb7b564668848
Anton, (Discord: antonie#1798), well-known Web3 enthusiast and Panther community member. Address: 0xeC88b933a75F961Ce55d7EaF6CDD6CEd103A4AD8
Dan, (Discord: DanP#0547), well known Community member. Address: 0x3f6Dd0C54c0F86F85c5bB6Cc5a82538f702bF103
The permissions for this set of Snapshot Authors and Snapshot Admins are proposed to last for six months, after which the community will revise the list of nominees and vote on their appointment.
Neither Snapshot Admins nor Snapshot Authors hold any privilege in Panther’s governance mechanism.
Snapshot Admins must maintain the settings of the Panther's Snapshot.org space in strict accordance with this and future governance proposals.
The following actions are proposed:
Update the list of Snapshot Authors as described in the Sections #1 and #2.
Update the list of Snapshot Admins as described in the Sections #3 and #4.
The full details of this proposal are visible also in raw Markdown format on IPFS.
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
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
The following Subgraph instances will be used to feed data to the front end dApp:
at https://thegraph.com/hosted-service/subgraph/toxicehc/panther with the ID QmTi7Z7YoUpzYqwGytPuKYu2FuYPEhtPTsXti5dRxn8wHR
at https://thegraph.com/hosted-service/subgraph/cryptoefelle/panther with the ID QmZPs5CFi5vpZW73DmwF5VMzt5CYvFX7vD9Ez9gkZteuRd
(Some more instances may be added to this list.)
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.
Register $ZKP as an allowed:
Register PNFT as an allowed:
Set existing contracts on Polygon to work with newly deployed contracts:
Allow zAsset redemption since 2023-04-07T18:00:00.000Z:
Allow AdvancedStakeRewardController to mint PNFT tokens:
Set advance staking rewarding parameters - 15% APR to be effective since 2022-12-08T18:00:00.000Z for 180 days:
Accept advanced stakes on Polygon since 2022-12-08T18:00:00.000Z for 119 days:
Reserve 2000 PNFT tokens for first 2000 stakes:
Mint 6,000,000 $ZKP as rewards for advanced stakes and send tokens to AdvancedStakeRewardController on Polygon via PoS bridge:
Set existing contracts on mainnet to work with newly deployed contracts:
Accept advanced stakes on mainnet since 2022-12-08T18:00:00.000Z for 119 days:
Allow AdvancedStakeRewardController to send all $ZKPs from its balance as rewards:
Mint 14,000 $ZKP as rewards for deployment and send 10,000 out of this amount to deployers:
This proposal introduces two key initiatives:
Extending the “Advanced Staking” program till August 22, 2023. The parameters of the program can be found in the “Terms for smart contracts” section.
Activating updates to the frontend (UI) of Panther Protocol (version 0.5.1). A list of updates can be found in the v0.5.3 release description.
As discussed on Panther’s Discourse forum, the community recommends running a new cycle of the “Advanced Staking” program (AS2), with parameters stated below in the “Terms for smart contracts” section.This proposal authorizes and triggers the execution (via Panther's space on Snapshot.org and the Reality.eth oracle) of the attached blockchain transactions listed below under Annex, deploying and configuring Panther's smart contracts to launch AS2.
The community recommends using the v0.5.3 frontend instead of v0.5.1 (the previous one).In order to have a user-friendly URL pointing to v0.5.3’s frontend, and to safeguard access to the correct link/app, the community makes a recommendation to configure the pantherprotocol.eth ENS domain namespace in such a way that the user-friendly link https://ipfs.io/ipns/pantherprotocol.eth will point to the v0.5.3 frontend.
It is proposed to follow the below parameters for extending the “Advanced Staking” program:
Other parameters remain the same as defined by PIP-9.
Approve all parameters included in the sections “Terms for smart contracts” and “Community Deployment Rewards”.
Authorize and execute on the Ethereum Mainnet and Polygon network the deployment and configuration transactions described in the Annex, to achieve the terms for the AS2 program to be those outlined in the section “Terms for smart contracts”,
Transfer the reward of 2,000 $ZKP for the frontend v0.5.1 deployment, as per PIP-11’s, Proposed actions, Point 1, to the user with the Ethereum address 0xE1B583De9cB37196031b771686734a31ec365768.
Allocate 100,000 $ZKP out of the total 450M $ZKP allocated for Protocol rewards, to be used for Community Deployment Rewards under the present and future proposals.
Request the Panther Foundation to configure the pantherprotocol.eth namespace so that the URL https://ipfs.io/ipns/pantherprotocol.eth will point to the v0.5.3’s frontend deployed on IPFS.
Deploy the `AdvancedStakeV2ActionMsgTranslator` smart contract on the Polygon network by invoking the `DeterministicDeploymentProxy` on the Polygon Network.The transaction will initiate a call to `FxRoot` on the Ethereum mainnet, which will bridge the contract bytecode to the Polygon network through the `MaticBridgeModule`.
Deploy the `AdvancedStakeV2ActionMsgTranslator` smart contract on the Ethereum mainnet using the `DeterministicDeploymentProxy`.
Configure the `Staking` and `AdvancedStakeRewardAdviserAndMsgSender` smart contracts on the Ethereum mainnet to work with the newly deployed `AdvancedStakeV2ActionMsgTranslator`.
Re-enable Advanced Stakes on the Ethereum mainnet from Thursday, April 6, 2023, at 6:00:00 PM UTC until Tuesday, August 22, 2023, at 12:00:00 PM UTC, with a lock period of 60 days.
Configure the `Staking` and `AdvancedStakeRewardAdviserAndMsgSender` contracts on the Polygon network to interact with the newly deployed `AdvancedStakeV2ActionMsgTranslator`.Calls to `FxRoot` on the Ethereum network will trigger the corresponding calls on the Polygon network.This is done through the bridging mechanism provided by the `MaticBridgeModule`.Once the transactions are executed on the Ethereum network, they will be relayed to the Polygon network, where they will be decoded and executed.
Re-enable advanced stakes on Polygon starting from Thursday, April 6, 2023 at 6:00:00 PM UTC until Tuesday, August 22, 2023 at 12:00:00 PM UTC, with a lock period of 60 days.The transaction will call `FxRoot` on the Ethereum mainnet to bridge the configuration data to the Polygon network through `MaticBridgeModule`.
Update the advanced staking reward parameters by changing the end time to Tuesday, August 22, 2023 at 4:00:00 PM GMT.The transaction will invoke the call to `FxRoot` on the mainnet to facilitate the transfer of the configuration call across the Polygon bridge.
Transfer ZKP reward to the community member for executing the PIP-11.
Add and configure a 100,000 $ZKP Vesting Pool designated for Community Deployment rewards.
Please vote to accept or reject the proposed actions detailed above.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.
Further description of blockchain transactions and configuration details maybe found in the technical details section of PIP-13 in the Panther DAO GitBook.
The full details of this proposal are also visible in raw Markdown format on IPFS.
This proposal covers a set of processes and methods as a next step forward in Panther’s road towards decentralization. Furthermore, this proposal covers the introduction of the Panther Protocol DAO Council. The purpose of this proposal is to improve the DAO’s Governance Framework and make it more suitable for high level, decentralized, decision making as discussed by the community on Panther’s discussion forum [1] [2].
Finally this proposal executes the Community Deployment Rewards as stated on PIP-13.
This proposal serves the purpose of making the Panther Protocol more decentralized. This will be achieved by:
Installing a DAO Council who will review Panther Improvement Proposals (PIPs) and decide if they will be pushed to Snapshot by verifying if the proposal draft is aligned with the mission, vision and values of the Panther DAO. The purpose of the DAO Council is to prevent requests that are out of budget, and those that do not meet the scope and roadmap of Panther as well as spam request proposals moving to Snapshot.
Turning an implicit Governance Framework into a transparent set of guidelines and rules, voted in by the Panther DAO.
The identities of the DAO Council nominees are available in the proposal’s description section.
During the last few months, the Panther community has discussed the Panther Protocol Governance Framework in order to define workflows and realize a diagrammatic representation of Panther’s Governance process. Because of these efforts, a set of rules and guidelines are now defined and proposed as can be seen on the Panther Governance Framework flow diagram.
If this proposal passes, the Panther Protocol DAO will have three council members who will be responsible for carrying out the review process within the Governance Framework for PIP submissions and labelling them based on the results of the review process as described in the DAO Governance Process. A majority vote made by the Council Members will decide if a proposal draft is being approved for voting or being rejected because it breaches the DAO Governance Rules and Values.
The following DAO Governance Rules and Values are proposed:
Panther's mission is to provide privacy to an innately transparent system. Enabling confidential, trusted transactions and interoperability in Decentralized Finance (DeFi).
Panther's purpose is to build and accelerate the development of private scalable blockchain infrastructure for Web3.
Panther's vision of the world where people have access to Web3 products and services while preserving their privacy and protecting them from surveillance and maintaining composability with DeFi protocols.
Panther does not sacrifice security for innovation.
Panther stands for process and decision transparency, where every one of them is openly shared with the community.
The following three community members are proposed as DAO Council members:
Santiago Velez: Co-Founder & Division Lead (R&D) at Block Digital Corporation, VP of R&D at Sindric Solutions, LLC Former Nuclear Engineer, VP of UWUA L590 Engineers Union and Panther Protocol user.
Jillian Godsil: Journalist, Broadcaster, Influencer, CEO, Writer, Former European Parliament Candidate, Law Changer, Panther Protocol user & early contributor.
Debra Farber: Host of The Shifting Privacy Left Podcast, CEO, Principled LLC, and Advisor to the PrivacyTech Rise, Privado, the Institute of Operational Privacy Design, and XRSI.
The DAO Council will be installed for a period of 6 months, after which the community is to nominate a new list of council members. DAO Council members can be re-elected by the community. Furthermore it is proposed that the Panther DAO Council will have an operations contributor who will support the DAO Council review process and streamline the communication process between the Council and the proposal draft initiators.
This proposal does not impact or change the DAO Veto Council as mentioned on the LaunchDAO proposal. The signers of the DAO Multisig as defined on point 8 of the launchDAO proposal remain valid and are not affected or influenced by this proposal and could be put up to vote through another, separate proposal.
The following actions are proposed:
1. Approve the DAO Governance Process as stated in the Background section of this proposal.
2. Approve the DAO Governance Rules and Values as stated in the Description section of this proposal.
3. Approve Debra Farber, Jillian Godsil, and Santiago Velez to be the members of the Panther DAO Council in accordance with the Governance Flow Diagram as shared in the description section of this proposal.
4. Send the deployment rewards according to the points 1, 2 and 3 of the ‘’Community Deployment Rewards’’ section of PIP-13, namely:
The distribution of 2000 $ZKP towards the following address for deploying the updated frontend (v0.5.3) onto IPFS:0xE1B583De9cB37196031b771686734a31ec365768
The distribution of 6000 $ZKP to the following address who executed the blockchain transactions to deploy and configure the smart contracts on the Ethereum Mainnet and Polygon network:0xE1B583De9cB37196031b771686734a31ec365768
The distribution of $155.19 USD in $ZKP tokens @ ZKP=0.02460 USD) as a gas fee compensation for the community member who executed point 4.2.
The $ZKP/USD rate as mentioned at point 3 will be updated on the day that this proposal will be published on Snapshot. The Huobi ZKP/USDT pair shall be used to define the amount of ZKP equivalent to the gas fee compensation. By doing so, it is proposed to implement a coefficient of 1.2 (186.23 USD) in order to compensate for possible overheads and volatility.
Please vote to accept or reject the proposed actions detailed above.
Voting power is calculated by Snapshot.org taking a Snapshot of the number of $ZKP tokens staked per holder at the block within which the proposal was created.
Further description of blockchain transactions and configuration details maybe found in the technical details section of PIP-14 in the Panther DAO GitBook.
The full details of this proposal are visible also in raw Markdown format on IPFS.
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.
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.
The Panther team proposes a solution rescuing existing rewards, and "upgrading" the existing contracts to correct the bug, with the following actions:
Create a fresh vesting pool of 2M ZKP tokens on the Ethereum Mainnet, minted from the total 450M $ZKP allocated for Protocol rewards.
Bridge the newly minted 2M $ZKP to a new RewardTreasury
contract on Polygon.
Configure RewardTreasury
to allow its tokens to be spent by a new StakeRewardController
contract.
Reinstate display of (corrected) reward figures in the staking app UI.
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:
If necessary, add a temporary guard to the DAO multisig which would prevent execution of some or all of the steps above.
"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.
Parameter | Description |
---|---|
This proposal describes a bug fix to the new staking program on Polygon, to ensure fair distribution of rewards in accordance with , which was .
The recent deployment of Panther’s staking program on the Polygon network was quickly followed by discovery of an unfortunate bug where the 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 , 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.
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 .
Disable the existing StakeRewardAdviser
contract for the unstake
action, to prepare for a corrective contract and to ensure that are not violated.
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 . 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.
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 , which states:
Last day stakes are accepted
August 22, 2023 12:00:00 PM UTC. This can be earlier should “Amount of $ZKP allocated for rewards to all stakers” (see PIP-9) get depleted or Panther’s mainnet beta be launched beforehand.
Time for a staker to withdraw rewards from the MASP (but forfeiting the right to accumulate PRPs)
Immediately after the stake is created
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.
It is proposed to use the following new smart contract on the Ethereum Mainnet:
All other contracts remain as documented in previous proposals.
StakeRewardAdviser
replacementThis replacement only needs to be done for the unstake
action, not for stake
, since the classic staking program already closed for new stakes.
StakeRewardController2
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.
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:
were initiated as a Snapshot proposal in the [PantherProtocol.eth space](https://snapshot.org/#/pantherprotocol.eth](https://snapshot.org/#/pantherprotocol.eth).
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”.
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.
To clarify, this only applies to the Reality.eth transactions directly associated with this DAO proposal, which are listed at . It does not promise any compensation for normal staking / unstaking transactions, or other interactions with the smart contracts.
Contract | Address |
---|
The previous , which is tightly coupled with the buggy contract, will be replaced by calling the removeRewardAdviser
function of the existing contract, followed by addRewardAdviser
to configure its replacement.
This contract returns modified advice with zero shares of the reward pool, effectively bypassing the need for to attempt to invoke the buggy contract to redeem shares.
vestingPools::addVestingPools([wallet], [poolParams])
will be called on the existing contract on the Ethereum Mainnet, where:
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 (), having cast votes to approve execution of the transactions;
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 |