How It Works

Phase 1 — Identity Setup

One-time, done during onboarding

1. 01

   Connect your wallet

   Connect with any EVM wallet (MetaMask, WalletConnect, Coinbase Wallet, Privy social login, etc.). The wallet is used only to sign a message — not to hold privacy funds directly.
2. 02

   Set a PIN

   You choose a numeric PIN. Dust derives your private stealth keys using PBKDF2(wallet_signature + PIN, salt, 100 000 iterations). The PIN never leaves your browser. Neither the wallet signature nor the PIN alone are sufficient — both are required.
3. 03

   Register a .dust name

   Your stealth meta-address (a pair of secp256k1 public keys: spendKey and viewKey) is registered on the StealthNameRegistry contract under a name like alice.dust. This is what senders look up. It contains no balance information and maps to no single address.

Phase 2 — Receiving a Payment

Sender-side, no interaction from recipient needed

1. 01

   Sender looks up alice.dust

   The sender visits /pay/alice (or uses any UI that queries StealthNameRegistry). The contract returns Alice's meta-address: her two public keys.
2. 02

   Stealth address is derived (ECDH)

   The sender picks a random scalar r, computes a shared secret via Elliptic Curve Diffie–Hellman: sharedSecret = r × viewKey. A fresh one-time stealth address is derived: stealthAddress = spendKey + hash(sharedSecret) × G. This address is unique every time — the same sender paying Alice twice produces two completely different addresses.
3. 03

   ETH is sent to the stealth address

   The sender broadcasts a normal ETH transfer to stealthAddress. Simultaneously, an announcement (ephemeralPubKey R, stealthAddress) is emitted on the ERC5564Announcer contract — it's the encrypted hint Alice's scanner uses.

Phase 3 — Detecting & Claiming

Recipient-side, runs automatically in the browser

1. 01

   Scanner polls announcements

   Every 30 seconds, the in-browser scanner fetches new announcements from ERC5564Announcer. For each announcement it recomputes sharedSecret = viewKey × R and checks whether the derived address matches the announced stealthAddress.
2. 02

   Stealth private key is derived

   When a match is found, Alice derives the stealth private key: stealthPrivKey = spendKey + hash(sharedSecret). This key controls the funds. It never leaves the browser — it is computed in memory and used only to sign.
3. 03

   Gasless claim via ERC-4337

   Alice clicks Claim. The stealth key signs a UserOperation locally. A sponsored relayer submits it to the EntryPoint contract. The DustPaymastercovers gas. A StealthAccount is deployed at a CREATE2 address and immediately drains its balance to Alice's designated claim address — all in one atomic transaction.

Phase 4 — Consolidation (Privacy Pool)

Optional — breaks the fan-in correlation

If you receive 10 stealth payments and claim all of them to the same address, an on-chain observer can see 10 claim transactions landing at one wallet. DustPool V2 breaks this link with a ZK-UTXO model — deposit any amount, withdraw with a FFLONK proof, optionally split into common denominations to prevent amount fingerprinting.

1. 01

   Deposit any amount to DustPoolV2

   Deposit ETH or ERC-20 tokens in any amount — no fixed denominations required. Your browser computes a Poseidon commitment C = Poseidon(ownerPubKey, amount, asset, chainId, blinding)and a nullifier N = Poseidon(nullifierKey, leafIndex). The commitment is inserted into a relayer-maintained off-chain Merkle tree (depth 20).
2. 02

   Generate a FFLONK ZK proof (in-browser)

   When withdrawing, the browser generates a FFLONK proof (no trusted setup required) using the 2-in-2-out transaction circuit (~12,400 constraints). Public inputs include: merkleRoot, nullifier0, nullifier1, outCommitment0, outCommitment1, pubAmount, pubAsset, recipient, chainId. For denomination privacy, use the 2-in-8-out split circuit (~32,000 constraints) to break withdrawals into common denomination chunks automatically.
3. 03

   Relayer verifies and executes

   The proof is submitted to a relayer (same-origin Next.js API) which verifies the FFLONK proof on-chain via DustPoolV2.withdraw(). The contract checks: (1) Merkle root validity, (2) nullifier freshness, (3) chainId binding, (4) FFLONK proof verification, (5) solvency. Funds are sent to your chosen recipient. For split withdrawals, withdrawSplit() processes up to 8 output notes in one transaction.

Compliance Layer

Built-in accountability without sacrificing privacy

1. 01

   Deposit screening (Chainalysis Oracle)

   Every deposit is screened against the Chainalysis sanctions oracle. If the depositor's address is flagged, the transaction reverts with DepositBlocked(). This prevents sanctioned funds from entering the privacy pool.
2. 02

   1-hour cooldown period

   After depositing, a 1-hour cooldown enforces that withdrawals can only go to the original depositor's address. After the cooldown expires, funds can be withdrawn to any address. This gives compliance systems time to flag suspicious deposits.
3. 03

   Voluntary disclosure via view keys

   Users can derive a view key from their stealth keys and generate a self-authenticating disclosure report. The report lists all notes (deposits, transfers, withdrawals) with amounts and Poseidon commitment verification — without revealing spending keys. Useful for tax reporting, audits, or regulatory compliance.

Phase 5 — Private Swaps

Optional — swap tokens without a traceable on-chain signature

1. 01

   Generate a FFLONK proof for withdrawal

   The browser generates a FFLONK proof against your DustPoolV2 UTXO notes — the same 2-in-2-out transaction circuit used for regular withdrawals. The proof targets DustSwapAdapterV2 as the recipient, binding the withdrawal to the swap adapter contract.
2. 02

   Atomic withdraw-swap-deposit via DustSwapAdapterV2

   The relayer submits the swap to DustSwapAdapterV2, which executes three steps atomically: (1) withdraws from DustPoolV2 using your FFLONK proof, (2) swaps on a vanilla Uniswap V4 pool (no custom hook), (3) deposits the output tokens back into DustPoolV2 with an on-chain Poseidon commitment. All three steps succeed or revert together.
3. 03

   Receive new UTXO notes

   After the swap completes, you hold new DustPoolV2 UTXO notes denominated in the output token. The swap leaves no traceable link between input and output — the adapter contract is the only visible on-chain participant. Your new notes can be withdrawn or used in further transfers normally.