The Alberta Buck - Notes Flow (v2)

Alice's wallet has done all the slow work before any transaction is broadcast:

• She owns 1,200 BUCK on-chain.
• She has decided on the denomination split: [1000, 100, 25, 25, 25, 25]. N=6. The deployed mint pipeline pins a small set of batch sizes – recommended {16, 128, 1024} – one circom circuit and one verifier per pin. Alice's wallet rounds her requested split up to the smallest pin N* >= 6, here N* = 16, and pads with 16 - 6 = 10 "blinded zero" openings whose v_i = 0. The padding leaves cost the same SNARK constraints as live notes but contribute zero to totalFace and are spendable for zero BUCK; in effect they are anonymity-set filler whose openings Alice may discard. The narrative below tracks the six live notes and ignores the ten dummies (they show up in the on-chain commitments[] vector alongside the live ones, indistinguishable to Mallory).
• She has chosen an idHash_i for each recipient (typically a Poseidon hash of the recipient's IdentityRegistry-bound ElGamal credential, derived once at out-of-band introduction time).
• Her CSPRNG produces a fresh rho_i nonce per leaf – live or padded.

She now has 16 opening tuples in memory: 6 live, 10 dummies.

For i = 0..15 (six live, ten dummies) her wallet computes

cm_i = Poseidon6( T_CM, flavor_i, v_i, rho_i, idHash_i, predicate_i )

This is pure off-chain Poseidon arithmetic in alberta_buck.wallet.notes. Sixteen uint256 field elements drop out. Their order in the eventual on-chain array is fixed by Alice's local list – the contract preserves whatever order she submits, and the SNARK assumes leaves land in the tree at indices [nextLeafIndex, nextLeafIndex+1, ..., nextLeafIndex+N-1] in submission order.

Alice's wallet must also keep a local mirror of the rolling tree state. The Tornado-style Merkle tree the contract maintains is parameterised by the standard filledSubtrees[d] for d = 0..TREE_DEPTH-1 – the rightmost partially-built node at each level. The wallet snapshots this state from the chain (or replays it from the mint event log) immediately before assembling the proof, then derives, for each of the 16 leaves in submission order, the depth-20 sibling sequence the in-circuit insertion will consume. That derivation is the one delicate piece of wallet-side mint code; everything else is straightforward Poseidon arithmetic.

Alice's wallet runs scripts/snark/prove_mint_batch.js. The mint_batch.circom circuit at her chosen pin N* = 16 takes a witness that covers not just the openings but the tree update itself, because the Merkle insertion lives inside the SNARK.

Public signals (circom emits the circuit OUTPUTS first, then the public inputs; arity 2N+4):

issuerMode[i]   # i in 0..N-1: per-leaf PUBLIC=1 / PRIVATE=2 (a circuit OUTPUT,
                #   the deterministic flavor projection -- Notes.mint gates on it)
oldRoot         # the live note root she read from chain
newRoot         # the root after folding her N leaves
nextLeafIndex   # the live tree size she read from chain
totalFace       # 1200e18 -- range-bounded to 128 bits
cm[i]           # i in 0..N-1: the commitments, exposed DIRECTLY (not a batch hash)

The commitments are exposed as public inputs directly (no batch digest): each input costs ~6K gas in the EVM verifier, cheaper than recomputing a keccak over calldata on-chain, and far cheaper than an in-circuit Poseidon over N elements. (A2 / private-issuer batches use a separate circuit, mint_batch_a2, that exposes each leaf's eIss instead of issuerMode; see The Redemption and the Decryptability companion.)

Private witness (per-leaf and per-level):

For i in 0..N-1:
  flavor[i], v[i], rho[i], idHash[i], predicate[i]    # the opening
  pathSiblings[i][d] for d in 0..TREE_DEPTH-1         # 20 siblings per leaf

The pathSiblings for leaf i are derived by the wallet from its local filledSubtrees mirror plus the previously-folded leaves of this same batch (leaves 0..i-1 sit at known positions and contribute their Poseidon hashes to i's path on the right). The wallet does this work; the chain consumes only oldRoot, newRoot, and the calldata cms[].

In-circuit constraints:

1. Per-leaf opening. For each i, cm[i] === Poseidon6(T_CM, flavor[i], v[i], rho[i], idHash[i], predicate[i]). N Poseidon-6 evaluations, N equality constraints.
2. Range bounds. Each v[i] and totalFace passes through Num2Bits(128).
3. Sum conservation. sum(v[0..N-1]) === totalFace.
4. Rolling Merkle insertion. The circuit threads oldRoot and nextLeafIndex through N successive single-leaf insertions – the standard Tornado-style incremental-tree fold, performed in-circuit: at each step it folds cm[i] up the tree using pathSiblings[i][*] and Switcher(...) per level, advances the rolling state, and finally asserts the resulting root equals newRoot. N x TREE_DEPTH Poseidon-2 hashes (~4.3K constraints per leaf).
5. Flavor range + issuer mode. Each flavor[i] \in {A1=1, A2=2, B1=3}, and issuerMode[i] is the deterministic projection (A2 → PRIVATE, else PUBLIC), exposed as a public output. This is what makes a bearer leaf provably public-issuer (and a private-issuer bearer note unmintable – see the Decryptability companion, Why B2 is impossible).

Constraint counts work out to roughly 21,900 R1CS per leaf (opening + range-bound + dual Merkle walk: one path consumed to attest oldRoot, one to advance newRoot); the shipped pinned-N set measures 22,052 R1CS at N=1, 350,913 at N=16, and 701,697 at N=32. The doubling per pin holds linearly through the projected sizes (N=128 ~2.8M R1CS, N=1024 ~22M). At N=16 the 2^19 PTAU and ~6 s prover wall on a dev laptop are comfortable; at N=128 it is rapidsnark-and-minutes; at N=1024 it is hours plus a multi-GB zkey. The scripts/snark/setup.sh ceremony emits one verifier per pin.

The witness is processed by snarkjs's Groth16 prover. Tens of seconds to minutes later the wallet has a fixed-size proof object (pi_A: G1, pi_B: G2, pi_C: G1), encoded as ABI-static (uint256[2], uint256[2][2], uint256[2]) – exactly 256 bytes regardless of N.

Observation. The Groth16 proof reveals nothing about the witness. Soundness guarantees that no proofBytes can satisfy the verification equation unless a witness exists; zero-knowledge guarantees that the verification equation reveals nothing about which witness was used. Mallory, even with the proof in hand, cannot back out v[i], rho[i], idHash[i], flavor[i], predicate[i], or the per-leaf Merkle paths – only oldRoot, newRoot, nextLeafIndex, totalFace, the cm[i], and the per-leaf issuerMode[i] (flavor-class: public vs private, no identity) leak.

Alice now broadcasts a single transaction T_mint calling

// Minting is gated-only: a nameable issuer Identity is bound to every batch.
// Alice (a public Corporate Identity here) uses the PUBLIC overload:
notes.mint(
    proofBytes,
    oldRoot, newRoot, nextLeafIndex,
    1200e18,                       // totalFace
    [cm_0, cm_1, ..., cm_15],      // cms.length === N* (here 16)
    [PUBLIC, ..., PUBLIC],         // issuerMode (a SNARK public input of mint_batch)
    issuerSig                      // Schnorr by Alice's registered key over keccak(cms)
);
// A private (A2) issuer uses the other overload instead:
//   notes.mint(..., cms, issuerMode, a2Bindings)  // routes the proof to mint_batch_a2
//                                                  //   and ties each leaf's eIss
// There is no unbound mint path -- an unnameable note cannot be created.

The honest EVM walks Notes.mint (the PUBLIC overload):

// Stale-state guards + field bounds (_verifyMintOrRevert).
require(cms.length > 0,                            "Notes: empty mint");
require(issuerMode.length == cms.length,           "Notes: issuerMode/cms length");
require(oldRoot       == roots[currentRootIndex],  "Notes: stale oldRoot");
require(nextLeafIndex == self.nextLeafIndex,       "Notes: stale nextLeafIndex");
require(newRoot != 0 && newRoot < FIELD_R,         "Notes: bad newRoot");

// SNARK verify: the proof binds issuerMode + cm[] + the roots.  The
// MintVerifierAdapter dispatches by cms.length to the per-N Groth16 verifier;
// public-signal vector is [issuerMode[0..N), oldRoot, newRoot, nextLeafIndex,
// totalFace, cm[0..N)] (outputs lead), arity 2N+4.
require(mintVerifier.verifyMint(
            proofBytes, issuerMode, oldRoot, newRoot, nextLeafIndex, totalFace, cms
        ),                                         "Notes: bad mint proof");

// Public-issuer binding (gated-only): every leaf must be PUBLIC-mode,
// msg.sender must be a registered PUBLIC Identity, and issuerSig must be a valid
// Schnorr over keccak256(cms).  (The PRIVATE-mode overload instead routes the
// proof to mint_batch_a2 and verifies one A2 re-encryption binding per leaf,
// tying each committed leaf's eIss.)
require(identityRegistry.isPublicIdentity(msg.sender),
                                                   "Notes: public-mode leaf needs public issuer");
require(identityRegistry.verifyIssuerSchnorr(
            msg.sender, keccak256(abi.encodePacked(cms)), issuerSig),
                                                   "Notes: bad issuer binding");

// Pull BUCK only after the proof is accepted, then advance (_advanceAndPull).
require(buck.transferFrom(msg.sender, address(this), totalFace),
                                                   "Notes: transfer failed");
currentRootIndex = (currentRootIndex + 1) % ROOT_HISTORY_SIZE;
roots[currentRootIndex] = newRoot;
self.nextLeafIndex     += cms.length;
noteFaceSum            += totalFace;

// Single batch event; cms[] live in calldata.
emit Minted(msg.sender, totalFace, /*startIndex=*/ nextLeafIndex,
            /*count=*/ cms.length, newRoot);

Five things happen in strict order, and all of them are atomic (one transaction, one EVM state transition):

1. Stale-state guards. The contract asserts that oldRoot equals the current ring-buffer head and nextLeafIndex equals the live tree size. Either fails if another mint landed since Alice's wallet snapshotted state (more on this under Prover Contention and the Rollup Race below).
2. Calldata binding. The cms[] are exposed directly as Groth16 public inputs (no batch digest), alongside the per-leaf issuerMode[] the circuit emits, so any tampering with cms[] or issuerMode[] en route from the prover to the chain mismatches the SNARK and the verify call rejects.
3. SNARK verify. The MintVerifierAdapter dispatches by cms.length to the per-N verifier (one circuit per pin, one verifier contract per pin), unpacks the 256-byte proofBytes into Groth16 form, builds the 2N+4-entry public-signal vector [issuerMode[0..N), oldRoot, newRoot, nextLeafIndex, totalFace, cm[0..N)] (circuit outputs lead), and invokes the appropriate MintBatchN${N}Groth16Verifier. If the verifier returns false, the entire transaction reverts – nothing is written, no BUCK moves.
4. BUCK escrow. buck.transferFrom debits totalFace from Alice and credits the Notes pool. Allowance-driven pull, gated by Alice's prior approve(notes, 1200e18, E_notes, pi_CP). This CP-bound approve is mandatory: Alice is a private EOA, and mutual decryptability requires a per-pair CP fragment for every private party (the identityHash fallback is only valid for Public-Identity contracts). The pool was bound under a Public Identity (bindContract(notes, pk, E, true)), so the pool side falls back to _identityHash(notes) without requiring a fragment from the pool. The Notes operator decrypts Alice's CP ciphertext from the IdentityExchange event under subpoena.
5. Root advancement. The contract writes newRoot into the next ring-buffer slot, advances currentRootIndex and nextLeafIndex, accumulates noteFaceSum, and emits a single Minted(issuer, totalFace, startIndex, count, newRoot) event. The new root immediately becomes the live root that the next minter must read.

If any of (a)-(e) fails – stale root, stale leafIndex, bad proof, insufficient BUCK, missing approval – the entire transaction reverts and the chain state is indistinguishable from no submission at all. Alice gets one shot per transaction; she cannot retry a partial state.

Note on duplicate commitments. The contract carries no commitmentExists[cm] duplicate check – not because duplicates are harmless, but because they are economically self-punishing: if Alice submits the same opening twice (whether across two batches or twice in one), she pays totalFace on each occurrence, the leaves land at distinct tree indices, but the spend nullifier Poseidon3(T_NF, rho, idHash) is deterministic in the opening. After the first spend nullifies cm, the second copy is unspendable forever. Net result: Alice burns BUCK she could have kept. The chain's job is value conservation, not saving Alice from a buggy rho RNG.

After T_mint confirms, Alice transmits each live opening to its intended recipient by any out-of-band channel: an encrypted message, a printed QR code, a USB stick. The payload to recipient i is:

note_artifact_i = {
  txHash:    T_mint,                # Ethereum transaction ID
  leafIndex: startIndex + i,        # absolute position in the commitment vector
  cm:        cm_i,                  # for cross-checking against calldata
  opening:   ( flavor_i, v_i, rho_i, idHash_i, predicate_i ),
  meta:      { issuer: Alice's IdentityRegistry handle, batchSize: N*, ... },
}

The chain itself never sees opening. cm_i is already folded into newRoot; the artifact carries it explicitly only as a convenience so the recipient does not have to recompute it before locating it in the batch's calldata cms[].

The ten dummy openings Alice generated to pad to the pinned N=16 circuit receive no artifact; they are discarded (or, at Alice's option, retained privately as unspendable anonymity-set filler). From the recipient's perspective the presence of dummies is invisible: Bob's artifact only names his own leaf, and the batch total totalFace = 1,200 BUCK is exactly the sum of the live v_i.

Bob receives his artifact for the 1,000-BUCK note. Without trusting Alice and without any help from an indexer, he runs:

1. Recompute and check. Bob computes cm_check = Poseidon6(T_CM, flavor, 1000e18, rho, idHash, predicate) and asserts cm_check == cm. If this fails, Alice lied about the opening; Bob discards the artifact and demands a real one. (Binding of Poseidon makes substitution impossible.)
2. Look up the mint transaction. Bob reads T_mint on-chain, parses the call data into (proofBytes, oldRoot, newRoot, nextLeafIndex, totalFace, cms[]) and reads msg.sender from the transaction envelope.
3. Confirm msg.sender is Alice. Cross-check msg.sender against the IdentityRegistry: it must resolve to Alice's PS-credentialed identity. If Bob wanted an A1 identified cheque, the issuer field of his opening must match.
4. Confirm calldata membership. Assert cms[leafIndex - nextLeafIndex] == cm (where the artifact's leafIndex is the absolute position). The chain's acceptance of T_mint confirms that every entry in cms[] was folded into newRoot and that newRoot was added to the root ring buffer. Bob therefore has chain-anchored evidence that cm is officially a commitment in the pool.
5. Confirm batch totals. Read totalFace from the call data. The chain's acceptance of T_mint is itself a proof that the Groth16 verifier accepted – which means sum(v[0..N-1]) === totalFace holds in the witness. Bob does not need to re-verify the proof; the EVM already did. But if he wants belt-and-suspenders, he can re-run MintVerifierAdapter.verifyMint(proofBytes, issuerMode[0..N), oldRoot, newRoot, nextLeafIndex, totalFace, cm[0..N)) locally against the same on-chain bytecode, assembling the public-signal vector from the calldata exactly as the contract does.

After (1)-(5) Bob knows:

• His note encodes exactly 1,000 BUCK. (Step 1.)
• It was minted in T_mint by Alice. (Steps 2, 3.)
• It is one of N* (here 16) commitments folded into the tree by that mint, the others being cms[] \ cm. (Step 4.)
• The live values among the other siblings sum to exactly 1200 - 1000 = 200 BUCK (the residual of totalFace once Bob subtracts his own v); the batch may also contain dummy openings with v = 0. (Step 5 + the per-note opening relation: he knows his value, the chain attests to the sum.)
• He learns nothing else about the other notes – not their individual values, not their recipients, not their flavors, not which are live and which are padding. Each cm_j is hiding under a fresh rho_j he does not have.

This is the unlinkability promise made concrete: each recipient can pin down their own slice and the batch total, without learning anything about siblings.

MintBatchN*Groth16Verifier.sol (one per pinned N) was emitted from the Groth16 verification key produced by the trusted setup (production ceremony pending; dev-only entropy in scripts/snark/setup.sh today). Its bytecode is deployed once and immutable. Validators run whatever bytecode sits at that address; Alice cannot tamper with it without consensus-breaking the chain.

Knowledge soundness of Groth16 means: for every proofBytes the verifier accepts on public inputs [issuerMode[0..N), oldRoot, newRoot, nextLeafIndex, totalFace, cm[0..N)], there exists a witness (flavor[i], v[i], rho[i], idHash[i], predicate[i], pathSiblings[i][*])_i such that:

• cm[i] = Poseidon6(T_CM, flavor[i], v[i], rho[i], idHash[i], predicate[i]) for all i
• each v[i] and totalFace fit in 128 bits and sum(v[i]) = totalFace
• folding cm[0..N-1] into the tree rooted at oldRoot, starting at position nextLeafIndex, using pathSiblings[i][*] as the right-of-insert context, yields exactly newRoot
• each issuerMode[i] is the deterministic flavor projection (A2 → PRIVATE, else PUBLIC) of the witness flavor[i].

Alice is free to find such a witness any way she likes – she's the prover. But she cannot find a witness for a false statement; that's what soundness prohibits.

The proof check, the BUCK pull, and the root advancement all live in the same Notes.mint function. An EVM transaction is all-or-nothing: the only two outcomes are "the entire call's state changes commit" or "the entire call's state changes revert".

This means Alice cannot, for instance:

• Verify a proof, then refuse to pay – the verifier acceptance and the transferFrom live in the same call, gated by the same require.
• Pay 1,200 BUCK but then get away with advancing only part of the tree – newRoot is SNARK-attested as the deterministic fold of all of cms[] onto oldRoot at nextLeafIndex, and the contract writes it in one store.
• Replay a prior proofBytes – the SNARK is bound to (oldRoot, newRoot, nextLeafIndex, totalFace) and the cm[] / issuerMode[] vectors, and the contract's stale-state guards reject any submission whose oldRoot no longer matches the live root or whose nextLeafIndex no longer matches the live tree size.
• Submit the same opening twice in one batch to double-spend at spend time – the nullifier is deterministic in (rho, idHash), so whichever duplicate lands first at spend will consume both. (See the duplicate-commitment note under Step 3.)

The Groth16 verifier consumes the public-signal vector [issuerMode[0..N), oldRoot, newRoot, nextLeafIndex, totalFace, cm[0..N)]. The proof was generated against the specific values Alice committed to before submission. If Alice tries to submit the proof with a different totalFace, a different newRoot, a different nextLeafIndex, or a permuted or tampered cms[], the verifier rejects.

The cm[i] are public inputs to the SNARK directly: the contract passes the calldata cms[] straight into the verifier's public-signal vector, so any mismatch between the commitments the proof sealed and the commitments the transaction carries reverts at verify time.

The refreshed test/MintVerifier.t.sol should cover at least these tamper paths, each expected to revert with Notes: bad mint proof or Notes: stale oldRoot or Notes: stale leafIndex or an ABI decode error:

• totalFace + 1
• newRoot flipped by one bit
• oldRoot spoofed to a stale value
• nextLeafIndex spoofed to a fictional size
• cms[0] ^ 1 (commitment tampered in calldata after proving)
• cms[] length differs from the dispatched verifier's pinned N
• malformed 256-byte proofBytes

Soundness is not a proof of absence of attack, but every documented attack surface is closed by a test that triggers a verifier reject.

Suppose hostile-Alice tries to mint two contradictory batches that both claim to be the canonical breakdown of her T_mint transfer. She would need:

• Two different proofBytes and/or cms[], both passing the on-chain verifier.

That requires either:

• Two valid Groth16 witnesses for the same public inputs (allowed – but they yield the same cms, so they are not contradictory), or
• Two valid Groth16 witnesses with different public inputs. Allowed too, but each one demands its own transferFrom for its own totalFace – that is the duplicate-spend problem ERC-20 solves. Alice cannot transfer the same 1,200 BUCK twice without holding 2,400 BUCK to start with.

So a single 1,200-BUCK escrow yields exactly one accepted batch. The only freedom Alice has is which batch she lays down – which denominations and which recipients – and that freedom is hers to keep, by design.

What about hostile-Alice trying to mint more commitment value than she escrowed? She would need a witness whose sum(v[i]) equals the integer totalFace that the EVM sees, but whose individual v[i] values actually sum to more. In F_r with r ~ 2^254 and no range check on v[i], the constraint sum(v[i]) === totalFace would be satisfiable by witnesses whose integer sum differs from totalFace by a multiple of r. mint_batch.circom closes this with a Num2Bits(128) range constraint on each v[i] and on totalFace, mirrored by spend.circom's check on face and the witness v. A 128-bit cap is comfortably above any plausible BUCK denomination and well below r/2, so an integer overshoot can never wrap.

What about hostile-Alice trying to mint a commitment that is already in the tree (to collide on a nullifier she does not control, or to attempt a hash-collision attack)? She cannot collide on a nullifier without knowing somebody else's opening – the nullifier is a Poseidon-PRF output, so forging a collision is as hard as inverting Poseidon. She can re-mint her own opening (the contract no longer blocks duplicates), but doing so forces her to pay totalFace a second time and buys her nothing: the nullifier is deterministic in the opening, so whichever of her two copies she spends first permanently nullifies both. This is the value-conservation property in action – the chain does not need a commitmentExists check because the nullifier mechanism already collapses duplicate openings to one spend, and Alice bears the cost of any duplication.

The shipped spend circuit (spend.circom; see alberta-buck-ethereum.org) lets Bob deposit his note without revealing which cm in the on-chain set he opened. The spend SNARK proves "I know an opening to some commitment in the Merkle tree under the public noteRoot that hashes to this nullifier", with cm as a private witness rather than a public input. Unlinkability of spend events to mint events is now a chain-observable property: Mallory sees a fresh nullifier, a public face, and a recipient – nothing that points back to a specific commitment in the tree. The full walkthrough of the redemption flow is in The Redemption (Spend), Step by Step below.

Already covered above: Notes.mint performs proof verification, BUCK pull, and commitment appends in one EVM call. Either all happen or none.

The transfer and the commitments are bound in the same call: there is no "pre-deposit, then mint" or "mint, then deposit later" flow that an attacker could desynchronize. Each Notes.mint invocation does its own transferFrom; each transferFrom debits Alice's BUCK balance once. Two minting transactions require two transferFrom debits, which require Alice to actually hold 2 * totalFace BUCK.

A literal replay – broadcasting the exact same T_mint calldata in a new transaction – fails for three independent reasons:

1. Stale-state guards. The contract checks oldRoot == roots[currentRootIndex] and nextLeafIndex == self.nextLeafIndex. The first mint has already advanced both, so the replay's oldRoot and nextLeafIndex public inputs no longer match the live chain state. The contract reverts before the SNARK is even called, with Notes: stale oldRoot or Notes: stale leafIndex.
2. SNARK binding. Even if a future minter coincidentally re-created the same oldRoot and nextLeafIndex state (which is prohibited by the monotonic advancement of nextLeafIndex), the SNARK was bound to the specific (cms[], newRoot) pair of the prior batch. A replay would fold the same cms[] a second time and produce a different newRoot than the SNARK attested to, breaking the rolling-tree relation.
3. Allowance and balance. Even setting the above aside, the second mint would re-debit Alice's BUCK and re-consume her allowance to the Notes pool – economic-level double-escrow protection on top of the structural guards.

Replay of the same opening across batches is structurally allowed but economically self-punishing: Alice escrows totalFace again, the duplicate commitment lands at a fresh leaf index, and the deterministic nullifier Poseidon3(T_NF, rho, idHash) means the first spend nullifies every copy. Alice pays twice for a spend-once outcome.

The mint verifiers' verification keys are fixed by the trusted-setup ceremony for that deployment. A proof generated against the dev-key in scripts/snark/setup.sh will not verify against a production-key contract on mainnet, and vice versa. Public inputs are also sealed into the proof: a proof valid on Sepolia for totalFace=1200 cannot be reused on mainnet because the on-chain verifier address (and key) differ.

The only cross-context vulnerability would be a chain-id collision on identical verification keys, which the production setup ceremony precludes by construction.

When Alice and Bob both submit T_mint_A and T_mint_B targeting the same oldRoot:

• One of the two (by block ordering) lands first and updates the root.
• The other transaction executes, discovers the stale-state mismatch, and reverts at the require(oldRoot == roots[currentRootIndex]) line before any BUCK moves.

Transaction fees are paid by the loser for the reverted transaction (gas for the revert path, not for the full mint). The loser then re-proves against the new oldRoot and nextLeafIndex and resubmits. The new proof folds their commitments onto the root that now includes the winner's commitments – no commitment has been lost; the loser's tree-position is just different from the one they originally predicted.

Three mitigation layers, in ascending complexity:

1. Optimistic retry (wallet-level). On revert, the wallet re-fetches (currentRoot, nextLeafIndex) from the chain, rederives the sibling paths for the new insertion positions, re-runs the prover, and resubmits. For small N this is fast enough to not matter. This is the recommended initial deployment strategy.
2. Retry budget and back-off (wallet-level). For large N where prover time is nontrivial (minutes to hours at N=1024), the wallet should expose a "chance of contention" estimate to the user and offer to batch at the smallest pinned N that fits the job, or to enqueue the mint on a private relay channel during low-traffic windows.
3. Sequencer / proof aggregation (future). If real-world contention warrants it, an external sequencer can batch multiple users' mints into a single proof per slot, preserving the N-independent on-chain cost while amortising prover time. Sequencer capture is a separate trust axis and is deferred; the shipped protocol is sequencer-free.

• Atomicity. A reverted mint leaves no chain-visible state change; it is strictly indistinguishable from no submission.
• Value conservation. No reverted transaction debits BUCK, so there is no way for a loser to pay the pool without appending commitments.
• Unlinkability. A re-submitted mint on a fresh root still produces the same (anonymity-preserving) calldata and event shape; Mallory cannot tell a retry from a first attempt.
• Spend-time invariants. The spend circuit takes the current noteRoot (or any recent-window root); a late-arriving mint does not invalidate any previously-proved spend.

The rollup race is the price of replacing ~800K gas/leaf with ~500 gas/leaf, and for practical block-rate contention it is negligible.

From the mint walk (Step 5: Recipient Verification) Bob already has:

note_artifact_0 = {
  txHash:    T_mint,
  index:     K + 0,
  cm:        cm_0,
  opening:   ( flavor_A1, 1000e18, rho_0, idHash_bob, predicate_0 ),
  meta:      { issuer: Alice, ... },
}

He has independently confirmed that cm_0 is in Notes.commitments[] at index K and that Poseidon6(T_CM, opening) reproduces it. The opening has been sitting in his wallet for weeks, months, or years – addressed A-notes are cryptographically safe for indefinite holding (Notes).

Notes.sol maintains a Tornado-style incremental Poseidon-T3 Merkle tree of TREE_DEPTH = 20 (max ~1M leaves). The per-leaf insertion math lives inside the mint SNARK; the contract just records the SNARK-attested newRoot at each mint() call. The current root is exposed as noteRoot(). Two things happen:

1. Bob (or, more practically, any light-node helper running off-chain) reconstructs the tree off-chain. The commitments themselves are available from each mint transaction's calldata cms[], keyed by the Minted(issuer, totalFace, startIndex, count, newRoot) event that indexes the batch. A replayer walks all Minted events in order, takes the cms[] slice out of each mint's calldata, and appends them to its local tree using the same ZERO_VALUE and Poseidon-T3 wrapper the in-circuit insertion uses. Bob's Merkle path for cm_0 – a sequence of sibling hashes plus left/right indices up to the root – falls out of that rebuilt tree. The path is purely public information; everyone can reproduce it, and Bob does not have to trust any indexer because calldata is canonical.
2. Bob reads the current noteRoot() via eth_call. He may instead pin any root in the recent-roots window: Notes.sol retains the last ROOT_HISTORY_SIZE = 30 roots in a ring buffer (roots[], advanced once per inserted leaf), and the on-chain isAcceptedRoot() scans that ring backward from currentRootIndex. This is the standard zk-rollup hygiene (Zcash, Tornado Cash) for tolerating prover latency: a spend assembled against a slightly-stale root remains acceptable so long as fewer than 30 mints have landed in the meantime.

The shipped spend.circom derives the nullifier as a Poseidon-3 hash of a fixed tag, the witness rho, and the witness idHash bound at mint:

\[ nf \;=\; \mathrm{Poseidon}_3\!\bigl(T_{NF},\; \rho_0,\; \mathrm{idHash}_0\bigr). \]

The tag \( T_{NF} \) is keccak("AlbertaBuck/Notes/Nullifier/v2") mod r. It domain-separates nullifier preimages from every other Poseidon hash in the protocol, the commitment included, so a structural collision between a nullifier and a commitment is impossible. Three properties follow:

• Deterministic. The same (rho, idHash) always yields the same nf. So Bob can only spend cm_0 once; a second attempt re-derives the same nf and is rejected by nullifiers[nf] = true on the first spend.
• Unforgeable without the opening. An attacker who sees cm_0 and the tree cannot compute nf without rho_0 and idHash_0, both of which live inside the opening (and rho_0 is not derivable from the recipient's identity alone).
• The note proof binds the opening and nullifier, not the identity. The flavor-agnostic spend.circom treats idHash as a witness scalar – it does not constrain it to a registered Identity. That binding is the separate Step-4 deposit gate: for A1/A2 one folded proof that recomputes this same nullifier from the \( idHash \) it opens, and shows the spender is the registered Identity paired with the key that reads the note; for B1 the EIP-196 depositor-binding sigma and a membership proof over its committed point. Keeping the identity binding out of spend.circom keeps the one proof every spend shares small. And because the deposit is identity-keyed (not account-keyed), an addressed note survives the loss of any single account key: re-register a fresh Fountain account on the same \( M_{\text{rec}} \) and deposit (recovery, not finality).

The nullifier is the chain-observable anchor of the spend. Publishing it marks cm_0 as consumed from the tree's semantic point of view, even though the tree itself remains append-only and nothing is deleted.

Bob's wallet runs scripts/snark/prove_spend.js (the spend-side analogue of prove_mint_batch.js, using the depth-20 PTAU produced by scripts/snark/setup.sh). spend.circom's signal layout is exactly:

public  noteRoot;         # an accepted root from the on-chain ring buffer
public  nullifier;        # the nf from Step 2
public  face;             # 1000e18 -- the BUCK to release (range-bounded to 128 bits)
public  recipient;        # Bob's on-chain address (the payout destination)
public  chainId;          # replay-domain separation

private flavor, v, rho,
        idHash, predicate;        # the note opening
private pathElements[depth];      # depth-20 sibling hashes
private pathIndices[depth];       # left/right bit per level

The shipped circuit enforces five relation groups:

1. Range bounds and value match. Both the public face and the witness v pass through Num2Bits(128), then face === v. This closes the field-overflow gap: v cannot wrap around r to claim more than its in-range share.
2. Opening binds. cm = Poseidon6(T_CM, flavor, v, rho, idHash, predicate).
3. Merkle membership. MerkleProof(20) walks (cm, pathElements, pathIndices) up the tree using Switcher + Poseidon(2) per level and asserts the climb reaches noteRoot.
4. Nullifier derivation. nullifier === Poseidon3(T_NF, rho, idHash).
5. Public-input ghost binding. recipient and chainId each appear in a trivial x*x row. This is the minimal anchor needed for circom not to optimise out unreferenced public signals; once anchored, Groth16's IC[] commitment makes them non-malleable from the mempool's perspective.

Critically, cm is not a public input; it is recomputed inside the proof from the witness opening. The proof convinces the verifier that some cm in the tree satisfies (1)-(4); it does not reveal which.

This spend.circom note proof is flavor-agnostic: A1, A2, and B1 all use the same circuit and the same on-chain spendVerifier.verifySpend check for the cm-membership + nullifier discharge (one nullifier derivation). Bob's wallet serializes the Groth16 proof into the standard (uint256[2], uint256[2][2], uint256[2]) ABI tuple (256 bytes). The flavor-specific identity material – the re-encryption eEnc and the fold proof (A1/A2), or eDepForIss, the depositor-binding proof and its membership proof (B1) – is assembled separately and submitted alongside the note proof in Step 4.

Bob's note is A2 (private issuer), so he deposits via spendCoupledA2. Beyond the Step 1–3 note proof he supplies exactly two things: eEnc – a fresh re-encryption of the leaf ciphertext \( eIss \) under his mailbox key \( pk_{\text{recv}} \) (same plaintext, new randomness, so the chain never sees the mint-time ciphertext again) – and foldProof, the folded gate's Groth16 triple (alberta_buck.wallet.deposit_fold):

notes.spendCoupledA2(proofBytes, noteRoot, identityRoot, nullifier, 1000e18, bob,
                     eEnc, foldProof);

That is the whole addressed calldata, with the identity root Bob proved against. A sigma, a separate membership proof and a note-binding proof used to ride along beside it, sharing a public point; one witness states what they only jointly suggested, so they are gone and so is the point. The honest EVM walks:

require(address(identityRegistry) != address(0), "Notes: identity registry not set");
require(recipient != address(0),  "Notes: zero recipient");
require(face      > 0,            "Notes: zero face");
require(_isAcceptedRoot(root),    "Notes: unknown root");
require(!nullifiers[nullifier],   "Notes: already spent");

// (1) Note proof: cm in the pool tree under `root`, nullifier well-formed,
//     flavor bound to this entry point.
require(spendVerifier.verifySpend(
    proof, root, nullifier, face, recipient, block.chainid, FLAVOR_A2, 0
),                                "Notes: bad spend proof");

// (2) The identity root: one the registry still retains, posted within
//     the age the Notes consumer declares (seven days).
require(identityRegistry.acceptsRoot(identityRoot, NOTES_MEMBERSHIP_CONSUMER),
                                  "Notes: identity root not accepted");

// (3) The folded gate.  The adapter reads msg.sender's registered key and
//     credential and derives EVERY public input, so relation (2) is
//     necessarily about an account that really is registered.
require(depositFoldVerifier.verifyFoldA2(
    foldProof, nullifier, identityRoot, eEnc, msg.sender),
                                  "Notes: bad folded deposit gate");

nullifiers[nullifier] = true;
noteFaceSum          -= face;

require(buck.transfer(recipient, face),   // pool isCarrying => Carrying path
        "Notes: transfer failed");
emit SpentCoupledA2(nullifier, face, recipient);

Five invariants are enforced in order:

1. root appears in the recent-roots window. A root that has rotated out is stale – Bob must rebuild the proof against a fresher root.
2. nullifier has never been published before (Theorem 10 in the proofs says this single-bit check is sufficient for double-spend prevention).
3. The note proof is valid against SpendGroth16Verifier via the SpendVerifierAdapter, which packs [root, nullifier, face, recipient, chainid] into the public-signal vector. By soundness Bob holds an opening of a cm under root, with nullifier = Poseidon3(T_NF, rho, idHash).
4. identityRoot is accepted: the registry still holds it in its ring of 256 postings, and it was posted within the seven days Notes declares. That age is how long a holder cleared from its registry can still spend.
5. verifyFoldA2 succeeds. One proof shows that \( k \) opens eEnc, that msg.sender's registered credential opens to the same \( m_{\text{rec}} \) the receiving leaf commits beside \( k \), that the decrypted issuer Identity is registered under the shipped salt, that the note's committed \( T \) opens against \( k \), and that the nullifier is the one this note's \( idHash \) produces. The adapter derives the public inputs, including the account read from the registry. There is no committed point in the statement, and the event logs none.

If any of (a)-(e) reverts, the whole transaction reverts: no BUCK moves, the nullifier bit is never set, noteFaceSum is unchanged. Bob gets one attempt per root window; a failed spend retries with a refreshed proof, but never consumes a nullifier without paying out the BUCK.

An A1 note takes spendCoupledA1, the same fold with the face public and no issuer-membership relation: eRec encrypts the plaintext \( M_{\text{rec}} \) under \( pk_{\text{recv}} \). A B1 note takes spendCoupledB1, where the sigma is verifyDepositorBinding and the membership proof opens \( P_{\text{dep}} \) on \( H_{\mathrm{PEDERSEN}} \). All three are detailed in The Identity-M Spend Path (A1, A2, B1).

The call inside Notes.spendCoupledA2 is a plain buck.transfer(bob, 1000e18). Because the Notes pool is bound isCarrying in the IdentityRegistry, BUCK routes that transfer through its internal _carryingTransfer path on this single egress. (spendCoupledA1 and spendCoupledB1 take the same path.) Nothing in Buck.sol is special-cased for the pool: it is just a registered, isCarrying account making an outbound transfer of 1,000 BUCK to a registered recipient. The result on-chain:

• Buck.balanceOf(Notes) decreases by exactly 1,000 BUCK – nominal balance only.
• Buck.balanceOf(Bob) increases by exactly 1,000 BUCK.
• Buck.Transfer(Notes, Bob, 1000e18) is emitted (a standard ERC-20 event; the carrying apportionment is internal, with no distinct event).
• Notes.Spent(nullifier, 1000e18, Bob) is emitted.
• Notes.nullifiers[nullifier] becomes true.

What "carrying" means in the ledger. BUCK demurrage is a balance-time integral: each account stores its buckSeconds (the crystallised \( \int B\,dt \)) plus the timestamp of its last touch. A transfer from a non-Carrying account settles the sender's accrued fee (a one-shot burn) and hands the recipient fresh, zero-age BUCK. A transfer from an isCarrying account – the _carryingTransfer path – differs in two surgical ways:

1. No sender-side fee burn. The pool sheds a proportional slice of its live buck-seconds rather than burning a fee; its per-BUCK age is preserved.

2. Recipient absorbs the pool's age. The recipient inherits that slice of buck-seconds (carried = liveBs * amount / poolRaw), added to its own:

   liveBs   = pool.buckSeconds + pool.raw * elapsed;
   carried  = liveBs * amount / pool.raw;
   pool.buckSeconds       = liveBs - carried;   // pool sheds its share
   recipient.buckSeconds += carried;            // recipient inherits the age

System-wide BUCK-age is preserved across the call (no fee is burned, no fresh-BUCK dilution at the recipient); the demurrage that the pool would have burned on a standard outgoing transfer instead rides into Bob's account as inherited buck-seconds. Bob will pay it the next time he makes a standard outgoing transfer.

Why this is the right rule for the pool. Per-note age is opaque – the pool holds aggregate BUCK behind opaque commitments and cannot tell Bob's note's age from any other note's. The Carrying path collapses the calculation to the pool's average per-BUCK age at spend time: every spender of the same face absorbs the same buck-seconds slice, keeping the spend-time anonymity set intact. The trade-off is that Bob inherits the pool's average age regardless of how long his specific note sat in the tree. Anyone whose note rested longer than the pool average comes out ahead; this is the cost of anonymity, and the upside for long-term holders.

The full discussion (one new BUCK method, one new event, no per-account mode flag) is in Demurrage-Carrying Transfers below.

After T_spend confirms, Mallory can read:

T_spend:
  from:  Bob (a registered IdentityRegistry account)
  to:    Notes (system-public)
  data:  Notes.spendCoupledA2(proofBytes, noteRoot, identityRoot, nullifier,
                              1000e18, Bob, eEnc, foldProof)

events:
  Buck.Transfer(Notes, Bob, 1000e18)
  Notes.SpentCoupledA2(nullifier, 1000e18, Bob)

What she infers:

• That a note was spent. Yes – the nullifier is fresh and the pool balance dropped by 1,000 BUCK.
• That the spend was for 1,000 BUCK to Bob. Yes – face and recipient are public inputs (they must be, to tell the ERC-20 whom to pay).
• Which commitment in the tree was consumed? No – cm is a private witness to the SNARK. Mallory's anonymity set is every unspent commitment of flavor A in the pool whose hidden v could equal 1,000 BUCK. At deployment scale this is potentially the entire pool minus prior nullified entries; in a same-denomination regime (many 1,000-BUCK notes in circulation) it is exactly the 1,000-BUCK subset.
• Which mint did the spent note come from? No – there is no cross-reference to T_mint in T_spend. The only link back to any specific mint would be the nullifier, but nullifiers are Poseidon-PRF outputs over secret material; inverting one to recover (flavor, M_rec, rho) is exactly the pre-image resistance we assume.
• Who held the note before Bob? No. If Alice gave the note to Carol who handed it to Dave who sold it to Bob, none of those transfers touched the chain. The chain sees only "at mint Alice deposited, later Bob withdrew" – the intermediate holders are invisible.

The residual linkability surfaces are (i) face (the revealed amount) and (ii) recipient (the on-chain payout address). Both are unavoidable at the SNARK/ERC-20 boundary – the contract must know where and how much to pay. The community- standardized mitigation is fixed-denomination notes (so revealing face does not subdivide the anonymity set) and batched, relay-mediated payouts (so revealing recipient need not reveal the true beneficiary). Both are orthogonal to the core spend circuit and can be layered on top.

Can any actor other than Bob – Alice-the-issuer, a prior holder, or a random Mallory – redeem cm_0? Three protections apply, the third being the folded deposit gate:

1. Opening secrecy. spend.circom requires the full note opening (flavor, v, rho, idHash, predicate) as a private witness. Without rho_0 and idHash_0 the circuit is unsatisfiable, so no one without the opening can produce a valid nullifier or proof. For Alice's secrets, this is the load- bearing protection on bearer-flavor (B1) notes: she could in principle race the bearer to deposit, which is the civil-trust semantics of bearer cash and is discussed at length in alberta-buck-notes.org §Long-Term Holding Safety.
2. Recipient-binding at the payout site. recipient is a public SNARK input ghost-bound by recipient * recipient, so Groth16's IC[] commitment makes it non-malleable. A front-runner who intercepts Bob's proofBytes and resubmits with a different recipient is rejected by the verifier. chainId is bound identically, blocking cross-chain replay.
3. Identity binding via the folded gate. For an A2 deposit Bob provides the ciphertext and one Groth16 proof. With the fold verifier set, spendCoupledA2 checks that the receiving secret opens the ciphertext, that Bob's registered account opens to the Identity paired with that secret in the receiving leaf, and that the decrypted issuer is registered under the shipped salt. Alice cannot redeem to herself even knowing the opening: she does not hold \( k \), and no leaf pairs her Identity with Bob's mailbox.

The strict identity-binding guarantee is a chain-observable property when the fold verifier is set: one Groth16 accept is the gate. The note proof enforces the commitment and the nullifier; the fold enforces that the depositor is the Identity paired with the mailbox the note was keyed to.

A B1 note (bearer, public issuer) is redeemed the same way, with the depositor binding playing the role the fold does for A2: spendCoupledB1 calls verifyDepositorBinding (the depositor re-encrypts its own \( M_{\text{dep}} \) under the public issuer's key, coupled to its payout account) plus a membership proof of \( M_{\text{dep}} \). Knowledge of the note opening is still the bearer authorisation – if two parties hold copies of the same B1 opening (a paper note photographed and forwarded), whichever submits first wins, the intended civil-trust semantics of bearer cash – but the depositor is additionally proven to be a registered Identity the issuer can name (see The Identity-M Spend Path (A1, A2, B1)).

The original Property C question – subsequently only those N valid notes can be deposited – becomes concrete at this layer. Claim: no actor can redeem a commitment cm unless

1. cm was appended to commitments[] by a prior Notes.mint transaction whose Groth16 proof verified (i.e., cm is part of an honest mint batch), and
2. The actor holds the opening of cm, and
3. For A-spends, the actor is the depositor keyed by M_rec in that opening.

Proof sketch. The spend circuit's relation 2 (Merkle membership) rejects any cm not in noteRoot. The mint circuit's relations 1-2 (opening binding and sum conservation) are what places a cm in noteRoot in the first place, and by the mint-side soundness story in Why Alice Cannot Cheat every such cm corresponds to a well-formed opening whose v is included in the mint's totalFace escrow. The spend circuit's relation 5 (face === v) then ensures the BUCK released equals exactly the share of the escrow that cm was allocated. Summing over every accepted spend of a given mint batch, the cumulative BUCK released equals at most the totalFace escrowed – property C follows from mint-side value conservation plus spend-side nullifier uniqueness.

Field wrap-around is foreclosed by range bounds: mint_batch.circom range-bounds each v[i] to 128 bits and spend.circom range-bounds both face and the witness v identically, so an integer overshoot of totalFace by a multiple of r is structurally impossible at either end. Property C rests on those range bounds plus the nullifier-uniqueness check and Merkle membership.

Before the flavour-specific walkthroughs, three primitives are common to all three:

• The identity accumulator. Registries keep private subtrees of depth 12, an aggregator of depth 20 has their roots for leaves, and its root is posted on chain into a ring of 256, each with its time. register refuses a caller-supplied leaf. Every leaf function leads with its own v2 field tag \( \tau \): the addressed gate proves \( \mathrm{Poseidon}(\tau_R, m, k, salt) \), and B1 proves \( \mathrm{Poseidon}(\tau_S, M.x, M.y, salt) \). The unsalted point leaf remains for public trees and for the unilateral receipt's contains check, which is a different statement from the spend.
• B1's membership proof. identity_membership_b1.circom proves \( T = b H_{\mathrm{PEDERSEN}} \), \( P_{\text{dep}} = M + T \) with the addition's precondition enforced, and the salted leaf's path. The contract passes the sigma's \( P_{\text{dep}} \) into the verifier. The generator is hashed to the curve, so the blind cannot be shifted onto another registered Identity – a circuit that WITNESSED \( T \) instead, on a generator whose logarithm is known, let an unregistered depositor spend.
• The aggregator. Registries, feature authorities and regulators feed subtree roots into a CentralMerkleService (depth 20, up to 2^20 subtrees) whose root the registry's ring retains. Every level hashes alike, so a subtree path and the aggregator path compose into the one 32-level path the gates prove. The reference is alberta_buck.registry.merkle_service; Rust and JavaScript mirror it.

Bob's note is flavour A2 (addressed, private issuer). The note opening carries \( eIss = (R_e, C_e) \) – the issuer's Identity \( M_I \) encrypted under Bob's receiving key \( pk_{\text{recv}} \), plus the anti-framing binding (verifyIssuerReenc) that ties \( eIss \) to the issuer's own registered Identity, plus the issuer's naming salt and the randomness \( r' \). Bob decrypts with \( k \), not with \( m_{\text{rec}} \).

==== Step A0: Bob Holds the A2 Note ====

The artifact Bob received off chain:

note = (
  flavor = A2,  v = 1000e18,  rho,  idHash,  predicate,  # the commitment opening
  eIss  = (R_e, C_e),                                      # M_I under pk_recv
  T,                                                        # committed in idHash
  r_prime, gamma, salt_iss,                                 # what the fold needs
  binding,                                                  # verifyIssuerReenc
  mint_tx_ref,                                              # where cm was folded
)

==== Step A1: Bob Chooses a Deposit Account ====

Bob selects any registered Fountain account bound to his identity scalar \( m_{\text{rec}} \). His wallet reads the account's registered \( (pk_{\text{dep}}, E_{\text{dep}} = (R_d, C_d)) \) from the IdentityRegistry. Because all accounts share the same \( m_{\text{rec}} \), he is free to use a fresh account every time – no re-registration, no key pinning.

==== Step A2: Build the Folded Witness ====

Bob builds ONE witness (alberta_buck.wallet.deposit_fold), and the gate is one proof over it. Two facts have to be established and they rest on two different secrets – \( k \) opens the note, \( m_{\text{rec}} \) owns the account – so there is no scalar for a sigma's shared nonce to tie, and proving them side by side would say nothing about their owner. A thief with a stolen payload answers the reading half with the stolen \( k \) and the Identity half with its OWN registered Identity, and both halves are true.

private:  k, m_rec, sk_dep, salt, r', gamma, salt_iss, two Merkle paths,
          eNote, eIss, T
public:   nullifier, identityRoot, eEnc, and -- read from the registry, not
          accepted from the prover -- pk_dep and E_dep for msg.sender

The relations, all in circuits/deposit_fold_a2.circom:

1. \( k \) decrypts the note's ciphertext to a point \( M_I \), and \( eEnc \) re-encrypts that same \( M_I \) under the same \( k \).
2. The account credential decrypts under \( sk_{\text{dep}} \) to \( M_{\text{rec}} = m_{\text{rec}} G \).
3. \( \mathrm{Poseidon}(\tau_R, m_{\text{rec}}, k, salt) \) is a registered leaf. This is the relation a split gate leaves out, and the one the thief cannot satisfy: no registered leaf pairs ITS Identity with the key it stole.
4. That leaf's path folds to the posted identityRoot.
5. \( M_I \) is itself registered, as \( \mathrm{identity\_leaf\_salted}(M_I, salt_{\text{iss}}) \) under the salt the note shipped.
6. The note's committed \( T \) opens as \( (r'k)G + \gamma H_{\mathrm{PEDERSEN}} \): the key the mint binding proved about is the key Bob holds.

Relation (3) used to be free, because the two scalars were one value. It is now the load-bearing one. And because the circuit hashes the very signals its other relations consume, a single tampered \( m_{\text{rec}} \) breaks the decryption, the credential and the leaf at once – there is no seam between the two secrets for a thief to work in.

A1 is the same gate with relations (5) and (6) removed and the face made public: its ciphertext decrypts to the recipient's OWN Identity, so relation (2) already covers what (5) would say, its public issuer has no key to re-aim, and it ships no witness material about anyone else.

==== Step A3: What the Prover Does Not Choose ====

DepositFoldVerifierAdapter derives every public input on chain. It reads \( pk_{\text{dep}} \) and \( E_{\text{dep}} \) from IdentityRegistry for msg.sender, takes identityRoot from the registry, and limb-encodes eEnc itself. So relation (2) is necessarily about an account that really is registered, and there is no committed point for the wallet to decouple from anything – because there is no second proof to decouple it from.

==== Step A4: Submit the Deposit ====

notes.spendCoupledA2(
    proof,                            // Groth16: note opening + noteRoot membership
    noteRoot,
    identityRoot,                     // the posted root the fold proves against
    nullifier,                        // Poseidon(T_NF, rho, idHash)
    face,                             // 1000e18
    recipient,                        // Bob's payout address
    eIss,                             // eEnc: the fresh re-encryption under pk_recv
    foldProof                         // the folded gate's (a, b, c)
);

==== Step A5: On-Chain Verification ====

spendCoupledA2 gates on five conditions:

1. The fold verifier is wired. It cannot be cleared, so this is a deployment invariant rather than a configuration; an addressed spend without it reverts here, before anything else is checked.
2. Standard note spend: noteRoot accepted, nullifier fresh, the note opening proof verifies (spendVerifier.verifySpend).
3. identityRoot is accepted for the Notes consumer: retained in the registry's ring and posted within seven days.
4. The folded gate: verifyFoldA2(foldProof, nullifier, identityRoot, eEnc, msg.sender) accepts.
5. BUCK transfer, then nullifiers[nullifier] = true and SpentCoupledA2(nullifier, face, recipient).

The event publishes no point. An earlier shape logged the committed \( P_I \); a log is not a constraint, and logging a point that no relation reads invites an auditor to believe otherwise.

If any check fails the whole transaction reverts. No BUCK moves, no nullifier is consumed. (End to end, with real proofs: NotesE2E.t.sol.)

What relation (5) closes. Suppose an issuer keys \( eIss \) to a throwaway point so the recipient cannot name it. Relations (1) to (4) still pass – Bob really can decrypt to some point. But that point is not a registered Identity, so no salt opens a leaf for it and relation (5) has no witness: the deposit reverts. There is no spendable-but-unnameable note.

What relation (6) closes. An issuer can instead key the ciphertext so that the key its binding proves about opens it to its own \( M_A \) while Bob's key opens it to a DIFFERENT registered Identity \( M_B \). The binding is true and relation (5) holds on \( M_B \)'s leaf, so without (6) Bob would honestly name \( M_B \). But the note commits the binding's \( T = r'\,pk + \gamma H_{\mathrm{PEDERSEN}} \), and (6) opens it against Bob's own \( k \): re-aiming the key needs \( M_B - M_A \) as a known multiple of \( H_{\mathrm{PEDERSEN}} \), a discrete logarithm (Proofs, Theorem 12). The executed transcript below mints exactly this note and watches the delivery, the fold and the receipt each refuse it.

==== Step A6: The Unilateral Receipt ====

After the spend confirms, Bob's wallet produces a unilateral receipt naming both parties – from \( k \) and his own Identity, two values rather than one derived from the other:

A verifiable decryption proof (verifiable_decrypt_prove, a Chaum-Pedersen DLEQ) makes the receipt third-party-checkable without revealing \( k \). The receipt tuple:

A court or auditor checks five links (verify_receipt):

Full specification and tests: alberta-buck-notes-unilateral.

The cryptography above is small enough to run. This section is a complete, executing transcript against the shipped wallet (alberta_buck.wallet.unilateral_a2 over BN254 \( \mathbb{G}_1 \)) – mirroring test_unilateral_a2.py. The blocks below are org-babel source blocks sharing one Python session: re-exporting this document re-runs them top to bottom, and the printed RESULTS are regenerated. The session is seeded, so a re-run reproduces this transcript byte for byte – and fails loudly if the wallet API drifts. The wallet's curve arithmetic executes on the compiled buck-identity kernel (buck_core.buck_identity, arkworks BN254); the first block asserts it, so this document renders only against the production cryptography. The pure-Python py_ecc path remains the executable specification the kernel is proven bit-identical against (core/vectors/identity-kernel-vectors.json).

The cast: two Identities, one of them with two accounts. An Identity is a KYC-bound scalar \( m \) and its point \( M = mG \). The Identity Fountain lets one \( m \) back unlimited unlinkable accounts, each an ElGamal encryption \( E_{\text{addr}} = (R, C) = (rG,\ M + r\,pk) \) of the same \( M \) under that account's own key.

import random
from alberta_buck.wallet import backend
from alberta_buck.wallet.bn254 import G1, ORDER, mul, add, neg, eq, rand_scalar
from alberta_buck.wallet.elgamal import elgamal_encrypt, elgamal_decrypt
from alberta_buck.wallet.unilateral_a2 import (
    IdentityTree, mint_unilateral_a2,
    make_receipt, verify_receipt,
)
from alberta_buck.wallet.recvkey import receiving_key
from alberta_buck.wallet.salt import derive_salt
from alberta_buck.wallet.deposit_fold import (
    DepositFoldRefused, deposit_fold_check, deposit_fold_a2_witness,
    deposit_fold_witness,
)
from alberta_buck.registry.tree import identity_leaf_salted, receiving_leaf
from alberta_buck.registry.merkle_service import rooted_registry

assert backend() == "kernel", "must run the production kernel: evaluate in the repo venv"
print(f"wallet crypto backend     = {backend()} (buck_core.buck_identity)")

_seed = random.Random(0xA1BE27AB0CC)     # ONE deterministic transcript
rng   = lambda: _seed.getrandbits(256)

CHAINID = 1
def account(m):                    # one Fountain account bound to identity m
    sk = rand_scalar(rng); pk = mul(G1, sk)
    M  = mul(G1, m)                # the shared Identity point
    r  = rand_scalar(rng)          # registration randomness; the fold witnesses it
    E  = elgamal_encrypt(M, pk, r)    # registered credential
    return dict(m=m, M=M, sk=sk, pk=pk, E=E, r=r)

def pt(P):                         # compact point display
    return f"({int(P[0]) % 10**8:>8d}..., {int(P[1]) % 10**8:>8d}...)"

m_iss, m_rec = rand_scalar(rng), rand_scalar(rng)
issuer = account(m_iss)                      # the payer (private issuer)
rec0   = account(m_rec)                      # recipient account #0
rec1   = account(m_rec)                      # recipient account #1 (SAME identity)
M_rec  = mul(G1, m_rec)                      # what the issuer learns out of band

tree = IdentityTree()                        # unsalted points: what a receipt checks
for a in (issuer, rec0):                     # one leaf per *identity*
    tree.insert(a["M"])

# The mailbox is not the Identity.  k comes from the wallet seed, and the
# private registry commits the pair (m_rec, k) under the holder's salt.
# The issuer's SECOND association is an ordinary salted identity leaf: its
# salt is what an A2 payload ships, and it says nothing about the issuer's
# own mailbox.  The registry's subtree is enrolled under an aggregator, so
# its paths are the 32-level paths the gates prove: 12, then 20.
KYC = "kyc:ca-ab-2026"
seed_rec = rand_scalar(rng)
k_rec, pk_recv = receiving_key(seed_rec)
salt_rec = derive_salt(seed_rec, KYC)
seed_iss = rand_scalar(rng)
salt_iss = derive_salt(seed_iss, KYC, 1)
priv = rooted_registry(KYC)
priv.insert_leaf(identity_leaf_salted(issuer["M"], salt_iss))
priv.insert_receiving(m_rec, k_rec, salt_rec)

print(f"issuer Identity    M_I   = {pt(issuer['M'])}")
print(f"recipient Identity M_rec = {pt(M_rec)}  (accounts rec0, rec1)")
print(f"receiving key      pk_recv = {pt(pk_recv)}  (not M_rec)")
print(f"identity tree root        = {hex(tree.root())[:20]}...")
print(f"posted identity root      = {hex(priv.root())[:20]}...  ({priv.depth}-level paths)")

wallet crypto backend     = kernel (buck_core.buck_identity)
issuer Identity    M_I   = (34794633..., 55370756...)
recipient Identity M_rec = (78777287...,  1501867...)  (accounts rec0, rec1)
receiving key      pk_recv = (27820058..., 70606247...)  (not M_rec)
identity tree root        = 0xff9f26af3a3e77cf95...
posted identity root      = 0x638a64903f90cc47d9...  (32-level paths)

Mint: encrypt the issuer's own Identity under the recipient's mailbox. The issuer addresses the note to the Identity and keys both ciphertexts to \( pk_{\text{recv}} \), learned on the same out-of-band channel that carries \( M_{\text{rec}} \). It needs nothing from the recipient at payment time. The anti-framing binding (verifyIssuerReenc, with the recipient slot set to \( pk_{\text{recv}} \)) proves \( eIss \) re-encrypts the issuer's own registered \( M_I \). The mint object carries \( salt_{\text{iss}} \), the salt of the issuer's naming association, and \( r' \), the randomness of \( eIss \). The fold checks \( eIss.R = r'G \) and opens \( \mathrm{identity\_leaf\_salted}(M_I, salt_{\text{iss}}) \); neither value is the issuer's mailbox salt. The binding's \( T \) is committed in \( idHash \) beside both ciphertexts, and its blind \( \gamma \) is the third thing the recipient needs. The delivery (wallet/delivery.py) carries \( r' \), \( \gamma \) and \( salt_{\text{iss}} \) wrapped to \( pk_{\text{recv}} \), with \( T \) in the clear.

note = mint_unilateral_a2(issuer["sk"], issuer["E"], pk_recv,
                          v=1000, rho=rand_scalar(rng),
                          issuer=0xA11CE, chainid=CHAINID,
                          salt_iss=salt_iss, rng=rng)
assert eq(note.M_I, issuer["M"])
assert note.salt_iss == salt_iss
print(f"minted A2 note: v = {note.opening.v}")
print(f"  cm     = {hex(note.cm)[:20]}...       (the only on-chain artifact)")
print(f"  idHash = {hex(note.idHash)[:20]}...   (Poseidon11(T_ID, eNote, eIss, T))")
print(f"  eIss   = ElGamal(M_I under pk_recv)  R = {pt(note.eIss.R)}")

minted A2 note: v = 1000
  cm     = 0xdfb168e9bc18175305...       (the only on-chain artifact)
  idHash = 0x1d41ad0b39ccfc02fa...   (Poseidon11(T_ID, eNote, eIss, T))
  eIss   = ElGamal(M_I under pk_recv)  R = (49017840..., 29504036...)

Delivery: the recipient names the issuer with the receiving secret. The decryption secret is \( k \), not \( m_{\text{rec}} \). Every account the recipient owns shares \( m_{\text{rec}} \); none of them opens the note. \[ C_e - k\,R_e = (M_I + r'\,pk_{\text{recv}}) - k(r'G) = M_I. \]

M_I = elgamal_decrypt(note.eIss, k_rec)
assert eq(M_I, issuer["M"])
opened_by_m = eq(elgamal_decrypt(note.eIss, m_rec), issuer["M"])
print("recipient decrypts eIss with k -> the issuer's registered Identity:")
print(f"  C_e - k*R_e = {pt(M_I)} == M_I")
print(f"  the identity scalar opens it: {opened_by_m}")

recipient decrypts eIss with k -> the issuer's registered Identity:
  C_e - k*R_e = (34794633..., 55370756...) == M_I
  the identity scalar opens it: False

Deposit from ANY account bound to \( m_{\text{rec}} \). Authority is the Identity, so both rec0 and rec1 spend the same note under the one mailbox key. The gate is one witness. It refuses unless \( k \) decrypts the ciphertext, the account credential decrypts to \( M_{\text{rec}} \), and a registered leaf commits the pair \( (m_{\text{rec}}, k) \) under the holder's salt, on a path to the posted root. There is no shared public point for a second proof to meet at.

for name, acct in (("rec0", rec0), ("rec1", rec1)):
    w_acct = deposit_fold_witness(
        m_rec=m_rec, k=k_rec, sk_dep=acct["sk"], salt=salt_rec,
        E_dep=acct["E"], note_ct=note.eIss, tree=priv)
    ok = deposit_fold_check(
        w_acct, pk_dep=acct["pk"], E_dep=acct["E"],
        note_ct=note.eIss, root=priv.root())
    print(f"folded gate from {name}: verifies = {ok}")

folded gate from rec0: verifies = True
folded gate from rec1: verifies = True

On chain the same statement is one Groth16 proof. DepositFoldVerifierAdapter.verifyFoldA2 derives every public input: the nullifier, the posted identity root, the ciphertext, and the depositor's registered key and credential, the last two read from the registry rather than accepted from the caller. The proof bytes are only the Groth16 triple, and they are the whole of the addressed calldata beside the re-encryption:

// Notes._spendCoupled (abridged).
require(identityRegistry.acceptsRoot(identityRoot, NOTES_MEMBERSHIP_CONSUMER),
        "Notes: identity root not accepted");
bool ok = depositFoldVerifier.verifyFoldA2(
    foldProof, nullifier, identityRoot, eEnc, msg.sender);
require(ok, "Notes: bad folded deposit gate");

The fold witness: the note tie and the issuer's naming leaf, in one proof. The spend supplies a fresh re-encryption of \( eIss \) under the same \( pk_{\text{recv}} \). deposit_fold_a2_witness is the JSON the circuit consumes. It asserts the four relations above, the fifth – the decrypted issuer Identity opens identity_leaf_salted(M_I, salt_iss), and that leaf's path folds to the same root – and the sixth, \( T \) opening against \( k \). A wrong salt is not a member.

s = rand_scalar(rng)
t = (note.r_prime + s) % ORDER
eEnc = elgamal_encrypt(note.M_I, pk_recv, t)
w = deposit_fold_witness(
    m_rec=m_rec, k=k_rec, sk_dep=rec0["sk"], salt=salt_rec,
    E_dep=rec0["E"], note_ct=note.eIss, tree=priv)
iss_leaf = identity_leaf_salted(issuer["M"], salt_iss)
iss_path = priv.path(priv.leaves.index(iss_leaf))
fold = deposit_fold_a2_witness(
    witness=w, rho=note.opening.rho, id_hash=note.idHash,
    e_note=note.eNote, e_iss=note.eIss, r_prime=note.r_prime,
    t=t, r_E=rec0["r"], e_dep=rec0["E"], pk_dep=rec0["pk"],
    e_enc=eEnc, salt_iss=salt_iss, iss_path=iss_path,
    T=note.binding.T, gamma=note.gamma, identity_root=priv.root())
print(f"A2 fold witness built: {len(fold)} signals, relations asserted")
print(f"  public nullifier = {hex(int(fold['nullifier']))[:20]}...")
print(f"  eEnc.R limb0     = {fold['eEncRx'][0]}  (fresh re-encryption)")
assert fold["saltIss"] == str(salt_iss)
assert int(fold["eEncRx"][0]) != 0

try:
    deposit_fold_a2_witness(
        witness=w, rho=note.opening.rho, id_hash=note.idHash,
        e_note=note.eNote, e_iss=note.eIss, r_prime=note.r_prime,
        t=t, r_E=rec0["r"], e_dep=rec0["E"], pk_dep=rec0["pk"],
        e_enc=eEnc, salt_iss=(salt_iss + 1) % ORDER, iss_path=iss_path,
        T=note.binding.T, gamma=note.gamma, identity_root=priv.root())
    print("wrong issuer salt: BUILT (must not happen!)")
except AssertionError as exc:
    print(f"wrong issuer salt: REFUSED ({exc})")

A2 fold witness built: 34 signals, relations asserted
  public nullifier = 0x13bfa2e1a4b72873ff...
  eEnc.R limb0     = 5454261353227722156  (fresh re-encryption)
wrong issuer salt: REFUSED (the shipped issuer salt does not open the issuer's leaf)

Proving this witness is the heavyweight step – 3,833,338 constraints along 32-level paths – and it runs in the build pipeline (scripts/snark/setup_deposit_fold_a2.sh) rather than in this session. The setups are dev entropy. test/DepositFoldA2Verifier.t.sol verifies a real proof on chain and requires every public input, walked alone, to break it.

The unilateral receipt: the recipient names BOTH parties, alone. From \( k \) and its own Identity – two values, not one derived from the other – the recipient recovers \( M_I \) and produces a third-party-checkable receipt. The verifiable decryption is under \( pk_{\text{recv}} \). The membership checks below are membership of the two Identity points in the unsalted tree the receipt was given. They are not the spend's receiving-leaf check; that check is the fold.

receipt = make_receipt(k_rec, M_rec, note, issuer=0xA11CE, chainid=CHAINID,
                       tree=tree, rng=rng)
res = verify_receipt(receipt, issuer["pk"], issuer["E"], tree.root(), tree)
assert res.valid
assert eq(res.issuer_M, issuer["M"])
assert eq(res.recipient_M, M_rec)
assert res.value == 1000
assert eq(receipt.pk_recv, pk_recv)
print(f"unilateral receipt: {res.reason}")
print(f"  names issuer    {pt(res.issuer_M)}")
print(f"  names recipient {pt(res.recipient_M)}")
print(f"  decrypts under  {pt(receipt.pk_recv)}")
print(f"  value           {res.value}")

unilateral receipt: VALID
  names issuer    (34794633..., 55370756...)
  names recipient (78777287...,  1501867...)
  decrypts under  (27820058..., 70606247...)
  value           1000

A stolen payload does not spend, and a throwaway key does not name. A thief holding \( k \) and its own registered Identity satisfies each half of a split gate. The fold refuses on the leaf: no registered leaf pairs the thief's Identity with the key it stole. Separately, a ciphertext keyed to a key the recipient does not hold decrypts to garbage, and that point is not a registered Identity, so the receipt does not verify.

m_thief = rand_scalar(rng)
thief = account(m_thief)
seed_t = rand_scalar(rng)
k_t, _pk_t = receiving_key(seed_t)
salt_t = derive_salt(seed_t, KYC)
priv.insert_receiving(m_thief, k_t, salt_t)
try:
    deposit_fold_witness(
        m_rec=m_thief, k=k_rec, sk_dep=thief["sk"], salt=salt_t,
        E_dep=thief["E"], note_ct=note.eIss, tree=priv)
    print("thief witness: BUILT (must not happen!)")
except DepositFoldRefused as exc:
    print(f"thief witness: REFUSED on relation {exc.relation}")

pk_bogus = mul(G1, rand_scalar(rng))
eIss_bogus = elgamal_encrypt(issuer["M"], pk_bogus, rand_scalar(rng))
M_I_bogus = elgamal_decrypt(eIss_bogus, k_rec)
print(f"ciphertext under a throwaway key decrypts to {pt(M_I_bogus)}")
print(f"  that point is a registered identity: {tree.contains(M_I_bogus)}")

thief witness: REFUSED on relation 3
ciphertext under a throwaway key decrypts to (49911686...,  9395411...)
  that point is a registered identity: False

A split key names no puppet. The mint binding proves \( eIss \) carries the minter's own Identity to the key hidden in \( Q \), and an ElGamal ciphertext does not commit to its key. So a minter holding a registered sock puppet \( M_B \) picks \( pk_{\text{mint}} = pk_{\text{recv}} + r'^{-1}(M_B - M_I) \): the same \( eIss \) is its own \( M_I \) under \( pk_{\text{mint}} \) and \( M_B \) under Bob's key. The binding verifies, relation (5) holds on \( M_B \)'s leaf, and without more an honest Bob would name the puppet. The more is \( T \): the note commits it, and it opens under the key the minter chose, not Bob's. Bob's wallet refuses the delivery, the fold refuses relation (6), and the receipt refuses to name \( M_B \). mint_unilateral_a2 cannot produce this note, so it is minted by hand:

from alberta_buck.wallet.issuer_reenc import issuer_reenc_prove, issuer_reenc_verify
from alberta_buck.wallet.unilateral_a2 import MintedA2, a2_id_hash
from alberta_buck.wallet.notes import FLAVOR_A2, NoteOpening, note_commitment
from alberta_buck.wallet.delivery import DeliveryRefused, deliver_a2, open_a2

_seed_sp = random.Random(0x5B1175)        # local; the shared transcript is untouched
rng_sp   = lambda: _seed_sp.getrandbits(256)

M_B    = mul(G1, rand_scalar(rng_sp))     # the minter's registered sock puppet
salt_B = derive_salt(rand_scalar(rng_sp), KYC, 1)
priv.insert_identity_salted(M_B, salt_B)
tree.insert(M_B)

r_s     = rand_scalar(rng_sp)
pk_mint = add(pk_recv, mul(add(M_B, neg(issuer["M"])), pow(r_s, -1, ORDER)))
eIss_s  = elgamal_encrypt(issuer["M"], pk_mint, r_s)
gamma_s = rand_scalar(rng_sp)
bind_s  = issuer_reenc_prove(issuer["sk"], r_s, pk_mint, issuer["E"], eIss_s,
                             0xA11CE, CHAINID, gamma=gamma_s, rng=rng_sp)
rn_s    = rand_scalar(rng_sp)
eNote_s = elgamal_encrypt(mul(G1, 1000), pk_recv, rn_s)
idh_s   = a2_id_hash(eNote_s, eIss_s, bind_s.T)
open_s  = NoteOpening(FLAVOR_A2, 1000, rand_scalar(rng_sp), idh_s, 0)
split   = MintedA2(eNote=eNote_s, eIss=eIss_s, M_I=issuer["M"], idHash=idh_s,
                   cm=note_commitment(open_s), opening=open_s, binding=bind_s,
                   r_prime=r_s, r_note=rn_s, gamma=gamma_s, salt_iss=salt_B)

print(f"binding verifies against Alice's record: "
      f"{issuer_reenc_verify(issuer['pk'], issuer['E'], eIss_s, bind_s, 0xA11CE, CHAINID)}")
print(f"Bob's k opens eIss to the puppet:        {eq(elgamal_decrypt(eIss_s, k_rec), M_B)}")
try:
    open_a2(deliver_a2(split, pk_recv), k_rec)
    print("delivery: OPENED (must not happen!)")
except DeliveryRefused as exc:
    print(f"delivery: REFUSED ({exc})")

t_s   = (r_s + rand_scalar(rng_sp)) % ORDER
eEnc_s = elgamal_encrypt(M_B, pk_recv, t_s)
w_s   = deposit_fold_witness(m_rec=m_rec, k=k_rec, sk_dep=rec0["sk"], salt=salt_rec,
                             E_dep=rec0["E"], note_ct=eEnc_s, tree=priv)
try:
    deposit_fold_a2_witness(
        witness=w_s, rho=open_s.rho, id_hash=idh_s, e_note=eNote_s, e_iss=eIss_s,
        r_prime=r_s, t=t_s, r_E=rec0["r"], e_dep=rec0["E"], pk_dep=rec0["pk"],
        e_enc=eEnc_s, salt_iss=salt_B,
        iss_path=priv.path(priv.leaves.index(identity_leaf_salted(M_B, salt_B))),
        T=bind_s.T, gamma=gamma_s, identity_root=priv.root())
    print("fold: BUILT (must not happen!)")
except AssertionError as exc:
    print(f"fold: REFUSED ({exc})")

res_s = verify_receipt(make_receipt(k_rec, M_rec, split, issuer=0xA11CE, chainid=CHAINID,
                                    tree=tree, rng=rng_sp),
                       issuer["pk"], issuer["E"], tree.root(), tree)
print(f"receipt: {'VALID' if res_s.valid else 'INVALID'} ({res_s.reason})")

binding verifies against Alice's record: True
Bob's k opens eIss to the puppet:        True
delivery: REFUSED (T does not open to this mailbox under the unwrapped gamma)
fold: REFUSED (T != rm*G + gamma*H (keyed to another mailbox))
receipt: INVALID (the binding's Identity is not the one decrypted)

That is the guarantee: the recipient holds the secret that names the issuer, the identity scalar does not, a stolen mailbox key does not spend under a different Identity, and a key chosen to frame a puppet does not name one.

An addressed note names an Identity and is keyed to that Identity's receiving key. Those are two different objects doing two different jobs, and it is worth being clear why, because collapsing them into one is the most natural design in the world and it does not work.

The read/write split makes \( m \) a read capability: the design hands it to every counterparty, because that is how a receipt names a person. So it cannot also be the thing that opens the recipient's mail. One disclosure would read every note that person ever receives, in both directions in time. A read capability you give away cannot be a decryption key you keep.

The arithmetic is even less forgiving than the principle. Suppose a leaf encrypted the recipient's Identity under itself: \[ eRec = (r'G,\; M_{\text{rec}} + r'M_{\text{rec}}) = (r'G,\; m_{\text{rec}}(G + R)). \] Message and key would share one secret, so the Diffie-Hellman hardness protecting every other ciphertext here would simply be absent. A candidate Identity tests with one scalar multiplication – no proof, no key, no issuer secret – and an issuer holding its client list could ask "is any note in existence addressed to anyone I certified?" and get answers.

Keying the same plaintext to \( pk_{\text{recv}} \) instead turns that question into a decisional Diffie-Hellman decision, which is the lock the rest of this design already rests on. Run both and watch the difference:

import random
from alberta_buck.wallet.elgamal import elgamal_encrypt, elgamal_decrypt
from alberta_buck.wallet.salt import derive_salt
from alberta_buck.wallet.deposit_fold import (
    DepositFoldRefused, deposit_fold_witness,
)
from alberta_buck.registry.tree import IdentityMerkleTree

_seed_rk = random.Random(0xBADDECAF)      # local; the shared transcript is untouched
rng_rk   = lambda: _seed_rk.getrandbits(256)

m_rec_rk = rand_scalar(rng_rk)                       # the recipient's Identity
M_rec_rk = mul(G1, m_rec_rk)
k_rk     = rand_scalar(rng_rk)                       # the recipient's RECEIVING key
pk_demo  = mul(G1, k_rk)          # local; must not clobber the session's pk_recv

# A harvester's candidate list: every Identity it ever certified, plus the one
# it is hunting.  It holds no keys and needs none.
cands = [rand_scalar(rng_rk) for _ in range(8)] + [m_rec_rk]

# Today's A1 leaf ciphertext: the Identity encrypted under ITSELF.
eRec_today = elgamal_encrypt(M_rec_rk, M_rec_rk, rand_scalar(rng_rk))
hit = [c for c in cands if eq(eRec_today.C, mul(add(G1, eRec_today.R), c))]
print(f"today:   C == m*(G+R) over {len(cands)} candidates -> {len(hit)} hit"
      f"  ({'IDENTIFIED' if hit == [m_rec_rk] else 'no'})")

# The same plaintext under a key that is not the Identity.
eRec_new = elgamal_encrypt(M_rec_rk, pk_demo, rand_scalar(rng_rk))
hit2 = [c for c in cands if eq(eRec_new.C, mul(add(G1, eRec_new.R), c))]
print(f"fixed:   the same scan over the same candidates  -> {len(hit2)} hit")
print(f"         recipient still reads it with k:  {eq(elgamal_decrypt(eRec_new, k_rk), M_rec_rk)}")
print(f"         the Identity scalar no longer does: {eq(elgamal_decrypt(eRec_new, m_rec_rk), M_rec_rk)}")

today:   C == m*(G+R) over 9 candidates -> 1 hit  (IDENTIFIED)
fixed:   the same scan over the same candidates  -> 0 hit
         recipient still reads it with k:  True
         the Identity scalar no longer does: False

Nine candidates, one hit under the collapsed design, zero under the real one. The recipient still reads its mail; it reads it with \( k \), a secret it hands to nobody.

Two secrets need a gate that joins them. Separating reading from Identity buys the privacy above and creates an obligation: the deposit gate must say something a single-secret design would get for free. "I can read this note" and "I am this registered Identity" are facts about two different secrets, and a gate that proved them side by side would say nothing at all about their owner:

sk_rk = rand_scalar(rng_rk); pk_rk = mul(G1, sk_rk)
E_dep_rk = elgamal_encrypt(M_rec_rk, pk_rk, rand_scalar(rng_rk))     # registered account
m_iss_rk = rand_scalar(rng_rk); M_I_rk = mul(G1, m_iss_rk)
eIss_rk = elgamal_encrypt(M_I_rk, pk_demo, rand_scalar(rng_rk))      # A2 note, to the demo key

def split_gate(m_id, k_read, sk_acct, E_acct, ct):
    """The deposit gate with the two jobs merely separated: prove the account
    holds m_id, and prove k_read decrypts the note.  Nothing joins them."""
    holds = eq(E_acct.C, add(mul(G1, m_id), mul(E_acct.R, sk_acct)))
    M = add(ct.C, neg(mul(ct.R, k_read)))                   # whatever k decrypts to
    return holds, M

holds, M = split_gate(m_rec_rk, k_rk, sk_rk, E_dep_rk, eIss_rk)
print(f"honest deposit: account holds the Identity = {holds}, "
      f"decrypts to M_I = {eq(M, M_I_rk)}")

m_thief = rand_scalar(rng_rk); sk_thief = rand_scalar(rng_rk)
E_thief = elgamal_encrypt(mul(G1, m_thief), mul(G1, sk_thief), rand_scalar(rng_rk))
holds_t, M_t = split_gate(m_thief, k_rk, sk_thief, E_thief, eIss_rk)
print(f"thief with a stolen payload and its OWN Identity:")
print(f"  its account holds its own Identity = {holds_t}")
print(f"  the stolen k decrypts to M_I       = {eq(M_t, M_I_rk)}")
print(f"  -> both halves pass.  The note is spendable by the wrong person.")

honest deposit: account holds the Identity = True, decrypts to M_I = True
thief with a stolen payload and its OWN Identity:
  its account holds its own Identity = True
  the stolen k decrypts to M_I       = True
  -> both halves pass.  The note is spendable by the wrong person.

A thief holding a stolen payload proves the reading half with the stolen \( k \) and the Identity half with its own registered Identity. Both halves are true. Neither says they belong together.

So the gate states the tie instead of assuming it – the discipline every relation in the folded gates follows, and for the same reason: never infer equality from two proofs that happen to share a public point. One witness, one circuit, four relations, with the accumulator leaf committing the scalars \( (m, k, salt) \):

secret_rk = rand_scalar(rng_rk)
salt_rk = derive_salt(secret_rk, "kyc:ca-ab-2026")
tree_rk = IdentityMerkleTree(depth=10, private=True)
tree_rk.insert_receiving(m_rec_rk, k_rk, salt_rk)           # scalars, not points
tree_rk.insert_receiving(m_thief, rand_scalar(rng_rk),
                         derive_salt(rand_scalar(rng_rk), "kyc:ca-ab-2026"))

# deposit_fold_witness carries the four relations over ONE witness and
# refuses on the one that fails.  It is the reference the circuit is
# checked against, so this block runs the shipped gate, not a sketch.
w = deposit_fold_witness(m_rec=m_rec_rk, k=k_rk, sk_dep=sk_rk, salt=salt_rk,
                         E_dep=E_dep_rk, note_ct=eIss_rk, tree=tree_rk)
print(f"honest witness: exists, k decrypts to M_I = {eq(w.M, M_I_rk)}")
try:
    deposit_fold_witness(m_rec=m_thief, k=k_rk, sk_dep=sk_thief, salt=salt_rk,
                         E_dep=E_thief, note_ct=eIss_rk, tree=tree_rk)
    print("thief witness: BUILT (must not happen!)")
except DepositFoldRefused as exc:
    print(f"thief witness: REFUSED on relation {exc.relation}")
k2 = rand_scalar(rng_rk); salt2 = derive_salt(secret_rk, "kyc:ca-ab-2026", 1)
tree_rk.insert_receiving(m_rec_rk, k2, salt2)
w2 = deposit_fold_witness(m_rec=m_rec_rk, k=k2, sk_dep=sk_rk, salt=salt2,
                          E_dep=E_dep_rk, tree=tree_rk,
                          note_ct=elgamal_encrypt(M_I_rk, mul(G1, k2),
                                                  rand_scalar(rng_rk)))
print(f"rotated key:   spends, under an unlinkable leaf = {w2.leaf != w.leaf}")

honest witness: exists, k decrypts to M_I = True
thief witness: REFUSED on relation 3
rotated key:   spends, under an unlinkable leaf = True

The thief fails on relation (3): no registered leaf pairs its Identity with the key it stole. Rotation works – a fresh receiving key, a fresh salt, a leaf that links to nothing – because rotation is the accumulator's re-association.

Where each secret lives, and why that is the right place. Authority is the Identity, so losing an account key strands nothing: register another account on the same Identity and deposit. Reading is a key, so it lives in the wallet seed, which is where every wallet has always kept reading keys, with guardian-wrapped copies for the cases that warrant more. What the Identity scalar deliberately cannot do is reconstruct the reading key, because a key derivable from a record you have disclosed is a key held by everyone who has the record. The cost of naming yourself to a counterparty is that they can name you back. It stops there.

What the separation does not cost. Addressing stays unilateral: the payer needs \( pk_{\text{recv}} \), learned on the same out-of-band channel that carries \( M_{\text{rec}} \), and needs nothing from the recipient at payment time. Receipts still name both parties. The note tie keeps its shape, since it witnesses a product of the randomness and the recipient's scalar and computes it fixed-base, and \( r \cdot k \) is as fixed-base as anything else. And B1 needs none of this: a bearer note is keyed to the issuer's registered account key, so the question never arises.

Where to read further. The shipped surface is wallet/recvkey.py (the key, its seed derivation and its binding evidence), registry/tree.py receiving_leaf (the leaf that commits the pair) and wallet/deposit_fold.py (the gate above), with twenty-five tests in alberta_buck/test/test_receiving_key.py. The same arguments also run standalone in scripts/review/receiving_key_proto.py, deposit_gate_split.py and deposit_gate_folded.py.

A1 is A2 with the issuer in the clear. \( idHash \) commits \( (eNote, m_{\text{issuer}}) \) instead of a second ciphertext. eRec encrypts the plaintext \( M_{\text{rec}} \) under \( pk_{\text{recv}} \), not under \( M_{\text{rec}} \): the Identity is what the note names, and the mailbox key is what opens it. The spend gate is deposit_fold_a1, the same four relations as A2 without the issuer-membership relation, because the plaintext of eRec is the recipient's own Identity, which the receiving leaf already commits. The face \( v \) is a public input of that proof. (The batch Schnorr is checked at the mint transaction – verifyIssuerSchnorr; here the signature is synthetic, since the session has no chain.)

from alberta_buck.wallet.unilateral_a1 import (
    mint_unilateral_a1, make_receipt_a1, verify_receipt_a1,
)
from alberta_buck.wallet.deposit_fold import deposit_fold_a1_witness

note_a1 = mint_unilateral_a1(M_rec, pk_recv, v=100, rho=rand_scalar(rng),
                             m_issuer=m_iss, rng=rng)
print(f"minted A1 note: v = {note_a1.opening.v}")
print(f"  idHash = Poseidon6(T_ID, eNote, m_issuer)   = {hex(note_a1.idHash)[:20]}...")
print(f"  eRec   = ElGamal(M_rec under pk_recv)       R = {pt(note_a1.eRec.R)}")
print(f"  identity scalar opens eRec: "
      f"{eq(elgamal_decrypt(note_a1.eRec, m_rec), M_rec)}")
print(f"  receiving secret opens eRec: "
      f"{eq(elgamal_decrypt(note_a1.eRec, k_rec), M_rec)}")

rcpt_a1 = make_receipt_a1(k_rec, M_rec, note_a1, issuer["M"], issuer=0xA11CE,
                          chainid=CHAINID, tree=tree, rng=rng)
res_a1 = verify_receipt_a1(rcpt_a1, tree.root(), tree)
assert res_a1.valid and res_a1.value == 100
assert eq(rcpt_a1.pk_recv, pk_recv)
print(f"A1 receipt: {res_a1.reason} -- issuer public, decryption under pk_recv")

minted A1 note: v = 100
  idHash = Poseidon6(T_ID, eNote, m_issuer)   = 0x911c1e6a2194d467e9...
  eRec   = ElGamal(M_rec under pk_recv)       R = (21561397..., 33803650...)
  identity scalar opens eRec: False
  receiving secret opens eRec: True
A1 receipt: VALID -- issuer public, decryption under pk_recv

The A1 fold witness: the value ciphertext is pinned by the public face. deposit_fold_a1_witness is what deposit_fold_a1.circom consumes. It checks \( eNote = (r_n G,\ (v + r_n k)G) \) and \( eEnc = (t G,\ (m_{\text{rec}} + t k)G) \), with \( v \) public, and the same leaf \( \mathrm{Poseidon}(\tau_R, m_{\text{rec}}, k, salt) \). A different receiving secret does not open \( eNote \). A thief that holds \( k \) and substitutes its own Identity is refused by the leaf, the same relation the A2 block already showed.

w_a1 = deposit_fold_witness(
    m_rec=m_rec, k=k_rec, sk_dep=rec0["sk"], salt=salt_rec,
    E_dep=rec0["E"], note_ct=note_a1.eRec, tree=priv)
t_a1 = rand_scalar(rng)
eEnc_a1 = elgamal_encrypt(M_rec, pk_recv, t_a1)
fold_a1 = deposit_fold_a1_witness(
    witness=w_a1, rho=note_a1.opening.rho, id_hash=note_a1.idHash,
    e_note=note_a1.eNote, v=note_a1.opening.v, m_issuer=m_iss,
    r_note=note_a1.r_note,
    t=t_a1, r_E=rec0["r"], e_dep=rec0["E"], pk_dep=rec0["pk"],
    e_enc=eEnc_a1, identity_root=priv.root())
print(f"A1 fold witness built: {len(fold_a1)} signals, relations asserted")
print(f"  public face v    = {fold_a1['v']}")
print(f"  public nullifier = {hex(int(fold_a1['nullifier']))[:20]}...")

k_other, _pk_other = receiving_key(rand_scalar(rng))
try:
    bad = deposit_fold_witness(
        m_rec=m_rec, k=k_other, sk_dep=rec0["sk"], salt=salt_rec,
        E_dep=rec0["E"], note_ct=note_a1.eRec, tree=priv)
    print(f"wrong mailbox key: BUILT (must not happen!) leaf={bad.leaf}")
except DepositFoldRefused as exc:
    print(f"wrong mailbox key: REFUSED on relation {exc.relation}")

A1 fold witness built: 29 signals, relations asserted
  public face v    = 100
  public nullifier = 0x2803ab97dcb757fc45...
wrong mailbox key: REFUSED on relation 3

The circuit is 3,309,276 constraints on a 32-level path. DepositFoldA1Verifier verifies a real proof on chain (test/DepositFoldA1Verifier.t.sol), and test/NotesE2E.t.sol spends an A1 note through the fold inside the full lifecycle. The dev setup is not a ceremony.

Carol holds a B1 note from a public issuer. She has never been identified to the issuer; at spend she reveals her Identity to the issuer alone, through an encryption only the issuer can decrypt.

==== Step B0: Carol Holds a B1 Note ====

Carol's artifact carries the issuer's public Identity \( M_{\text{issuer}} \) in the clear with a Schnorr signature, but no per-recipient ciphertext (bearer semantics).

==== Step B1: Carol Encrypts Her Identity for the Issuer ====

At deposit Carol's wallet encrypts her Identity under the public issuer's key:

\[ E_{\text{dep}\to\text{iss}} = (R_f, C_f) = (rG,\ M_{\text{Carol}} + r\,pk_{\text{iss}}). \]

Only \( sk_{\text{iss}} \) recovers \( M_{\text{Carol}} \); to Mallory the ciphertext is IND-CPA noise.

==== Step B2: Generate the Depositor-Binding Proof (A2 dual) ====

Carol's wallet proves (b1_bind_prove, verifyDepositorBinding) knowledge of \( (m_{\text{Carol}}, sk_{\text{dep}}, r) \) such that the ciphertext encrypts the same Identity bound to Carol's payout account:

The shared witness \( m_{\text{Carol}} \) couples (E2), (F2), and (P): the Identity bound to Carol's payout account is exactly the one encrypted for the issuer and the one committed (blinded) in \( P_{\text{dep}} \) – so a colluding depositor cannot substitute a different Identity, and the membership below is bound to the right point. (11 Python + 6 Solidity tests.)

==== Step B3: Submit Notes.spendCoupledB1 ====

Carol calls the membership-bound B1 deposit:

notes.spendCoupledB1(
    proof, noteRoot, identityRoot, nullifier, face, recipient,
    issuanceCommitment,              // the mint commitment the spend opened
    issuer,                          // public issuer address
    eDepForIss,                      // (R_f, C_f) encrypting M_Carol
    b1Proof,                         // verifyDepositorBinding (incl. P_dep)
    membershipProof,                 // membership of M_Carol, bound to P_dep
);

The contract verifies the binding, then the membership of b1Proof.P_dep (the same point the binding committed), and emits SpentCoupledB1(nullifier, face, recipient, issuer, eDepForIss) with the ciphertext only the issuer can decrypt. Carol is now provably a registered Identity the issuer can name – the membership-bound dual of the A2 recipient receipt (test/NotesCoupledB1.t.sol, 6 tests).

==== Step B4: Issuer Decrypts and Produces a Receipt ====

The issuer scans SpentCoupledB1 events, decrypts \( M_{\text{Carol}} \) with \( sk_{\text{iss}} \), and alone produces a plaintext receipt naming both parties:

(make_issuer_receipt in alberta_buck.wallet.b1_binding.)

The same session, continued. Carol is a registered Identity the (public) issuer has never met; she holds a bearer note's opening. At spend she builds eDepForIss – her own \( M_{\text{dep}} \) encrypted under the issuer's key – and the five-relation depositor-binding sigma couples it to her payout account and to the blinded membership commitment \( P_{\text{dep}} \):

from alberta_buck.wallet.b1_binding import (
    b1_bind_prove, b1_bind_verify, make_issuer_receipt, verify_issuer_receipt,
)

m_carol = rand_scalar(rng)
carol   = account(m_carol)
tree.insert(carol["M"])

pk_iss = issuer["pk"]
binding, eDepForIss = b1_bind_prove(m_carol, carol["sk"], carol["E"], pk_iss,
                                    account=0xCA801, chainid=CHAINID, rng=rng)
ok = b1_bind_verify(carol["pk"], carol["E"], pk_iss, eDepForIss, binding,
                    account=0xCA801, chainid=CHAINID)
print(f"B1 depositor binding from Carol: verifies = {ok}")
print(f"  eDepForIss = ElGamal(M_carol under pk_iss)  R = {pt(eDepForIss.R)}")
print(f"  P_dep      = {pt(binding.P_dep)}  (blinded; membership binds it)")

B1 depositor binding from Carol: verifies = True
  eDepForIss = ElGamal(M_carol under pk_iss)  R = (87291686...,  3992517...)
  P_dep      = (81747299..., 99754363...)  (blinded; membership binds it)

The issuer alone – reading eDepForIss from the SpentCoupledB1 event – decrypts and proves the depositor's Identity, the dual of the A2 unilateral receipt. And the collusion-substitution is rejected: a ciphertext under any other key breaks the coupled sigma, so the depositor cannot mis-name itself.

rcpt_iss = make_issuer_receipt(issuer["sk"], issuer["M"], eDepForIss,
                               value=25, issuer=0xA11CE, chainid=CHAINID,
                               tree=tree, rng=rng)
res_b1 = verify_issuer_receipt(rcpt_iss, tree.root(), tree)
assert res_b1.valid
assert eq(res_b1.recipient_M, carol["M"])
print(f"issuer-unilateral receipt: {res_b1.reason}")
print(f"  names depositor {pt(res_b1.recipient_M)} == M_carol")

eDep_sub = elgamal_encrypt(carol["M"], mul(G1, rand_scalar(rng)), rand_scalar(rng))
ok_sub = b1_bind_verify(carol["pk"], carol["E"], pk_iss, eDep_sub, binding,
                        account=0xCA801, chainid=CHAINID)
print(f"substituted eDepForIss verifies = {ok_sub}  (collusion-substitution rejected)")

issuer-unilateral receipt: VALID
  names depositor (53868701..., 76614019...) == M_carol
substituted eDepForIss verifies = False  (collusion-substitution rejected)

In all three flows the chain reveals:

• A fresh nullifier and a spent face amount.
• The payout address.
• For A1/A2: the re-encryption \( eEnc \) under an unpublished \( pk_{\text{recv}} \) (semantically secure) and one fold proof; no committed point.
• For B1: the issuer address, \( E_{\text{dep}\to\text{iss}} \) (IND-CPA) and the perfectly hiding \( P_{\text{dep}} \).
• The posted identity root the spend names (one uint256 per posting, revealing nothing about which identities are active, since the leaves are salted).
• No plaintext Identities, no link between the spend and any specific commitment in the tree, and no link between mint and spend events.

from pathlib import Path
SNARK = Path("build/snark")

def mb(*paths):
    total = 0
    for p in paths:
        pp = Path(p)
        if not pp.exists():
            return None
        total += pp.stat().st_size
    return total / 1e6

ARTIFACTS = [
    # circuit                          consumer    zkey                                          witness generator (+ .dat)
    ("mint_batch N=1   (B1/A1 mint)",  "issuer",
     "mint_batch_n1/mint_batch_n1_final.zkey",
     ["mint_batch_n1/mint_batch_n1_js/mint_batch_n1.wasm"]),
    ("mint_batch N=32  (B1/A1 mint)",  "issuer",
     "mint_batch_n32/mint_batch_n32_final.zkey",
     ["mint_batch_n32/mint_batch_n32_js/mint_batch_n32.wasm"]),
    ("mint_batch_a2 N=1  (A2 mint)",   "issuer",
     "mint_batch_a2_n1/mint_batch_a2_n1_final.zkey",
     ["mint_batch_a2_n1/mint_batch_a2_n1_js/mint_batch_a2_n1.wasm"]),
    ("mint_batch_a2 N=32 (A2 mint)",   "issuer",
     "mint_batch_a2_n32/mint_batch_a2_n32_final.zkey",
     ["mint_batch_a2_n32/mint_batch_a2_n32_js/mint_batch_a2_n32.wasm"]),
    ("spend            (all spends)",  "depositor",
     "spend/spend_final.zkey",
     ["spend/spend_js/spend.wasm"]),
    ("b1 membership    (B1 spend)",   "depositor",
     "b1_membership/b1m_0001.zkey",
     ["b1_membership/identity_membership_b1_js/identity_membership_b1.wasm"]),
    ("deposit_fold_a1  (A1 spend)",    "depositor",
     "deposit_fold_a1/deposit_fold_a1_0001.zkey",
     ["deposit_fold_a1/deposit_fold_a1_cpp/deposit_fold_a1",
      "deposit_fold_a1/deposit_fold_a1_cpp/deposit_fold_a1.dat"]),
    ("deposit_fold_a2  (A2 spend)",    "depositor",
     "deposit_fold_a2/deposit_fold_a2_0001.zkey",
     ["deposit_fold_a2/deposit_fold_a2_cpp/deposit_fold_a2",
      "deposit_fold_a2/deposit_fold_a2_cpp/deposit_fold_a2.dat"]),
]
print(f"{'circuit':34s} {'consumer':10s} {'zkey':>10s} {'witness gen':>12s}")
print("-" * 70)
sizes = {}
for name, who, zkey, gens in ARTIFACTS:
    zs = mb(SNARK / zkey)
    gs = mb(*(SNARK / g for g in gens))
    if zs is None or gs is None:
        print(f"{name:34s} {who:10s} {'absent':>8s} {'absent':>12s}")
        continue
    sizes[name] = (zs, gs)
    print(f"{name:34s} {who:10s} {zs:>8.1f}MB {gs:>10.1f}MB")

circuit                            consumer         zkey  witness gen
----------------------------------------------------------------------
mint_batch N=1   (B1/A1 mint)      issuer         10.1MB        2.8MB
mint_batch N=32  (B1/A1 mint)      issuer        321.1MB        5.5MB
mint_batch_a2 N=1  (A2 mint)       issuer         10.6MB        4.3MB
mint_batch_a2 N=32 (A2 mint)       issuer        337.0MB        7.2MB
spend            (all spends)      depositor       5.5MB        3.1MB
b1 membership    (B1 spend)        depositor     272.1MB        8.5MB
deposit_fold_a1  (A1 spend)        depositor    1863.3MB       35.6MB
deposit_fold_a2  (A2 spend)        depositor    2116.0MB       44.4MB

The two fold zkeys dominate. They are the proving keys for the 3,309,276-constraint A1 gate and the 3,833,338-constraint A2 gate, and Groth16 proving keys scale with constraint count. B1's membership key is the 494,701-constraint circuit. Everything else a wallet fetches for a mint or a note opening is a few megabytes to a few hundred.

One real proof per circuit, over the same fixture worlds the live-EVM transcript spends (Receipt, The Whole Flow, Executed): snarkjs (wasm witness + prove) for the small circuits, the circom C++ witness generator

• rapidsnark for the big ties – exactly the pipeline

scripts/snark/gen_e2e_fixtures.sh runs.

import json, shlex, subprocess, tempfile, time

E2E    = SNARK / "e2e"
FIX    = Path("alberta_buck/test/vectors/e2e")
RAPID  = next(Path("lib").glob("rapidsnark-*/bin/prover"))
tmp    = Path(tempfile.mkdtemp(prefix="docflow-prove-"))

def timed(cmd):
    t0 = time.monotonic()
    subprocess.run(cmd, check=True, capture_output=True)
    return time.monotonic() - t0

times = {}

# Issuer: the batch-mint proofs (witness + Groth16 via snarkjs).
for flavor, script in (("b1", "prove_mint_batch.js"),
                       ("a2", "prove_mint_batch_a2.js")):
    args = json.loads((FIX / f"{flavor}.json").read_text())["mint_args"]
    args = [a.replace(f"e2e_{flavor}", f"docflow_{flavor}") for a in args]
    times[f"mint {flavor} (issuer)"] = timed(
        ["node", f"scripts/snark/{script}", *args])

# Depositor: the flavor-agnostic spend proof (against the docflow mint).
payout = json.loads((FIX / "a2.json").read_text())["payout"]
times["spend (depositor, all)"] = timed(
    ["node", "scripts/snark/prove_spend.js",
     "build/snark/mint_batch_a2_n1/fixtures/docflow_a2.json",
     "0", payout, "1", "docflow_a2"])

# Depositor, B1: the repaired membership proof (wasm witness + snarkjs).
b1 = SNARK / "b1_membership"
times["b1 membership (depositor)"] = (
    timed(["npx", "snarkjs", "wtns", "calculate",
           str(b1 / "identity_membership_b1_js/identity_membership_b1.wasm"),
           str(E2E / "b1/b1_membership_input.json"), str(tmp / "b1.wtns")])
  + timed(["npx", "snarkjs", "groth16", "prove", str(b1 / "b1m_0001.zkey"),
           str(tmp / "b1.wtns"),
           str(tmp / "b1_proof.json"), str(tmp / "b1_public.json")]))

# Depositor, addressed flavors: the folded gate (C++ witness + rapidsnark).
for flavor, nb in (("a1", "deposit_fold_a1"), ("a2", "deposit_fold_a2")):
    gen  = SNARK / nb / f"{nb}_cpp" / nb
    zkey = next((SNARK / nb).glob("*_0001.zkey"))
    wit  = timed(["bash", "-c",
                  f"ulimit -s 65520 && {shlex.quote(str(gen))} "
                  f"{shlex.quote(str(E2E / flavor / 'fold_input.json'))} "
                  f"{tmp}/{nb}.wtns"])
    prv  = timed([str(RAPID), str(zkey), f"{tmp}/{nb}.wtns",
                  f"{tmp}/{nb}_proof.json", f"{tmp}/{nb}_public.json"])
    times[f"fold {flavor} (depositor)"] = wit + prv

for k, v in times.items():
    print(f"{k:30s} {v:6.2f}s")

mint b1 (issuer)                 0.96s
mint a2 (issuer)                 0.98s
spend (depositor, all)           0.75s
b1 membership (depositor)       20.09s
fold a1 (depositor)             13.05s
fold a2 (depositor)             16.94s

Download = first-run fetch (zkey + witness generator); prove = wall time for every SNARK that party runs for one note, from the measurements above. The artifact-free sigma legs (Schnorr / issuer_reenc / depositor binding / eEnc re-encryption / receipt vd proofs) add milliseconds and nothing to download.

BILL = [
    ("issuer    b1/a1 (N=1)", ["mint_batch N=1   (B1/A1 mint)"],
     ["mint b1 (issuer)"]),
    ("issuer    a2    (N=1)", ["mint_batch_a2 N=1  (A2 mint)"],
     ["mint a2 (issuer)"]),
    ("depositor b1",          ["spend            (all spends)",
                               "b1 membership    (B1 spend)"],
     ["spend (depositor, all)", "b1 membership (depositor)"]),
    ("depositor a1",          ["spend            (all spends)",
                               "deposit_fold_a1  (A1 spend)"],
     ["spend (depositor, all)", "fold a1 (depositor)"]),
    ("depositor a2",          ["spend            (all spends)",
                               "deposit_fold_a2  (A2 spend)"],
     ["spend (depositor, all)", "fold a2 (depositor)"]),
]
print(f"{'party / flavor':24s} {'download+store':>15s} {'prove (per note)':>17s}")
print("-" * 58)
for who, arts, ts in BILL:
    dl = sum(sum(sizes[a]) for a in arts)
    pt = sum(times[t] for t in ts)
    print(f"{who:24s} {dl:>13.1f}MB {pt:>16.2f}s")

party / flavor            download+store  prove (per note)
----------------------------------------------------------
issuer    b1/a1 (N=1)             12.9MB             0.96s
issuer    a2    (N=1)             14.9MB             0.98s
depositor b1                     289.2MB            20.84s
depositor a1                    1907.6MB            13.81s
depositor a2                    2169.0MB            17.70s

• Lazy, tiered artifact fetch. A receive-and-hold wallet needs zero SNARK artifacts. A B1-spending wallet needs ~25 MB (spend + identity_membership_b1). The 1.9 and 2.2 GB fold keys are needed only to spend an addressed note, so fetch them in the background on first A1/A2 receipt (the user will plausibly spend later), with hash-pinned, resumable downloads. An issuer wallet sizes its mint key to its batch habit: 10 MB at \( N{=}1 \), ~330 MB at \( N{=}32 \).
• One progress bar that matters. Every proof except the depositor's identity gate is under ~2 s – below UX-noticeable for a payment flow. That gate's ~15-20 s (a fold under rapidsnark, or B1's membership under snarkjs) is the one moment to design for: prove in the background between "note received and verified" and "deposit", or show explicit progress at spend. Proving is local and private – nothing leaves the device – and never blocks the counterparty (the issuer's proof is done before delivery; the depositor's at their leisure).
• Per-payment chain bandwidth is negligible next to the artifacts: the depositor replays the commitment tree from Minted calldata (32 B per leaf in the pool plus log overhead) and reads one identity-tree path; both are KB-scale at today's pool sizes and cacheable incrementally.
• Verification is free to distribute: the Groth16 verifiers are on chain, and the bilateral receipts re-verify with no SNARK artifacts at all – a third party checks a slip with the pure-Python wallet alone.

BUCK demurrage is a balance-time integral: each account stores its buckSeconds (the crystallised \( \int B\,dt \)) plus the timestamp of its last touch, and its accrued fee is rate \cdot (buckSeconds + balance \cdot elapsed). Two ledger responses to that accrued fee are distinguishable at transfer time, selected by the sender's isCarrying flag:

• Deducting transfer (sender is non-Carrying, the default). On a 1,000-BUCK outgoing, Alice's accrued fee for the pre-transfer balance is settled at Alice – one-shot burned against her balance, and her buckSeconds is re-crystallised from the new balance. The 1,000 BUCK then lands at Bob fresh: his inflow begins accruing age from now, diluting his effective age. From a system perspective, accrued fees are burned at each transfer and the recipient enters fresh.
• Carrying transfer (sender is isCarrying). On the same 1,000-BUCK outgoing, nothing is burned at the sender: the pool sheds a proportional slice of its live buck-seconds (carried = liveBs \cdot 1000 / poolRaw) and keeps its per-BUCK age. Bob inherits that slice (buckSeconds + carried=), so he absorbs the age of the BUCKs he just received. Nominal balances move by exactly 1,000 on each side; no fee is burned; total system BUCK-age is preserved.

The invariant the carrying variant keeps is: nominal BUCK out = nominal BUCK in (no silent burn at the transfer site), with the recipient's forward index shift representing the demurrage they will pay on their next standard outgoing transfer.

Three structural features of the pool make the deducting default wrong:

1. Per-note age opacity. When Alice mints six notes, the pool records only six opaque Poseidon commitments. The pool cannot deduct "the demurrage Alice's specific note owes" at spend time, because the chain does not distinguish one commitment's age from another. Any per-note fee would have to be computed off the pool aggregate, which would force Bob to pay fees that the pool's other depositors owed – and, worse, differentiate one commitment's payout from another, destroying the anonymity set.
2. Face-to-payout identity. face is the public SNARK output and the value the mint circuit committed to. A deducting pool transfer would deliver face - fee to Bob while the proof claimed face. This would break the mint-to-spend value-conservation invariant: the SNARK's promise would not match the ERC-20 ledger movement, and the spend circuit would have to become aware of demurrage accounting to compensate.
3. Pool as bookkeeping buffer. The pool is not a long-term BUCK holder; every BUCK that enters is earmarked for one future redeemer. Deducting fees at the pool's egress would siphon value into a burn that the pool has no way to replenish, producing a cumulative insolvency as outstanding notes circulate.

The carrying path fixes all three: no per-note age, face to payout, no pool insolvency.

There is no separate transferCarrying method and no TransferCarrying event. The carrying behaviour is selected by a per-account flag, isCarrying, set when the account is bound:

// IdentityRegistry: governance sets isCarrying at bind time.
function bindContract(address t, ..., bool isPublicIdentity_, bool isCarrying_) external;
mapping(address => bool) public isCarrying;