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...
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...
Panther’s decentralized, disruptive approach to data privacy and compliance offers a significant leap forward for several industries. While Panther will primarily deal with token transactions at its mainnet release, the core underlying components of the system offer the ability to extend into many other fields where privacy, auditability, and tracking are critical to providing value.
At mainnet release, some of the use cases for Panther include:
Zero-Knowledge (ZK) accounts: Panther users can deposit multiple types of tokens into Panther's Shielded Pools, where they can hold their assets confidentially while retaining the ability to showcase their balance to anyone. Combining ZK proofs with an approach based on ZK disclosures and decentralizing access to compliance, Panther is pioneering privacy-preserving access to DeFi while enabling new compliance mechanisms. Its vision puts users in control of who views their data while creating a path to comply with regulations.
Privacy-preserving transactions: Within Shielded Pools, users can transact with each other, conduct trades, and swap assets, while also remaining able to showcase their transaction history at will. This can enable them to create a new crypto economy based on data privacy and compliance.
Private staking, vesting, and token distributions: Using Panther's solutions, teams can build products and issue tokens to their users while preserving their privacy.
Secure, privacy-preserving DeFi access: Users can privately interact with the most popular DeFi dApps and protocols (such as NFT marketplaces, lending/borrowing markets, or DEXs) directly from Panther by using DeFi Adaptors. This allows them to safeguard their data while still relying on the security and liquidity of the underlying networks on which the most popular protocols are deployed.
Earning rewards for enabling privacy in DeFi: By using Panther, every user provides others with privacy, which makes them eligible to receive rewards in Panther's native token, $ZKP.
A zero-knowledge cross-protocol layer unlocking compliant DeFi.
Panther is a cross-protocol layer that uses zero-knowledge technology to build DeFi solutions that meet regulatory requirements and satisfy users' on-chain data privacy needs. The goal of Panther is to allow seamless access to DeFi and create a cross-chain-supported architecture that serves different use cases.
Panther’s zero-knowledge primitives are also generalizable to KYC, selective disclosures between trusted parties, private ID, voting, and data verification services.
According to our Roadmap, the mainnet trading dApp will be released in Q3 2023.
Users access Panther by depositing assets into Shielded Pools). Deposited assets are secured in a Vault smart contract, which means they gain access to the equivalent zAssets (1:1 collateralized "shielded" versions of their tokens to be utilized within the Panther dApp). zAssets open different possibilities for users, who can send, swap, receive, and pay with them.
Internal OTC trades utilize an atomic swap mechanism called zTrade. Shielded Pools can exist in different chains (EVM-compatible in the first version), interconnected by zBridges. Panther users can also interact directly with external DeFi and NFT platforms using DeFi Adaptors.
The following diagram illustrates the flow of assets between Panther and transparent, public blockchain networks:
Since Zero-Knowledge proofs enable Panther's privacy features, users can disclose their transaction history to anyone at will. Additionally, an MPC-based Data Safe mechanism stores basic details about transactions. These can only be revealed by the Panther DAO or another holder of the keys (including the user). This means that the user can access this data, for example, upon request by regulators.
Panther features ZK- and non-ZK Reveals. By interacting with a Trust Provider, users can access zero-knowledge attestations of truth for any statement, such as their identity, total balance, transaction history, etc. Panther Reveals are flexible and can be leveraged by any protocol requiring trust attestations, enabling trust schemes in DeFi.
Panther is empowered by its native token. $ZKP can be used to pay for services at a Protocol level, such as Relayer fees, KYC/KYT fees, or simple gas fees for meta transactions with relayers. $ZKP is also the governance token to participate in the Panther DAO. The Panther DAO is a fully decentralized organization that governs the development of the Panther Protocol.
Testing the dApp
Earn $ZKP in-app by creating a Panther account
Text instructions and video How-tos available
The testnet dApp is open to community testers. To help test, use the entrypoint link above.
We advise reading the latest stage's announcement before testing, as they contain critical information to support your efforts.
Thank you so much for being part of the self-custody data revolution!
TL;didn't watch
Connect your MetaMask wallet.
Change the network to Sepolia testnet.
Click on Complete onboarding and complete your dummy KYC.
You will need some test ETH
Note that faucets require the wallet to hold ETH dust to release test ETH. Alternatively, you can mine test ETH from an empty wallet.
Activate your Panther account.
Go to the zAssets tab, and deposit some test tokens.
Go to Withdraw and withdraw some test tokens.
Send test tokens to other Panther zAddresses (make a 2nd account for transfers if needed; this is allowed in the testing phase).
The table below lists each testnet stage, along with a link to its documentation page, the accompanying blog announcement, the function tested, and any additional notes.
The intention is for the testnet dApp Stages 0-5 deployed on Polygon's testnet, Mumbai and Stage 5 onward on Sepolia testnet. The mainnet beta dApp will be launched on Polygon mainnet. Mainnet Polygon testing will take place starting from Stage 7. At this Stage, a canary deployment will be used to test the Protocol in an environment as close to full production as possible.
Panther will provide users with test cases to execute on the test dApp. These are specific to each testing stage and will be communicated via our official channels before the launch of each stage.
Learn more about the various tetnet stages in the changelog.
Entrypoint | Current version | Status |
---|---|---|
Stage | Status | Article | Function Tested | Notes |
---|---|---|---|---|
🚧 Migration to Sepolia testnet
Stage 0
Released
Updates as per blog post Change details
Stage 1
Released
User Onboarding
Stage 2
Released
Panther Rewards
Stage 3
Released
Deposit & Basic disclosures
Stage 4
Released
Shielded Pool deposit, transfer, and withdrawal
Stage 5
Released
Bundler/Relayer integrations and gasless transactions
Migrating to Sepolia Change details
Stage 6
In development
Fee management, basic disclosures, zAccount renewal
Although anyone can use Panther, it was specifically designed with the following types of users in mind:
These users are particularly wary of surveillance, corporate data mining, and other forms of digital control. They also believe that new technology can enable new forms of decentralized communication, commerce, and social organization that are resilient and resistant to censorship and control.
Privacy enthusiasts who are interested in maintaining their privacy and security in the digital age can benefit from Panther Protocol in several ways:
On-chain data privacy: Panther enables its users to access DeFi (decentralized finance) privately and securely. Its Zero-Knowledge (ZK) primitives ensure that user transactions remain private and untraceable.
Compliance: Panther aims to create a path for users to access DeFi compliantly, meeting regulatory requirements.
Trust attestations: Panther's ZK attestations of truth enable users to prove their identity and other attributes without compromising their privacy. This can be useful for users interested in preserving their privacy while verifying other information.
Decentralization: Panther is powered by a fully decentralized organization, the Panther DAO, which governs the development of the Protocol. This ensures that users have a say in the direction of the Protocol and that it remains true to its cypherpunk roots.
Native token: Panther Protocol's native token $ZKP can be used to pay for services, govern the Panther DAO, and be staked to improve the Protocol's privacy set. This gives users a stake in the Protocol's success and ensures they have a say in its development.
Panther can benefit users interested in pursuing high yields across the DeFi ecosystem in several ways:
Data protection: Panther allows users to access DeFi privately and securely, which can be particularly important when pursuing high yields. By maintaining their privacy, users can avoid attracting the attention of bad actors who may try to exploit their high-yield positions.
Cross-chain functionalities: Panther is a cross-chain application, meaning users can deploy their assets across DeFi dApps/Protocols on different chains. This enables users to access a broader range of DeFi opportunities, increasing their chances of finding high-yield opportunities.
Zero-Knowledge attestations: Panther's ZK attestations of truth enable users to prove their identity or other attributes without compromising their privacy. This can be useful when participating in opportunities requiring identity verification or for taxation/declaring purposes.
Overall, Panther's on-chain data privacy, cross-chain functionality, access to ZK attestations, governance, and use of $ZKP tokens can all benefit users interested in pursuing high yields across the DeFi ecosystem.
Crypto users managing large sums of assets prioritize preserving their privacy for security. These users can benefit from secure and shielded transactions, encrypted data storage, and privacy-preserving identity management. Panther can provide: Zero-knowledge transactions: By performing them, a user can preserve their confidentiality and prevent others from accessing sensitive information about their dealings or identity.
Secure asset storage: Panther’s Shielded Pools allow users to deposit and manage their assets securely and privately. This can help protect their assets from theft or unauthorized access and keep them confidential.
Privacy-preserving identity management: Panther can allow users to create private and secure identities that can be used for different services within the Panther ecosystem. This helps protect the user's personal information and identity from unauthorized access or misuse.
Trust attestations: Panther Protocol's ZK- and non-ZK Reveals enable users to access ZK attestations of truth for any statement, such as age, identity, total balance, etc. This can be particularly useful for users who need proof of their assets or identity while maintaining their privacy.
Web3 builders and developers can take advantage of Panther's privacy-focused infrastructure and tooling to build DeFi applications that provide greater privacy and confidentiality to users. Since Panther's infrastructure is open-source, anyone can adapt and build upon existing tools to create their own infrastructure that benefits from Panther.
Developers can also leverage Panther’s ZK primitives and trust attestations to build privacy-preserving identity management solutions, voting systems, and data verification services. These solutions can be particularly useful in industries such as healthcare, finance, and government, where data privacy and confidentiality are of utmost importance.
Overall, Panther aims to provide the Web3 environment with a powerful set of privacy tools and infrastructure that can be leveraged to build the next generation of privacy-preserving DeFi applications. Builders and developers using Panther’s primitives can differentiate their applications from the competition and provide greater user value.
Combined with other Panther components, Zones create a tech stack that institutions can leverage in many ways. Some of the use cases that institutions can benefit from are:
Permissioned environments: Institutions can become Zone Managers and allowlist users (either from the general public or their own) for maximum security and control. This allows institutional traders to trade without interacting with Panther's larger user set while benefitting from the system's capabilities.
OTC Desks: Panther's zTrade functionality can work as an OTC desk for institutions, creating a similar for ZK transactions within on-chain dark pools.
On-chain compliance support: Zone Managers can set rules within their Zone and integrate third-party compliance tools, such as KYB support to onboard crypto asset managers.
The section on institutional users will be expanded as we advance on its development.
Working with cryptoassets in Panther Protocol
Panther Protocol will allow users that comply with their Zone Manager's compliance requirements to open a zAccount to non-interactively:
stake, and
with zAssets in the Shielded Pool.
Shielded Pool
The Shielded Pool supports the non-interactive trades of zAssets: shielding external wallet addresses
Panther Shielded Pools may be deployed to different L1 or L2 chains
Access to a Shielded Pool is granted via a zAccount created via the dApp within a dedicated Zone
Panther Protocol's Shielded Pools underpin the Protocol's vision for compliant, privacy-enhanced trading. Shielded Pools are partitioned into Zones: logical partitions of liquidity with their own entry requirements.
A Shielded Pool supports multiple asset types, i.e. is a Multi Asset Shielded Pool (MASP). Each Pool supports the non-interactive transfer of zAssets within Zones. This non-interactive architecture is fundamental to enabling two parties to transact without knowing or revealing each other's EOA (externally owned account) addresses, i.e. their wallet addresses. This renders the transactions within these pools untraceable while providing users with the flexibility to disclose information selectively, thus enabling a pathway to compliance.
Users within Zones can:
Register and activate Panther zAccounts and zero-knowledge compliance checks
Deposit and withdraw assets
Transact and send funds to other zAccount holders within the Pool
Receive rewards and pay fees
Interact with DeFi dApps and protocols
Conduct OTC-like atomic swap trades
Access cross-chain functionalities
Earn Panther $ZKP rewards
Panther Zones are dedicated areas within Shielded Pools that enable users to trade with allowlisted assets and known counterparties. Every Zone is managed and configured by a licensed entity known as a Zone Manager, and users must undergo verification with a KYC provider.
Each Zone in a Shielded Pool supports compliance in a fully agnostic manner, i.e. compliance is defined by the VASP-licensed Zone Manager.
The following diagram highlights how a Shielded Pool allows an end user, the zAccount holder of Zone A in this instance, to transact in this privacy-enhanced Protocol.
Notice that the same Pool can support multiple Zones, here as Zone A and Zone B. This allows Zones A and Zone B to have different daily limits, different supported assets, and different requirements for entry, such as different supported geographical regions for end user residence.
Furthermore, while the KYC compliance provider submitting the attestation that the EOA, e.g. MetaMask wallet, is associated with an individual that has successfully complied with the Zone Manager's ruleset is the same for Zones A and B in this simplified representation, in fact, Zone Managers may undertake their own KYC or select alternative third-party KYC providers. The Protocol itself simply requires the attestation, it does not have insight into who is making that KYC attestation.
While the mainnet beta release of Panther Protocol is deployed to Polygon, the Protocol itself supports a multi-chain strategy.
Deploying Shielded Pools onto multiple blockchains is a key milestone for Panther is to deploy — further strengthening the ecosystem and diversifying access to DeFi. This vision, which puts users in control of who views their data while retaining compliance, constitutes a first-of-its-kind approach that leverages existing liquidity, increases connectivity, and is attractive to institutions and retail users alike.
A Shielded Pool is a set of smart contracts where users can deposit various tokens, safeguarded by cutting-edge cryptographic techniques such as SNARKs and zero-knowledge proofs (ZKPs).
On-chain state changes are achieved when Panther's Shielded Pools update a collection of append-only Merkle trees, where each leaf is a commitment to a UTXO representing zAssets — essentially an IOU for the corresponding collateral deposited by a user and locked in the Panther Vault, or zAccounts.
Learn more about non-interactive asset transfer
Find out more about which asset classes are supported
Follow external links from the glossary to learn more
zTrade (OTC Trading)
Panther will support privacy-enhanced Over-The-Counter trades
Within zTrade, users can conduct OTC transactions while enjoying unprecedented data privacy. The process begins when a maker deposits digital assets into a Shielded Pooland converts them into zAssets, effectively safeguarding their holdings. Once users initiate a trade, they set the conversion rate at which they are willing to sell their assets. Takers, conversely, can browse the available offers and accept the one that suits their needs, confident that their privacy is being fully maintained.
Unlike traditional OTC marketplaces, zTrade will not require any custodian services, thanks to the self-custody and automated nature of on-chain DeFi transactions. Furthermore, zTrade preserves the confidentiality of users' identities, transaction details, and asset holdings.
Some of the advantages of zTrade over centralized or decentralized swap mechanisms include:
Low fees
Instant settlements with data protection
Possibly, earning rewards
to be determined by the DAO
Zero-Knowledge Assets
zAssets represent digital assets as UTXOs
ZK proof of UTXO activity are written on-chain
This mechanism enables privacy-enhanced trading
When a user deposits a digital asset into the Panther Vault via their Panther account, a UTXO (Unspent Transaction Output) is generated to represent that asset — the zAsset.
This means that the zAsset data that represents the original digital asset on-chain is both condensed and encrypted. Asset balances and balance changes are not publicly available should a Panther account address become known to an observer.
Users can withdraw their zAssets back into their original form whenever needed. When they do so, the UTXO that represented the underlying asset is "spent".
zAssets are fully collateralized by the underlying tokens that users deposit through UTXO ownership. The ownership of those zAssets can be transferred through in-pool UTXO transactions, which represent the ability to convert zAssets back into native assets on the Pool’s underlying blockchain network.
The observable data that results from a trade is that a UTXO was committed to the smart contract. Only the owner of the UTXO can decrypt the ZK-proof and ascertain the value and token that the UTXO represents.
Panther's Shielded Pools support the following asset classes:
ERC-20 (including some variants like ERC-404)
ERC-721
ERC-1155
This allows different Zones to support different asset sets, which will enable Zone Managers to determine what assets they support according to risk profiles, state laws, and other considerations.
Stablecoins
USDC
USDT
DAI
Other tokens
wETH
wBTC
MATIC
CRV
LINK
These tokens represent the largest DEX flow on Polygon and, as such, can aid Panther’s goal of bootstrapping its privacy through user activity. Further integrations can then be leveraged as activations on their own and help the Protocol’s organic growth by engaging the communities associated with them.
Users can then use these attestations to issue an unforgeable mathematical proof, verifiable on- and off-chain, which Service Providers can reference and verify. This indicates that the user has the attributes, credentials, or reputation needed to participate in a transaction, with selective sharing of personal data. The user can make a given Panther Reveal (carrying no personal data) or non-ZK (carrying personal data). Both would be verifiable by anyone if submitted on-chain. Furthermore, ZK Reveals are generalizable across other segments such as private identity, insurance, credit scoring, Web3 authentication and other services.
Once a Service Provider (such as a KYC verifier, Institutional DeFi service, or Web3 Protocol) receives a Panther ZK Reveal, they do not get to learn what the underlying information is, only that the proofs are valid and the users’ claims are true. Also, the Trust Providers who issued the attestations never learn anything about when or how users use those attestations when interacting with Service Providers.
zAccounts
zAccounts function as private ledgers for users
zAccounts don't hold PII (Personally Identifiable Information) such as name, dob, etc.
The core functionality of the zAccount is to allow users to safely deposit assets to transact with. Additionally, it lets users prove their balance in a private setup or withdraw their assets back to a publicly owned wallet.
The Protocol can verify the completion and nature of the user's verification without holding any sensitive personal data — while empowering the end user with tailored information sharing. It employs advanced zero-knowledge methods to ensure the confidentiality and control of users' transactional data on the blockchain.
To simplify compliance, each end user's activities are consolidated under a singular ledger, or zAccount.
However, rather than using a single fully-public spending key for each recipient, known to the whole world, a new spending keypair is derived. This pair is guaranteed to be unique for each UTXO and strengthens the system’s privacy while offering greater flexibility to disclosure schemes.
Using the babyJubJub curve, each zAccount account generates:
A read public/private keypair: ReadPubKey, ReadPrivKey.
A Keypair for stealth address generation: SpendPubKey, SpendPrivKey.
All users then register ReadPubKey, SpendPubKey with a registry available to other users in that Pool.
Status | Entrypoint |
---|---|
Status | Entrypoint |
---|
zTrade will be the world's first on-chain Over-The-Counter (OTC) marketplace.
Using the Polygon network (at ), zTrade offers an innovative approach to OTC trading by connecting makers and takers in a fully privacy-enhanced, secure environment. It leverages the attributes of the and to enable OTC trades.
Zero on large trades
Status | Entrypoint |
---|
zAssets are 1:1 representations of digital assets deposited by users into . It is the zAsset that confers much of the Protocol's privacy-enhancing features.
When users deposit their assets into a Panther Shielded Pool, they essentially convert their regular tokens or assets into zAssets, to be managed within Panther’s layer.
The Protocol uses (Succinct Non-Interactive Argument of Knowledge) proofs to store UTXO data on-chain. This allows a user’s on-chain state to be stored privately and to ensure private state changes.
Which assets may be deposited are determined by the .
The can propose assets for allowlisting at any time since allowlisting an asset requires a manual configuration. For the Protocol’s first release, Panther will probably launch supporting the following assets:
zAccounts are represented by UTXOs, so it's worth taking time to understand our unique .
Status | Entrypoint |
---|
Panther uses Zero-Knowledge, to flip the issue of compliance on its head. Rather than users sharing their personal information with every institution or Protocol they interact with, Panther instead allows them for each use case (e.g. one for proof of address, one for identity, etc.) to interact only once with only a single trusted party (a Trust Provider) which can verify their information and issue a signed cryptographic attestation.
Status | Entrypoint |
---|
zAccounts belong to a managed by a Zone Manager
The zAccount is the end user's entrypoint to a Zone, and thereby to a . A zAccount associates a user's EOA (Externally Owned Account, i.e. a wallet) with their KYC attestation, as required by the .
The Protocol is designed to allow the Zone Manager to define compliance and the compliance attestation that is required to validate a zAccount. This enables Zone Managers to allow decentralized identities, and assign third-party KYC providers. Users can establish a zero-knowledge zAccount following .
zAccounts are crafted using a specific type of unspent transaction output () within the Merkle Tree structure of UTXOs. Each zAccount UTXO encapsulates critical user-specific details, including the zAccount's unique identifier, balances in ZKP and PRP, Zone-ID, and more.
The Shielded Pool assigns every , represented by a commitment, to an “owner” — the only zAccount able to spend it. This is achieved by including a public (spending) key in generating the UTXO commitment, for which only the zAsset recipient knows the corresponding private (spending) key.
Deep dive into Panther Protocol's
In development on testnet
*Description coming soon.
Concept |
In development on testnet |
In development on testnet |
In development on testnet |
Get started with staking $ZKP
Panther rewards staking
Staking is initiated via a dedicated dApp
Sophisticated staking strategies will be supported going forward
Follow the How to stake with v0.5+ or learn more about staking with $ZKP here.
Panther DAO supports staking, enabling stakers to:
Earn rewards
Participate in governance
Contribute to the Protocol's privacy
As of February 2022, staking $ZKP allows stakers to participate in Panther’s Governance.
Staking will be rolled out in three phases:
Phase 1: Traditional
Phase 2: Experimental
Phase 3: Private
The current testnet version supports Phase 1, the traditional staking phase.
In January 2022, Panther DAO made staking accessible through the "Launch App" button on Panther's Home page to facilitate secure access through a reliable information source.
In time, a list of safe decentralized mirrors to access Panther's dApp will be set up here.
Follow the How to stake with v0.5+
Learn more about staking crypto in Panther Academy.
Learn more about Panther's planned staking phases.
Status | Current version | Entry-point |
---|---|---|
Polygon mainnet
"Launch App" button on Panther's Home page
To stake your tokens:
Go to https://pantherprotocol.io/ and click "Launch App". Make sure to read the page before you proceed.
Connect your blockchain wallet holding both $ZKP and native tokens to the app. You need native tokens (e.g. ETH on mainnet or MATIC on Polygon) to pay the transaction fees.
Enter the number of tokens you want to stake manually.
Click on the blue button at the bottom of the page. It should read "STAKE (NUMBER OF TOKENS) ZKP." Make sure all data is correct.
Your wallet will prompt you to confirm the gas transaction associated with sending your tokens to be staked. Press "Confirm" if you want to proceed. Remember, the Ethereum network determines fees, so if you consider them too high, you can try at another time.
Your wallet will inform you once your tokens are successfully staked. You'll be able to see your staked balance on this same page.
For any questions related to staking, you can contact our team and community.
The Advanced Staking app has two pages, one for Staking and one for managing zAssets. Our top Menu also links to Panther’s Snapshot.eth space, where Panther’s governance proposals are voted on. On the right side, the blue “Connect Wallet” button allows the user to permit the app to see and interact with their MetaMask wallet. This is necessary for the dApp to suggest transactions in which the wallet interacts with the Advanced Staking smart contracts.
The Staking page is the app’s homepage. It allows the user to:
Stake or unstake $ZKP.
Check their balances of unstaked $ZKP (available for staking), staked $ZKP, $zZKP rewards, and expected PRP balance.
See how much unclaimed $zZKP rewards are left for the Advanced Staking program and the current staking APR.
The time remaining until the staking program ends.
On the zAssets page, the user can:
Check their total balance per zAsset (through Advanced Staking, the only zAsset available will be $zZKP).
Inspect their $zZKP, Unrealized Privacy Rewards balance per individual stake, and total.
Redeem $zZKP before the mainnet dApp is launched.
You will find the Balances Card on the left side of the Staking page. This panel shows the user’s available $ZKP, staked $ZKP, zZKP rewards, and Expected PRP Balance. An approximate USD value is provided next to each $ZKP or $zZKP balance.
The panel also displays the user’s MATIC/ETH (depending on their connected network) balance in the top right corner. Make sure you have enough MATIC/ETH to pay the transaction fees required for some steps of the staking, unstaking, and rewards redemption processes.
To refresh the values, click on the refresh icon to the right of “Available ZKP balance,” and a MetaMask signature request will pop up. You will need to accept it, which does not incur gas fees.
Note: Data updating can take time. Please watch the spinning wheel inside the “Available ZKP Balance” field in the top right corner. Data should be up to date as soon as the wheel stops (but you might need to refresh the page).
Located to the right of the Balance Card, the Stats panel displays the amount of Advanced Staking rewards already distributed, the percentage of the total they represent, and the total rewards offered. It also shows the time left until Advanced Staking closes and its current APR. Note: Staking APR and Privacy rewards APR are two different parameters.
The tab for staking $ZKP in Advanced Staking is located below the Stats panel on the Stake panel.
You can input the amount of $ZKP you intend to stake on the box on the top or click the “MAX” button on the right side next to the Panther logo to automatically insert your entire $ZKP balance. The minimum stake size is 1000 $ZKP.
The warning below the amount box refers to the lockup period of 60 days set on PIP-9, to which all stakes in Advanced Staking are subject. Only after this period can you unstake your originally-deposited $ZKP. The lockup period doesn’t apply to the rewards from staking, as we will address on the zAssets Page session.
After the warning message, you can preview the $zZKP and Expected PRPs staking rewards your stake will entitle you to. This preview is just a forecast, and final numbers may vary slightly.
As time progresses, you will accrue additional Unrealized Privacy Rewards (non-flat PRPs) on top of your initial amount (2,000, only for the first 2,000 stakes). These additional rewards will only be awarded if you keep your $zZKP rewards in the pool till mainnet beta’s launch.
If you’re satisfied, you may click the blue button. This step requires $MATIC/$ETH (depending on the network you’re on) to cover gas fees.
After clicking the blue button, three MetaMask windows will appear in quick succession. The first will prompt you to approve Panther’s Advanced Staking contract to move your $ZKP. The second window will ask that you accept the actual staking transaction. Gas fees apply to both steps.
After staking, you can see your updated balance on the Balances Card and the zAssets page.
_______________________________________________
It’s important to understand the distinction between unstaking (of staked $ZKP) and early redemption (of $zZKP rewards). Unstaking and redeeming are separate functions of separate smart contracts.
Users can unstake $ZKP after their stake’s lockup period ends (60 days per individual stake). Doing so returns only their original $ZKP stake to their wallet. The accumulated staking rewards need to be redeemed separately.
A user can redeem their $zZKP rewards from a specific stake after 120 days since the launch of the Advanced Staking program. Doing so before the launch of Panther mainnet beta, necessarily entails forfeiting all Unrealized Privacy Rewards (one of two types of PRP rewards )associated with that stake.
_______________________________________________
The Stake panel has two tabs: Stake ZKP and Unstake ZKP. You can switch between them through the buttons on the panel's top. The Unstake ZKP tab allows you to inspect and unstake your stakes.
To unstake one of your stakes, click the “unstake” button on the right side of said stake. This will prompt you with a MetaMask window where you can confirm the transaction —gas fees apply. Your $ZKP will be returned to you once the network confirms the transaction.
Exactly as with staking, you can see your updated balance on the Balance Card and the zAssets page.
Advanced Staking (previously referred to as Experimental Staking) is an intermediate step towards Panther’s mainnet dApp Staking on Polygon and the Ethereum Mainnet. Through it, users can earn rewards and help Panther test the features that will, in due time, enable privacy through Shielded Pools. Because of its importance for the Protocol’s development, it is considered Panther’s version 0.5.
Advanced Staking will be launched on December 8th by the Panther DAO, according to Panther Improvement Proposal #10. It will debut a Multi-Asset Shielded Pool, or simply a Shielded Pool, where users can shield assets but not conduct transactions at the time of the staking app launch.
Panther’s v0.5 is a progressive step towards developing the core technologies surrounding the Shielded Pool, mainly how UTXOs are created, managed, and tracked. Advanced Staking acts as a step to deploy and test the above capabilities by issuing staking rewards as $zZKP directly within the Shielded Pool.
Staking Rewards
The number of tokens to be released as rewards in Advanced Staking is 6,000,000 $ZKP.
The formula for distributing rewards is the following:
Reward = Amount * APR * Period / 365 APR - 15% Period - 60 days
Where:
Reward: reward for a stake ($zZKP)
Amount: amount staked ($ZKP)
APR: Annual Percentage Rate (%)
Period: rewarded period (days)
PRP Rewards
v0.5 also introduces Panther Reward Points. PRPs are non-transferable points associated with a user's Panther account. The mechanisms for calculating and generating PRPs will also be used on Shielded Pools in the Protocol's mainnet beta. When the Protocol's mainnet beta is live, users that deposit assets (contributing to the privacy set) will receive PRPs to be redeemed for $zZKP through a single-sided Automated Market Maker.
At v0.5, there are two types of PRP rewards:
Expected PRP Rewards: The first 2000 stakers will be rewarded with 2000 PRPs per stake, as decided by the community through PIP-9. These rewards will not continue growing or change (i.e. they are “flat”). Users can see them on the Balance Card on the Staking page. This type of PRPs will be awarded automatically and is not forfeitable.
Users that qualify for this kind of reward will receive a “stake-proof” NFT allowing them to access their Expected PRP Rewards once mainnet beta is launched.
Unrealized Privacy Rewards: These will be calculated and accrued based on the Privacy rewards APR, which the community will decide through a Panther Improvement Proposal. This APR will be set through a PIP before mainnet beta is launched. These PRPs will only be awarded when mainnet beta launches and only if a user has kept their $zZKP rewards in the pool until mainnet beta. If $zZKP rewards are redeemed via early redemption mechanics, the user will lose all of his accrued PRPs of this kind.
All PRPs will be available to exchange for $zZKP via the[ single-sided AMM](../../v0.5 also introduces Panther Reward Points. PRPs are non-transferable points associated with a user's Panther account. The mechanisms for calculating and generating PRPs will also be used on Shielded Pools in the Protocol's mainnet beta. When the Protocol's mainnet beta is live, users that deposit assets (contributing to the privacy set) will receive PRPs to be redeemed for $zZKP through a single-sided Automated Market Maker at the time of the mainnet beta launch.
Get started with Advanced Staking.
These Operator roles are vital to Panther Protocol:
Within Panther, ecosystem operators sign transactions and pass them to the queue to be mined by Oshiya Operators. This adds to the privacy set.
Within Panther, VASP-licensed operators set up Zones to enable entry into Panther's Shielded Pool according to the KYC requirements they configure.
Compliance Providers are dedicated service providers who ensure that the Zone Manager's KYC/KYT requirements are met by zAccount holders.
Learn about:
Classic Staking began on February 2nd and ended on May 4th, 2022. New stakes were automatically disabled by the smart contracts on April 27th, 2022, as previously scheduled.
Staking was available to all holders of unlocked tokens, i.e. buyers with a percentage or all of their tokens unlocked at TGE.
Panther Relayer overview
In return for a fee, Relayers provide an optional service to Protocol users — adding to the privacy set
Relayers pass bundles of transactions, signed and paid, to the Shielded Pool contract
signing the transactions with their public key
paying the gas fees
relaying bundles of transactions to the Shielded Pool contract
Relayers, therefore, enhance privacy, since observers are unable to pinpoint the actual address that initiated the transaction because the Relayer signs the underlying blockchain transaction with their key.
As of testnet stage 6 and mainnet beta, Relayers support:
Account activation
Account renewal
Claiming PRP voucher
Deposit
Internal transfer
PRP to ZKP exchange
Withdrawal
Relayers pickup transaction relay requests and bundle these together. The details of this bundle are passed to the PayMaster contract which verifies the fee calculation. If the fee to be paid by the originator of each transaction is enough to cover the gas fees of the underlying platform, Matic for testnet and mainnet beta, then the PayMaster contract converts $ZKP from the pool of ZKP it controls into the native token, e.g. Matic using Uniswap's v3 service.
Note, PayMaster does this at intervals, not per bundle, to reduce fees.
Note that the fee calculation includes a buffer value, the failure fee. This ensures that the pool controlled by the PayMaster does not become depleted in the event of tx failures due to a re-org, gas-cost spike, or other impediment to tx success.
The gas fees are those fees charged by the blockchain, so Matic are required to pay tx costs in testnet and mainnet beta.
The gas fee charged by the Relayers includes their fee.
Panther has integrated with Etherspot’s Skandha ERC4337 Relayer and Bundler service to send transactions to the blockchain. Users may select (Bundler = YES / NO) before submitting their transactions.
IMPORTANT: Following a decentralized approach, this deployment by the Panther DAO is accessible through the This is to facilitate secure access through a reliable information source.
Within Panther, zMiners run an — code that fetches the pending mining queue. Oshiya then computes updates to the Merkle trees needed to append the UTXOs of the queue to the trees, creates a SNARK-proof that proves the correctness of the updates, and submit these updates to be written on-chain together with the proof to Panther smart contracts.
Panther launched a $ZKP Governance Staking program right after TGE. This allowed holders of to stake their $ZKP holdings to govern the Protocol. Rewards came from a 6.65 million $ZKP pool. Each user earned a proportion of the new rewards added to the Rewards Pool ongoingly, divided based on their pool share.
Panther Relayers are providing a relaying and bundling service that run the (optional) Relayer service to provide an additional privacy layer by breaking the link between the initiator of the transaction and the transaction itself. Relayers earn rewards for:
The Relayer service leverages features introduced by the such as tx (transaction) bundling and account abstraction.
The fee pays the that computes how to mine the transactions on-chain.
Private Staking will be the final state of staking. By the time Panther transitions to Private Staking capabilities, the technology behind Advanced Staking will have informed the release of , and Panther will be at its mainnet release.
Private Staking is the ultimate goal of $ZKP staking: A system that rewards users for staking tokens directly into a Shielded Pool, enhancing the Protocol's privacy-preserving capabilities along the way. To understand how privacy staking contributes to privacy, check out our piece on. All of Panther's staking rewards and incentives align with this purpose.
Relayer Get Started
Interested in contributing to privacy-enhanced trading by providing a Relayer service? Reach out to us at contact@pantherprotocol.io.
zMiner overview
Oshiya Operators are Protocol Miners, named zMiners
In the testnet and mainnet beta Protocol, zMiners provide distributed computational power to support the Protocol and earn rewards
Oshiya prepares batches of UTXOs to be inserted into the Bus tree; the Merkle Tree that stores UTXOs
Operating an Oshiya node requires no technical know-how
This enables future versions of the Protocol to allow users to self-process their own UTXOs and write them on-chain from within the dApp
Optimizing Oshiya may be possible, this does require technical know-how
zMining is a gas-optimized approach to transaction validation in Panther’s Shielded Pool. Panther zMiners run the Oshiya code (previously referred to as Miner code) responsible for computing the updates required to append batches of UTXOs on-chain. zMiners provide off-chain execution and submit the proof to the Panther contract to verify the validity of their computation.
Within Panther, transfers (P2P transactions), deposits, and withdrawals result in UTXO commitments. Oshiya fetches the batch of pending UTXOs from one of the queues on the Bus tree, computes the required updates to the Merkle tree needed to append the UTXOs of the queue to the Bus tree, creates a SNARK proof that proves the correctness of the updates and the validity of the UTXOs to be committed and, if the proof is valid, these updates are written on-chain by Panther Protocol's smart contracts.
A successful update results in the miner's EAO (externally owned account, an Ethereum address for mainnet beta release) receiving a reward, as shown:
Oshiya operates on the principle of redundancy, meaning that several zMiners may attempt to compute the commit required to process the batch of UTXOs. Only one zMiner will succeed and receive the reward. The total amount of rewards for batching and processing all UTXOs in a queue is split into two parts:
Guaranteed reward
Premium payment
The Protocol assumes that the zMiner will collect accumulated rewards, i.e. they will accumulate a reward pot and extract this at intervals. This makes more sense than paying gas fees for small value extractions.
A “guaranteed” reward, as set by the DAO.
The proposal is that the zMiner is guaranteed a minimum of 80% of the reward available for that batch in the queue. The remaining 20% goes into a pool to pay out premiums.
The premium depends on the age of the queue, it's calculated proportionally to the number of blocks that have passed since the queue was started, counting from the creation of the earliest UTXO in the queue. The premium will be calculated through accrual at a fixed factor with the caveat that a premium is paid out only if the fund is not depleted.
The proposal is to initially set at the premium as 0.1% of the “assigned reward” for every pending block.
See the reward functions in the source code.
Technical Oshiya Operators are welcome to run the Docker service, however, even non-technical Operators may run an Oshiya node via a simple dApp interface.
Batch Processing: Oshiya processes up to 64 UTXOs in batches, integrating them as leaves in the Merkle tree within the Bus tree contract. This approach maximizes efficiency and scalability when handling transactions.
SNARK scalability: At the heart of Oshiya's architecture is the efficiency gain of validator vs. prover. SNARK technology ensures validity of Merkle Tree updates by placing the computational load on the prover (Oshiya), allowing the validator to verify the validity of the offered proof with a relatively trivial amount of computational effort.
Optimized Gas Usage: By processing UTXOs in batches and employing SNARK proofs, Oshiya significantly reduces the gas costs associated with processing transactions individually, offering a more cost-effective solution.
Enhanced Privacy: Outsourcing the computational load to Oshiya allows the Protocol to use a larger Bus tree at reasonable costs. This larger tree accommodates more UTXOs, hence increasing the anonymity set.
Note that this anonymity will be shared between Shielded Pools across different networks.
Cost Efficiency: Users benefit from reduced transaction costs due to the gas-optimized approach.
The Protocol can also support a tip from the initiator of the transaction, however, this feature will not be included in testnet or mainnet beta versions.
The codebase for Oshiya is open for community involvement. We encourage developers and blockchain enthusiasts to contribute towards optimizing and enhancing Panther Protocol — ensuring it stays at the forefront of blockchain technology.
Oshiya Node Operator Get Started
A testnet version of the Oshiya mining service is live
Earn rewards for Protocol mining
The testnet Panther Protocol dApp is supported by testnet Oshiya node Operators, known as zMiners. Anyone can run Oshiya to earn rewards as they contribute to the Protocol.
Ethereum-compatible EOA (externally-owned account, i.e. wallet)
MetaMask is recommended
Spare CPU
Follow the Get Started instructions in Docker.
The interface provides:
The interval field. zMiners may adjust the cycle length by updating this variable.
Private key refers to the EAO to which rewards will be sent. Either enter the Ethereum account address or use the Connect MetaMask button.
RPC endpoint.
During testnet, users may enter any viable Mumbai RPC endpoint available from Chainlist.
Start/Stop mining.
Note that the current session will complete and Oshiya will terminate on Stop.
Mining attempt outcomes.
While you may run multiple instances of Oshiya, remember that the computational load will increase, and there is a race condition against other miners
The dApp provides a very basic interface for community members interested in earning when the Protocol is released. Be aware that it may eventually become non-viable to zMine via the app should tech-savvy operators make their own optimizations.
Understand more about the responsibility of the Oshiya module
For more information, see the original Stage 0 Get Started page
Entry-point | Current version | Status |
---|---|---|
🚧 Migration to Sepolia testnet
ditto
ditto
Zone Manager Get Started
Are you a VASP-licensed operator interested in customizing your own trading Zone for privacy-enhanced trading? Reach out to us at contact@pantherprotocol.io.
Compliance service providers overview
Panther Protocol is agnostic as to which individual service providers enable the compliance aspects of the Protocol
3 services are required, these may be issued by the same operator, or different operators, as per the Zone Manager's preference:
KYC
KYT
Data Escrow
i.e. the same service provider may provide all 3 services, or the Zone Manager may engage 2, or 3 providers.
Know Your Customer data will be required by the majority of regulators world-wide. The Zone Manager will work with KYC service providers to collect the relevant data according to their Zone's compliance requirements.
Know Your Trade data will be required by the majority of regulators world-wide. The Zone Manager will work with KYC service providers to collect the relevant data according to their Zone's compliance requirements.
Basic audit data will be stored by specialist service providers that may then be revealed in special circumstances of legally-required forced reveals. The Zone Manager will be required to coordinate with the specialist data storage provider to "crack" open this data storage mechanism to undertake the reveal.
Considering the difficulties in developing a decentralized solution that preserves privacy and enables compliance, Panther designed an approach that utilizes three essential components: third-party compliance vendor integrations, Panther zAccounts and Zones.
By leveraging the Protocol's zero-knowledge characteristics, these elements collectively form a pathway to achieve compliance.
To see the regulatory rationale for Panther integrating compliance tools, please visit our article on these solutions
Panther has built a system that retains neutrality by integrating compliance providers that accept multiple types of verification. These systems are called “multi-compliance vendors”, as they give users the ability to choose from a variety of compliance providers while retaining a decentralized approach.
The Panther DAO has been commissioned to select a multi-compliance vendor that aligns with its interests, a discussion taking place in Panther’s forum. When integrating these providers, the following requirements are taken into consideration:
Ability to blocklist PEPs or newly-flagged individuals based on unverified identities.
Blocklists for verified EoAs.
Ability to perform checks to create an “allowlist” that works on- and off-chain.
Preferably, the ability to have an on-chain verification list maintained through oracles/smart contracts.
Performing validations at deposit and withdrawal.
Optionally, allowing users to register multiple addresses. This is suggested so that users can break the on-chain link between their transactions by withdrawing and depositing from different addresses.
Optionally, using a zero-knowledge proof to allow users to create new accounts once they have passed verification.
Within Panther’s solution, compliance providers need to be able to process users’ data without the Protocol learning it, proving a user’s ownership of their wallet and giving them a zero-knowledge proof that attests to the validity of their statements. This allows users to access Panther but maintains the Protocol’s neutrality. The diagram below exemplifies this process:
Zone Manager overview
Zone Managers are responsible for managing Zones, setting rules for who can join it, and what activities these users can engage in.
Zones are logical partitions of liquidity within Shielded Pools, each of which is managed by a different Zone Manager. Zone Managers can determine what KYC information their Zones require from users, and control the integration of specific compliance vendors into their Zones to fit their specific goals.
Zone Managers set the Zone for users: they determine types of verifications these users undergo, and other factors related to Zones such as what assets may be traded, users’ transaction limits, etc. As such, Zones Managers define what compliance means for their Zone.
This also allows the Zone Manager to determine what constitutes KYC, whether that be providing an email address, to an in-person yearly verification.
Panther Protocol fees and rewards
Fees can be categorized as:
Network fees
Rewards are issued as Panther Reward Points (PRPs)
PRPs are exchanged for $ZKP as $zZKP
Rewards are paid to the transactors for all activities that contribute to the Protocol's privacy set. With the exception of the withdrawal fee, Protocol fees are paid in $zZKP while the gas fee for the underlying chain is paid in that chain's native token. Fees are paid to service providers and Ecosystem Operators that contribute to the transaction lifecycle. A fee is paid on the withdrawal of assets from the Protocol, as this decreases the Protocol's privacy set.
Users receive rewards whenever they conduct an activity beneficial to the Protocol’s privacy set. PRPs, Panther Reward Points, are issued for these in-app activities:
Onboarding
Account creation is incentivized through an onboarding reward. This is key to building a network effect at launch.
Deposit
Locking assets in the Panther Vault in exchange for zAssets.
Send
Transferring zAssets to another Panther zAccount.
Stake
Note, staking will be included in the mainnet beta app's function, at testnet, it's achieved through a separate app.
Using DeFi adaptors.
Topping up the $ZKP pool
The single-sided AMM pool must be recharged by a user willing to pay the gas fee and sign the transaction for transferring $ZKP from the Ethereum network to the base chain for the Protocol, i.e. Polygon for mainnet beta. This effort and cost is rewarded.
PRPs are exchanged for $ZKP as $zZKP.
Protocol fees are paid to Ecosystem Operators for their part in the transaction lifecycle, while the base chain's network fee, in this case Polygon's gas fee, is paid in their native token, i.e. on Polygon, in Matic. As per the following image showing the dApp deposit page.
There are currently 4 Protocol fees:
Relayer fee
Processing fee
Withdrawal fee
KYC fee
As Panther releases the Protocol onto more chains, and enters its multi-chain phase, the cross-network gas fee will also apply.
Relayer fee
Relayers provide an optional service to Protocol users that adds to transactional privacy. Using the account abstraction model, Relayers sign transactions, pay the gas fees, and pass bundles of transactions to be executed in the Shielded Pool contract. This masks the origin of the account that created the transaction.
Processing fee
The processing fee pays the zMiner, an Ecosystem Operator that provides distributed computational power to support the Protocol transaction layer.
Withdrawal fee
Users are incentivized with rewards to remain in the Protocol, and disincentivized to remove assets with a withdrawal fee. As assets are removed from the Shielded Pool, the privacy set is decreased, and so a fee is applied in the token of transaction. This is a direct cost applied when users decide to move their assets out of the privacy-preserving environment of the Shielded Pool and back into their wallet address or other destination. As per the following image showing the dApp withdrawal page: note the fee level is still to be determined by the DAO, the value shown is a placeholder item only.
KYC fee
To create a zAccount, the user must comply with the KYC conditions stipulated by the manager of the Zone they are attempting to join. Typically, for most locales, this KYC process must be undertaken annually, and the fee is paid directly to the third-party service provider.
Next, let's dive deeper into how the fees that are paid to the Protocol on the withdrawal penalty circulate back into the Protocol's $ZKP economy.
Panther Protocol economic model
PRPs are exchanged for $ZKP as $zZKP via a single-sided AMM
$ZKP is purchased on the open market using withdrawal fees
45% of the total $ZKP supply is assigned to Protocol rewards and incentives
Panther Protocol has designed a circular economy to provide a stable economic model able to withstand sell and buy pressures according to the game theory of the Protocol.
Fee and rewards are designed to balance each other as per the following logic:
More transactions within Panther means more rewards issued to users
Number of transactions will be correlated with withdrawals; i.e. more transactions results in more $ZKP sent to the rewards pool
Increasing the balance of the rewards pool creates a better PRP:$ZKP ratio, hence users enjoy better returns on their PRPs
Let's dive deeper into the reward pool mechanics.
Users are automatically rewarded for conducting specific activities in PRPs; stored as a balance in each zAccount.
The PRP reward spread creates a dynamic distribution model between PRPs and the total available $ZKP rewards in the reward pool at any given time. This is because the $ZKP reward pool has no fixed value, rather it has sources that contribute to it:
Fixed release schedule
Fees
Initially, the main source of $ZKP in the Reward Pool is the fixed release schedule, i.e. the $ZKP rewards supply. This reward pool will emit $ZKP for 12 years. This gives the Protocol time to become established to the extent that the withdrawal fee pool can support the Protocol rewards once the fixed rewards supply is exhausted.
Users must sign the transaction and pay the gas on the Ethereum network, to top up the $ZKP pool within the AMM. They earn PRP rewards to facilitate this exchange, this reward increases as the emitted $ZKP pool increases.
Panther’s AMM functions by allowing users to redeem PRP for $ZKP at a fluctuating rate. Exchange rates in this system are proportional to $ZKP in the pool and the total PRPs available. Through this mechanism, Panther has created a game-theoretical way to price privacy.
Learn more about Panther's tokenomics
zSwap features a user interface similar to the DEXs mentioned above for a familiar user experience. It also allows users to dictate the token IDs for the assets they want to sell/buy from a list of accepted assets (see below), enabling them to choose the specific swap pair they wish to trade. Users can also input the amount of the sell token they wish to trade, and the zSwap function will query an exchange rate based on these inputs and provide users with up-to-date values. This ensures that users can make informed decisions about their trades and optimize their transactions for the best possible outcome.
The ability for users to swap assets privately serves a double purpose:
Allowing users to trade between all allowlisted assets available using the platforms above.
Contributing to the privacy that Pools provide to users holding assets within them.
In other words, no one can link assets within the pool to specific users since they can swap assets and trade with one another within it, even if deposits/withdraws to the Pool itself are viewable by observers.
Status | Entrypoint |
---|
The first use case for DeFi Adaptors, zSwap, is designed to facilitate swap transaction flow towards some of the most widely used protocols in the Polygon DeFi ecosystem — , , and . This functionality is found within the “Swap” tab in Panther’s decentralized application (dApp).
zSwap’s goal is to cater to a wide range of user types, including retail users, institutions, and market makers. At , zSwap will support the interaction with three different platforms, with the ability to highlight the best platform or “route” for users to conduct their swaps, allowing them to swap tokens at the most favorable rates and incur smaller fees.
In development on testnet |
zBridges
To realize the Protocol’s vision of cross-chain zero-knowledge access to DeFi, Panther will deploy its Shielded Pools onto multiple blockchains (L1s and L2s). zBridges will connect these Pools on different blockchain networks, enabling cross-chain transactions and compounding the difficulty of tracking user activity.
zBridges are a cutting-edge cross-chain feature developed by Panther, and a key component of the cross-protocol Zero-Knowledge layer concept. They allow users to transfer their zAssets across multiple blockchains while preserving privacy. With an initial focus on Ethereum Virtual Machine (EVM)-compatible chains, zBridges extend the benefits of shielded transactions to a broad range of blockchain networks, enhancing interoperability in the DeFi landscape.
Using Shielded Pools and zAssets, zBridges allow users to send and receive digital assets across chains. Users with zAssets on a sending chain can execute cross-chain transactions, with the Protocol leveraging native network liquidity to ensure a fully collateralized and secure transfer.
The underlying executing and receiving blockchains assure the security and integrity of transactions via zBridges. Users can confidently conduct cross-chain transactions, knowing their assets are secure and their on-chain data is safeguarded.
As the demand for interoperability in the DeFi ecosystem grows, zBridges are a significant milestone. They represent a step forward in developing privacy-preserving, cross-chain solutions that bring together the benefits of multiple blockchain networks, helping redefine the boundaries of what's possible within decentralized finance.
Status | Entrypoint |
---|---|
Concept
Some key metrics for $ZKP are:
To see your $ZKP, you might have to manually add $ZKP to your Metamask or blockchain wallet.
Please be aware that you will need to do this once for each account and network. For example, if you have $ZKP in two accounts on the Ethereum mainnet and one on Polygon, you must add the ZKP token to each of these three accounts separately.
There are a few ways to add the token, listed below. They all work for MetaMask, but not all will work with other wallets.
Visit https://pantherprotocol.io/ and click "Launch App."
Ensure you have the correct account and network selected in MetaMask.
Click the three dots (...) in the top right corner.
Click "Add ZKP Token."
You should see a popup, which you can then confirm to add.
These official MetaMask instructions offer several ways to add the $ZKP token to MetaMask:
How to add unlisted tokens (custom tokens) in MetaMask
You should use one of the following contract addresses, depending on which network your $ZKP is on:
Network
Contract address
Ethereum mainnet
Polygon mainnet
At the genesis of our Protocol, we faced the titanic task of allocating our tokens fairly among purchasers, the founding team, and the community enthusiasts that will use and govern Panther.
We decided that the following allocation best represents our principles and creates a healthy setup for all network participants:
$ZKP allocations per stakeholder.
The full details of the token allocations are as follows:
Public Sale: 5% of the total supply was sold to the public with two unlocking schedules, depending on the price paid per $ZKP.
Private Rounds: 15% of the total supply was sold via pre-Seed, Seed, and three subsequent Private Sale rounds. Through these private funding rounds, Panther raised 10 million USD.
Foundation: 15% of the total supply has been reserved for the Foundation between General (8%), Reserves/Liquidity (5%), Education (1.75%), and Bug Bounties (0.25%).
Protocol Rewards: The Panther DAO has reserved 45% of the total supply for Protocol rewards and incentives.
Founders, team, and advisors: 20% of the total supply will be vested to the founders, team, and advisors, with a linear unlocking over three years. This allows Panther to continue hiring and retaining the best talent in the industry for years to come.
For the raw technical smart contract data which implements the above, please see section 1.3 of LaunchDAO proposal #3.
Release of $ZKP over 144 months.
The issuance of ZKP tokens will follow a sensible release that keeps the interests of all network participants aligned. Key stakeholders and project stewards are subject to long vesting periods for their tokens, ensuring long-term commitment to the Protocol's success.
As outlined in the Panther whitepaper, Panther is on a continuous path toward decentralization. This approach is by design, as the Protocol focuses on building a solid foundation to support further development, adoption, and decentralization of the Protocol.
Panther has been decentralized since day one, launching through a decentralized token and smart contract generation event called 'LaunchDAO.' Members of the Panther community directly participated in this launch. In addition to receiving a $PreZKP non-transferable token, which serves as a badge of honor, voting members also received $ZKP tokens after the token launch.
Through Snapshot, the Panther community can vote on Panther Improvement Proposals (PIPs). PIPs cover various topics, from democratic procedures to code releases. Once a proposal is published on Panther's Snapshot page, it can be voted upon by the community. If the vote does not pass, no action is taken, preserving the community's power to decide the Protocol's direction.
Before a proposal moves to Snapshot, it should be discussed on Panther's community-managed forum, Discourse. On the Panther forum, the community can make new topics or contribute to the existing discussions to let their voice be heard.
Building up to the launch and deployment of Panther Protocol v0.5, Panther achieved a significantly higher level of decentralization through Panther Improvement Proposals 6, 7, 8, 9, and 10. Through these proposals, various Protocol components were governed, deployed, and configured by the Panther community.
PIP-8 set the stage by putting more responsibilities in the hands of the Panther community by onboarding new Snapshot Authors and Admins. Authors are community members who can publish a PIP draft from Discourse onto Snapshot. At the same time, Admins are responsible for maintaining the integrity of the platform's governance structure by enforcing DAO governance rules and values. The Panther DAO Council introduced by PIP-14 decides if a proposal draft from Discourse is suitable to be voted on and serves Panther's interests.
PIP-8 also defined the process of electing future Snapshot Authors and Admins. PIP-8 sought to enhance decentralization by augmenting the number of Authors and Admins within the Panther Protocol ecosystem. The proposal successfully onboarded two Panther contributors and six community members as Snapshot Authors empowered to propose changes on Snapshot.org. Furthermore, two new community-elected Admin accounts were added as signatories on the Gnosis Safe multisig wallet, which serves as the sole admin account for Panther's Snapshot.org space. The multisig wallet operates under a "2-out-of-3" signing policy, ensuring that changes to the Snapshot.org space's settings are approved by at least two of the three allowlisted Admins.
PIP-8 increased community participation in the Protocol's governance and eliminated potential points of failure. Introducing new Snapshot Authors, Admins, and a multisig for Admin actions improved the Protocol's resilience and decision-making process. These permissions are valid for six months, after which the community proposes and votes on a fresh set of nominees to continue in the role. The second election of Admins and Authors occurred through PIP-15, which put these functions solely in the hands of community members.
PIP-9 and PIP-10 also formalized the terms for the staking program, giving the community a direct route to decide how a significant amount of funds would be distributed among stakers. The community has since also expanded the Advanced Staking program, executed CEX listings for $ZKP, and formalized its procedures, among other things.
$ZKP is Panther Protocol's Governance Token. Token holders can vote on governance matter on Panther Improvement Proposal ( or DAO proposals) on Snapshot.
$ZKP is also a driving force of Panther Protocol that is used as a rewards token and allows users the ability to pay for third party services that support the Panther ecosystem.
In our efforts to infuse DeFi with default privacy, we attempt for Panther to be used as the de-facto solution for private DeFi access. To keep this network functioning as intended, Panther requires architecture and design that incentivizes the right actions.
Creating enticing incentives means aligning the interests and behaviors of all network participants while minimizing destabilizing conduct to the greatest extent possible. Game theory offers a framework to model these intentions and understand how they work within complex real-life settings. Thanks to this, we can create optimal cost structures for using and contributing to Panther’s Shielded Pools, helping inform governance decisions.
$ZKP, therefore, serves to incentivize:
Privately staking $ZKP to earn rewards for adding tokens to Pools and increasing the anonymity set. Panther can act as a price discovery mechanism for privacy, bringing in new users for a positive feedback loop, eventually lowering the cost of privacy.
Relayers paying fees privately on behalf of users, furthering anonymity, to earn $ZKP.
Governance-focused staking to encourage long-term governance participation.
$ZKP can also:
Be staked to secure the interchain bridges in an AMM model.
Be used by users to pay for services on the platform at a discounted rate, such as:
(i) to pay fees associated with zAssets;
(ii) to pay transaction fees for sending zAssets;
(iii) to pay Reveal fees;
(iv) to pay for interaction with external DeFi protocols.
Be used by the DAO to pay for services provided to the Protocol, such as:
(i) to pay incentive fees to privacy stakers and transactors.
(ii) to pay relayer service fees.
(iv) to pay voting stakers.
(v) to pay for community-driven deployments.
$ZKP's ERC-20 address on Ethereum is 0x909E34d3f6124C324ac83DccA84b74398a6fa173
$ZKP's ERC-20 address on Polygon is 0x9A06Db14D639796B25A6ceC6A1bf614fd98815EC
Panther uses Reality.eth in order to verify real-world events for smart contracts.
Built by Social Minds Information Systems, it is a crowd-sourced oracle dApp for user-defined questions. This means that whenever Panther puts out a DAO proposal, Reality.eth verifies the outcome of the vote. If this outcome is positive, the transactions embedded within the proposal can be executed permissionlessly by anyone via the Zodiac Reality module. Reality.eth achieves this (with the help of the Panther team) through a clever system that crowdsources answers on-chain.
Reality.eth allows anyone to set up a question and tie funds to its answer. It works through a system of bounties and bonded deposits.
The answer to the question can be binary (yes/no), a timestamp, one option out of a list, or multiple options. An arbitrator is also appointed. The arbitrator can be a DAO or a decentralized on-chain open-source system such as Kleros.
The question asked can then be answered and verified by anyone who wishes to claim the funds tied to it. In Panther’s case, this question is: “Did the Panther DAO approve proposal X on Snapshot at (ADDRESS)”? Should the question receive an initial answer (which has to be accompanied by a bond), it may either go uncontested (which awards the answerer the askers’ tied funds) or contested (which starts a bidding war, as each new contester has to introduce progressively higher bonds).
Because Reality.eth is game-theoretically modeled, the system resolves after a given number of attempts, after which the bidding war stops or the arbitrator is called in. The owner of the answer selected by the arbitrator receives the entire amount in bonds from all submitted answers, thus permanently settling the question.
After a question is settled, both the question and its answer remain on the blockchain as verified decentralized information accessible by any smart contract on the same network. Since this information is considered to be true, it can be used by the Zodiac Reality Module — developed by Gnosis — to execute the transactions tied to the proposal.
One of the most exciting uses for Reality.eth’s system is to verify a voting outcome. Thanks to the Zodiac Reality Module, deployment can be automated for changes to be instantly implemented should a given proposal pass.
Panther has been using Reality.eth and the Zodiac Reality Module to implement DAO proposals since Panther DAO Proposal #2. This process makes crafting proposals a lot more difficult since they have to be meticulously created to work as intended from the very first deployment. Panther accepts this trade-off to favor progressive decentralization.
As of writing, Reality.eth can work on the Ethereum Mainnet, Polygon, Binance Smart Chain, among other Layer-1s, as well as Layer 2 protocols such as Optimism and Arbitrum.
Reality.eth also checks all of the following boxes for Panther:
It leaves the outcomes and governance in the hands of the DAO.
It is fully compliant, as anyone can see on-chain that the proposals to the Panther DAO are only merged after a vote by $ZKP holders.
It allows users to verify their trust in the Protocol and is therefore decentralized. As opposed to blindly trusting developers, the Panther community and DAO can publicly see who the Panther team’s arbitrator is, raise questions about their qualifications, analyze the code in every proposal, and contest Reality.eth calls if they feel the need.
This system makes Panther more transparent, decentralized, team-agnostic, and validates the governance use case of $ZKP.
Panther's decentralized frontend refers to a user interface that is not controlled or hosted by a central entity. This allows users to interact with our Protocol in a trustless and permissionless way.
The documentation on this topic is currently under construction and will soon be updated to provide more details on this feature.
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.
Panther Protocol is a decentralized Protocol, governed by the Panther DAO, a decentralized autonomous organization for community-led decision-making. This section covers some of the DAO's procedures and history of the DAO, whereas the complete formal framework can be seen under Governance framework.
Panther utilizes Snapshot for community members to vote on Panther Improvement Proposals (PIPs). PIPs cover various topics, from democratic procedures to code releases.
Once a proposal is published on Snapshot, it can be voted upon by the community. If the vote does not pass, no action is taken, preserving the community's power to decide the platform's direction.
Furthermore, the ongoing process of using Discord and Telegram to brainstorm with the community before issuing proposals changed with the release of Panther’s Discourse forum. Using the Panther forum, Snapshot Authors can refer back to the relevant discussions directly on the proposal itself, thus providing more context for the voters.
Admins and Authors for Panther's Snapshot page are voted on by the community. Authors can publish proposals in Panther Protocol’s space on the Snapshot.org cloud service, and Admins can update settings on it. The roster of Authors and Admins is renewed every six months, as has happened via PIP-8 and PIP-15. The latter marked the first time these roles were entirely handed to community members.
PIP-14 formalized an explicit Governance Framework to make it easier for the Panther community to participate in DAO governance.
PIP-14 also introduced the formation of a DAO Council entrusted with reviewing Panther Improvement Proposals (PIPs) from our Discourse forum. By verifying the alignment of proposals with Panther DAO’s mission, vision, and values, the Council can prevent spam requests and proposals that are out of budget or misaligned with Panther's scope and roadmap.
PIP-14 established an explicit Governance Framework to make it easier for the Panther community to participate in DAO governance.
The establishment of implicit rules and guidelines. These rules, which are now formalized, can be found in the following diagram:
As you can see, the diagram outlines a clear process for community members to conceive, discuss, and formalize Panther Improvement Proposals.
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.
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.
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.
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.
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 Snapshot.org. This does not promise any compensation for normal staking/unstaking transactions, or other interactions with the smart contracts.
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:
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.
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.
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”.
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;
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 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.
Parameter | Description |
---|---|
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.
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.
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 (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”.
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.
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 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.
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
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.
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:
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”.
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.
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.
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.
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”.
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:
(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:
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;
at with the ID QmTi7Z7YoUpzYqwGytPuKYu2FuYPEhtPTsXti5dRxn8wHR
at with the ID QmZPs5CFi5vpZW73DmwF5VMzt5CYvFX7vD9Ez9gkZteuRd
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.
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”
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.
Please vote to accept or reject the proposed actions detailed above. As per the existing DAO governance structure last updated in PIP-7, 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 a more human-readable form in raw Markdown format on IPFS.
It is proposed to use the following new smart contract on the Ethereum Mainnet:
All other contracts remain as documented in previous proposals.
StakeRewardAdviser
replacementThe previous StakeRewardAdviser
, which is tightly coupled with the buggy RewardPool
contract, will be replaced by calling the removeRewardAdviser
function of the existing RewardMaster
contract, followed by addRewardAdviser
to configure its replacement.
This replacement only needs to be done for the unstake
action, not for stake
, since the classic staking program already closed for new stakes.
StakeRewardController2
This contract returns modified advice with zero shares of the reward pool, effectively bypassing the need for RewardMaster
to attempt to invoke the buggy RewardPool
contract to redeem shares.
vestingPools::addVestingPools([wallet], [poolParams])
will be called on the existing VestingPools
contract on the Ethereum Mainnet, where:
wallet
is the address of the DAO multi-sig address on Ethereum (0x505796f5Bc290269D2522cf19135aD7Aa60dfd77).
Final poolParams
will be:
This will result in a poolId
of 15 (since 0--12 were created during TGE, and 13 and 14 in previous proposals).
This new pool is required in order to cover the total rewards which were earned via Mainnet classic staking but have not yet been claimed.
The newly minted reward tokens will be immediately released into the StakeRewardController2
contract. In order to protect against any further mishaps, this contract has a rescueErc20
method which would allow the DAO to recover any funds accidentally locked in that contract. It is certainly expected that this emergency rescue mechanism will never be needed as a result of further bugs; however to provide extra assurance to stakers with unclaimed rewards, the contract has been configured so that this mechanism cannot be used prior to 2022-08-15T00:00:00.000Z.
Contract | Address |
---|---|
StakeRewardController2
0x1B316635a9Ed279995c78e5a630e13aaD7C0086b
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 the staking program defined by LaunchDAO, which launched the Panther Protocol and its smart contracts (including Staking
) and was approved by 95.16% of voters. 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 staking app.
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.
The recent completion of Panther’s Classic Staking program on the Ethereum Mainnet was followed by the discovery of an unfortunate bug where the RewardPool
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 RewardMaster
contract because of this.
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.
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 Panther's "Classic" staking solution, and/or had staked $ZKP delegated to you.
As per the existing DAO governance structure, voting power is calculated by snapshot.org taking a snapshot of the total number of ZKP tokens staked (and/or received via delegation) on both Ethereum and Polygon at the time when the proposal was created.
The 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.
Also on Mainnet, replace the existing StakeRewardAdviser
contract for the unstake
action with a new StakeRewardController2
contract, which bypasses the buggy code in RewardPool
, distributes fairly accrued rewards to existing stakers as specified by the previously approved terms of LaunchDAO proposal #3.
Release the full 3.556M $ZKP to the StakeRewardController2
contract, so that existing stakers can claim their rewards.
This proposal was accepted with 99.98% of the vote on May 9th, 2022.
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 . It does not promise any compensation for normal staking / unstaking transactions, or other interactions with the smart contracts.
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.
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 proposal describes a bug fix to the new staking program on Polygon, to ensure fair distribution of rewards in accordance with DAO proposal #3, which was previously approved by 98.74% of voters.
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.
The recent deployment of Panther’s staking program on the Polygon network was quickly followed by discovery of an unfortunate bug where the MaticRewardPool
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 DAO proposal #3, whereby rewards should vest linearly over 56 days. The bug unfairly denies all ZKP holders the opportunity they should have had to accrue rewards at any time during the 56 day period.
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.
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 Panther's "Traditional" staking solution, and/or had staked $ZKP delegated to you.
As per the existing DAO governance structure, voting power is calculated by Snapshot.org taking a Snapshot of the total number of ZKP tokens staked (and/or received via delegation) on both Ethereum and Polygon at the time when the proposal was created.
The Panther team proposes a solution rescuing existing rewards, and "upgrading" the existing contracts to correct the bug, with the following actions:
Disable the existing StakeRewardAdviser
contract for the unstake
action, to prepare for a corrective contract and to ensure that the previously approved terms of DAO proposal #3 are not violated.
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.
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 the previously approved terms of DAO proposal #3. There will be a period for the switchover from the old contract to the new one. It ends if / when the proposal is executed, at which point any stakes newly created during this period will lose their accrued rewards. This will not affect stakes created before the switchover period commenced.
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.
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 DAO launch proposal, which states:
"To protect, take corrective actions, and minimize the risks caused by smart contract bugs, etc. This proposal will allow a set of signers of the DAO multisig to have an overrule power."
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.
This proposal was accepted with 98.69% of the vote on March 16th, 2022.
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”.
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.
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.
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 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”.
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”.
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.
Get Started with Panther
Welcome to Panther Protocol, a Zero-Knowledge cross-protocol layer unlocking privacy-enabled DeFi.
Panther Protocol rewards dApp users that deposit and transact, and ecosystem operators that keep the Protocol moving:
Join the DAO and guide the future of Panther's multi-chain privacy-enhancing Protocol.
Panther Protocol applies a set of smart contracts on EVM-compatible blockchains. It is built with a modular architecture to support compliant transactions in Shielded Pools.
The technology relies heavily on cryptography to provide a privacy-enhanced mechanism to trade on public ledgers.
These documents are a comprehensive resource intended to help you learn everything you need to navigate the Panther ecosystem.
Either browse freely or follow this suggested learning path:
Sign up for a Panther account to earn
Stake $ZKP to earn and improve the privacy set
Become a zMiner to earn while processing transactions
Earn $ZKP for code optimizations
Join the community
Understand the zAccount and Zone Manager role
Understand the Shielded Pool and Multi-chain vision
Learn about the UTXO model
Learn about the Protocol's fees and rewards
Understand compliance strategies
Learn about the vision for decentralization
Learn about $ZKP
Learn about zBridges
Learn about DeFi adaptors
In our commitment to offering both privacy and transparency within our decentralized application, we introduce the Historical CSV Data Export feature. This functionality allows users to voluntarily export a comprehensive history of all transactions associated with their zAccount. Notably, these transactions are not linked to the public addresses of the dApp users, ensuring privacy is maintained.
Complete MASP Transaction History: Users can access a full record of their transactions, neatly compiled in a CSV file. This includes details of all activities conducted maintaining a transparent and traceable personal record.
User-Controlled Disclosure: This feature embodies our Protocol's core principle of voluntary disclosure. Users have complete control over the generation and sharing of their transaction history, empowering them to maintain privacy or provide transparency at their discretion.
Viewing Transaction History: Users can view/search their past transaction via the interface within the History tab. This action triggers the compilation of their transaction history.
Export: Users can click the export button and download transaction history in csv file.
Compliance and Reporting: For users requiring transaction history for compliance or reporting purposes, this feature provides a detailed and verifiable record without compromising privacy.
Personal Record Keeping: Users seeking to maintain personal records of their digital asset movements can utilize this feature for organized and accessible transaction history.
Note on Privacy and Security While the Historical CSV Data Export feature is designed to offer detailed transaction history, it is crucial to note that user privacy remains our paramount concern. All exported data is handled with strict privacy measures, ensuring that user identities and their association with public blockchain addresses remain confidential. Users are encouraged to safeguard their exported data with the same diligence they apply to their private keys and other sensitive information.
One key component that will help realize Panther’s vision of decentralized, privacy-preserving DeFi access is to develop plugins specific to existing protocols and connect them to Panther Pools (Panther’s private Multi-Asset Shielded Pools. This overall solution is referred to as DeFi Adaptors.
Each plugin enables zAssets to interact with DeFi protocols by passing relevant values and function types, resulting in a seamless transaction flow while maximizing the benefits of both protocols for the user. Thanks to this system, users gain access to Panther’s privacy-preserving features while integrating with DeFi services (such as atomic swaps, liquidity provisioning, and staking) without letting go of the underlying security of the blockchain networks Panther is deployed on.
Panther’s catalog of DeFi Adaptors will be ever-expanding to interact with a broad range of DeFi dApps and protocols. Each of these different interaction types will have a dedicated Adaptor, and, as you will see below, the DeFi Adaptor dedicated to swapping assets through DEXs is called zSwap.
Thanks to this system, users gain access to Panther’s zero-knowledge privacy without letting go of the underlying security of the blockchain networks Panther is deployed on.
DeFi Adaptors will debut on Polygon at the release of Panther’s testnet dApp.
Another critical feature of DeFi adaptors is their ability to integrate with Panther's Shielded Pools. Panther's Shielded Pools allow users to deposit (multiple types of) tokens and trade within the pool without being traced. Using Zero-Knowledge proofs and ZK SNARKs cryptography, DeFi Adaptors ensure that users' assets cannot be traced back to any particular user.
Adaptors enable users to break the on-chain link between their assets and DeFi activity. By facilitating private asset transactions and enhancing the zero-knowledge transaction flow towards widely used DeFi protocols, adaptors like zSwap help to ensure that users' sensitive financial information is kept secure.
Since transactions happen to and from Pools, with diverse users entering and withdrawing from them, transacting within them, and interacting with outside protocols (including swapping assets), an external observer finds it extremely challenging to surveil any user. This is demonstrated in the diagram below.
Some use cases of DeFi Adaptors include:
Swaps: DeFi Adaptors facilitate users accessing swaps and interacting with the decentralized finance ecosystem from Panther’s Shielded Pools. This enables users to securely and privately exchange assets while safeguarding their data privacy.
Liquidity provisioning: DeFi Adaptors allow users to contribute their zAssets to liquidity pools in decentralized exchanges (DEXs) or automated market makers (AMMs). This enables users to earn passive income through fees generated from trades without creating a link to their wallets and identity.
Staking: DeFi Adaptors can enable users to stake their zAssets in various decentralized platforms, such as proof-of-stake networks or yield farming protocols. This allows users to earn rewards or interest on their assets.
Cross-Chain compatibility: DeFi Adaptors can be designed to work across multiple blockchain platforms and systems, promoting cross-chain collaboration and enabling users to interact with a wide range of DeFi applications while preserving their privacy.
Seamless Integrations: DeFi Adaptors can be integrated into user-friendly wallets and platforms, ensuring that even users with limited technical knowledge can access the benefits of Shielded Pools while participating in the DeFi ecosystem.
Status | Entrypoint |
---|---|
In development on testnet
zSwap uses advanced algorithms to identify the optimal routing path for the trade execution while allowing the user to choose other sub-optimal options if that is their preference. It provides an optimized user experience by automatically defaulting to the platform with the least price impact based on the trade variables that the user is wishing to execute.
Additionally, zSwap displays a calculation of the difference between the best available opportunity and the rest of them in terms of the price impact of each DEX (e.g. a trade could feature a 2% impact in Curve as opposed to a 0.3% on in Uniswap). In the future, zSwap might be expanded to support more DEX integrations to allow further diversity of asset flow and access to deeper liquidity.
We are in the process of developing documentation that provides users with an overview of the $ZKP token design. This will help users better understand the features and functionalities of our token.
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 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.
Parameter | Description |
---|---|
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 .
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
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. |
The remaining part of rewards, which were allocated according to and used during two cycles of the Advanced Staking program.
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.
The following scenario may help you understand how zSwap works in a practical setting:
Alice wants to swap her ETH for USDC. As a privacy-conscious user, she already holds her ETH as zETH within Panther Protocol (ETH deposited into a Shielded Pool). This grants her access to the privacy-preserving functionalities of zSwap.
Alice connects her wallet to Panther and navigates to the Swap page on the Panther dApp’s interface.
Alice navigates to the left side of the UI and chooses the selling token and an amount based on her historical deposits (for example, zETH). She then chooses the receivable token (for example, zUSDC.
zSwap automatically calculates the exchange rate between the sellable and receivable asset (e.g. 1750 zUSDC per 1 zETH) according to real-time market data from DEXs.
zSwap will automatically display the best swapping route identified and the details of the swap. Alice can choose to expand the list of DEX routing options to compare the costs of using a different DEX and select it if she decides to do so.
After Alice finds a preferred option among all the DEX options available, she executes the transaction by pressing the Swap button.
The DeFi Adaptor generates a unique hashed time-locked contract (HTLC) for this atomic swap.
During the swap process, Panther user reveals their secret keys within the predefined time limit, allowing the DeFi Adaptor to execute the atomic swap. This process preserves her privacy, as Panther’s user identity and transaction details remain shielded within the Pool.
Once her transaction goes through, the newly deposited asset (in our example, USDC) is delivered to Alice as a zUSDC. Alice also gets rewarded for conducting a transaction on zSwap through Privacy Reward Points (PRPs), which reward users for increasing the anonymity rate of the Panther ecosystem. Should there be an issue that causes the transaction to fail at any step of the way, Alice’s asset balance would remain unchanged.
Panther deployed LaunchDAO, a system allowing every user who completed Know-Your-Customer identity verification for the Public and Private token sales to issue a zero-knowledge proof anonymously verifying their participation. Using this proof, individually-verified users were able to use a zero-knowledge system to vote on whether to launch the Protocol on the Ethereum and Polygon blockchains.
Thanks to this first-of-its-kind zero-knowledge, decentralized launch, Panther has been fully decentralized from Day 1. The Protocol achieved this while generating primitives useful across the blockchain industry for private voting and decentralized launching.
If you want to learn more about LaunchDAO, you can see the original how-to guides, smart contracts, and proposals at the LaunchDAO historical archive below.
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.
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.
Per proposal #3, to participate in voting, users need to have staked $ZKP in Panther's staking smart contract on the Ethereum Mainnet or Polygon.
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.
The contents of this proposal are identical to those presented in Section #3 of PIP-6, 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.
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.
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.
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
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 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.
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 .
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”.
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.