Cloak Technical Documentation

What Cloak protects against

• On-chain observers — any party indexing the settlement chain cannot determine which deposit funded which card or transfer. Deposits, withdrawals, and card-authorization events share a single indistinguishable nullifier set.
• Relayer operators — a single malicious relayer cannot deanonymize a transfer. Proofs carry no sender identity; the relayer learns only (commitment set root, nullifier, recipient payload, amount). IP metadata is stripped at the first hop.
• BIN sponsor / issuer — the card issuer sees authorization requests for a DPAN but never sees which wallet funded the card's underlying balance. The funding event is on a different system boundary.

What Cloak does NOT protect against

• Merchant-level deanonymization — if you give a merchant your shipping address, they know where you live. The protocol cannot help.
• Timing correlation at low pool sizes — a deposit followed immediately by a withdrawal of the same denomination still links statistically. The anonymity set is the pool, not the protocol.
• Compelled disclosure — the BIN sponsor, under subpoena, can disclose transaction logs tied to a DPAN. Cloak severs the on-chain linkage, not legal process against the issuer.
• Device compromise — keys live in the user's browser / phone. A compromised device compromises the wallet.

Trust assumptions

• At least one honest relayer in the batch path. With ≥3 hops the link is broken if any one is honest.
• Groth16 soundness assuming the toxic waste of the trusted setup was properly discarded. Cloak uses the Powers of Tau #84 (BN254) universal SRS.
• Solana liveness and finality (~12s). No Cloak property depends on re-orgs beyond the standard confirmation window.
• The BIN sponsor maintains its license with the card network. If the sponsor is terminated, card authorizations stop until a replacement program is onboarded.

Flow: funding a card

1. User generates a note locally — a tuple (sk, rho, amount, asset). Commits C = Poseidon(sk, rho, amount, asset).
2. Wallet submits a deposit transaction transferring amount of asset into the Shielded Pool SPL, along with the commitment C.
3. The pool appends C to an append-only Merkle tree of depth 32. Tree root is updated.
4. Later, user signs a card-mint intent I and produces a Groth16 proof that: (a) they know sk, (b) C is in the tree, (c) the nullifierN = Poseidon(sk, C) has not been spent.
5. The proof and I travel through N relayer hops. Each hop re-signs and shuffles the batch before forwarding to the issuer.
6. Issuer verifies the proof, consumes the nullifier, credits the card's prefund balance with the BIN sponsor, and emits a provisioning token to the user's phone wallet.

deposit.circom

Proves that a fresh commitment was correctly formed from a secret note. No Merkle membership yet; the deposit itself inserts the commitment. This circuit is optional — clients can submit the commitment directly for simple deposits, or use the circuit to prove the amount range.

pragma circom 2.1.9;
include "poseidon.circom";
include "comparators.circom";

template Deposit() {
    signal input sk;         // secret key, private
    signal input rho;        // random nonce, private
    signal input amount;     // private
    signal input asset;      // private, but range-checked
    signal output C;         // public commitment

    // range: amount <= 2^40 so fits in 13 decimals of USDC
    component lte = LessEqThan(40);
    lte.in[0] <== amount;
    lte.in[1] <== (1 << 40);
    lte.out === 1;

    component hash = Poseidon(4);
    hash.inputs[0] <== sk;
    hash.inputs[1] <== rho;
    hash.inputs[2] <== amount;
    hash.inputs[3] <== asset;
    C <== hash.out;
}
component main = Deposit();

spend.circom

The main privacy-preserving circuit. Proves (a) ownership of a note whose commitment is in the Merkle tree, (b) derivation of a unique nullifier, (c) a correct fresh output commitment for the change note, (d) that input amount ≥ output + fee.

template Spend(depth) {
    // public
    signal input root;         // Merkle root of commitments
    signal input nullifier;    // derived from (sk, C_in)
    signal input C_out;        // fresh commitment
    signal input fee;          // relayer fee in native units
    signal input extDataHash;  // binds to off-chain payload

    // private
    signal input sk, rho_in, amount_in, asset_in;
    signal input pathElements[depth];
    signal input pathIndices[depth];
    signal input rho_out, amount_out;

    // 1. recompute input commitment
    component cIn = Poseidon(4);
    cIn.inputs <== [sk, rho_in, amount_in, asset_in];
    signal C_in <== cIn.out;

    // 2. Merkle membership
    component mt = MerkleProof(depth);
    mt.leaf <== C_in;
    mt.root <== root;
    for (var i = 0; i < depth; i++) {
        mt.pathElements[i] <== pathElements[i];
        mt.pathIndices[i] <== pathIndices[i];
    }

    // 3. nullifier = Poseidon(sk, C_in)
    component nf = Poseidon(2);
    nf.inputs[0] <== sk;
    nf.inputs[1] <== C_in;
    nf.out === nullifier;

    // 4. output commitment C_out = Poseidon(sk, rho_out, amount_out, asset_in)
    component cOut = Poseidon(4);
    cOut.inputs <== [sk, rho_out, amount_out, asset_in];
    cOut.out === C_out;

    // 5. conservation: amount_in === amount_out + fee
    amount_in === amount_out + fee;
}
component main = Spend(32);

Batch structure

interface RelayBatch {
  // list of Groth16 proofs for spend intents
  proofs: Uint8Array[];          // each 127 bytes
  publicInputs: PublicInputs[];  // root, nullifier, C_out, fee, extHash
  payloads: EncryptedPayload[];  // onion-encrypted per hop
  batchRoot: Hash;               // Poseidon over publicInputs
  relayerSig: EdDSASignature;    // signed by the forwarding relayer
  receivedAt: number;            // unix ms, for timing analysis
  hopIndex: number;              // 1 <= hopIndex <= 3
}

Operational parameters

Onboarding a relayer

1. Generate an Ed25519 identity keypair. Publish the public key and astratum.json containing endpoint, version, supported hop indices, fee, TLS cert fingerprint.
2. Submit a self-attested registration tx to the on-chain relayer directory. No stake is required — discovery is permissionless.
3. Clients observe uptime and performance. Poorly performing relayers are silently pruned from the default routing set but can be selected manually.

Authorization flow

1. User's phone wallet presents DPAN via NFC
2. Merchant acquirer → Visa DPS → BIN sponsor authorization endpoint
3. BIN sponsor forwards auth request to Cloak program manager
4. Program manager checks card's prefund balance (held per-DPAN at sponsor)
5. Approve/decline response returned synchronously
6. On approve: sponsor reserves balance; settlement at T+1 from pool
7. Pool sends stablecoin to sponsor settlement account via on-chain tx
8. Sponsor converts on-chain USDC → fiat USD for network settlement

Why the user doesn't KYC

The sponsor's card program is licensed under a prepaid + stored-value framework that permits KYC-lite issuance under $2,500 per card and $10,000 aggregate per holder per year (FinCEN general exemption § 1022.380). Cloak's cards fall within these thresholds by design. For higher-limit persistent cards, the user completes the sponsor's own KYC; at that point, Cloak's privacy guarantees extend only to the on-chain link, not to the sponsor.

Settlement timing

Apple Pay IAP sequence

1. Cloak app requests a provisioning token from the BIN sponsor, including: card FPAN, PAR, requested wallet (Apple).
2. Sponsor calls Visa Token Service; VTS returns an encrypted payload (manifest) and TOS-signed activation data.
3. App calls PKAddPaymentPassRequest with the encrypted payload. iOS hands to the Secure Enclave.
4. Apple Pay displays the card. Subsequent NFC payments use the DPAN — the FPAN is never broadcast.

PAR linkage

Every card — regardless of DPAN or FPAN — carries a stable Payment Account Reference. PAR lets compliance, fraud, and chargeback systems correlate transactions across wallet instances without revealing the underlying PAN. Cloak embeds the PAR into the sponsor program; we do not create our own.

Derivation

// BIP-39 mnemonic -> 64-byte seed
const seed = mnemonicToSeedSync(mnemonic);

// Cloak-specific root
const root = hkdf(seed, info = "cloak-root-v1", length = 32);

// Note key: per-deposit, non-repeating
function noteKey(index: number): Scalar {
  return hkdf(root, info = `note-${index}`, length = 32);
}

// Signing key: one per device
const signingKey = hkdf(root, info = "sign-v1", length = 32);

Storage

• Browser — seed is encrypted with user-entered passphrase, stored in IndexedDB. Never uploaded.
• Mobile — seed lives in Secure Enclave (iOS) / StrongBox (Android). Face/Touch unlocks a per-session copy.
• Recovery — write down the 12 words. No social recovery, no guardian, no email reset. Cloak cannot restore access. This is explicit, not a bug.

Audits

Bug bounty

Administered via Immunefi. Live program. Severity ladder matches Immunefi Vulnerability Severity Classification v2.3 for DeFi.

Repositories