These Operator roles are vital to Panther Protocol’s proposition:

• Compliance Providers

• Oshiya Operator

• Relayer

• Zone Manager

Compliance Providers

Compliance Providers are dedicated service providers who ensure that the Zone Manager's KYC/KYT/KYB (know your customer, trade, and business) requirements are met by zAccount holders.

Learn more about Compliance Providers

Oshiya Operators

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 in the queue to the trees, creates a SNARK proof that proves the correctness of the updates, and submits these updates to be written on-chain together with the proof to Panther smart contracts.

Get started as an Oshiya Operator.

Relayers

Within Panther, Ecosystem Operators sign transactions and pass them to the queue to be mined by Oshiya Operators. This adds to the privacy set.

Learn more about Relayers.

Zone Managers

Within Panther, VASP-licensed operators set up Zones to enable entry into Panther’s Shielded Pool according to the regulatory requirements they configure.

Learn more about Zone Managers

Are you a VASP-licensed operator interested in customizing your own regulated trading Zone for privacy-enhanced trading? Reach out to us at contact@pantherprotocol.io.

TL;DR

• In return for a fee, Relayers will 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

Introduction

Panther Relayers are specialist Operators providing a relaying and bundling service that runs 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.

Supported transactions

As of testnet stage 6, Relayers support:

• Account activation

• Account renewal

• Claiming PRP voucher

• Deposit

• Internal transfer

• PRP to ZKP exchange

• Withdrawal

This same feature set is intended for mainnet beta release

Overview

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.

Note, PayMaster does this at intervals, not per bundle, to reduce fees.

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 is required to pay tx costs in testnet up to Stage 5.

The zMiner fee pays the Ecosystem Operator that computes how to mine the transactions on-chain.

Rewards

The gas fee charged by the Relayers includes their fee.

Service providers

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.

TL;DR

• A testnet version of the Oshiya mining service is live

• Earn rewards for Protocol mining

Introduction

The testnet Panther Protocol dApp is supported by testnet Oshiya node Operators, known as zMiners. Anyone can run Oshiya and earn rewards for contributing to the Protocol.

Prerequisites

• Ethereum-compatible EOA (externally-owned account, i.e. wallet)

MetaMask is recommended

• Spare CPU

Get started

Option A: Docker image

Follow the Get Started instructions in Docker.

Option B: dApp

The interface provides:

1. The interval field. zMiners may adjust the cycle length by updating this variable.

2. Private key refers to the EAO to which rewards will be sent. Either enter the Ethereum account address or use the Connect MetaMask button.

3. RPC endpoint.

During testnet, users may enter any viable Mumbai RPC endpoint available from Chainlist.

1. Start/Stop mining.

Note that the current session will complete and Oshiya will terminate on Stop.

1. Mining attempt outcomes.

Gotchas

• 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. Should tech-savvy operators make their own optimizations, zMining via the app may eventually become unviable.

What next?

• Understand more about the responsibility of the Oshiya module

• For more information, see the original Stage 0 Get Started page

TL;DR

• Oshiya Operators are Protocol Miners, named zMiners

In the proposed 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

Introduction

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:

Rewards

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.

Guaranteed reward

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.

Premium payment

The premium depends on the queue’s age. 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.

Oshiya dApp

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.

Core features

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

User benefits

• 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, in the Multi-chain vision, 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.

Future potential

The Protocol can also support a tip from the transaction initiator; however, this feature will not be included in testnet or mainnet beta versions.

What next?

The codebase for Oshiya is open for community involvement. We encourage developers and blockchain enthusiasts to contribute towards optimizing and enhancing Panther Protocol’s mining feature — ensuring it stays at the forefront of blockchain technology.

TL;DR

• Vasp-licensed operators may

• Zone Managers will:

  • Determine for access to a

  • Set KYT/transactional requirements

  • Allowlist trading Zones and may allowlist users

  • Set transaction limits: daily limits, maximum deposit amounts, withdrawal amounts

  • Are the liaison for regulatory authorities

Introduction

Zone Managers are responsible for managing , setting rules for who can join their Zone, and what activities these users can engage in.

Zones are logical partitions of liquidity within , each of which is configured to regulatory requirements by a Zone Manager. Zone Managers can determine what KYC information their Zones require from users, and control the integration of specific into their Zones to fit their specific goals, and set KYT restrictions for the compliance provider to enforce.

Zone Managers set the Zone for users: they determine the types of verifications these users undergo and other factors related to Zones, such as what Zones users may trade with, users’ transaction limits, etc. As such, Zones Managers define what .

This allows the Zone Manager to determine what constitutes KYC, whether that be providing an email address or an in-person yearly verification, and what constitutes KYT.

Regulatory compliance

By determining what compliance rules their Zone adheres to, Zone Managers can allow users from different geographies to enjoy privacy-enhanced trading while adhering to regulators' strictures. Should a regulator wish to make inquiries, they have a VASP-registered entity to work with despite the Protocol being decentralized.

Working together with trusted stakeholders, Zone Managers can:

• Extract day-to-day transaction data

TL;DR

• 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/B

  • KYT

  • Data Escrow

i.e. the same service provider may provide all 3 services, or the Zone Manager may engage 2 or 3 providers.

KYC/B

Most regulators worldwide will require Know Your Customer / Know Your Business data. The Zone Manager will work with KYC service providers to collect the relevant data according to their Zone’s compliance requirements.

KYC verification is conducted when the user registers their Externally Owned Account (EOA), i.e. wallet. On success, the Compliance provider attests to the compliant status of that EOA holder at account activation and will fail once the attestation expires.

KYT

Most regulators worldwide will require Know Your Trade data. The Zone Manager will work with KYT service providers to collect the relevant data according to their Zone’s compliance requirements.

KYT verification is required at each deposit and withdrawal to ensure that the trade complies with the Zone Manager’s regulatory demands.

Data Escrow

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.