Skip to main content

Confidential Assets

Polymesh Confidential Assets (PCA) enable privacy-preserving transfers of digital assets while still supporting regulated-market workflows like receiver affirmation, multi-leg settlement (transfers), and asset-specific compliance access.

At a high level, participants submit Zero-Knowledge Proofs (ZKP) that a balance update is valid (e.g., “I can afford this debit”, “this state transition is well-formed”) without revealing the underlying amounts or linking the sender/receiver identities. Separately, encrypted settlement details can be made accessible to designated compliance participants.

Reference

Polymesh Confidential Assets are the Polymesh implementation of the P-DART paper (the underlying protocol design), which builds on the DART paper.

Why Confidential Assets?​

The Confidential Assets functionality on Polymesh (PCA), powered by P-DART (Polymesh - Decentralized, Anonymous, and Regulation-Friendly Tokenization), delivers a unique combination of high-level privacy and essential regulatory compliance features, making it ideal for tokenized securities and regulated finance.

Key benefits and achievements:

  • Full Anonymity with Constant Transaction Size: PCA provides full anonymity and confidentiality for balances, transaction values, asset types, and identities in an account-based model. Crucially, it achieves this privacy guarantee with a constant transaction size (O(1)), resolving an inherent limitation of many other partially anonymous account-based systems whose size grows with the anonymity set.
  • Dual Regulatory Compliance (Prospective and Retrospective): PCA introduces a robust compliance framework that supports both passive auditing and active control.
    • Auditors: Hidden, passive compliance entities designated by asset issuers who can decrypt asset-specific transaction data to provide retrospective auditability for regulatory reporting or cap table management. Do not gate settlement execution.
    • Mediators: Active participants with the same decryption capabilities as auditors (can decrypt and inspect asset-specific settlement legs), but who must also affirm or reject pending transfers, providing prospective regulatory control. Settlement remains pending until mediators act when required.
  • Support for Complex Multi-Leg Settlement: PCA includes a mechanism for settlement creation, allowing a creator to define the sender, receiver, asset type, and value for each leg (representing an asset transfer) of a proposed settlement.
  • Receiver Affirmation and Reversibility: Transactions require explicit affirmation or rejection from all counterparties, aligning blockchain payments with regulatory requirements often seen in securities transfers. The system also supports reversibility, allowing the sender to reclaim unaffirmed funds, which prevents assets from being locked indefinitely.
  • Avoidance of Concurrency Issues: The PCA design circumvents the concurrency issues common in other account-based anonymous payments, where changes to the account state (e.g., from an incoming transaction) could invalidate an outgoing transaction's Zero-Knowledge Proof.
  • Non-Interactivity: The system supports non-interactivity, enabling senders to initiate payments to receivers who may be offline at the time of transfer.
  • Proof of Balance (PoB) Support: PCA enables a Proof of Balance mechanism, allowing any verifier to request the exact balance of a specific asset from a user, accommodating the complexities of split balances caused by pending transactions requiring receiver affirmation.
  • Multi-Party Transaction (MPT) Efficiency: PCA efficiently facilitates the transfer of a specific asset to multiple receivers, or the affirmation of receipts from multiple senders, within a single transaction by combining proofs generated by multiple parties in a single transaction, thereby increasing efficiency in privacy-preserving settings.
  • Support for Mandatory Regulatory Actions: The protocol supports key regulatory procedures, including account freezing and forced transfers.

What's Private vs. Public​

The PCA protocol is fundamentally designed to achieve a difficult balance: ensuring full anonymity for participants and transactions while maintaining a publicly verifiable, regulatory-compliant ledger. The model is not about hiding the entire chain, but strategically concealing the sensitive elements within cryptographic shells (commitments and Zero-Knowledge Proofs).

The following sections detail what is kept Private (Confidentiality) versus what is published to the chain as Public (Integrity and Verification).

What is Kept Private (Confidential Information)​

P-DART/PCA achieves full anonymity by ensuring that sensitive transactional data is only verifiable via cryptographic proofs, concealing the details of the transfer and the identity of the confidential account owners.

  • Account State Secrets: The entirety of a user's internal account state is kept private. This includes the account secret key , the finalized (spendable) balance, the pending transaction counter, and the secret randomness values used to derive the nullifier and generate the commitment.
  • Transaction Value and Asset Type: The actual transferred value between accounts and the specific asset type involved are concealed through commitment or encryption within the Zero-Knowledge Proof (ZKP).
  • Identity and Linkability: The identities/public keys of the sender and receiver are concealed within the transaction. Crucially, the protocol guarantees unlinkability between a participant's successive account states, preventing tracing of a user's transaction history.
  • Auditor/Mediator Keys in Transactions: While the public encryption key of the designated auditor/mediator is publicly known, the protocol requires that this key be concealed during the confidential transaction itself. This concealment is necessary to prevent revealing the underlying asset type, as the mapping between the asset and the auditor is publicly known.
  • Decoupled Signing Key: The confidential account keys used to generate the ZKP are kept secret and are distinct from the standard public keys used to sign and submit the transaction to the network. This ensures that the validity of the confidential transfer relies solely on the ZKP integrity, not the public signing key, though practical anonymity requires additional considerations to avoid linking the public signing key to the activity.

What is Public (On-Chain Verification and Integrity)​

For the blockchain to maintain integrity, prevent fraud, and facilitate regulation, certain cryptographic objects and metadata must be publicly recorded:

  • Commitments and Accumulator: A cryptographic representation of the new account state, the account commitment, is publicly published after a transaction. These commitments are aggregated into a global, publicly maintained Accumulator.
  • Nullifiers (Double-Spending Tags): To prevent an old account state from being spent twice, the unique, deterministic nullifier associated with the spent account commitment is publicly revealed and recorded in the List of Nullifiers. The nullifier ensures that double-spending attempts fail validation.
  • Proof Validity: The Zero-Knowledge Proof itself is public information, which allows any consensus member to execute the Validate function and verify the validity of the underlying computation without accessing the hidden transaction data.
  • Regulatory Lists: The Issuer-Asset-Auditor list (LIAA) and the Key-Asset list (LKA) are publicly maintained lists used for compliance lookups and asset registration.
  • Settlement Status and Metadata: The fact that a transaction occurred, its unique identifier, and the transition of its settlement status (e.g., from pending to finalized) are recorded publicly.

Key Nuances in Execution and Fee Payment​

Signing Key vs. Proof Validation​

The transaction submitted to the Polymesh network must be signed by a standard Polymesh key. However, this key's role is typically limited to covering network fees and authorization for submission, not validating the integrity of the confidential transfer:

  • Decoupled Validation: In PCA, validation relies on the Zero-Knowledge Proof. If the proofs provided by the counterparties (sender, receiver, mediator) are valid, the transaction is accepted, regardless of the submitter's specific public signing key.
  • Settlement Affirmation: Settlement logic requires explicit affirmations proven by the ZKP, where the user that generates the proof proves ownership of the secret key corresponding to the confidential account, not the standard signing key used for network interaction.

Fee Mechanism and Privacy​

While PCA ensures that asset details and account balances remain confidential, the use of POLYX for network fees presents a potential privacy leakage risk. Because POLYX transactions are public on the Polymesh ledger, the address paying the fee can often be linked to a user's identity.

To maintain full anonymity, users should consider the following options to decouple their identity from their confidential transactions:

  • One-Time Use Wallets (Large Pool Funding): A user can generate a fresh wallet for a confidential transaction. To prevent this new wallet from being linked back to their main identity, it should be funded from a large, mixed pool, such as a withdrawal from a Centralized Exchange (CEX). This breaks the on-chain link between the user's primary holdings and the fee-paying account.
  • Third-Party Relayer Services (Off-chain Payment): Users can employ a relayer to submit transactions on their behalf. The relayer pays the on-chain POLYX fee using their own account. The user can then reimburse the relayer through a separate, private channel (such as an off-chain payment or a different cryptocurrency), ensuring no traceable POLYX movement appears on the Polymesh ledger.
  • Anonymous Fee mechanism: For users who want to pay network fees directly on-chain, without managing additional keys, while maintaining anonymity, PCA provides an on-chain anonymous fee payment mechanism. Users fund a confidential fee account and generate Zero-Knowledge Proofs to authorize fee deductions from a pooled system account. This proof is then shared with a Relayer Service that submits the transaction on your behalf. For detailed mechanics, see Anonymous Fees.
  • Network-Level Anonymity: Even with these fee strategies, "network leakage" (such as an IP address) can reveal a user's identity. For maximum privacy, these fee-hiding techniques should be used alongside network-layer protections like a VPN or the Tor network.

By using these methods, users ensure that the public requirement to pay for network resources does not undermine the private nature of their confidential asset transfers.

Background: DART → PCA​

PCA is the Polymesh implementation of P-DART (Polymesh - Decentralized, Anonymous, and Regulation-friendly Tokenization), which evolved from the DART protocol to address the specific settlement and compliance requirements of regulated financial markets.

P-DART: An Evolution for Settlement and Compliance​

While DART provides the cryptographic foundation for decentralized, anonymous accounts and transfers, P-DART extends this model to support multi-party, regulated settlement workflows:

  • Settlement Creation: P-DART allows a creator to define complex settlements with multiple "legs," where each leg specifies a sender, receiver, asset type, and value. This enables multi-asset, multi-party transactions in a single atomic operation.
  • Explicit Counterparty Affirmations: Settlements require active consent (affirmation or rejection) from all designated participants (sender, receiver, and optionally mediators) before execution. This aligns blockchain payments with real-world regulatory requirements, such as those in securities transfers.
  • Prospective Regulatory Control (Mediators): Beyond DART's retrospective auditor model, P-DART introduces mediators: active participants who must explicitly affirm or reject a pending settlement. This enables real-time regulatory intervention when required by policy or law.
  • Operational Controls: P-DART adds administrative tools like account freezing (to prevent updates) and forced transfers (for key loss recovery or clawbacks), essential for regulated asset lifecycles.
  • Anonymous Fee Payment: P-DART incorporates a sophisticated Relayer Flow using confidential fee accounts and Zero-Knowledge Proofs, allowing users to pay network fees anonymously without compromising privacy or enabling DoS attacks.

In essence: DART is the foundation for private accounts and transfers; P-DART is the framework for regulated, multi-party settlement and compliance.

Core Building Blocks (Concepts)​

  • Commitments: Hide an account state while binding it to a unique state update.
  • Curve trees / accumulators: Allow a participant to prove “my committed state is in the set of valid states” without revealing which one.
  • Nullifiers: A one-way tag that prevents the same old state from being used twice.
  • Zero-knowledge proofs: Prove well-formed updates (including range/consistency checks) without revealing the secret state.
  • Auditors and mediators: Asset-specific encrypted visibility and optional “must-affirm” workflow support.

Compliance Roles: Auditors and Mediators​

Confidential Assets introduce two hidden roles for regulated assets:

  • Auditors: Can decrypt asset-specific settlement payloads to inspect transaction details (sender, receiver, asset, value) for retrospective review and reporting. Do not gate settlement, transfers execute regardless of auditor review.
  • Mediators: Possess all auditor capabilities (can decrypt and inspect asset-specific legs), but must also affirm or reject pending settlements before they execute. Settlement remains pending until mediators act when required by asset policy. This provides prospective regulatory control.

This dual model lets issuers choose between passive auditability (auditors only) or active intervention (auditors + mediators) per asset type.

Transfer/Settlement Workflow (Summary)​

Confidential settlement is multi-step to support receiver affirmation and optional mediation:

  1. Create settlement: Publish encrypted legs + a settlement proof.
  2. Affirmations: Sender, receiver, and optionally mediator affirm or reject.
  3. Claim/finalization: Receiver claims to credit value into finalized balance.

This separation enables “accept/reject first, credit later” semantics for regulated assets.

Proof of Balance and Operational Controls​

Implementation Status

Proof of Balance, account freezing, and forced transfer features are not available in the initial devnet launch. Support for these capabilities will be added in future releases.

  • Proof of Balance (PoB): Prove an asset balance to a verifier without revealing history. Implemented via counters and optionally counter-update transactions.
  • Account freezing: Gate or prevent updates in exceptional cases under authorization.
  • Forced transfer: Support recovery/key-loss and clawback flows under policy.

Learn More​