TL;DR

• Zone Managers determine what compliance looks like for their Zone/s

• The Protocol is agnostic as to which third-party compliance provider/s 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 compliance provider integrations, Panther zAccounts, and Zones.

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.

For testnet, the Panther DAO was commissioned to select a multi-compliance vendor that aligns with its interests.

Discussed in Panther’s forum.

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

• Each transaction results in an encrypted “message to self” stored on-chain

Similarly, to support forensic reveals, 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, ZK proofs 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 Trust Providers who issued the attestations never learn when or how users use those attestations when interacting with Service Providers.

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

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