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.
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 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.
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.