Shielded Pool

Shielded Pool

StatusEntrypoint

In development on testnet

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:

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?

Last updated