Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
These Operator roles are vital to Panther Protocol:
Within Panther, zMiners run an Oshiya node — 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.
Get started as an Oshiya Operator
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:
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 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
Panther Relayers are specialist Operators 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:
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
The Relayer service leverages features introduced by the ERC-4337 standard such as tx (transaction) bundling and account abstraction.
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 zMiner fee pays the Ecosystem Operator that computes how to mine the transactions on-chain.
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.
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
Zone Manager Get Started
Entry-point | Current version | Status |
---|---|---|
Are you a VASP-licensed operator interested in customizing your own trading Zone for privacy-enhanced trading? Reach out to us at .
🚧 Migration to Sepolia testnet
ditto
ditto
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.
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.
Relayer Get Started
Interested in contributing to privacy-enhanced trading by providing a Relayer service? Reach out to us at contact@pantherprotocol.io.
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: