TL;DR

• A showcase dApp demonstrating what trading in a regulated Zone could look like

• Text instructions and video How-tos are available

Testnet

The testnet dApp is open to community testers. To help test, use the entrypoint link above.

Thank you so much for being part of the self-custody data revolution!

How-tos

Tryout a dApp access to Panther Protocol

TL; didn’t watch

1. Connect your MetaMask wallet.

2. Change the network to Amoy testnet.

3. Click on Complete onboarding and complete your dummy KYC.

4. You will need some test MATIC.

Note that faucets require the wallet to hold MATIC 0.001 to release test MATIC.

1. Activate your Panther account.

2. Go to the zAssets tab, and deposit some test tokens.

3. Go to Withdraw and withdraw some test tokens.

4. Send test tokens to other Panther zAddresses (make a 2nd account for transfers if needed; this is allowed in the testing phase).

Please note: test tokens have no value; testors have no claim in relation to tokens stored or transmitted on testnet.

Testnet stage announcements

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.

dApp deployment

The intention is for the testnet dApp Stages 0-7 to be deployed on Polygon’s testnet, Amoy.

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.

Note: As the protocol developer, Panther Ventures Limited is resuming the testnet after re-deployment on Amoy. Panther Protocol Foundation is finalizing the details of the reward mechanism and will ensure that testers are rewarded proportionally to their efforts and we expect all incentives will be distributed via airdrop. This blog will be updated with more specifics in the coming days. Disclaimer For the avoidance of doubt, tZKP, tzZKP, tPRP, test MATIC, and any other tokens mentioned in this announcement or within the product are for testing purposes only and have no economic value, nor can they be exchanged for value. Participation on our incentivized Testnet versions may result in you earning rewards, but such credits are not represented on any blockchain as tokens.

What next?

Learn more about the various testnet stages in the changelog.

Panther’s proposed decentralized, disruptive approach to data privacy and compliance offers a significant leap forward for several industries. While Zone Managers will primarily deal with token transactions, the system’s core underlying components are applicable to many other fields where privacy, auditability, and tracking are critical to providing value.

Some of the initial use cases for Panther will include:

• Zero-Knowledge (ZK) accounts: Users who fit the Zone Manager’s profile, can deposit multiple types of tokens into Panther’s , where they can hold their assets confidentially while retaining the ability to showcase their balance and transaction history to selected recipients. Combining with an approach based on and decentralizing access to compliance, Panther will facilitate pioneering privacy-preserving access to DeFi while enabling . Its vision gives users more control over who views their data while enabling Zone Managers and users to comply with regulations.

• Privacy-preserving transactions: Within the , 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 cryptoeconomy 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: Panther Protocol will enable users to privately interact with the most popular DeFi dApps and protocols (such as NFT marketplaces, lending/borrowing markets, or DEXs) directly from Panther by using . 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.

Builders

Web3 builders, licensed Zone Managers, and developers will be able to 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 will be open-source, anyone can adapt and build upon existing tools to create their own infrastructure that benefits from Panther.

Developers will also be able to 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 compliance-enabling 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 will be empowered to differentiate their applications from the competition and provide greater user value.

Licensed Zone Managers

Panther Protocol proposes a modular solution to empower VASP-licensed entities to operate regulatory-aligned trading Zones on behalf of their user base. Zone managers may be interested in serving the following potential users:

Financial institutions and enterprises

Panther Protocol is developing a tech stack that institutions can leverage in many ways. Institutions can benefit from:

• Permissioned environments: VASP-licensed institutions can become and allowlist users (either from the general public or closed groups) for maximum compliance alignment. This allows institutional traders and their clients to trade without interacting with Panther’s larger user set while benefiting from the privacy-enhancing capabilities of the Shielded Pool.

• OTC Desks: Panther’s proposed will function as an OTC desk for institutions.

• On-chain compliance support: Zone Managers set rules for their Zone and integrate , such as KYC, KYT, and KYB support, to onboard their user base.

Retail users and Web3 natives

The Protocol will also allow Zone Managers to serve a broad retail userbase:

Web3 natives

Web3 natives are attracted to the principles of self-governance and decentralization. They are often particularly wary of surveillance, corporate data mining, and other forms of digital control.

Web3 natives who are interested in maintaining their privacy and security in the digital age can benefit from Panther Protocol in several ways:

• Compliance: Panther aims to create a path for users to access DeFi compliantly, meeting the regulatory requirements of their locales.

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

DeFi yield seekers

Zone Managers can support users interested in pursuing yields across the DeFi ecosystem in several ways:

Data protection: Panther will allow 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 positions.

Cross-chain functionalities: Panther is designed as 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 attractive opportunities.

Zero-Knowledge attestations: Panther’s ZK attestations of truth will 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 decentralized principles, on-chain data privacy, cross-chain functionality, and access to ZK attestations, can all benefit users interested in pursuing high yields across the DeFi ecosystem.

Power-users

With Panther Protocol, Zone Managers are able to support power crypto users: those who manage large sums of assets while preserving their privacy. These users can benefit from secure and shielded transactions, encrypted data storage, and privacy-preserving identity management that Panther’s proposed Protocol can provide:

Zero-knowledge transactions: Users will be able to preserve their confidentiality and prevent others from accessing sensitive information about their dealings or identity.

Privacy-preserving identity management: Panther Protocol will allow users to create private and secure identities that can be used for different services within the Panther ecosystem. This will help protect the user’s personal information and identity from unauthorized access or misuse.

❓ What is Panther?

Panther Protocol proposes a cross-protocol layer using Zero-Knowledge technology to build DeFi solutions that meet customizable regulatory requirements and satisfy users' on-chain data privacy needs.

Panther Protocol’s proposal is to provide a modular, decentralized architecture that enables Zone Managers to simplify the creation of regulated trading Zones that support seamless, privacy-enhanced access to DeFi and create a cross-chain-supported architecture to serve different use cases.

As per the Roadmap, Panther is testing the Protocol on testnet.

Panther’s proposition is unique as each Zone in the Shielded Pool benefits from the privacy set provided by activity across all Zones, irrespective of whether these Zones are allowed to trade with each other.

🛠️ How does Panther work?

Zone Managers will determine the conditions for user entry into their Zone and assign compliance providers to ensure compliance with the conditions they set.

Users will create zAccounts via the Zone Manager’s dApp instance to access Panther’s Shielded Pool. Supported cryptoassets will be deposited and secured in a Vault smart contract, and the equivalent zAsset printed. zAssets are 1:1 collateralized "shielded" versions of the original token to be utilized within the Panther dApp. Following the Multi-chain vision, Shielded Pools will exist on different chains (EVM-compatible in the first version), interconnected by zBridges.

Together with Zones and zAccounts, zAssets will offer privacy-enhanced transfers within a regulatory-enabled environment, whether users send, swap, or receive them.

Sophisticated trading mechanisms will be supported, such as internal OTC trades which utilize an atomic swap mechanism called zTrade. Panther users will also be able to 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:

🤔 Selective disclosures

Since Zero-Knowledge proofs underpin Panther’s proposed privacy features, users will be able to disclose their transaction history to anyone at will. Additionally, an MPC-based Data Safe mechanism will store basic details about transactions.

Panther proposes ZK- and non-ZK Reveals. By interacting with a Compliance Provider, users can access Zero-Knowledge attestations of truth for any statement, such as their identity, total balance, transaction history, etc. Panther’s proposed reveals are flexible — supporting any protocol requiring trust attestations and enabling trust schemes in DeFi.

Welcome to Panther Protocol: a proposal for a Zero-Knowledge cross-chain layer supporting regulated Zones for privacy-enabled DeFi.

What do you want to do today?

Panther Protocol for Zone Managers

Panther Protocol provides a vision of a fully-decentralized, multi-chain privacy-enhancing Protocol enabling VASP-registered entities to create and customize regulated trading environments.

Govern and Operate

Panther Protocol's development will become the responsibility of Panther DAO and is strengthened by its community and Ecosystem Operators.

Learn

Panther Protocol will apply a set of smart contracts on EVM-compatible blockchains. Its modular architecture design will 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:

Disclaimers

While this software is in development, the active present voice is used to communicate future intentions, not the current state of functionality.

The publisher of this work, Panther Ventures Limited, is a Web3 software development company and is not authorized to provide financial or distributed ledger technology services.

TL;DR

• zAccounts function as private ledgers for users

• zAccounts belong to a Zone managed by a Zone Manager

• zAccounts don't hold PII (Personally Identifiable Information) such as name, dob, etc.

Introduction

The zAccount is the end user's entrypoint to a Zone, and, thereby, to a Shielded Pool. A zAccount associates a user’s EOA (Externally Owned Account, i.e. a wallet) with their KYC attestation, as required by the Zone Manager.

The core functionality of the zAccount will be to delink the user’s transactions from their publicly-observable EOA. Additionally, it will let users prove their trades and balance in a privacy-enabled manner, and withdraw their assets back to a publicly owned wallet.

zAccounts and privacy

When a user successfully passes KYC and activates their zAccount, the account Id will be made available from a public lookup table maintained by the Panther Smart Contract. This table will allow anyone to access the zAccount Id to find its two root public keys. These keys are required to spend and access zAssets. The critical outcome of the Protocol’s design is that EOAs/wallet address won’t be linked to trades within, or outwith the Protocol when using a DeFi adaptor.

zAccounts and compliance

The Protocol is designed to allow the Zone Manager to define compliance, which is enforced as a compliance attestation required to validate a zAccount. This will enable Zone Managers to support decentralized identities and assign third-party KYC providers. Users can establish a Zero-Knowledge or zAccount following successful verification.

The Protocol can verify the completion and nature of the user’s verification without processing any personal data — while empowering the end user with tailored information sharing. It will employ 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 will be consolidated under a singular ledger, or zAccount.

zAccount architecture

zAccounts are crafted using a specific type of unspent transaction output (UTXO) within the Merkle Tree structure of UTXOs. Each zAccount UTXO will encapsulate critical user-specific details, including the zAccount’s unique identifier, asset balances, Zone ID, and more.

The Shielded Pool will assign every zAsset, represented by a UTXO 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.

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 — strengthening the system’s privacy while offering greater flexibility to disclosure schemes.

What next?

• Deep dive into Panther Protocol’s UTXO model

• Learn more about Panther Protocol keys

TL;DR

• determine what compliance looks like for their Zone/s

• The Protocol is agnostic as to which third-party integrates

• The Protocol does not process user data; compliance providers do

• Transactional data can only be accessed by stakeholders with the correct keys

Introduction

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 integrations, Panther , and .

By leveraging the Protocol’s Zero-Knowledge characteristics, these elements collectively form a pathway to achieve compliance.

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 allow users to choose from a variety of compliance providers while retaining a decentralized approach.

When integrating these providers, the following requirements are taken into consideration:

• Ability to blocklist Politically Exposed Persons (PEPs) or newly-flagged individuals based on unverified identities

• Blocklists for Externally Owned Accounts (EOAs), i.e. wallets

• Ability to create an “allowlist” to control entry to a Zone

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

Panther Protocol allows compliance providers to process user data without the Protocol learning it: by proving a user’s ownership of their wallet and giving them a Zero-Knowledge proof that attests to the validity of their KYC statements. This allows users to access Panther but maintains the Protocol’s neutrality. The diagram below exemplifies this process:

What next?

Not only do the compliance providers enable Zone Managers and users to demonstrate their transactional activity to regulators, but they also give the individual zAccount holder, the user, a high degree of control over what data they reveal to whom. Learn more about user reveals.

TL;DR

• zAssets represent digital assets as UTXOs

• ZK proof of UTXO activity will be written on-chain

• This mechanism enables privacy-enhanced trading

Introduction

zAssets enable 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 will essentially convert their regular tokens or assets into zAssets, to be managed within Panther’s layer.

Deposit

When a user deposits a digital asset into the Panther Vault via their Zone Manager’s access point, a UTXO (Unspent Transaction Output) is generated to represent that asset — the zAsset.

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.

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 be publicly available should a Panther account address become known to an observer.

Withdraw

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

Transfer

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.

zAssets enhance privacy

The observable data that results from a transaction 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.

Which asset classes are supported?

Panther’s Shielded Pools support the following asset classes:

• ERC-20 (including some variants like ERC-404)

• ERC-721

• ERC-1155

DAO-approved assets

The Panther DAO must approve assets for allowlisting; since allowlisting an asset requires manual configuration.

What next?

TL;DR

• Each transaction results in an encrypted stored on-chain

Similarly, to support , each transaction results in an encrypted “message to data escrow”

• Account holders can choose what of this, and their KYC data, they reveal and to whom

• Account holders may provide ZK proofs rather than the raw data

Introduction

When users transact from a zAccount, they create an encrypted “message to self” to be stored on-chain — accessible with their private key. In this way, basic details of the transaction event, such as the asset type and value and when ownership was relinquished, are retained. The account holder, however, can’t reveal anything about the recipient of a transaction, other than the zAccount’s Id.

Account holders may then select what transaction and KYC data they reveal and to whom.

Selective reveals

Panther Protocol uses Zero-Knowledge, to give users more control over their data. 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.

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 don’t learn the underlying information; only that the proofs are valid and the users’ claims are true. Also, the who issued the attestations never learn when or how users use those attestations when interacting with Service Providers.

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

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.

Zone Manager’s will allow users who satisfy their compliance requirements to open a zAccount to non-interactively:

• deposit

• withdraw

• transfer

• trade

with zAssets in Panther Protocol’s Shielded Pool.

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

• The Shielded Pool supports the non-interactive trades of zAssets: shielding external wallet addresses

• Panther’s Shielded Pool may be deployed to different L1 or L2 chains

• Access to a Shielded Pool is granted via a zAccount created via the Zone Manager's entrypoint/dApp within a dedicated Zone

Introduction

Panther Protocol’s Shielded Pool underpins the Protocol’s vision for compliant, privacy-enhanced trading. The Shielded Pool is partitioned into Zones: logical partitions of liquidity with their own entry requirements.

The Shielded Pool supports multiple asset types, i.e., it’s a Multi-Asset Shielded Pool (MASP). The 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.

The transactions within these pools are not observable on-chain, and users will have the flexibility to disclose information selectively, thus enabling a pathway to compliance.

Users within Zones will be able to:

• 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

Shielded Pool Zones

Panther Zones are dedicated areas within the Shielded Pool that enable users to trade with allowlisted assets and known counterparties. Every Zone will be managed and configured by a licensed entity known as a Zone Manager, and users must undergo verification with a KYC provider.

Each Zone in the Shielded Pool will support compliance in a fully agnostic manner, i.e. compliance is defined by the VASP-licensed Zone Manager.

The following diagram highlights how the Shielded Pool will allow an end user, the zAccount holder of Zone A in this instance, to transact in this privacy-enhanced Protocol.

Notice that the Shielded Pool will be able to support multiple Zones, here as Zone A and Zone B. This allows Zones A and Zone B to have different:

• Entry requirements

such as different supported geographical regions for end user residence.

• Transaction limits

Such as daily limits, maximum deposit amounts, and withdrawal amounts)

• KYT/transactional requirements

• Theoretically, even different supported assets

Not for mainnet beta release

Zone Managers will also be able to configure which Zones the user may trade with. For example, Zone A may allow its users to trade with Zone B and vice versa, but Zone B may not allow its users to trade with Zone C.

Furthermore, while the 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 is designed to require the attestation from a provider that’s registered in the Protocol; it doesn’t require insight into which provider is making that KYC attestation.

Multi-chain Shielded Pools

While the mainnet beta release of Panther Protocol will be deployed to Polygon, the Protocol itself supports a multi-chain strategy.

Shielded Pools on multiple blockchains will further strengthen the ecosystem and diversify 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, and increases connectivity.

Shielded Pools across multiple chains will share the same anonymity set, irrespective of the chain that trades occur on. An external observer can’t pinpoint which chain a zAsset was created on. This shared anonymity is unique to Panther’s proposed Protocol.

Shielded Pool architecture

A Shielded Pool is a set of smart contracts where users will be able to 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.

What next?

• 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

TL;DR

• Each transaction results in an encrypted “message to data escrow”

• The message is secured with an "ephemeral key", i.e. a unique key is created for every transaction

• Only with the alignment of the stakeholders who hold cryptographic keys can the message be unpacked and the data revealed

Introduction

The Forensic Data Escrow (FDE) mechanism supports one-off/ad-hoc inquiries. This is in contrast to the data a Zone Manager may extract for ongoing/routine compliance procedures that are part of every transaction — the latter are supported by different mechanisms implemented in the protocol.

The routine Protocols are wip.

The FDE retains an encrypted record containing private data of a particular transaction in a Shielded Pool. This mechanism does not require any spending keys, i.e., it can be used to deanonymize data but not to spend funds.

The Protocol prepares, verifies, and publishes a transaction record for every transaction. Decrypted FDE records provide transaction data such as:

• Which zAccounts received funds

• Which Zones the funds originate from and and were spent in

• Whether the UTXO/s created by the investigated transaction have already been spent

• Which transaction(s) initially created the queried UTXOs

Stakeholders

The FDE Operator’s key must be used to access FDE records. Either the Network FDE Assistant or the Zone FDE Assistant must comply to use this key.

Network FDE assistant

The Network FDE assistant (or the Zone FDE Assistant) role controls the FDE record key. This key is required to decrypt the FDE record; for a transaction in a specified Zone on a specified network and share this key with the FDE Operator.

FDE Operator

FDE Operator adds a layer of control over the Zone FDE Assistant’s key. The FDE Operator must comply and use their key to allow the Network FDE Assistant to decrypt a particular transaction on the designated network for the designated Zone.

The FDE Operator can’t open an FDE record with their Key alone (as they don’t control the FDE record key). Either the Network FDE Assistant or the Zone FDE Assistant should participate in the decryption process (providing the FDE record key).

On the other hand, neither the Network FDE Assistant nor the Zone FDE Assistant can decrypt any FDR without the FDE Operator (as they don't control the FDE Operator’s key).

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

Introduction

Panther Protocol aims to offer both privacy and transparency from the dApp. To this end, the Historical CSV Data Export feature 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, enhancing transactional privacy.

Key features

The CSV file provides a full record of the user’s transactions — maintaining a transparent and traceable personal record.

Furthermore, this feature supports voluntary disclosure. Users have granular control over the generation and sharing of their transaction history, giving them nuanced control over whether to maintain privacy or provide transparency according to the intended recipient of the data.

How it works

Using their encrypted on-chain data, users can generate audit files from within the dApp:

1. View Transaction History

Users can view/search their past transaction via the interface within the History tab within the dApp. This action triggers the compilation of their transaction history.

1. Export

Users can click the export button and download their transaction history as a CSV file.

Use cases

• 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, user privacy remains a 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.

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

Oshiya dApp

Core features

• 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?

zSwap

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

zSwap’s goal is to cater to a wide range of user types, including 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.

The ability for users to swap assets privately serves a double purpose:

1. Allowing users to trade between all allowlisted assets available using the platforms above.

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

Under the hood

• Alice connects her wallet to Panther and navigates to the Swap page on her Zone Manager’s dApp interface.

• Alice navigates to the left side of the UI and chooses the selling token and an amount based on her historical deposits (e.g. zETH). She then chooses the receivable token (e.g. 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.

• During the swap process, Alice reveals her 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 set of the Panther ecosystem. Should an issue cause the transaction to fail at any step of the way, Alice’s asset balance would remain unchanged.

TL;DR

• Fees can be categorized as:

  • Network fees

• Rewards are issued as Panther Reward Points (PRPs)

Introduction

Rewards are issued for all activities that contribute to the Protocol’s privacy set. With the exception of the withdrawal fee, Protocol fees are charged as a gas fee, 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.

Rewards

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 .

• Send

Transferring zAssets to another Panther .

• Stake

Fees

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.

Protocol fees

There are currently 4 Protocol fees:

• Relayer fee

• Processing fee

• Withdrawal fee

• KYC fee

Relayer fee

Processing fee

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

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

TL;DR

• Vasp-licensed operators may apply to become Zone Managers

• Zone Managers will:

  • Determine entry requirements for access to a zAccount

  • 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 Zones, setting rules for who can join their Zone, and what activities these users can engage in.

Zones are logical partitions of liquidity within Shielded Pools, 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 compliance vendors 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 compliance means for their Zone.

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:

• Supply forensic data held in Data Escrow

• Extract day-to-day transaction data

A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z

A

Appending

Within Panther Protocol, the term appending is used to describe the process of reading queued UTXOs from storage and creating a batch of up to 64 UTXOs.

B

Batch

Within Panther Protocol, the term batch is used to describe a group of up to 64 UTXOs.

C

Cryptocurrency

Cryptocurrency TL;DR

Digital asset using cryptography to secure transactions.

Cryptocurrency detail

Cryptocurrencies and cryptography are indissociable because the digital asset uses cryptography to secure transactions. With no centralilized authority regulating the system, it operates while nodes support it. Panther Protocol provides a privacy-enhanced trading service for users to trade digital assets such as cryptocurrencies.

Cryptographically secure

To be considered cryptographically secured, the result needs to be:

• Confidential — Not understood by anyone

• Unalterable by anyone, including the creator

• Non-repudiable: This means that the sender or creator cannot deny their intentions at later stages

• Able to be authenticated by all parties involved

D

Dummy

Within Panther Protocol, the term dummy is used to describe a placeholder UTXO used to fill up a queue to 64 UTXOs.

Decentralized

Decentralization, in simple terms, means dissolving central authority and giving the right of governance to the stakeholders involved in the system, giving full control back to the ordinary user. Panther Protocol is governed by a decentralized authority, the Panther DAO.

DeFi adaptors

Shielded Pools are connected to popular DeFi protocols through custom plugins called “DeFi Adaptors.” The first use case for Panther’s DeFi Adaptors, zSwap, allows users to execute swaps on the most liquid DEXs without publicly revealing their identity.

Diverse Pool Privacy (or “Why multiple assets?”)

By allowing users of multiple kinds of assets to enter the Pool (e.g., different token types supported within a given chain, such as ERC-20, non-fungible, and other standards of tokens), users of every compatible token can access the same privacy, regardless of the liquidity of their assets. While a single-asset Pool for rarely-used tokens would struggle to find much security due to the relatively low volume of transactions, MASPs can leverage popular assets to quickly build critical speed and provide much-needed privacy to the long tail of crypto assets.

The fact that different types of assets can co-exist in the same Pool is called Diverse Pool Privacy. Thanks to it, Pools can get large enough to preserve data heterogeneity, i.e. have so many transactions happening within them that it becomes challenging to track and deanonymize users.

E

ECDH

[Elliptic-curve Diffie–Hellman (ECDH)](https://en.wikipedia.org/wiki/Elliptic-curve_Diffie%E2%80%93Hellman#:~:text=Elliptic%2Dcurve%20Diffie%E2%80%93Hellman%20(,or%20to%20derive%20another%20key) is is a variant of the Diffie–Hellman protocol using elliptic-curve cryptography. ECDH provides a key agreement protocol that enables two parties to share secrets over insecure channels. This shared secret may be a key, or, as in the case of Panther Protocol, it can be used to derive a key. The key, or the derived key, is then used to decrypt/encrypt subsequent communications using a symmetrical key cipher.

Panther Protocol uses EDCH over the baby Jubjub elliptic curve.

F

Fully collateralized

Within the Panther Protocol, the zAsset is always backed by 1:1 of the underlying asset, i.e. fully collateralized. If you have 1 zBTC (privacy-enhanced BTC), that zBTC is always backed by an entire BTC within a Panther Vault.

G

H

Hash

Hash functions are used in data storage. Often, they convert variable input-sized data into fixed-sized values.

I

Inserting

Within Panther Protocol, inserting describes the process of adding a batch of up to 64 UTXOs to the Merkle Tree.

Interoperable

“Interoperable” means that Panther will provide DeFi users with privacy no matter what public blockchain is used by their DeFi application of choice. Panther can be perceived as a private hub that connects all public blockchains, creating a privacy pipe that creates one robust privacy-enabled environment.

J

K

Keys

Keys are used to decrypt cryptographic secrets. Public keys are points on an elliptic curve, while private keys are scalars in the field. Thus keys are found in pairs, or keypairs.

L

M

MASPs

Within Panther, Multi-Asset Shielded Pools (MASPs) are sets of smart contracts where users can deposit various tokens. Within a pool, the transaction path of these tokens is safeguarded by Zero-Knowledge proofs (ZKPs). This renders the transactions within these pools untraceable while providing users with the flexibility to selectively disclose information, thus enabling a pathway to compliance.

Merkle tree

A Merkle tree is a hash-based data structure stored in a tree-like structure. Hashes may encode files that are much smaller than the original data file. Each leaf node of the tree is a hash of a block of data, and each non-leaf node is a hash of its children.

Merkle trees are useful in distributed systems as they provide an efficient data verification mechanism. They are popular in peer-to-peer networks such as Bitcoin and Git. Panther uses Merkle trees in its MASP.

N

O

Oshiya

Oshiya TL;DR

Ecosystem operators known as zMiners earn rewards by running an Oshiya node to collect and process Shielded Pool transactions.

Oshiya detail

Panther’s Oshiya selects a batch of pending transactions represented by UTXOs from the mining queue on the Bus tree and creates a SNARK-proof that proves the correctness of Merkle tree updates it proposes, and submits these updates to be written on-chain together with the proof to the smart contract. Finally, Oshiya validates this proof by calling a verifier contract and updates the root Merkle Tree of the Panther contract.

Oshiya’s use of SNARKs provides operational efficiency by enabling up to 64 transactions to be committed to one proof.

P

Panther Protocol

Panther Protocol TL;DR

Panther is a cross-protocol app layer that uses Zero-Knowledge technology to build DeFi solutions that meet regulatory requirements and satisfy users’ on-chain data privacy needs.

Privacy Enhancing Technology

PET TL;DR

A Privacy Encancing Technology, PET, improves the privacy layer. No two methods are equal in their impact.

Q

Queue

Within Panther Protocol, a queue is a group of UTXOs held in storage on-chain.

R

Relayers

Relayers TL;DR

Panther Relayers provide an (optional) privacy layer within Panther Protocol by breaking the link between the initiator of the transaction and the transaction itself.

Relayers detail

Panther Relayers are network operators who charge a fee for signing transactions with their public key, paying the transaction gas fees, and relaying bundles of transactions to the Shielded Pool contract where they are processed by zMiners. Relayers enhance privacy, since observers are unable to pinpoint the actual address that initiated the transaction.

S

Shielded Pool

Shielded Pool TL;DR

A proprietary Multi Asset Shielded Pool is core to Panther Protocol's private operating environment: allowing users to conduct (disclosable) confidential digital asset trades.

Shielded Pool detail

Shielded Pools are essentially a collection of append-only Merkle trees, where each leaf is a commitment to a UTXO representing a number of zAssets (or zNFTs).

Users trade UTXOs that represent the underlying locked asset. The UTXOs may only be traded within a Shielded Pool. The Shielded Pool acts like a walled garden: only invited users and assets may enter. Assets are deposited in the Panther vault in exchange for a zAsset.

Slippage

Slippage is the delta between the anticipated price of an order and the execution price.

Staking

Panther DAO has approved staking yield pre-mainnet beta launch to reward the growing community. DeFi Lama tracks Panther Protocol’s market capitalization and Advanced Staking TVL (total volume locked).

T

Transparency

Public blockchains require transparency to allow anyone, and most importantly node operators, to validate transactions without dependence on centralized intermediaries. This transparency, while advantageous in many respects, also necessitates a privacy solution. This is what Panther Protocol offers.

U

UTXO

UTXO, or Unspent Transaction Output, defines the outcome of a digital transaction or an on-chain state update, such as merging zAssets into one record. Bitcoin uses UTXOs, but the cryptocurrency is not itself a UTXO. Within Bitcoin, if Alice has a UTXO representing 5 BTC and wants to send Bob 2 BTC, the entire UTXO is unlocked and sent to Bob and Bob returns a UTXO to the value of 3 BTC.

Alternatively, Alice may own 2 UTXOs that, in total, represent 2 BTC and both of these will have their ownership transferred to Bob to complete the transaction.

Panther Protocol also leverages a UTXO model, but one that is quite unique to the use cases it solves for.

V

VASPs

VASPs are virtual asset service providers. In most states, entities like crypto exchanges must be licensed to provide VASP services. Within Panther, the Zone Manager must be a licensed VASP.

W

X

Y

Z

zAccount

Within Panther, zAccounts are akin to bank accounts that safeguard users’ on-chain data privacy and ownership. All transactions conducted by a given user are linked to the same zAccount. Panther developed this novel mechanism to support compliance, decentralized identity, and selective disclosures.

zAccounts are implemented using a particular type of UTXO inside the UTXOs Merkle Tree. Every zAccount UTXO contains important values at a user/account level, such as the zAccount’s ID, zAsset balances, PRP balance, ZoneID, etc.

zAsset

zAsset TL;DR

A zAsset, is a "mirror" asset that is printed when an asset is deposited and locked in the Panther contract. It’s subsequently spent when that asset is withdrawn.

zAsset detail

When an asset is deposited and locked in the Panther vault, a UTXO or zAsset is printed. In this way, the zAsset:asset always exists in a strict 1:1 ratio. Users can send, swap, receive, and pay with zAssets.

zBridges

Shielded Pools may be deployed onto multiple blockchains (L1s and L2s) to realize the Protocol’s vision of cross-chain Zero-Knowledge access to DeFi. The zBridges will connect these Pools on different blockchain networks, enabling privacy-enhanced cross-chain transactions.

zMiners

zMiners TL;DR

zMiners are ecosystem operators who earn rewards by running an Oshiya node.

zMiners details

zMiners are essential contributors to the transaction processing capabilities of Panther Protocol. They decentralize the responsibility of processing queues containing up to 64 UTXO commitments with a SNARK proof, enabling continual execution of transactions in Panther's Shielded Pools.

Zone manager

A licensed entity that configures a trading area by allowlisting assets and trusted counterparties.

Zero-Knowledge proofs (ZK-proofs) are cryptographic protocols that allow one party (the prover) to prove the truth of a statement to another party (the verifier) without revealing any additional information beyond the validity of the statement itself. In other words, a Zero-Knowledge proof demonstrates knowledge or possession of certain information without revealing the information itself. The key features of Zero-Knowledge proofs are:

• Completeness: If the statement is true, an honest prover can convince an honest verifier of its truth with overwhelming probability.

• Soundness: If the statement is false, no prover, even if malicious, can convince a verifier of its truth, except with negligible probability.

• Zero-Knowledge: The proof should not reveal any information beyond the statement's validity. Even after interacting with the prover and receiving the proof, the verifier should not gain additional knowledge about the underlying witness or secret information.

Despite being decades old, Zero-Knowledge proofs have only recently become practical for real-world use in finance. The implications of the technology are enormous: ZKPs can maintain blockchains’ accuracy and make scalability possible with ease and precision. Users can also know with complete clarity how their data is utilized, while only needing to share what’s absolutely necessary for a given transaction.

Zero-Knowledge proofs have various applications, including:

• Authentication and identification: Zero-Knowledge proofs can allow users to authenticate or identify themselves to a party without revealing any personally identifiable information.

• Privacy-Preserving transactions: Zero-Knowledge proofs can be used to prove the correctness of a transaction or computation without revealing the inputs or intermediate values involved.

• Secure Multi-Party Computation (MPC): Zero-Knowledge proofs can enable multiple parties to perform joint computations on their private inputs without revealing the inputs to each other.

• Blockchain and cryptocurrencies: Zero-Knowledge proofs are widely used in blockchain and cryptocurrency systems to enhance privacy, improve scalability, and verify the correctness of transactions without exposing sensitive information. Zero-Knowledge proofs provide potent tools for cryptographic protocols, allowing for secure and private interactions between parties while maintaining confidentiality and integrity. With ZKPs, users no longer need to re-execute every transaction in a ledger, as they can instead check a succinct proof.

TL;DR

• Spender encrypts a message to recipient that is published on-chain

• All zAccount holders scan the chain for UTXO commitments and attempt to read the message

• Only the intended recipient, the account holding the cryptographic key, may read the message and assume spend rights to a UTXO

Introduction

An essential requirement of Panther’s Shielded Pools is to ensure the untracability of transactions to stakeholders who do not hold the correct keys. To achieve this, the mainnet beta Protocol supports non-interactive transactions. That is, the spender can pass assets to the receiver's zAccount using the receiver’s public read key and the public root spending key available on a public lookup registry maintained by the smart contract.

Every zAsset UTXO has one “owner” or zAccount able to spend it. This is achieved by including a unique public (spending) key in the generation of the UTXO commitment, for which the corresponding private (spending) key is only known by the recipient.

In order to spend a UTXO the owner needs to prove (in Zero-Knowledge) that they hold the spending private key.

High-level overview of Panther's UTXO cryptography

The following conventions are applied to formulae:

• lowercase letters in formulae bellow denote prime field elements ("scalars") - i.e. private keys

• capital letters denote points on the elliptic curve - i.e. the public keys

• '*' denotes the multiplication of an elliptic curve point by a scalar, i.e. scalar multiplication

• The Protocol uses a shared symmetric key for encryption/decryption of messages with secrets

• Secrets. M are UTXO’s "opening values" for recipients and data for spenders to track past transactions

• Messages passed to the smart contract are encrypted:

  • spender to receiver

  • spender to self

• Sender publishes the Ephemeral key, E and ciphertext M' on-chain — formalizing a transaction

• Recipient scans chain to extract M (from M' using E) to take ownership of a UTXO

• Spender can re-create history by decrypting messages to self, M'

• Although spender knows the UTXO’s public key, only the recipient who holds the root spending private key may spend the UTXO

Next, let’s take a closer look at how the cryptography behind this Protocol is implemented.

Panther Protocol keys

A "key pair" is a pair composed of a private key and its corresponding public key.

The private key is a big integer ("scalar") from the prime field defined by the Baby Jubjub elliptic curve.

The public key, P corresponding to the private key, p is a point on the curve, such that the following equation holds:

P = p * G

Where, P and p are the public and private keys, and G is the generator of the group of elliptic curve points.

The so-called Base8 point is used as the generator. This point generates a "commutative group" of curve points that cryptographers call the "Baby Jubjub subgroup".

The ECDH key agreement protocol (over the Baby Jubjub elliptic curve) is used to share the symmetric key and to derive the spending keys of UTXOs.

The following key pairs are essential to the transfer of zAssets in the form of UTXO updates:

1. Recipient reading key pair (w, W = w * G): allows the recipient to decode messages with opening values of UTXOs, i.e. knowledge of the private key is needed to decrypt a message.

2. Root spending key pair (s, S = s * G): enables spending of a UTXO by the owner, i.e., no matter who generates a UTXO, only the holder of the private key may spend the UTXO.

The term "root" applies as spending keys for UTXOs are "derived" from this key pair.

1. Nullifier key (n, N = n * G): required in order to generate the nullifiers for UTXOs.

This key enables compliance, by encoding the nullifier so that information in the Data Safe may reveal whether the UTXO has been spent.

Next, let's consider how spending and encryption keys are derived.

Creating a new UTXO

When a zAsset is spent, an output, i.e. a new UTXO is created.

1. Spender selects two randoms, r and e, to derive the spending and message encryption keys.

2. Spender derives the spending public key S' for the new UTXO from the recipient's root spending public key S and the random r:

S' = r * S

1. Spender creates an ephemeral key using the random (e) from Step 1:

E = e * G

1. Spender creates the shared key, K to encrypt the message to the recipient with, based on the recipient’s public reading key, W and the random, e:

K = e * W

1. Spender composes the message to the recipient, M and encrypts the message into the ciphertext, M'.

5.1 Message composition. The message, M contains the information needed to spend the UTXO: random, r required for the recipient to generate the spending key, S' and other opening values (such as zAssetId and the value the UTXO represents).

5.2 Message encryption. The spender encrypts the message to the recipient with the shared key, K applying the symmetric encryption (applying the method AES-128-cbc): M' = Enc(M, K)

1. Spender calls the Shielded Pool contract to publish the new UTXO as well as the encrypted message to the recipient.

6.1 Publishes the ephemeral key, E and the ciphertext M'.

6.2 Using the same encryption key derivation method, but with own reading key instead of the recipient's reading key, the spender encrypts the message "to self". This encrypted message (which only the spender may decrypt) contains data required to reconstruct an audit trail of the spender's transactions.

Taking ownership of a UTXO

The following steps detail how a recipient is able to take ownership of the input UTXO.

1. Scan chain for ciphertexts

Each zAccount holder behaves as it is a potential recipient and scans the chain for ciphertexts, M' and ephemeral keys, E.

2. Attempt to decrypt every ciphertext

2.1 Compute the shared key, K

K = w * E

Note, if the spender encrypted the message with the recipient’s public reading key (i.e. the message is intended for the recipient), the recipient derives the same shared key that the spender used:

K = w * E = w * (e * G) = e * (w * G) = e * W

2.2 Decrypt the ciphertext using that key

M = Dec(M', K)

2.3 Analyze whether the decrypted message, M is meaningful

If an encrypted message (i.e. the ciphertext and the ephemeral key) was intended for a different recipient, and thus the non-recipient computed the wrong encryption key, the decryption algorithm still returns some random (meaningless) decrypted text. However, the true recipient can easily distinguish if the decrypted text, M contains properly formed or meaningless data.

So, IF M is invalid, message is ignored. IF M is valid, recipient extracts from M the random, r and other opening values required to spend the UTXO.

2.4 Derive the private spending key for the UTXO

The recipient derives the private spending key for the UTXO:

s' = r ∙ s here, '∙' denotes multiplication of integers (in the prime field).

Note, that the private spending key derived this way indeed corresponds to its public key that the spender derived:

S' = (r ∙ s) * G = r * (s * G) = r * S

This method provides an efficient encryption/decryption mechanism and a unique spending public key that is unlinkable to other transactions by the same recipient, even given that E is publicly accessible on-chain.

What next?

• Learn how UTXOs represent assets locked in the Panther vault, zAssets

• Understand how users enter a Shielded Pool to create a zAccount and transact with other account holders and the wider DeFi ecosystem

A hash function is a mathematical function that maps (or compresses) data of arbitrary size to fixed-size values, with the output sometimes called hash values, digests, or simply hashes. Given any input, it should be easy (or efficient) to compute the output. The number of possible output values is limited by the fixed output size, whereas the number of possible inputs is not restricted in the same way. Consequently, although the output is specific to the input, there will be many different inputs that map to the same output value.

The core properties of cryptographic hash functions are:

• Pre-image resistance (one way): Given a hash output, it should be difficult (computationally infeasible) to find any input that hashes to that given output.

• Collision resistance: It should be difficult to find two distinct messages m1 and m2 that hash to the same value. That is, where hash(m1) = hash(m2) for m1≠m2. Such a pair is called a collision. An algorithm-independent upper bound on the difficulty of finding collisions comes from the Birthday paradox, which implies that when searching for collisions by hashing random inputs, the expected number of trials before finding a collision is given by the square root of the number of possible outputs. That is, for collision resistance, the security level in bits is half that of the hash output bit length.

• Second pre-image resistance: For a given input, it should be difficult to find any second input that hashes to the same output. Note that collision resistance implies second pre-image resistance.

Documentation on hash functions is currently under construction, and we are actively working on providing users with a comprehensive overview of this technology.

UTXOs are a data storage model that is key to Panther’s Protocol.

Learn about:

• The UTXO model

• Encryption and decryption of UTXOs

Or return to a high-level abstraction of the UTXO and learn about zAssets.

Introduction

To realize the Protocol’s vision of cross-chain Zero-Knowledge access to DeFi, Shielded Pools may be deployed onto multiple blockchains (L1s and L2s). In this case, 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 envisioned by Panther and a key component of the cross-protocol Zero-Knowledge layer concept. They will 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.

Introduction

Panther’s Shielded Pool architecture includes the following Merkle trees:

• Bus processes UTXOs collectively by batching them

• Taxi processes UTXOs individually

• Ferry manages UTXO data in the multi-chain Panther ecosystem

In the dApp, users can choose between batched processing (taking the bus) and fast processing (taking the taxi) from the toggle available under the Fee section when submitting a transaction.

Bus tree

Within the “Bus” tree, each leaf is a commitment to:

• An “asset” UTXO representing a zAsset (or zNFTs) (essentially an “IOU” for the corresponding underlying collateral locked on the Panther Vault)

• “zAccount” UTXO, a record that keeps information about the owner of a zAccount

The name Bus Tree refers to the UTXOs being committed to the tree in batches of up to 64 UTXOs rather than individually. To get on the “bus”, a UTXO needs to be queued and wait until a zMiner processes that queue.

The “bus” approach makes the process more cost-efficient as all UTXOs in a queue share processing costs. As such, the individual cost for a transaction per user is much lower. On the other hand, users are dependent on the zMiner to process the queue. Just as users of a blockchain incentivize miners to pick up their transactions by defining how much they are willing to pay for “gas”, Panther Protocol users define the reward (denominated in $zZKP) that they are willing to pay to the zMiner who processes their UTXOs.

Taxi tree

Taxi tree has been released with Stage 5 of the testnet dApp.

To avoid "waiting for the bus," the Taxi tree allows UTXOs to be processed individually to enable near-instant spending. This removes the wait time required to process a batch, with an extra cost tradeoff.

Panther also utilizes , which stands for “Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge.” Thanks to ZK SNARKs, and just like with , a prover can prove their possession of information without revealing it. However, the added benefit of ZK SNARKs is that they allow this to happen without both parties interacting. This helps further users’ privacy and anonymity.

ZK SNARKs are:

• Succinct: The size of the proof is small compared to the size of the statement being proved.

• Non-interactive: ZK SNARKs do not require rounds of interaction between the prover and verifier except for a negligibly small probability.

• Argument: A weaker notion of a mathematical proof where we assume the prover has bounded computational resources.

• Knowledge: The prover cannot construct a proof without knowing a particular witness for the statement. This would be the equivalent of knowing “what to look for” or “what to decode”.

Specifically, Panther uses a pairing-based SNARK called .

Homomorphic encryption is a form of encryption that permits computations on encrypted data without the need to decrypt it. The output, when decrypted, is identical to that produced had the operations been performed on the unencrypted data. While there is a lack of practical schemes that deliver fully homomorphic encryption, there do exist practical schemes that exhibit some homomorphic capabilities. One example is RSA. Another is the discrete log-based systems, typically defined either modulo a prime p, or using . It is the latter that is the focus here.

There are two main types of homomorphic encryption: fully homomorphic encryption (FHE) and partially homomorphic encryption (PHE). FHE allows arbitrary computations to be performed on encrypted data, while PHE allows only certain types of computations to be performed, such as addition or multiplication using elliptic curves, with G being a generator of an elliptic curve group. The (homomorphic) operations that can be performed are:

• Addition: given points bG and cG, an expression of form a = b + c can be evaluated in encrypted form as aG = bG + cG.

• Scalar multiplication: given bG, an expression of the form, a = cb, where c is a constant, can be evaluated in encrypted form as aG = c(bG).

Groth16 is a well-known and widely-used pairing-based dating to 2016. Described by Jens Groth in the paper ”On the Size of Pairing-based Noninteractive Arguments,” it is one of the most widely used ZK SNARKs for ensuring privacy and confidentiality

As a ZK SNARK, Groth16 is Zero-Knowledge, which means that the protocol allows a prover to convince a verifier of the truthfulness of a statement without revealing any additional information about the underlying data. This, of course, is in addition to fulfilling the requisites of completeness and soundness.

Another noteworthy aspect of Groth16 is its succinctness. It enables the prover to generate a succinct proof attesting to the validity of a statement, while the verifier can efficiently verify the proof. The proofs generated using Groth16 are short and concise, requiring significantly less space to store and transmit. A proof contains only 3 group elements, and verification consists of checking a single equation's paring product using 3 pairings in total. This property is crucial for applications where proof size is a limiting factor, such as blockchain systems or privacy-preserving protocols.

The protocol is particularly designed for proving the knowledge of a witness about a statement that can be expressed as a polynomial equation over a finite field. The witness is a set of field elements that satisfy the polynomial equation, and the proof is a succinct representation of the witness that can be efficiently verified by the verifier. The witness also consists of algebraic relationships and computations in elliptic curve groups, such as statements about the satisfiability of equations involving pairing-based cryptography. In the latter case, the key idea behind Groth16 is to construct a proof system that leverages the bilinear pairing properties of elliptic curves to enable efficient verification of complex algebraic relations.

The protocol consists of three main steps: setup, proving, and verification.

1. Setup: In this step, the common parameters of the protocol are generated. This includes selecting an appropriate elliptic curve group, defining the bilinear pairing function, and establishing the necessary public parameters for the proof system.

2. Proving: The prover aims to demonstrate the truthfulness of a statement. They construct a succinct proof by following a set of computation rules specified by the proof system. The proof is typically generated by performing a series of mathematical transformations and computations on the input data ensuring that it remains valid and does not reveal any additional information.

3. Verification: The verifier’s role is to check the validity of the proof without learning anything beyond the truthfulness of the statement. The verifier uses the public parameters and the proof provided by the prover to perform a series of mathematical checks and computations. If the proof passes all the verification checks, the verifier accepts the proof and concludes that the statement is valid with a high probability. Like any other cryptographic system, it is not without limitations. One key consideration is the trusted setup phase, where a setup ceremony is required to generate the initial parameters used in the proof generation and verification. This setup process needs to be performed in a secure and trustworthy manner to prevent potential attacks or backdoors. As long as one of the participants in the trusted ceremony is honest, the setup can be considered secure.

Groth16 needs one setup for each circuit. The Groth16 protocol offers two other desirable properties for this kind of system: soundness (if the statement is false, the prover will not be able to convince the verifier) and succinctness (the proof is short and can be verified efficiently).

The Groth16 protocol has found applications in various domains, such as anonymous credentials, privacy-preserving cryptocurrencies, and decentralized finance (DeFi). In all of the latter, preserving privacy and proving correctness are crucial.

Documentation on Panther's cryptographic primitives is currently under construction.\

An elliptic curve is, in essence, simply the set of solutions (or points (x, y)) to an equation that can be represented in the form y^2 = x^3 + ax + b, where a and b, as well as points (x, y) that lie on the curve (that is, are solutions to the equation), belong to a finite field F_p defined by a prime p. That is, F_p is the set {0, 1, . . . , p − 1}, with addition and multiplication being modulo p.

Elliptic curves are of interest in cryptography because points can be added together, with the result also being a point on the curve. Furthermore, the set of points obtained by taking a point G (a generator) and adding it to itself repeatedly until reaching (or returning to) the starting point G, forms a group whose order (denoted here as q) is the number of points in the set. The relevance of this is that there is a class of asymmetric (or public key) cryptographic protocols known as the discrete log-based systems, and which include DSA and the Diffie-Hellman protocol, which are defined to work in a group. There are many different types of groups, but for cryptographic security, the so-called discrete log problem must be a complex problem to solve (for sufficiently large parameters). Two groups for which this problem is considered difficult are the group defined by the set of integers modulo a large prime p, and the group of points on an elliptic curve.

When used for cryptographic purposes, the order q is typically a large prime number and defines the scalar field of the curve.

Examples of elliptic curve groups include BN254 (the curve currently used by Panther), BLS12-377, and BLS12-381.

Note that in addition to size, the structure of the group of points on an elliptic curve is also important. The factorization of q − 1 defines the subgroups of Z_q. The inclusion in this factorization of 2^s for some sufficiently large s is required for using FFTs (for example, for multiplying polynomials), and is consequently crucial for the speed (or efficiency) of the proving process.

BN254 has 2-adicity 28 (that is, there exists a multiplicative subgroup of size 2^28).

zSwap uses advanced algorithms to identify the optimal routing path for 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 wishes to execute.

Additionally, zSwap calculates the difference between the best available opportunity and the rest 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% impact 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.

Pairings, or bilinear pairings or Weil pairings, are mathematical operations defined on certain types of elliptic curves. Pairings have important applications in modern cryptography and enable various cryptographic protocols and constructions. Generally, a pairing is a bilinear map that takes two points from different groups and maps them to a target group. The bilinearity property means that the pairing operation satisfies specific algebraic properties, such as linearity and distributivity. Pairings are typically defined on elliptic curves with special properties, such as those that are pairing-friendly or provide a suitable algebraic structure for efficient computation of pairings. Pairing-friendly curves are carefully chosen curves that allow for efficient and secure implementation of pairings.

Some key properties and applications of pairings include:

1. Bilinearity: Pairings exhibit a bilinear property, meaning they preserve the properties of addition and scalar multiplication in the groups involved. This property allows for computations involving pairings to be distributed across different groups and enables the construction of complex cryptographic protocols.

2. Cryptographic Constructions: Pairings are used in various cryptographic constructions and protocols, including identity-based encryption, attribute-based encryption, cryptographic accumulators, and non-interactive Zero-Knowledge proofs. Pairings provide the necessary mathematical operations to achieve desired security properties in these applications.

3. Homomorphic Properties: Some pairings, such as those on specific curves like the BLS12-381 curve, exhibit homomorphic properties. Homomorphic pairings enable computation on encrypted or encoded data without decrypting or revealing the underlying values. This property is particularly useful in privacy-preserving computations and protocols.

4. Efficiency and Security: Pairings can be efficiently computed on pairing-friendly curves, which enables the practical implementation of cryptographic protocols. Pairings are based on hard mathematical problems, such as the decisional Diffie-Hellman problem or the bilinear Diffie-Hellman problem, providing a foundation for cryptographic security. Pairings have revolutionized many areas of modern cryptography by enabling advanced cryptographic primitives and protocols. They provide a versatile and powerful toolset for achieving security, privacy, and efficient computation in various cryptographic applications.

Mathematically speaking, a pairing is a bilinear mapping as follows:

It is this bilinearity property that makes pairings such a powerful primitive in cryptography. Let $\mathbb{F}_{q^k}$be a finite extension of $\mathbb{F}p$ with $k \geq 1$. The groups $\mathbb{G}_1$ and $\mathbb{G}2$ are defined in $E(\mathbb{F}_{q^k})$ and the target group $\mathbb{G}_T$ is defined in the multiplicative group $\mathbb{F}^*_{q^k}$, so we usually write $\mathbb{G}_1$and $\mathbb{G}_2$ additively, whilst we write $\mathbb{G}_T$ multiplicatively. Thus, for $P, P^{\prime} ;\in \mathbb{G}_1$ and $Q,Q^{\prime} ;\in \mathbb{G}_2$, the bilinearity of $e$ means that

$e(P + P^{\prime},Q) = e(P,Q) · e(P^{\prime},Q),$

$e(P,Q + Q^{\prime}) = e(P,Q) · e(P,Q^{\prime})$

POSEIDON is a cryptographic hash function designed to be efficient when expressed as a circuit over a large prime field $\mathbb{F}$. It was introduced by Dmitry Khovratovich, Alexei Ivanov, and Dmitry Meshkov in 2019. Its use is advantageous in the context of SNARKs as many other hash functions (such as SHA-256) that are widely used in other contexts do not have efficient circuit representations. Panther uses this hash function as it fits the requirements of our platform.

Poseidon is a Snark-friendly cryptographic hashing algorithm based on a sponge function with the $POSEIDON^\pi$ permutation. Poseidon, as a function per se, maps strings over $\mathbb{F}_p$ (for a prime $p \approx 2^n > 2^{31}$) to fixed-length strings over $\mathbb{F}_p$, i.e. POSEIDON: $\mathbb{F}_p^* \longrightarrow \mathbb{F}p^o$ where $o$ is the output length measured in $\mathbb{F}_p$ elements (usually, $o = 1$). Poseidon takes a string of words in $\mathbb{F}_p$ as its input, and gives a single representative element of $\mathbb{F}_p$ as output (although longer outputs are supported).

The main features of the Poseidon hash include:

1. Efficiency: The Poseidon hash is designed to be highly efficient, enabling fast computation of hash values. It achieves this efficiency using a round-based permutation structure that can be parallelized and optimized for hardware implementations.

2. Security: The Poseidon hash is built upon the cryptographic sponge construction, which provides resistance against cryptographic attacks such as preimage attacks, second preimage attacks, and collision attacks. It employs a combination of algebraic and bitwise operations to ensure the security of the hash function.

3. Resistance to certain cryptographic attacks: The Poseidon hash is specifically designed to resist certain types of attacks that exploit algebraic properties of hash functions, such as differential and linear attacks. The round-based structure and carefully chosen operations make it resistant to these attacks.

4. Customizable parameters: Poseidon allows for the customization of its parameters, such as the number of rounds and field size, to adapt to specific security requirements and performance constraints. This flexibility enables the fine-tuning of the hash function for different applications.

5. Application versatility: Poseidon is suitable for a wide range of cryptographic applications, including digital signatures, Zero-Knowledge proofs, and blockchain systems. It provides a robust and efficient hashing primitive that can be utilized in various cryptographic protocols.

However, let's keep in mind that the Poseidon hash is designed for efficient and secure computation, especially in the context of Zero-Knowledge applications aiming to minimize proof generation time, proof size, and verification time (when it is not constant).

The primary application of Poseidon is hashing in large prime fields, and so $POSEIDON^\pi$ takes inputs of $t\ge 2$ words in $\mathbb{F}_p$. For curves such as BLS12-381 of BN254, the prime (scalar) fields have a size of around $2^{255}$. Consequently, a security level of 128 bits (that is, Poseidon-128) corresponds to a capacity of 255 bits, which is one field element.

It's important to note that the Poseidon hash is just one among many cryptographic hash functions available. While it is true that Poseidon is better than the Pedersen Hash and Rescue for several use cases, the choice of hash function depends on the specific requirements and security considerations of the application at hand.

Documentation on the Poseidon hash function is currently under construction, and we are actively working on providing users with a comprehensive overview of this technology.

\

TL;DR

• UTXOs are used to represent:

  • Digital assets (zAssets)

  • zAccounts

• To spend or open a zAsset UTXO the spender must provide a private key

This requirement for a unique private key for each UTXO contributes to the Protocol's privacy layer

Introduction

underpin the Protocol's privacy-enhancing solution. A UTXO is the of a data package committed to a leaf of a . The commitment of a UTXO on-chain and the data contained therein, is verifiable thanks to a SNARK proof generated at the time of the commit.

The commitment of a UTXO data package on-chain provides an immutable record of a transaction. However, data contained within the UTXO can only be accessed by providing the correct cryptographic solution.

UTXOs are used in different ways within the Protocol, which makes the "unspent transaction" a misnomer in certain instances. Let’s first consider the model that does create "change" or an unspent amount from a transaction by creating a UTXO worth the difference between its value and the amount spent: the zAsset UTXO.

zAsset UTXOs

represent digital assets as UTXOs. Every UTXO has one “owner” or zAccount able to spend it. This is achieved by including a public (spending) key in the generation of the UTXO commitment, for which the corresponding private (spending) key is only known by the recipient.

Spending UTXOs

During a spend event, the zAccount holder is either receiving an input UTXO, as in they are the recipient of a digital asset; or they are creating an output UTXO, as in they are spending/sending a digital asset.

When Alice transfers a UTXO to Bob, she transfers the UTXO's read and spend rights to Bob. This means that only Bob's zAccount may open and read the UTXO or spend the UTXO.

If a zAccount holder receives a UTXO, they must successfully decrypt the UTXO’s commitment. If they are able to calculate the child private spending key (childPrivSpendingKey), then they may spend the UTXO in the future, i.e. transfer ownership of all or part of the value of that UTXO.

This is how the Protocol protects the transactional privacy of the recipient. A transfer of a zAsset from sender to recipient is a non-interactive transfer i.e. the sender and recipient don’t have to communicate in order to facilitate the transaction. The only prerequisite is that the sender knows the recipient’s two root public keys (both spending and reading).

To access the receiver’s public keys, the sender’s zAccount looks up the user's zAccount registry. On zAccount activation, this registry establishes a link between the public root spending key, public reading key, and an EOA (externally owned account) i.e. a wallet address associated with the user. This allows an untracable method for the sender to access the receiver's data.

Shielded Pool contract responsibilities on spend

The Shielded Pool contract performs several checks when Alice sends a UTXO to Bob, it:

• Verifies that there is no double-spend of the UTXO

nullifierHash is calculated correctly and has not been used before

• Verifies the ZK proof:

  • the opening of the UTXO commitment is correct

  • the Merkle proof is correct

  • • Child Public Spending Key is derived from the Child Private Spending Key

    • Child Private Spending Key is the same input used in the opening of the UTXO commitment

zAsset transfer: UTXO spend

A zAsset transfer is a non-interactive, asynchronous spend/receive event that involves two UTXO models, the zAsset and the zAccount.

Let's consider the outcome of a spend event that results in the transfer of 1 zAsset UTXO.

As a result of the spender initiating a zAsset transfer to a different zAccount, at least 2 new UTXOs are committed to the Merkle Tree:

• Token of transaction: zAsset UTXO created to the value of the transfer amount

With a unique key based on the intended recipient's public key

• Token of transaction: zAsset UTXO representing any change, if a 0 amount i.e. no "unspent" value remains, then no UTXO is created

If Alice has a UTXO representing 5 zETH and sends Bob 2 zETH, the unspent amount is represented by at least 1 UTXO to the value of 3 zETH

• zAccount UTXO: the sender's zAccount UTXO is updated to deduct the value of asset sent from balance, fee deduction in zZKP, and an increment to their PRP reward

As a result of the receiver (asynchronously) unlocking the UTXO with their key:

• zAccount UTXO: receivers zAccount UTXO is updated to reflect the value of asset received

In addition to , Panther uses , , , and . Each of these mathematical and technical building blocks plays different roles in supporting the enablement of privacy, anonymity, and scalability. By drawing upon these technologies, Panther facilitates a shift in trust from regulatory frameworks and organizational practices to trustless mathematical proofs and their interpretation.

You can talk to people about Panther Protocol and the Panther DAO on all Panther community channels:

• ​

For the current dApp, see the . Each stage's entrypoint is deprecated in favor of the next stage.

Testing scope and stages

The following are the different stages of testing that users will undertake.

As mentioned, specific testing guides for each step will be released along with them.

More information on each stage can be found in the following sub-pages.

Note: As the protocol developer, Panther Ventures Limited is resuming the testnet after re-deployment on Amoy. Panther Protocol Foundation is finalizing the details of the reward mechanism and will ensure that testers are rewarded proportionally to their efforts and we expect all incentives will be distributed via airdrop.

Disclaimer

For the avoidance of doubt, tZKP, tzZKP, tPRP, test MATIC, and any other tokens mentioned in this announcement or within the product are for testing purposes only and have no economic value, nor can they be exchanged for value.

Participation on our incentivized Testnet versions may result in you earning rewards, but such credits are not represented on any blockchain as tokens.

What next?

Panther is testing and releasing:

• Testnet DeFi trading dApp

The testnet dApp will provide features such as DeFi integrations, zSwap, and support trading in the Shielded Pool: including zTrade, as its core features.

Each release is made available to community testers.

What next?

• Learn more about the testnet dApp releases phases

• Watch a video on how to create a testnet account

Status: Completed

For the current dApp, see the entrypoint. Note that, each stage's entrypoint is deprecated in favor of the next stage.

At this stage, users will be testing two features that allow Panther to combine privacy-preserving DeFi access with compliance capabilities:

Third-party compliance integrations

Panther has built a system that retains neutrality by plugging directly into compliance providers and integrating them into the application’s flow. These systems can capture certain types of user data and issue a Zero-Knowledge proof attesting that users have been verified without the Protocol learning any information from them.

The Panther DAO has been commissioned to select a compliance vendor that aligns with its interests, a discussion taking place in Panther’s forum. For the sake of this Testing exercise, an integration has been built that uses PureFi’s system. PureFi is a multi-vendor compliance provider that has demonstrated interest in partnering with Panther through the DAO discussions.

Registering using these integrations is a multi-step process that connects a user’s Panther Account with the verification performed by PureFi.

It consists of: a. Creating a Panther Account by connecting your wallet (e.g. MetaMask).

b. Undergoing a basic verification on PureFi’s site (opened in a pop-up tab).

c. Completing the verification process in the Panther dApp by providing the created proof of verification. This process involves downloading files on your browser (around 30MB), which can sometimes take 2-3 minutes (depending on IPFS’ responsivity at the time. In case of trouble, reloading may help.)

The above activates the user’s Panther account created in step (a) above, and issues account creation rewards to the user.

Panther Accounts

Within Panther, users are identified through their Panther Account (which has a corresponding zAddress), a concept similar to a bank account in that it englobes all of a user’s transactions within a single reference point. Accounts attest to users’ compliance verification while retaining Zero-Knowledge properties. In other words, they prove that a user has passed verification (as well as the type of verification passed), but they do not store any private information about users.

We posted an article further expanding on the rationale behind both of these components, as well as Panther’s compliance focus. Check it out here!

Testing and providing feedback

As we mentioned, Testnet rewards are automated, and as such, the Testnet itself will reward users for going through the Account creation flow. However, the goal for the Testnet is to debug and enhance the Protocol before the mainnet beta launch.

Our expectation is that users submit bugs and share ideas to enhance end-to-end functioning, interaction and usage of wallets, UI/UX flows, and let us know about any component that doesn’t look or feel as expected. We have created the following spreadsheet containing all the details that users can test, which includes functional and visual components. Note that every testing case is numbered to facilitate the process of providing feedback.

Spotting and fixing any possible bugs within the Testnet will make the first version of the protocol more sustainable in the middle term while allowing users to receive their earned rewards.

How to test

Users can visit the Testnet link for Stage 1 to test the onboarding functionality. This involves creating a Panther Account, undergoing a simple verification process (name and email required, ID NOT required) with PureFi, and activating their Account. We recommend that you test along with reviewing the testing spreadsheet so that you can keep track of everything you need to test.

To share feedback, testers will be using a dedicated form as the only accepted procedure. The steps mentioned in the form’s description are needed to make this interaction both efficient and productive.

All smart contracts and deployments by Panther are audited by well-known, reputable firms. In here, you can find a list of these audits.

Smart Contract Audits

• CERTIK: Panther ZKP Token Audit.

• 21 Analytics: Panther v0.5 Audit.

• CERTIK: Panther ZKP Vesting Audit.

Status: Completed

For the current dApp, see the entrypoint. Note that, each stage's entrypoint is deprecated in favor of the next stage.

At this stage, Users will be testing:

• Claim PRP voucher

• View private balance on the Dashboard

Vouchers

Vouchers are a reward mechanism that can be used by the Protocol to incentivize for certain functions that have to be triggered by Users. We refer to them as Admin functions. Those could include but not limited to functions such as

• Recharging Reward Pool

• Trigger conversion of token

Note: the onboarding reward voucher issued in this Stage is only for testing purposes.

Note: it can take up to a minute to get the voucher screen updated with the new voucher.

Voucher has a predefined value which can be different depending on the type of performed action (Onboarding = 500 PRP, triggering recharge the reward pool = PRP 100). Voucher is nominated in PRP. To get those PRP, one should claim a voucher which is akin to submitting a transaction “burn a voucher and get the corresponding PRP”.

Vouchers are grouped per type of action performed. Stage 2 will have two such groups - (1) Onboarding bonus voucher and (2) Recharge bonus voucher.

Vouchers can be claimed by group only, which means a user gets the total PRP for all vouchers in a given group. When claiming is completed successfully, a user will see an updated balance on his (a) Dashboard → Panther Rewards Points section → Available PRP amount and (b) Rewards page → Redeem PRP screen → Available PRP section.

Testing and providing feedback

As we mentioned, testnet rewards are automated, and as such, the testnet itself will reward users for going through the Rewards process. The goal for the testnet is to debug and enhance the Protocol before mainnet beta’s launch.

Our expectation is that users submit bugs and share ideas to enhance end-to-end functioning, interaction and usage of wallets, UI/UX flows, and let us know about any component that doesn’t look or feel as expected.

For the current dApp, see the entrypoint. Note that, each stage's entrypoint is deprecated in favor of the next stage.

Status: Complete (but the docker Panther Miner is still working!)

This testing stage (and activity in production) is directed towards miners, a key role in the Panther ecosystem, as opposed to DeFi users. It started in July 10th, 2023, and is projected to last for two weeks.

To see the original announcement, along with explanations of the components tested, click here.

Testing scope

Stage 0 launches the Panther Miner, a specialized miner designed to interact with a blockchain network.

Within Panther, Ecosystem Operators 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, create a SNARK-proof that proves the correctness of the updates, and submit these updates to be written on-chain together with the proof to smart contracts. As such, the Panther Miner software acts as the “Bus Operator” for the Bus Tree (see Shielded Pools on behalf of a user.

In this implementation, the algorithm to reward miners is fairly simple. Eventually, the Panther community may want to implement a more sophisticated algorithm after some initial usage statistics are collected.

How to test

To test at this stage, follow the steps below.

Test in app

1. Visit the miner test page.

2. Understand the following three variables:

2.1 Interval (in seconds): the designated pause between iterations produced automatically by the miner. You may reduce this down if your system and the RPC provider handles the load, or you may increase this to lengthen the space between iterations.

An iteration includes:

a) Checking the BusTree contract for a queue expecting processing and selecting the most profitable one to process.

b) Generating a ZK proof by processing the chosen queue.

c) Submitting the ZK proof to the blockchain.

2.2 Private Key: the private key of the wallet used to sign batch transactions and receive rewards.

There are two options for this field:

2.2.a Use an existing key, e.g. exported from your MetaMask; or 2.2.b Generate a new key pair. Click “Generate private key using MetaMask” and get a new private key inserted into the corresponding field. You can add the new address to your MetaMask (click “Show Private Key” to unveil and copy the data) afterward.

A new public key (address) will be reflected as soon as you start mining. Find it in the “Mining statistics” section.

2.3 RPC URL*: use any RPC you prefer, as long as it’s valid for the Mumbai network.

3. Ensure you have a positive balance of MATIC in your wallet to interact with the product. You can visit faucet_1 or faucet_2 to get test MATIC tokens.

4. Click the “Start Mining” button to start the process.

5. Check that the “Logs” section is updating.

6. Check that the “Mining Statistics” section is updating.

Please, note:

• The “Generated Proof” amount can be bigger than “Submitted Proof,” meaning other miners submitted a generated proof earlier than you.

• “Mining Success” = “Submitted Proof”(s).

• Your Balance (of MATIC) will decline over time because the miner client generates UTXOs to let you interact with them to test the functionality. Submitting UTXOs incurs a cost.

1. Check that you’re receiving rewards correctly.

2. Stop mining. (Note: the miner will finish the ongoing iteration before entirely stopping).

Using a Docker image

For users interested in running the Panther Miner themselves instead of using a browser version, the Dockerized version has the same functionalities and logic outlined above. Here’s the link to the Docker image page: https://hub.docker.com/r/pantherprotocol/miner-client Smart contract details (on Mumbai):

• BusTree: 0x678D34aA4fc546bA806287a8289FfdAA84681a03

• VPool: 0xCd85e3E918F1A36F939281d3ca707EE262a364c6

• test DAO multisig: 0xfB474a7FeCDaFBD412ebF0d60A0C32794F82d3dD

• PantherVerifier: 0xeeAfce13506847a19141A4513718df17383f4f7b

• PantherPool: 0xfDfD920F2152565E9D7b589e4e9faeE6699AD4bd

• Vault: 0x9619bd59411a8387a4119e548017C5b86c7bCec5

• FXPortalBridge: 0x542c2c3e6BBfD5979E5FEC6708764B93Ba210c51

Status: Testing in progress

1. DeFi Adaptors:

The first DeFi feature has been introduced: Swap functionality. Users can swap their shielded assets (zAssets) while keeping them in the MASP and interacting with external decentralized Swap protocol. For the purpose of testing, Stage 7 will include integrations with two Swap protocols - Uniswap V3 and QuickSwap simulated on Amoy ( the new test network of Polygon).

To prepare the transaction, a user should (1) choose the target pair for the swap and (2) set the amount to send (swap from). The user can see the estimated amount to receive (swap to). Additionally, the user can (3) switch the send/receive tokens within the chosen pair. Note: The amount to receive is not final and may vary depending on the user’s transaction settings (particularly the maximum slippage parameter) and the actual pool parameters at the time of transaction execution.

A swap transaction requires users to define the following settings to initiate it:

1. Route: By default, the product selects the best route, but users can change this option based on their preference.

2. Maximum Slippage: This parameter defines the allowable difference between the expected price of an asset and the actual price at which it is traded/swapped. Users can choose from (a) Auto, (b) preset amounts (0.1%, 0.5%, 1%), or (c) a Custom option. Note: Setting the slippage below 0.05% may cause the transaction to fail, while slippage above 1% could result in an unfavorable rate for the swap.

Transaction Deadline: This parameter sets the time frame after which a pending transaction will automatically revert if not completed. The current setting is fixed at 5 minutes.

Transaction parameters are divided into two groups: (1) swap and (2) protocol. The second group is consistent across the product's functionality, while the first group details the specific characteristics of the swap route:

1. Price Impact: This measures the price change resulting from the swap transaction the user intends to execute, considering factors such as liquidity, order book depth, and order size.

2. Swap Fee: This is the fee collected by the external platform that facilitates the transaction route. To preserve user privacy, this fee is initially collected using zZKP and later paid to third parties by the protocol.

3. Slippage: This parameter, set by the user, defines the acceptable difference between the expected price of an asset and the actual trading price.

4. Minimum Received: This represents the guaranteed amount the user will receive, taking the slippage parameter into account.

5. Ratio: This likely refers to the exchange rate or conversion ratio between the swapped assets.

1. Data Escrow

Data Escrow is an important Product Feature that supports Compliance Data requirements. Panther Protocols has implemented different types of Data Safe mechanism based on the roles that the DAO, Institutions (also referred as the Zone Manager) and Compliance provider perform to support this. In the next stage, we will continue to build the decryption mechanism for those roles to access the data. The whole process will be tested when those roles participate in the testing process - essentially we see this as a process to Zone Manager testing the protocol along with other participants.

1. History page:

The History page UI has been updated with structured and detailed data, including the following factors:

• Transaction Type

• Amount

• Asset

• USD Value

• Date and Time

Additionally, data sorting by these factors has been implemented to enhance user experience. To use the functionality one should hover a cursor on a particular column title and click it.

\

Status: Testing underway

During the Stage 5 test phase, the Mumbai network was fully deprecated, forcing the test dApp to transition to Sepolia.

For the current dApp, see the . Note that, each stage's entrypoint is deprecated in favor of the next stage.

Functionality

Stage 5 introduces two core functionalities with some extra details on the impact to UTXO Selection:

Integrations with 3rd party Bundlers

Panther has integrated with Etherspot’s Skandha ERC4337 Bundler service to send transactions to the blockchain. Users will now have an option to select (Bundler = YES / NO) before submitting their transactions.

• Bundler = YES will send transactions via the Bundler services in which case the network gas cost is deducted from the balance of their Panther Gas Account.

• Bundler = NO will send transactions directly from user's EOA (externally owned account, i.e. the connected MetaMask wallet) and the network gas fee is paid from that wallet in the native gas token.

Introducing faster transactions

Panther uses to process newly created UTXO in batches instead of individual UTXO commitment updates enabling lower gas cost for the transactions involved in this batch.

UTXO selection update

Stage 5 enables UTXO's to be processed individually as opposed to a batch enabling near instant spending of the new UTXO’s. This reduces the wait time to process the batch but comes with an extra cost. Technically this is referred to using a ‘Taxi’ (from the Taxi tree where the UTXO gets added).

The user can choose between the Regular Processing (taking the bus) and Fast Processing (taking the taxi) from the toggle available under the Fee section before submitting any transaction.

As a result of the above change to process newly created UTXO in two modes, some UTXOs may not be immediately available to be used in another transaction (or spent). This restriction applies only for a short period of time (a few minutes) until the Bus Queue or the Miner has processed the next queue. These restriction are:

• UTXOs created by two separate FAST transactions can't be spent together

• UTXOs created by FAST transactions and a REGULAR transactions cannot be joined together

Again, it is important to note that these restrictions apply only for a very small duration of time after the creation of a FAST transaction and it pertains to how soon you can spend a UTXO created by a FAST transaction and join it with other available UTXO’s. It has nothing to do with the FAST transaction in itself but the output of this transaction to be used in the next transaction.

User testing flow

Bundler selection

1. Navigate to any the transaction screen (currently Deposit, Transfer, and Withdraw) and check the new development in the Fees section.

2. A new Bundler toggle is available for selection between a YES or a NO:\

Processing selection

1. Navigate to any of transaction screen (currently Deposit, Transfer, and Withdraw) and check the new development in the Fees section.

2. A new toggle to select Processing Type is now available.\

UTXO selection update

Notes: The fee functionality is not completely integrated in this version yet so the testing expectation is that transactions are processed via Bundlers and users also able to process FAST transactions. The deduction of fees and the full calculations of fees will be implemented with Stage 6.

What next?

Status: Completed

For the current dApp, see the entrypoint. Note that, each stage's entrypoint is deprecated in favor of the next stage.

Functionality

Stage 3 and onwards is the beginning of User interaction with the MASP. Even though the previous stages issued rewards (PRP) in the MASP, users did not directly interact with the Shielded Pool. This stage forms the basis of some of the key components that will be released in further stages.

Stage 3 provides a brand new User Interface with enhanced images, icons, colors, and space alignment while the overall dApp flow has not changed.

The core functionality includes:

• Deposit a new asset (test Matic) into the MASP. Asset allowlisting is one of the DAO functions to exclude scam tokens into the MASP. For testing purposes, the team has included test Matic and expects to include a few more tokens in later stages.

• Stage 3 includes the basic disclosure functionality under the History tab. Basic disclosures provide information about different types of transactions performed within Panther along with its transaction hash and the date/time of the transaction.

User Testing Flow

To deposit a regular asset a user should:

1. Go to the Deposit screen by selecting any of the available options. From the:

   • Within the zAsset menu item, click on the Deposit tab as shown in the screenshot below

   • Within the My Public Asset section in the Dashboard, select the token; this takes the user to the Deposit screen

   • Private zAsset section will also have the option to select and deposit

   • On zAsset Portfolio, click the balance card

2. Select the token to deposit if it is not preselected, or adjust your selection via the token selection modal window.

3. Enter the amount to deposit.

4. Click the Deposit button and complete the transaction.

5. View the corresponding changes in the Dashboard, your Private zAssets section, and the adjusted balance of the deposited asset.

Status: Testing in progress

1. UTXOs joining on deposit:

The efficiency of the product is improved by maintaining the user's balance in a single UTXO during the deposit. This allows users to engage their entire balance in a single transaction, eliminating the need for additional MASP transactions to consolidate smaller UTXOs.

The dApp maintains the user's balance in one UTXO for optimal clarity and efficiency, following the preference to have a single large UTXO instead of numerous smaller ones. This structure allows users to engage any part of their balance in just one transaction, mitigating the necessity for a supplementary MASP transaction to consolidate smaller UTXOs.

When handling a deposit transaction, the dApp merges an available zAsset UTXO of the largest amount with the deposited amount, rather than initiating a new UTXO. As a result, the new UTXO displays the total amount collected.

1. zAccounts blacklisting:

The update introduces a blacklist functionality, aimed at ensuring compliance with legal standards while maintaining the core privacy features. This update enables blocking users reported as illicit by reporting agencies.. ZMs can now oversee and manage such request of discovery of any bad actor in their zones and take measures more effectively

The blacklist feature is designed to integrate with existing compliance processes aligning with Panther’s broader compliance mechanisms.

1. Diamond Proxy updates:

The necessity of implementing the Diamond Proxy architecture in the product arose from the issue of contract size limitations on Ethereum. In the old design, PantherPool held multiple logics such as zAsset activation, PRP claiming, PRP conversion, the main transaction and zSwap, ForrestTree, and some helper functions. As a result, the PantherPool contract grew to around 30-32 kilobytes, which exceeded Ethereum’s limit for contract size, set at 24.6 kilobytes. The team initially addressed this by offloading some logic, but this solution was insufficient for future scalability, particularly with the planned introduction of zTrade functionality.

The Diamond Proxy resolves this by allowing multiple contract implementations to be accessed through a single proxy. This proxy can delegate calls to different contract implementations as needed while maintaining a shared storage across all implementations. The advantage of this architecture is that it bypasses the size limitations by distributing the logic across smaller, more manageable contract pieces, ensuring scalability as new features (such as zTrade), are added to the protocol. Each implementation can have its own storage while benefiting from the shared core storage managed by the proxy.

By implementing this architecture, the protocol can not only overcome the immediate size limitation but also future-proof its infrastructure for new functionalities and scaling, ensuring smooth deployment and upgrade processes in the future.

1. Taxi ring buffer logic updates:

The Taxi functionality got a significant upgrade with the introduction of a ring buffer mechanism, marking a substantial improvement in blockchain data management. This update revolves around the implementation of a smart contract supporting two level-8 Merkle trees, each containing 128 leaves. The core innovation lies in its cyclical approach: as one tree fills up with data, the system seamlessly transitions to the second tree while resetting the first to an empty state. This process continues in alternation, effectively creating a ring buffer that optimizes memory usage and streamlines data handling.

On the smart contract side, the implementation is elegantly simple yet powerful. Only the root of the current active tree is stored, significantly reducing memory requirements. The contract autonomously manages the transition between trees, including the reset process, ensuring efficient and continuous operation. Meanwhile, the data management component has been enhanced to track the current location of used UTXOs within the trees and utilizes only the latest state of the Taxi tree. This approach eliminates the need to maintain historical data, simplifying data queries and substantially reducing storage requirements.

The benefits of this ring buffer update are far-reaching. By cyclically reusing trees, the system avoids unbounded growth of data structures, leading to optimized memory usage and improved performance. The simplified data management process results in faster transaction processing and enhanced scalability, allowing the system to handle a larger volume of transactions without a proportional increase in resource requirements. Moreover, the focus on current state rather than historical data significantly reduces storage needs and simplifies verification processes.

1. Strengthening UTXO Management with Enhanced Privacy, Key Rotation, and Nullifier Security:

The code has been enhanced to address key issues related to UTXO management, with significant improvements focusing on privacy, security, and compliance. A set of critical updates was implemented to tackle vulnerabilities in the system, particularly regarding how UTXOs are verified and managed through compliance provider public keys and nullifiers.

The addition of a UTXO secret random to the zAsset commitment addresses a critical security vulnerability in the protocol. This update prevents potential cheating on the receiver's root spending key, which previously allowed for unintended anonymous transfers. By implementing this change, we ensure that every UTXO's spending public key is correctly derived from the receiver's root spending public key, maintaining compliance with the protocol's design. This enhancement effectively closes a loophole that could have allowed users to bypass essential verification steps, thereby strengthening the overall security and integrity of the transaction system.

Secondly, the handling of compliance provider public keys was updated to allow for key rotation and secure management. Previously, if a compliance provider's key was compromised, the protocol faced risks of unauthorized access or transaction manipulation. Now, the system ensures that these keys can be securely updated, while still maintaining the integrity of UTXO tracking. This prevents any security breaches linked to compromised keys and reinforces compliance protocols.

Finally, nullifiers - which are crucial for determining whether a UTXO has been spent - have also been enhanced. The system now ensures that nullifiers are securely generated and tied to the UTXO secret random and compliance provider keys. This update allows compliance providers to compute the nullifier and verify whether a UTXO has been used, without revealing sensitive user information. If needed, compliance providers can open a data escrow to investigate specific transactions. This addition guarantees that UTXOs are correctly tracked, preventing the reuse of spent tokens and ensuring secure transaction validation.

Together, these improvements significantly increase the security, privacy, and compliance capabilities of the protocol. This ensures the system is robust against potential manipulations and capable of securely handling UTXO transactions, even with future token standards or compliance requirements.

1. Streamlining Codebase with BigInt while Enhancing Efficiency and Reducing Dependency on External Libraries:

The code has been enhanced by standardizing the handling of large integer values, transitioning to the native BigInt type instead of relying on both BigInt and the BigNumber library from ethers.js. This improvement addresses the previous inconsistency, where the combination of these two types led to unnecessary conversions, complicating the codebase and increasing reliance on external libraries. These conversions not only affected the readability and maintainability of the code but also increased the risk of bugs due to the constant switching between formats.

By focusing on BigInt for all internal operations, the codebase has become significantly more streamlined and easier to maintain. The use of BigNumber is now restricted solely to cases where it is essential for smart contract interactions, reducing the overall complexity of the code. This approach also helps improve performance by eliminating the need for continuous conversions between BigInt and BigNumber.

Moreover, this update prepares the system for future improvements, as BigInt is expected to receive better support and optimizations within the evolving JavaScript ecosystem. As BigInt is a native JavaScript feature, this change ensures the codebase is more aligned with modern JavaScript standards and future-proofed for long-term sustainability.

1. Enhancing Token Management by Improving Security and Accuracy in Token Type Verification:

This test version has been improved by addressing a critical issue related to the proper identification and management of token types. Previously, the system did not accurately differentiate between various token standards (e.g., ERC-20, ERC-721, or ERC-1155), which allowed users to potentially misrepresent the type of token being used in transactions. This lack of verification created a security risk where users could manipulate the system, falsely claiming a token type and benefiting from this misrepresentation. Furthermore, the protocol lacked the infrastructure to store or verify this token information effectively, leading to potential vulnerabilities as more token standards are introduced.

To resolve this, a new solution was implemented that introduces the TokenTypeAndAddressDecoder library. This library enables the protocol to decode the public input of transactions and accurately return both the token type and token address. Additionally, the zTransaction and zSwap facets have been updated to ensure compatibility with the latest circuit updates, allowing them to accept token type and address in a single signal. The library then decodes this signal, ensuring that token types are correctly handled during transactions.

As a result, the product now offers improved security by accurately verifying token types and addresses, minimizing the risk of system manipulation. This enhancement not only addresses the immediate security concerns but also prepares the system for future expansions, allowing it to handle a wider variety of token standards with increased reliability and efficiency.

Status: Completed

For the current dApp, see the entrypoint. Note that, each stage's entrypoint is deprecated in favor of the next stage.

Functionality

Stage 4 introduces two core functionalities:

• Internal Transfers (Send and Receive): Users can transfer zAssets to other Panther users inside the Shielded Pool. zAssets can be sent to another user using their zAddress. Every Panther user is assigned a zAddress that can be viewed on the Panther account. The Receive screen is also available for your convenience to share your Panther account address (referred as zAddress) via QR code. Simply, navigate to the dashboard and click on the Receive button.

• Withdrawal: Users will be able to withdraw zAssets from the Shielded Pool back to an external wallet. This external wallet can also be a new account different from the account used to deposit assets. Compliance checks are performed to ensure that users prove they are the owner of the zAccount they are interacting with and that the wallet where assets are withdrawn is a clean wallet.

The Protocol rewarding mechanics have been enhanced with two new features:

• Automatically converting pending PRPs into available PRP upon spending of UTXO(s) due to transfers and withdrawals.

• Rewarding a user with a flat PRP bonus upon spending UTXO(s).

User Testing Flow

Internal Transfer:

1. Navigate to the Send screen through:

   • Top main menu - zAssets - Send screen,

   • zAssets Portfolio card - Send button,

   • Dashboard - Private zAssets section - token line - token management buttons.

2. Set the amount.

3. Choose the token.

4. Manage UTXOs as needed.

NOTE: The current version allows the selection of a maximum of two UTXOs in a given transaction - that defines Selected Balance. By default, UTXO’s with the top two balances are selected. If the transfer amount is less than the chosen UTXO(s) amount, the new UTXO with the returned amount is added to users zAsset list.

1. Specify the destination address in the Panther account format, beginning with "ZK" and having a total of 42 characters - enter a new address or select from previously used options.

2. Push the Send button to initiate the internal transfer.

Withdrawal:

1. Navigate to the Withdraw screen through:

   • Top main menu - zAssets - Withdraw screen,

   • Dashboard - Private zAssets section - token line - token management buttons.

2. Set the amount.

3. Choose the token.

4. Manage UTXOs as needed.

5. Specify the destination address in Polygon network format, beginning with "0x" and having a total of 42 characters - enter a new address or select from previously used options.

6. Push the Withdraw button to initiate the internal transfer.

TL;DR

• Panther will support privacy-enhanced Over-The-Counter trades

Overview

zTrade will be the world’s first Zero-Knowledge on-chain Over-The-Counter (OTC) marketplace.

Using the Polygon network (at mainnet beta release), zTrade will offer an innovative approach to OTC trading by connecting makers and takers in a fully privacy-enhanced, secure environment. It leverages the attributes of the Shielded Pool and zAssets to enable OTC 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 Pool and converts them into zAssets. 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:

• Zero slippage on large trades

• Low fees

• Instant settlements with data protection

• Possibly, earning rewards

to be determined by the DAO

DeFi Adaptors

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.

DeFi Adaptors and Panther’s privacy

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.

Use cases

Some use cases of DeFi Adaptors include:

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

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

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

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

5. 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: Testing underway

Panther’s test network is now live on Amoy, Polygon’s test network, and can be accessed . Due to this network change, users will need to complete the onboarding process again and activate their test zAccount. Users who are using their old accounts, however, will not have to go through PureFi credential process again and will be moved directly to the account activation. This is a one-time activity required to access Panther.

For the current dApp, see the . Note that, each stage's entrypoint is deprecated in favor of the next stage.

Functionality

Stage 6 introduces two core functionalities with some extra details on the impact to UTXO Selection:

Fees Testing

This release introduces the mechanism for charging different types of fees within the simulated testnet, including Protocol Fees, Network Gas Fees, KYT fees and KYC Fees. All simulated fees are paid from the Panther Gas account in tZKP.

AMM Refilling with Protocol Fees Testing

Simulated protocol fees collected during the testing will be deposited into the AMM’s pool of tZKP.

Limited Subsidy Rewards Testing

The production (mainnet) version of Panther Protocol may include feature that will allow to introduce additional rewards to partially or fully compensate costs like Network Gas Cost, KYC, KYT and Miner fees, in service of encouraging use of the platform. Stage 6 of our testnet simulates this feature for testing purposes.

Note: This feature is designed to cover only tZKP-nominated fees, and will not involved test MATIC or other native test network tokens unless using the relayer service.

To continue learning about Panther, you can visit the following pages:

• Website

• Blog

• GitHub

2024 Updates

April 2024

• Panther Miner renamed to Oshiya with Oshiya Operators renamed to zMiners

• Oshiya code base moved to GitHub under MIT license

2023 Updates to Panther Miner

Note, Oshiya is not presenting public-facing versioning until such time as the codebase is made stable and optimizations are identified.

On June 15th, 2023, an update to the Panther Miner was introduced.

The new version aims to address a bug in which the in-browser Miner client can’t iterate through batches, fetching them from a graph.

The smart contracts were also updated to limit the mining of semi-empty queues. To limit semi-empty queue mining, this commit introduces a requirement of "maturity" for queues:

• A partially populated queue must remain pending processing for a number of blocks, which declines linearly with the number of UTXOs in the queue (fully populated queues are processable immediately).

• The above number of blocks (every block on Mumbai is ~2 sec) that a partially populated queue is disabled for mining, counted from the block when the 1st UTXO was added to the queue, is now computed as follows (rounded down):\

N = 100 * (64 - number_of_UTXOs) / 64

Note that “100” above is an adjustable parameter that might be tweaked further.

Note that:

• Only ~20 new queues per hour are available for zMining. This and other parameters influencing rewards may be tweaked this week as a part of the test program.

• The new zMiner will have significantly higher chances of mining a queue than the previous one.