Documentation

Understanding privacy-preserving token swaps with zero-knowledge proofs

Overview

Arcane Pool is a privacy-preserving Automated Market Maker (AMM) built on the EncryptedERC protocol. It enables token swaps where user identities, balances, and swap amounts remain fully encrypted on-chain.

Traditional DEXs like Uniswap expose every transaction detail publicly — who traded, how much, and their full balance history. Arcane Pool eliminates this information leakage while maintaining the same constant-product AMM mechanics.

The system achieves this by combining homomorphic encryption (which allows computation on encrypted data) with zero-knowledge proofs (which verify correctness without revealing inputs).

Privacy Model

Arcane Pool provides transaction-level privacy — each swap hides the trader's identity and the exact amounts exchanged. The privacy is achieved through three cryptographic layers:

ElGamal Encryption

All user balances are stored as encrypted ciphertexts using additively homomorphic ElGamal encryption on BabyJubJub. The contract can update balances without ever seeing plaintext values.

Zero-Knowledge Proofs

Groth16 proofs verify that swaps are valid — correct amounts, sufficient balances, proper encryption — without revealing any private inputs to the blockchain.

Poseidon Commitments

Privacy Commitment Tuples (PCTs) enable authorized auditors to verify compliance while keeping details hidden from the public.

What Is Private vs Public

Understanding exactly what information is hidden and what is visible is critical for assessing the privacy guarantees of the system.

Hidden On-Chain (Private)

User Identity

The actual person performing a swap is never linked to the transaction. Swaps are executed through a relayer pattern.

Swap Amounts

The exact amount of tokens being exchanged is encrypted. Neither the input nor the output amount is stored in plaintext.

User Balances

Every balance is stored as an ElGamal ciphertext (encrypted point on BabyJubJub). Only the owner's private key can decrypt it.

Transfer Linkability

No one can link which transfers belong to which user. The encrypted balance update reveals nothing about the operation.

Balance History

Even though the encrypted balance is updated after each swap, observers cannot determine the new plaintext balance or the delta.

Visible On-Chain (Public)

Pool Reserves

Total reserves in the pool are stored in plaintext. This is necessary for the AMM pricing formula (x * y = k) to function.

Swap Direction

Whether the swap was Token A → Token B or vice versa is visible from the reserve changes, though the exact amounts remain hidden.

Trade Count

The total number of swaps is publicly incremented. This is a metadata leak that could be mitigated in future versions.

Pool Configuration

Fee rate, token addresses, and pool existence are all public. These are structural parameters, not user data.

Encrypted Ciphertexts

The encrypted balance representations are stored on-chain, but they are computationally infeasible to decrypt without the private key.

Auditor-Decryptable (Compliance)

Transaction Amounts

The designated auditor can decrypt the Privacy Commitment Tuples (PCTs) attached to each transfer to verify the exact amounts.

Sender/Receiver Info

PCTs contain encrypted sender and receiver data that only the auditor's private key can unlock, enabling compliance checks.

How Swaps Work

A private swap in Arcane Pool happens in a carefully orchestrated sequence. Here is what happens when you click “Swap”:

1

Quote Calculation

client-side

The AMM computes the output amount using the constant-product formula with public reserve values. This is the only step that uses plaintext math.

2

Proof Generation — Trader Leg

off-chain

A Groth16 zero-knowledge proof is generated proving: (a) the trader has sufficient encrypted balance, (b) the encrypted transfer amount is correct, (c) the balance update is valid. The proof reveals nothing about actual values.

3

Proof Generation — Pool Leg

off-chain

A second proof is generated for the pool's side of the trade — proving the pool can send the output amount and that the encrypted balance updates are correct.

4

Atomic Swap Execution

on-chain

Both proofs are submitted to the AMM contract in a single transaction. The contract verifies both proofs on-chain and executes both transfers atomically — either both succeed or both revert.

5

Reserve Update

on-chain

The pool's plaintext reserves are updated, and a PrivateSwap event is emitted containing only the new reserve values and direction — no amounts or identities.

Cryptographic Primitives

BabyJubJub Curve

A twisted Edwards curve embedded in the BN254 scalar field. It provides the elliptic curve operations needed for key generation, ElGamal encryption, and Poseidon hashing — all efficiently provable in ZK circuits.

Field: BN254 | Type: Twisted Edwards | Security: ~126 bits

ElGamal Encryption (Additive Homomorphic)

Balances are encrypted as points on BabyJubJub. The additively homomorphic property means the contract can add encrypted amounts to encrypted balances without decryption: E(a) + E(b) = E(a+b).

Ciphertext: (C1, C2) ∈ BabyJubJub² | Homomorphic: Additive

Groth16 ZK-SNARKs

The proof system used for all privacy operations. Proofs are ~200 bytes, constant-size regardless of circuit complexity. Verification is performed on-chain in the Solidity smart contract.

Proof: 3 group elements | Verification: ~230k gas | Trusted Setup: Required

Poseidon Hash

A ZK-friendly hash function used for privacy commitment tuples (PCTs). Much more efficient inside arithmetic circuits compared to SHA-256 or Keccak.

Field: BN254 | Rounds: 57 | Rate: 2

Auditor Role

The auditor is a designated entity that holds a special private key capable of decrypting the Privacy Commitment Tuples (PCTs) attached to each transfer. This creates a controlled transparency model.

Every encrypted transfer includes two PCTs: one for the receiver (so they can verify the amount sent to them) and one for the auditor (so compliance can be verified when required). The auditor cannot modify transactions, freeze funds, or interfere with the protocol — they can only read the encrypted details.

In a regulated environment, this allows compliance teams to perform AML/KYC checks on flagged transactions without compromising the privacy of all other users. The auditor sees individual transaction details only — not the full balance history of any user.

Architecture

The Arcane Pool demo runs three services locally:

Hardhat Node

:8545

Local Ethereum blockchain running all smart contracts including EncryptedERC tokens, the AMM, ZK verifiers, and the Registrar.

API Server

:3001

Backend service running inside the Hardhat runtime for access to ZK proof generation (zkit). Handles swap execution, balance queries, and pool state.

Frontend

:3000

This Next.js application. Provides the swap interface, pool visualization, privacy indicators, and documentation.

Smart Contract Stack

The on-chain components include:

  • EncryptedERC — Privacy-preserving ERC20 with encrypted balances, ZK-verified transfers, and operator approval for AMM integration
  • EncryptedAMM — Constant-product AMM that coordinates atomic swaps using two encrypted transfers
  • Registrar — Manages user registration with ZK proof of key ownership
  • Groth16 Verifiers — On-chain ZK proof verification contracts for Registration, Mint, Transfer, Burn, and Withdraw circuits
  • BabyJubJub Library — Elliptic curve operations for on-chain encryption

Using Arcane Pool

Quick Start

Run the entire demo with a single command from the project root:

./run-arcane-pool.sh

This script will:

  1. Start a local Hardhat blockchain node
  2. Deploy all contracts (verifiers, registrar, 2 EncryptedERC tokens, AMM)
  3. Register seed users (Pool Custodian + initial traders) with ZK registration proofs
  4. Mint tokens: Pool (10,000 / 10,000), Phantom (5,000 AUR / 3,000 NOC), Specter (3,000 AUR / 5,000 NOC)
  5. Enable dynamic account onboarding so you can create unlimited additional traders from the UI
  6. Create a liquidity pool and approve the AMM as operator
  7. Start the API server and frontend

Multi-Account Testing

To verify privacy, open the swap interface in both a regular browser tab and an incognito window:

  1. In Tab 1, create or select a trader account
  2. In Tab 2 (incognito), create/select a different trader
  3. Perform a swap in Tab 1 — notice that Tab 2 sees the pool reserves update but cannot see who made the swap or the exact amounts
  4. Perform a swap in Tab 2 — Tab 1 sees reserve changes only

This demonstrates the core privacy guarantee: the pool state is shared and public, but individual transaction details are provably hidden.

Account Controls

  • Create unlimited accounts from the top-right `+ New Account` action
  • Import account using private key
  • Switch active trader from dropdown
  • Copy addresses directly from dropdown and Accounts panel
  • Private keys are accepted only during import and never displayed or stored in frontend UI
  • Fund selected account with AUR/NOC/native test balance using the Funding card

Demo Tokens

The demo uses two themed tokens that match the Arcane Pool aesthetic:

  • Aurum (AUR) — The gold token, representing value and light
  • Noctis (NOC) — The night token, representing shadow and mystery