Private Transfer
A private transfer moves shielded tokens from one vault to another without revealing the sender, recipient, amount, or asset type on-chain. It consumes one or two input notes owned by the sender and creates two new output notes — one for the recipient and one for the sender's change.
What the Circuit Proves
The transfer circuit (transfer.circom) generates a Groth16 zero-knowledge proof that attests, without revealing private data:
- Each real input note exists in a commitment tree of the Merkle forest.
- The sender knows the
spending_keycorresponding to theownerPkembedded in each input note (via BabyJubJub key derivation — see below). - Output commitments are computed correctly.
- Total input value equals total output value plus the gasless fee.
- All notes use the same asset.
- No value exceeds the u128 range.
- When two real inputs are used, their nullifiers are distinct (no self-double-spend in a single transaction). The pallet enforces this independently of the proof: two equal non-dummy nullifiers are rejected on-chain.
- Dummy input nullifiers are forced to zero.
Key Design: BabyJubJub Key Derivation
Ownership is proven by key derivation, not a signature. The circuit derives the owner public key from the spending key inside the R1CS system:
ownerPk.Ax = BabyPbk(spending_key).Ax
The prover must know the spending_key whose scalar multiplication of the
BabyJubJub base point Base8 produces the Ax coordinate embedded in the note
commitment. That is the discrete logarithm relation on the curve — it cannot be
faked, and the prover cannot substitute an arbitrary ownerPk.
This is a stronger statement than a signature check: BabyPbk proves knowledge of
the private key directly, where EdDSA only proves knowledge of a valid signature.
The derived Ax is bound to the note commitment, so an attacker cannot swap in a
different public key even if they could forge a signature-style check.
See Keys & Identity for where spending_key comes from.
Key Design: Dummy Note Support
Private transfers always consume exactly two input slots and produce exactly two output slots. When a user has only one note to spend, the second slot is filled with a dummy note — a placeholder with value = 0.
is_dummy[i] = IsZero(input_values[i])
IsZero is deterministic in R1CS: a prover cannot claim is_dummy = 1 for a note with value > 0. This is the same technique used in Zcash Sapling.
Dummy slots skip:
- Merkle membership verification
- Nullifier derivation and correctness check
- Ownership (BabyPbk) check
Dummy slots are still bound by:
nullifiers[i] * is_dummy[i].out === 0— the nullifier for a dummy slot must be zero. A prover cannot insert a real nullifier in the dummy slot while bypassing membership checks.- The anti-spam check in the pallet: a transaction where all nullifiers are zero (both inputs dummy) is rejected at the transaction pool level.
Public Inputs (On-Chain)
| Field | Type | Description |
|---|---|---|
merkle_root | Field | Commitment tree root at proof generation time |
nullifiers[2] | Field[2] | Nullifiers of the consumed input notes |
commitments[2] | Field[2] | Commitments of the newly created output notes |
asset_id | Field | Asset being transferred (must match all note asset IDs) |
fee | Field | Gasless fee deducted from input sum; credited per the dispatch origin — see Who receives the fee |
Private Inputs (Prover Only)
Input Notes (Consumed)
| Field | Type | Description |
|---|---|---|
input_values[2] | u128[2] | Note values (set second to 0 for a dummy slot) |
input_asset_ids[2] | Field[2] | Asset IDs of input notes |
input_blindings[2] | Field[2] | Random blinding factors used when the notes were created |
spending_keys[2] | Field[2] | Secret keys — derive ownerPk via BabyPbk and compute nullifiers |
Merkle Proofs
| Field | Type | Description |
|---|---|---|
input_path_elements[2][20] | Field[2][20] | Sibling hashes for each Merkle proof |
input_path_indices[2][20] | u8[2][20] | Path directions per level (0=left, 1=right) |
Output Notes (Created)
| Field | Type | Description |
|---|---|---|
output_values[2] | u128[2] | Values of the new output notes |
output_asset_ids[2] | Field[2] | Asset IDs of the output notes |
output_owner_pubkeys[2] | Field[2] | Ax coordinate of each recipient's key |
output_blindings[2] | Field[2] | Random blinding factors for output notes |
Security Properties
BabyPbk(spending_key) derives ownerPk inside the circuit. The prover must know the private scalar whose multiplication by Base8 equals the ownerPk in the note.
Nullifiers are inserted into the pallet's nullifier set after each transaction. When both inputs are real, the circuit enforces that their nullifiers are distinct — a note cannot be spent twice in the same transaction.
IsZero(value) is deterministic in R1CS. A prover cannot claim is_dummy = 1 for a note with value > 0. Dummy nullifiers are forced to zero and cannot be used to spend a real note while bypassing Merkle checks.
The pallet rejects any private_transfer where all nullifiers are zero (both inputs dummy). This prevents free Merkle tree inflation. Enforced in both validate_unsigned (tx pool) and execute (extrinsic).
Circuit Parameters
| Parameter | Value |
|---|---|
| Constraints | 33,687 |
| Tree depth | 20 (up to 1,048,576 notes per tree) |
| Public inputs | 7 (merkle_root, nullifiers[2], commitments[2], asset_id, fee) |
| Private inputs | 9 scalars + 40 Merkle path elements |
| Proving scheme | Groth16 / BN254 |
| Proving time | ~2–3 s (client machine) |
| Verification time | ~15 ms |
The proving key distributed with this release uses a single-party trusted setup. It is not secure for production use. A multi-party ceremony with 50+ participants is required before mainnet.
Known Limitations
- The circuit processes exactly 2 input notes and 2 output notes. Single-note spends require a dummy slot.
- There is no range check on output note values individually — only the conservation constraint and u128 range on inputs enforce correctness. Incorrect output splits would still satisfy the circuit but produce an unspendable change note.
- Recipient anonymity depends on the viewing key encryption scheme, not on this circuit directly.