The Alberta Buck - Notes (DRAFT v0.9)

David Chaum invented digital cash in 1982 with the blind-signature e-cash scheme.⁴ By 1989 he had founded DigiCash to commercialize it. By 1998 DigiCash was bankrupt – not because the cryptography failed (it worked), but because no merchant wanted to be the first to accept it and no consumer wanted to be the first to hold it. The two-sided market never bootstrapped.

Stefan Brands extended Chaum's work in 1993 with offline divisible coins that revealed the spender's identity if (and only if) they double-spent.⁵ Camenisch, Hohenberger, and Lysyanskaya improved on this in 2005 with compact divisible e-cash.⁶ None of these schemes ever shipped in production at scale.

Bitcoin, when it arrived in 2009, was deliberately not digital cash in the Chaumian sense. It was digital scarcity with public ledger transparency – closer to digital gold than digital cash. The bearer-paper market that grew up around it (Casascius, OpenDime, paper wallets) was an afterthought, not a design goal.

Zerocash (2014)⁷ and its production deployment as Zcash gave us the first scalable on-chain commitment-and-nullifier UTXO model – the cryptographic primitive that BUCK Notes use. Zcash showed that you can have private on-chain balances; it did not extend that to printable physical bearer instruments. Aztec⁸ extended the model with predicate-encrypted notes for private smart contract calls, but again, no paper.

Tornado Cash⁹ reduced the primitive to its simplest form (fixed-denomination commitments in, anonymous withdrawals out) and was OFAC-sanctioned in 2022. Privacy Pools¹⁰ extended Tornado with per-spend association-set proofs, restoring compliance paths without abandoning the privacy primitive.

The reason all of this never produced BUCK Notes – a printable, demurrage-aware, identity-aware private bearer instrument – is that it required four pieces to come together simultaneously, and they did not until now:

1. A commitment-and-nullifier UTXO model on a smart contract platform (Zerocash gave us this in 2014; Aztec deployed it on Ethereum in 2018-2020).
2. A cryptographic identity layer that lets some notes be targeted to a specific recipient and others be self-wormholed between a user's own unlinkable accounts (the BUCK identity system, with PS signatures, ElGamal credentials, and Chaum-Pedersen re-encryption – see Identity).
3. A demurrage mechanism that solves the lost-cash problem and gives bearer notes a finite lifespan (BUCK's demurrage and Jubilee are unique among monetary systems).
4. A jurisdictional reserve that backs the value, so the bearer note represents a real claim on real assets, not a speculative crypto-token whose price might collapse between print and deposit (Alberta Buck's commodity-basket-stabilized reserve and the BuckK PID controller).

Alberta Buck has all four. No prior system had all four. That is why BUCK Notes is a design, not a workaround.

Before the chapter-length treatment, here is the entire design in one page.

One on-chain primitive. A single Merkle tree of note commitments and a single nullifier set replace every parallel bearer-instrument architecture the Alberta Buck series has previously explored (self-wormholes between private accounts, signed cheques, targeted gifts, printable paper notes).

Two orthogonal axes parameterise a note. Depositor Identity binding (present: only the named recipient may deposit; absent: any registered holder of the opening may) crosses with issuer visibility (public: the issuer's Identity M is in the clear on the note; private: it is encrypted to the recipient). Crossing these yields three realisable flavors – the private-bearer cell is ruled out by BUCK's mutual-decryptability invariant:

• A2 – Addressed Cheque, Private Issuer. The issuer re-randomizes the recipient's registered ElGamal credential into the note payload; the A-spend predicate requires the depositor to produce \( sk_{\text{rec}} \) (the mint-time private key paired with the \( pk_{\text{rec}} \) used for the re-randomization) and prove it decrypts both \( E_{\text{note}} \) and the depositor's own registered credential to the same identity point. A note Alice issues from a private account to a named recipient (including herself at another of her own accounts) with no on-chain edge visible to third parties. The canonical wormhole is the degenerate self-issued subcase.
• A1 – Addressed Cheque, Public Issuer. Same addressed binding as A2, plus a Schnorr signature by the issuer over the commitment with their plaintext M_issuer. A cheque whose maker is publicly attributable and whose recipient is named but not visible to third parties – payroll, audit-friendly disbursement, B2C payment.
• B1 – Bearer Cheque, Public Issuer. Plaintext issuer M; no recipient binding; first registered holder to publish the nullifier \( \rho \) redeems. A cashier's cheque: maker known, bearer not, cash-on-presentation.

Demurrage needs no new machinery. The Notes Pool is simply the Notes contract's own ERC-20 balance – a regular BUCK account tracked by the existing demurrage ledger. Mint pulls totalFace BUCK from the caller via standard ERC-20 transfer (sender pays their own outgoing demurrage fee). Spend uses a carrying transfer unique to the Notes contract's single egress path: the recipient's nominal balance rises by the full face value, and their _indexAtLastTouch weighted-merges toward the pool's stale index, inheriting the average pool-residence demurrage on the inflowing share. Donations to the contract freshen the pool's index, directly lowering the demurrage absorbed by all subsequent spends. Conservation is automatic; the Jubilee continues to grow autonomously per BUCK's standard accounting.

Lost notes return value to the commons. Demurrage solves physical cash's oldest problem: a lost note's value decays at the same rate as an on-chain balance, with the difference accruing to the Jubilee rather than as seigniorage to the issuer.

Holding semantics differ by flavor. The addressed flavors (A1, A2) are cryptographically safe for long-term holding, because the spend predicate binds the recipient's Identity M and no mint-time knowledge enables a non-recipient to spend. The bearer flavor (B1) is a civil-trust instrument: the issuer necessarily knows \( \rho \) and could race the holder to deposit, so B1 cheques are meant to be cashed promptly and trusted only to the extent the issuer's legal standing and operational discipline warrant. This is an intrinsic cryptographic property, not a policy choice.

The remainder of this document develops each piece in detail and establishes the formal proofs (Theorems 7-11 of the companion Proofs document).

The Notes contract is a separate, dedicated contract (src/Notes.sol) holding a Tornado-style incremental Poseidon-T3 Merkle tree, a nullifier set, and a small ring buffer of historical roots.

The tree is fixed at depth \( d=20 \) (\(\approx 1{,}048{,}576\) leaves) and uses Poseidon-T3 (2-input) at every internal node. Under Phase-7-bis the per-leaf Merkle insertion logic lives inside the mint SNARK; the contract itself does not maintain zeros[] or filledSubtrees[] and does not expose an on-chain _insert() entry point. Every mint submits a SNARK-attested newRoot which the contract writes into roots[] in one step. The ring buffer holds the 30 most recent roots so spends remain valid for a short window after new notes are inserted, without requiring per-spend root-update synchronisation. The per-commitment commitmentExists duplicate-reject map from Phase 7 has also been retired – duplicate mints are now economically self-punishing via the deterministic nullifier \( \text{Poseidon}_3(\rho, \text{idHash}, 4242) \), so the chain does not need an explicit check.

The Notes pool – the BUCK custody side of the design – is just the Notes contract's own ERC-20 balance. No separate poolBalance, poolAge, or poolT state is maintained: the BUCK ledger's own per-account balance and demurrage index for address(notes) already are the pool, and noteFaceSum is a pure audit scalar (the total face-value liability outstanding). The pool is registered isSystemPublic in the IdentityRegistry so that identity-bound transfers from any registered party can land at it.

BUCKs transferred to the Notes contract on mint join its ERC-20 balance through the normal path. BUCKs transferred out on spend use a single new BUCK primitive – transferCarrying – which moves both face value and a proportional share of accumulated demurrage (via a weighted-index merge on the recipient's _indexAtLastTouch) from the pool to the recipient. This is the only non-standard BUCK operation in the design; see "Demurrage at the Pool Level" below.

A note commitment is a Poseidon hash of the fields the SNARK will later open:

\[ cm \;=\; H_{\text{cm}}\!\left(\text{flavor},\; v,\; \rho,\; \text{id-payload},\; \text{predicate}\right) \]

with:

• flavor \( \in \{A1, A2, B1\} \): the Identity-binding flavor
• v \( \in \mathbb{Z}_q \): face value
• \( \rho \): per-note randomness (source of the nullifier)
• id-payload: Identity-binding data (see "Note Flavors" section)
• predicate: optional additional spend predicate (time locks, oracle conditions, multi-sig; not elaborated in detail here – a single bit predicate == None keeps the SNARK to the three base flavors. See "Open Questions" for bounded-programmability notes.)

No per-note timestamp or baked-in BUCK-age: demurrage is computed at redemption time from the pool's account state \( (B, A) \), not from the individual note's life history, so no per-note age fields need to ride in the commitment¹¹.

The commitment is inserted as a leaf of noteTree at mint time.

The nullifier is a pseudo-random function of the note's secret witness material:

\[ nf \;=\; \text{PRF}_{\text{key}}(\rho) \]

where key is the spend-side secret specific to the flavor: the recipient's identity point \( M_{\text{rec}} \) for A-spend (recovered in-circuit by ElGamal-decrypting \( E_{\text{note}} \) under the depositor-supplied \( sk_{\text{dep}} \), which must equal the mint-time \( sk_{\text{rec}} \)), or \( \rho \) itself for B-spend (publicly derivable by any holder of the opening). The PRF is instantiated via Poseidon in the SNARK-friendly setting.

The nullifier is emitted on deposit; double-spend is rejected by set-membership check.

mint (burn, Phase-7-bis batch):
  # The caller supplies a batch of N commitments, the SNARK-attested
  # newRoot, and the oldRoot / nextLeafIndex they based the proof on.
  # The per-leaf Poseidon insertion is inside the SNARK, not on chain.
  require cms.length > 0
  require oldRoot       == roots[currentRootIndex]    # stale-state guard
  require nextLeafIndex == self.nextLeafIndex         # stale-state guard
  cmBatchHash = keccak256(abi.encodePacked(cms))
  require mintVerifiers[cms.length].verifyMint(
            proof, oldRoot, newRoot, nextLeafIndex, totalFace, cmBatchHash)
  # The SNARK has proved, for some witness
  #   (flavor_i, v_i, rho_i, idHash_i, predHash_i, pathSiblings_i)_i:
  #     - cm_i = Poseidon5(flavor_i, v_i, rho_i, idHash_i, predHash_i)
  #     - v_i in [0, 2^128), totalFace in [0, 2^128)  # Num2Bits(128)
  #     - sum(v_i) == totalFace
  #     - folding {cm_i} onto oldRoot at nextLeafIndex using pathSiblings_i
  #       yields newRoot
  #     - cmBatchHash == H(cm_0, ..., cm_{N-1})
  buck.transferFrom(caller, address(this), totalFace)
  # Adopt the SNARK-attested new root and advance the rolling state.
  currentRootIndex = (currentRootIndex + 1) % ROOT_HISTORY_SIZE
  roots[currentRootIndex] = newRoot
  self.nextLeafIndex     += cms.length
  noteFaceSum            += totalFace
  emit Minted(caller, totalFace, nextLeafIndex, cms.length, newRoot)

spend (mint-out):
  # caller supplies (proof, root, nullifier, face, recipient)
  require root in roots[]         # any of the last 30 historical roots
  require nullifier not in nullifiers
  verify SNARK (spend, B-flavor / bearer shape):
    - face in [0, 2^128) and face == v   # Num2Bits(128) on both
    - cm = Poseidon5(flavor, v, rho, idHash, predHash)
    - Merkle inclusion of cm under root  # Switcher + Poseidon(2) per level
    - nullifier == Poseidon3(rho, idHash, 4242)
    - ghost-bind public signals (face, recipient, chainId) via x*x
  nullifiers[nullifier] = true
  noteFaceSum -= face
  # The single new BUCK primitive: pay the face out of the pool to
  # recipient and merge the pool's demurrage index into recipient's
  # weighted-average _indexAtLastTouch.  Recipient receives face BUCK
  # and inherits the pool's average BUCK-age proportional to their
  # delivered share of the new total balance.
  buck.transferCarrying(recipient, face)

Full face value is delivered: the recipient's nominal balance goes up by exactly face. The pool's demurrage cost rides along as a weighted-merge of the pool's _indexAtLastTouch into the recipient's index, in proportion to the inflowing share of their new total balance. The recipient bears that demurrage on their subsequent outgoing transfers through the ordinary BUCK accounting path – the same path any holder travels, but on an inherited index acquired by accepting the note. No Jubilee payment is emitted from inside spend; the Jubilee grows autonomously per BUCK's standard _advanceGlobals / _accrueJubilee machinery, independent of how BUCK is distributed between accounts.

A standard BUCK transfer between two registered identities is a synchronous bilateral exchange:

1. Alice calls approve(bob, v, E_alice_for_bob, CP_proof). She re-encrypts her credential under \( pk_{\text{bob}} \) and proves (Chaum-Pedersen) that the re-encryption carries the same \( M_{\text{alice}} \) as her registered credential.
2. Bob calls approve(alice, 0, E_bob_for_alice, CP_proof). Same in the other direction.
3. transfer(bob, v) consummates the transfer once both halves are recorded.

All three steps may land in the same block, as long as they're available by transfer(bob, v)-time. Each party learns the other's \( M \); every on-chain observer sees both addresses, the amount, and the timing. The transfer edge (alice, bob, v, t) is public and permanent.

A Note reorganises the same three messages:

1. Mint. Alice performs her half of approve against a pool commitment rather than directly against Bob. Depending on whether the depositor is known at mint time, she either encrypts her credential under the depositor's public key (E_alice_for_depositor, identity-bound flavor) or publishes her credential in the clear with a bearer secret \( \rho \) (public-issuer bearer flavor). The commitment is appended to noteTree; Alice's outgoing BUCKs lands in the pool's balance \( B \).

2. Deposit. The eventual depositor submits a SNARK-proved spend predicate that simultaneously:

   • opens the commitment and proves nullifier correctness,
   • completes their half of approve by attaching E_depositor_for_issuer (the mirror ElGamal ciphertext) as a deposit-event payload, and
   • authorises transferCarrying(recipient, face) out of the pool, weighted-merging the pool's demurrage index into the recipient's _indexAtLastTouch.
3. Receipt. The issuer later scans deposit events for the nullifier of the note she printed and reads E_depositor_for_issuer to learn who cashed it.

Both parties end up with the same cryptographic knowledge of each other that approve would have produced. The only difference from the observer's perspective is that mint and deposit are two independent transactions, and the commitment pool hides which mint corresponds to which deposit; the demurrage liability transferred with \( v \) is the Note pool average at that instant¹¹.

Every BUCK transfer, note or otherwise, preserves a load-bearing Identity property: both parties must end up able to decrypt each other's \( M \). In approve, this is achieved explicitly by the two re-encryption calls. In a Note, the same property must still hold:

• At mint time, the issuer has to publish, alongside the commitment, enough material that the eventual depositor can recover \( M_{\text{issuer}} \).
• At deposit time, the depositor has to publish enough material that the issuer (reading chain events) can recover \( M_{\text{depositor}} \).

This invariant is the single strongest constraint on note structure. It is what rules out pure-bearer anonymous notes (neither party learns the other's identity), and what forces the exactly-three-flavor taxonomy below.

At mint: a transfer of \( v \) BUCKs from Alice's address to the contract address, plus a Minted(issuer, totalFace, startIndex, count, newRoot) event. The commitments themselves live in the transaction calldata (cms[]); each \( cm_i \) is a Poseidon hash, so observers learn nothing about the opening, the depositor, the issuer flavor, or \( \rho \).

At deposit: a transferCarrying of face BUCKs from the Notes contract address to the depositor's address, plus a Deposited(nf, E_depositor_for_issuer) event. Observers learn who the depositor is (standard transfer visibility), but not which mint this corresponds to. The TransferCarrying event is distinguishable from a standard Transfer, but only as a generic pool-egress signal; it does not link mint to spend.

The two transactions are decoupled in time and unlinked in the chain state. Any mass-harvest analysis that tries to reconstruct the (issuer, depositor, v, t) edge must either (a) correlate timing across the whole pool anonymity set, (b) subpoena a party with direct knowledge, or (c) break the SNARK / Poseidon.

Almost every downstream design choice is a corollary of "deferred approve handshake":

• Three note flavors correspond to three valid ways to complete the two halves of the approve across time (next section).
• Mutual decryptability is the invariant that kills a fourth flavor (private issuer, unknown depositor).
• Selective disclosure for compliance is the natural consequence of each party still holding cryptographic receipts of its counterparty, exactly as in approve.
• Integration with regular transfers requires no new semantics at the contract boundary: a note deposit is an ERC-20 transfer from the contract address, and the identity-exchange payload in the event is structurally identical to the receipt fragment approve already stores.

The opening is transmitted privately from issuer to depositor (for a self-wormhole A2, both are the same user operating from different accounts) through an out-of-band encrypted channel – typically the wallet's internal storage, or a direct peer-to-peer message between wallets. The note never leaves the issuer's control infrastructure. The canonical self-wormhole case: Alice mints an A2 note targeting her own M from a private account and deposits it into a second unlinkable account.

The opening travels as a digital message: an email, SMS, QR shown on a screen, signal-messenger attachment, NFC handoff. No physical artifact exists, but the recipient can store, forward, or print the opening at their convenience. A1 addressed cheques between parties with reliable digital communication occupy this surface.

The opening is printed as a QR code on a slip of paper, a card, a steel plate, or a sticker. For addressed notes (A1, A2) – where the cryptography already prevents a photographing observer from spending – no physical seal is required. For bearer B1 cheques – where whoever reads \( \rho \) can spend – the QR must be protected by a tamper-evident seal (hologram, scratch-off panel, or laminated sleeve) so the holder can verify they were the first to expose the secret.

A printed note typically also carries:

• A visible denomination (1, 5, 10, 100, 1,000, 10,000 BUCK) for human convenience. The actual value is what the commitment encodes; the printed face is metadata that a wallet verifies before deposit.
• A human-readable issuer mark, for visual recognition. Cryptographic authenticity comes from the on-chain commitment, not the mark.
• Redundant QRs front and back with Reed-Solomon error correction, plus the secret in base32 digits for manual recovery.

Paper notes are the form most people will think of when they hear "BUCK Note." Physical paper is the surface of last resort: it works offline, without batteries, across borders, through power outages, and past the expiration of any given digital communication channel.

A "fake" BUCK Note is any opening whose claimed commitment does not appear in the on-chain note tree. The Merkle inclusion proof inside the spend SNARK fails. No mint occurs. No second-guessing is required: there is no paper-inspection threshold to deceive and no "close enough" forgery that a harried cashier might accept.

This is a stronger anti-counterfeit guarantee than the Bank of Canada provides for physical $20 bills. Polymer banknotes can be counterfeited (the techniques are well-published; the question is only whether the counterfeit passes casual inspection). A BUCK Note cannot be counterfeited at all – the on-chain commitment registry is the authentic-bill list, and any printed note whose commitment is not in the tree will produce a FAKE wallet status on scan and nothing more.

A user-facing wallet that scans a BUCK Note (from chain storage, message, or paper QR) displays one of five statuses:

Casual users do not need to understand the underlying cryptography any more than they need to understand the security features of a $20 bill. They scan, see VALID, and accept the note as payment.

On Deposit, the wallet constructs the SNARK locally (or via a delegated prover service for thin clients), submits the transaction, and displays the result. SNARK construction for a single-note deposit is on the order of seconds on a modern smartphone – Aztec's Noir compiler and Zcash's Halo2 prover both run on mobile.

After successful deposit, the note's nullifier is consumed and the QR is permanently dead. A torn-in-half paper note is a human signal of finality, not a cryptographic one – but it's a useful ritual to prevent confused future holders from trying to redeposit a dead QR.

The canonical private-to-private transfer. Subsumes "self-wormhole" (the degenerate case issuer \(\equiv\) recipient, where Alice mints to her own registered \( M \) and later deposits from a different registered credential bound to the same \( M \)).

Mint. The issuer reads the recipient's registered credential \( E_{\text{rec}}^{(\text{reg})} = (R_r, C_r) \) from the IdentityRegistry and re-randomises it with fresh \( r' \):

\[ E_{\text{note}} \;=\; (R_r + r' G,\ C_r + r' \cdot pk_{\text{rec}}) \;=\; \bigl((r_r + r') G,\ M_{\text{rec}} + (r_r + r') pk_{\text{rec}}\bigr). \]

This is a valid ElGamal encryption of \( M_{\text{rec}} \) under \( pk_{\text{rec}} \) with randomness \( r_r + r' \). The issuer never learns \( M_{\text{rec}} \) or \( r_r \) – only the on-chain ciphertext is used as a re-randomisation template. To complete her half of the deferred approve, the issuer also encrypts her own \( M_{\text{issuer}} \) under \( pk_{\text{rec}} \) as \( E_{\text{iss-for-rec}} \) and packs it alongside the commitment.

\[ \text{payload}^{A2} \;=\; \bigl(E_{\text{note}},\ E_{\text{iss-for-rec}}\bigr) \]

Scan. The recipient trial-decrypts each candidate note's \( E_{\text{note}} \) with her own \( sk_{\text{rec}} \) and checks whether the result equals her \( M_{\text{rec}} \) (which she knows). Exactly one ElGamal decrypt and one point-equality per candidate – the same scan cost as a stealth-address scheme.

Spend. The depositor (who must be the recipient – specifically, the holder of \( sk_{\text{rec}} \) paired with the mint-time \( pk_{\text{rec}} \)) produces a SNARK proving:

1. Merkle inclusion of \( cm = H_{\text{cm}}(\text{flavor},\ v,\ \rho,\ \text{payload}^{A2}) \) in noteTree.
2. Nullifier \( nf = H_{\text{nf}}(\text{A} \| M_{\text{rec}} \| \rho) \), with \( M_{\text{rec}} = C_n - sk_{\text{dep}} \cdot R_n \) computed in-circuit from \( E_{\text{note}} = (R_n, C_n) \). Keying on \( M_{\text{rec}} \) rather than \( sk_{\text{dep}} \) keeps the nullifier value independent of which signing key decrypted \( E_{\text{note}} \) (a privacy property of the hash), but does not enable key-loss recovery: the decryption step itself requires the specific \( sk_{\text{rec}} \) paired with the mint-time \( pk_{\text{rec}} \).
3. Chaum-Pedersen equality (Theorem 6) between the depositor's registered \( E_{\text{dep}}^{(\text{reg})} \) and the note's \( E_{\text{note}} \): both decrypt to the same \( M \) under the same \( sk_{\text{dep}} \). The circuit uses a single secret-key witness, so this constraint implicitly forces \( pk_{\text{rec}} = pk_{\text{dep}} \) – the depositor's current registered public key must equal the recipient's mint-time key.
4. faceValue \( = v \).

Simultaneously, the depositor attaches E_depositor_for_issuer (an ElGamal re-encryption of their own \( M_{\text{dep}} \) under the issuer's \( pk_{\text{issuer}} \)) as a deposit-event payload, completing the approve handshake. The issuer's \( pk_{\text{issuer}} \) is not in the commitment (privacy!) but is carried inside the private witness and decrypted by the recipient from \( E_{\text{iss-for-rec}} \).

Consequences. Only the holder of the mint-time \( sk_{\text{rec}} \) can deposit (CP-soundness under single-key ElGamal). The issuer cannot spend what she printed unless she herself is the recipient. A-notes are bound to the mint-time key pair: Identity re-issuance to a fresh \( (sk', pk') \) on the same \( M \) does not restore spend capability, because \( E_{\text{note}} \) is under \( pk_{\text{rec}} \) and the fresh \( sk' \) cannot decrypt it. Loss of \( sk_{\text{rec}} \) renders the note unspendable; see "Key-Pair Binding and Loss Semantics" below.

Identical to A2 except the issuer additionally publishes her own \( M_{\text{issuer}} \) in the clear, with a Schnorr signature binding it to \( cm \):

\[ \text{payload}^{A1} \;=\; \bigl(E_{\text{note}},\ m_{\text{issuer}},\ \sigma_{\text{issuer}}\bigr) \]

The depositor no longer needs E_iss-for-rec – she reads \( M_{\text{issuer}} \) directly. No privacy loss for the depositor: E_depositor_for_issuer still conceals who deposited from casual observers, because the deposit event is only linkable to a specific note by someone holding \( \rho \) or scanning the commitment pool exhaustively.

Public issuers are typically institutional (employers, charities, payroll processors). Their identity is already public; baking it into the note adds audit value without changing any cryptography.

Use cases. Payroll from a named employer to an identified employee, charitable disbursement to an identified grantee, attribution-preserving B2C payment where the customer wants a cryptographic record that a specific merchant paid them.

The classic cashier's cheque. The issuer does not know the depositor at mint time; the note is bearer, and whoever shows up first with knowledge of \( \rho \) and a valid registered credential deposits.

\[ \text{payload}^{B1} \;=\; \bigl(m_{\text{issuer}},\ \sigma_{\text{issuer}},\ pk_{\text{issuer}}\bigr) \]

No depositor-side ElGamal is pre-encrypted because no depositor is known. The depositor reads the issuer's identity in the clear; the issuer reads the depositor's E_depositor_for_issuer from the deposit event. Mutual decryptability holds – just entirely via the public-issuer side at mint, and via the deposit-event payload at deposit.

Spend. The depositor produces a SNARK proving:

1. Merkle inclusion of \( cm = H_{\text{cm}}(\text{flavor},\ v,\ \rho,\ \text{payload}^{B1}) \).
2. Nullifier \( nf = H_{\text{nf}}(\text{flavor} \| \rho) \) (publicly derivable from \( \rho \); this is the first-come-first-served property of bearer notes).
3. Signature-in-SNARK check: \( \sigma_{\text{issuer}} \) verifies against \( pk_{\text{issuer}} \) in IdentityRegistry.
4. Schnorr PoK of \( sk_{\text{dep}} \) for registered \( pk_{\text{dep}} \), Fiat-Shamir bound to msg.sender, chainid, nullifier.
5. faceValue \( = v \).

No CP-equality is required – the issuer is public, the depositor is any registered identity, and the approve handshake completes via plaintext \( M_{\text{issuer}} \) plus E_depositor_for_issuer.

Consequences. The issuer knows \( \rho \) and therefore can race the intended bearer to deposit. But any such deposit attaches the issuer's identity to the deposit event – so an issuer-turned-thief is identified at the moment of theft. This is a civil-trust problem (the issuer breaks a promise to the bearer), not a cryptographic vulnerability. Same trust model as a paper cashier's cheque: the bank can in principle redirect the draft, and the law stops them.

The cryptographic taxonomy collapses to two spend-circuit shapes: an A-spend (CP-equality, covering A1 and A2) and a B-spend (Schnorr PoK + \( \rho \), covering B1). The public-vs-private issuer distinction is commitment metadata, not a separate circuit.

A fourth flavor – bearer notes with no identity hook on either side – is intentionally absent; see "What This Architecture Rules Out" below.

The Notes contract's own address is a registered account in the ordinary sense (system-public in IdentityRegistry). BUCKs flowing in (mints, donations) is a standard incoming transfer; BUCKs flowing out (spends) uses transferCarrying. The only contract-local state not already tracked by the BUCK ledger is the Merkle-tree root history (roots[], nextLeafIndex), the nullifier set (nullifiers), and noteFaceSum (aggregate live face value – an audit scalar, not a liability figure).

A regular transfer(alice, bob, v) followed (or preceded) by approve(alice, bob) has the following on-chain signature:

• Alice's account: face debited from her balance, plus her accumulated fee burned and _indexAtLastTouch[alice] reset to cumIndex_now.
• Bob's account: balance credited by face, his _indexAtLastTouch weighted-merged toward cumIndex_now.
• Edge observable: Alice –> Bob, amount face, block \( t \).

The A-flavor Note equivalent (A2 between two anon-valid accounts):

• Alice mints: standard ERC-20 transfer of totalFace to the Notes contract. Alice pays her own outgoing-transfer fee and resets her index, exactly as in a regular transfer. The pool's balance gains totalFace; its index weighted-merges forward.
• Bob spends at time \( t + \Delta \): the pool's transferCarrying delivers face to Bob and weighted-merges the pool's stale _indexAtLastTouch into Bob's index. Bob now bears the pool's averaged demurrage on the inflowing share of his balance.
• Edge observable: Alice –> pool at \( t \); pool –> Bob at \( t + \Delta \). The edge connecting them is erased.

Economic outcomes match a regular transfer up to the timing difference: Bob acquires the pool's averaged BUCK-age on the inflow, regardless of how long Bob's specific commitment sat in the tree. This is the key property that makes indefinite holding of A-flavor Notes economically equivalent to holding BUCK – same demurrage rate (averaged over the pool), just with a different edge visible on chain.

A B1 cashier's cheque replaces the bilateral approve with a public-issuer signature binding the note to a specific \( M_{\text{issuer}} \) and leaves the depositor unspecified:

• Issuer mints: transfer from issuer to pool. The issuer's \( m_{\text{issuer}} \) is bound into the commitment via the Schnorr signature.
• First registered holder to publish \( \rho \) deposits: pool –> depositor at some later time.
• The depositor and issuer end up mutually identified (per the BUCK invariant) through the note's commitment payload plus the on-chain deposit actor; no third party sees the edge.

A B1 Note is the natural digital analogue of a cashier's cheque drawn on a bank: the bank (public issuer) has pre-committed the funds; whoever presents the instrument redeems them.

Relative to a regular transfer, every Note costs additional gas for the SNARK verifier (mint or spend) and requires wallet software capable of producing the proof. For routine payments between counterparties who do not need to defeat chain analytics, a regular transfer is strictly cheaper and simpler. Notes are the correct tool when the privacy property – no on-chain edge between payer and recipient – is worth the additional gas and proving time, or when the instrument semantics (deferred recipient choice, pre-signed cheque, paper distribution) are themselves the point.

Notes compose transparently with the rest of BUCK:

• Identity Fountain re-issuance applies to Note mints and deposits identically to regular transfers. A-flavor notes do not benefit from re-issuance recovery: they are bound to the recipient's mint-time \( sk_{\text{rec}} \) via single-key ElGamal, so a fresh keypair cannot decrypt an \( E_{\text{note}} \) printed against the previous \( pk_{\text{rec}} \).
• Sanctions and Jubilee operate at the account level and reach the pool through its own account state, requiring no Notes-specific logic.
• Demurrage is accounted on each B_X, A_X pair including the pool's; pool-rate demurrage is a consequence of this accounting, not a parallel mechanism.
• Wallet UX can expose Notes as an alternative send mode in the same UI flow that calls transfer; the difference between "direct send" and "private send" becomes a single toggle.

BUCK accounts no longer carry an explicit BUCK-age \( A_X \) state. The implementation uses a global cumulative index, cumIndex, that grows at a fixed rate BASE_RATE_PER_SEC per second; each account stores only one extra scalar, _indexAtLastTouch[X], the value of cumIndex at the account's most recent settlement.

The fee owed by account \( X \) at any moment is \[ \text{feeOwing}(X) \;=\; B_X \cdot \frac{\text{cumIndex}_{\text{now}} - \text{idx}_X}{\text{SCALE}}, \] i.e. the account's nominal balance times the slice of cumIndex accumulated since it last touched. This is mathematically equivalent to the older \( \kappa A_X \) formulation – BUCK-age \( A_X = B_X \cdot (\text{cumIndex}_{\text{now}} - \text{idx}_X)/(\text{rate} \cdot \text{SCALE}) \) – but stores nothing per-account beyond a single index value.

On a standard ERC-20 transfer the sender's accumulated fee is first burned (its outgoing balance is reduced and totalSupply drops), the sender's idx resets to cumIndex, and the recipient's idx is weighted-merged toward cumIndex – the recipient receives clean BUCK with no inherited age and pays no fee.

Once per touch, the contract also "accrues the Jubilee": the gap between the Jubilee's required balance (its own accumulated cumIndex slice times totalSupply) and its actual balance is minted into the Jubilee account, and its idx is weighted-merged forward. This keeps the system-wide invariant

\[ \sum_{\text{all accounts } X} B_X \;=\; \text{totalSupply (incl. Jubilee)} \]

automatically preserved across every transfer.

The Notes pool is an ordinary BUCK account (the Notes contract's own ERC-20 balance). Its demurrage state is therefore exactly two numbers maintained by the BUCK ledger:

• \( B \) = balanceOf(notes) – BUCK transferred in via mint and donations, minus BUCK transferred out via spend.
• \( \text{idx}_{\text{pool}} \) = _indexAtLastTouch[address(notes)], the cumIndex snapshot at the pool's most recent touch.

The pool's effective fee-owed at this moment is \( B \cdot (\text{cumIndex}_{\text{now}} - \text{idx}_{\text{pool}})/\text{SCALE} \). The Notes contract never reads or writes either value: it lives inside the BUCK ledger just like every other account. Mints weighted-merge idx_pool toward the new cumIndex; spends use the carrying primitive defined next.

When a note of face \( v \) is spent, the Notes contract calls the single new BUCK primitive transferCarrying(recipient, v). Unlike the standard ERC-20 transfer, transferCarrying does not burn any sender-side fee: the pool's index is left untouched, the full face value lands in the recipient, and the recipient's _indexAtLastTouch is weighted-merged toward the pool's index (which is older than cumIndex_now, hence carries fee owed):

br        = balanceOf(recipient)                    // before transfer
idxFrom   = _indexAtLastTouch[pool]                 // pool's stale index
_indexAtLastTouch[recipient]
    = (br * _indexAtLastTouch[recipient] + v * idxFrom)
                             / (br + v)
_update(pool, recipient, v)                         // ordinary balance move

The pool's _indexAtLastTouch is not disturbed – successive spends from the pool draw against the same shared index, so each recipient inherits the same per-BUCK age share as long as the pool keeps minting and spending without an intervening standard transfer.

The recipient's combined index after the merge corresponds to a weighted average of the two BUCK-ages: the recipient's prior holding ages from its prior idx, and the freshly received \( v \) BUCK ages from the pool's idx. When the recipient next makes a standard outgoing transfer they pay the (combined) fee out of their balance, exactly as if they had personally held \( v \) BUCK across the pool's residence period.

This is the cost of anonymity: the recipient inherits the average pool BUCK-age, which is a net benefit for any note that has been held longer than the pool's average age, and a net cost for notes spent quickly into the pool. In practice, fast-circulating notes subsidise slow ones.

Any BUCK transferred to the Notes contract without minting a corresponding note arrives via a standard ERC-20 transfer, which weighted-merges the pool's _indexAtLastTouch toward the current cumIndex (i.e. forward in time). The pool's per-BUCK fee owed drops; subsequent transferCarrying spends therefore deliver recipients an index closer to cumIndex_now, meaning a smaller inherited fee-share per face unit. Over a sequence of spends, the donation is consumed as a demurrage subsidy for live noteholders.

Four origin cases, all handled identically:

1. Accidental transfers. A user fat-fingers the Notes contract as a recipient. Their BUCK is not burned; it freshens idx_pool, and future redeemers inherit marginally less fee.
2. Philanthropic donations. A user deliberately sends BUCK to the pool to subsidise noteholders. The subsidy spreads across all future redemptions until idx_pool staleness rebuilds.
3. Recovered collateral. Mechanism-level refunds (e.g., an issuer's collateral unlock) sent to the pool address.
4. Rounding / dust. Integer-arithmetic residuals. Self-healing.

After all notes are eventually spent, any remaining donation principal sits at noteFaceSum = 0, balanceOf(notes) > 0 – unclaimable by spend, but available to subsidise a fresh round of mints if the pool is used again, or recoverable by governance sweep (per Notes contract policy).

transferCarrying conserves the pool's and recipient's nominal balances exactly:

• \( \Delta B_{\text{pool}} + \Delta B_{\text{recipient}} = 0 \).

No fee is burned, no totalSupply movement happens; the recipient's idx weighted-merge is pure bookkeeping. The next time the recipient makes a standard transfer, the inherited fee-share will be paid out of their balance and into the Jubilee via the ordinary BUCK accounting path.

Globally, the system-wide invariant \( \sum_X B_X = \text{totalSupply (incl. Jubilee)} \) holds across every transfer (carrying or standard) by construction. The Jubilee's required-balance growth is independent of how BUCK is distributed between accounts; it depends only on cumIndex and totalSupply. No pool-specific conservation theorem is required.

Suppose the pool holds \( B = 10\,000\,000 \) BUCK and was last touched 0.5 yr ago, so the pool's idx_pool lags cumIndex_now by an amount corresponding to a 1% fee owed (the BUCK base demurrage rate is 2% per year). The pool currently owes the Jubilee \( 100\,000 \) BUCK against its \( 10\,000\,000 \) face.

Alice spends a note of face \( v = 1{,}000 \):

• Alice's BUCK balance rises by exactly 1,000.
• Alice's _indexAtLastTouch weighted-merges toward idx_pool: if she previously held 0 BUCK, her index is set to idx_pool directly (1% of fee per BUCK is now attached to her); if she previously held 9,000 BUCK at cumIndex_now, the merge yields an index close to cumIndex_now (only 0.1% of fee per BUCK across her now-10,000 balance).
• When Alice next makes a standard outgoing transfer of \( v \), her accumulated fee on the proportional share is burned out of her balance and credited to totalSupply such that the Jubilee can mint into balance. Net: she receives 1,000 face value, pays up to \( 1\% \times 1{,}000 = 10 \) BUCK as demurrage when she next spends – same economic outcome as if she had personally held the BUCK during the pool's residency.

Now suppose an anonymous donor sends 500,000 BUCK to the pool via a standard transfer. idx_pool weighted-merges forward toward cumIndex_now; the per-BUCK fee owed by the pool drops. Alice's next spend now inherits a smaller index-gap and therefore pays less demurrage on her next outgoing transfer – a direct subsidy from the donor.

The Jubilee's growth schedule is unchanged: it keeps accruing relative to cumIndex \cdot totalSupply regardless of how BUCK sloshes between accounts.

The answer is sharply localized: *the Note recipient inherits the pool's accumulated demurrage share on the face value they received and pays it on their next standard outgoing transfer.* The recipient has accepted the note, and with it the demurrage cost of the BUCK sitting in the pool while the note was outstanding.

This is the "price" the recipient pays for accepting a BUCK Note instead of a direct BUCK transfer: they inherit the average pool-residence demurrage, weighted across their prior holding. For notes held longer than the pool's average residence, this is cheaper than holding the BUCK directly; for notes spent quickly into the pool, it is more expensive. The trade-off is explicit in the resulting _indexAtLastTouch on the recipient's account.

Noteholders (while holding) bear no demurrage: they hold a cryptographic commitment, not a BUCK balance, and the BUCK they implicitly own sits in the pool where its accumulated fee is borne collectively until spent. The issuer (at mint time) pays their own outgoing-transfer fee through the standard ERC-20 path to deposit into the pool. Third parties bear nothing. The Jubilee keeps receiving the BUCK-wide demurrage stream regardless of how BUCK sloshes between accounts.

Every monetary system that uses physical bearer instruments suffers a constant slow loss to unrecoverable currency. Banknotes are lost in fires, dropped down storm drains, forgotten in the pockets of jeans that get washed and shredded, buried in landfills, sealed in walls, hidden by the elderly and forgotten by their heirs.

The Federal Reserve estimates that 5-10% of US paper currency is permanently unrecoverable at any given moment.¹² At a US M0 of approximately $2.3 trillion, this represents /$115-230 billion in permanently extracted value/ – seigniorage to the Federal Reserve, since the lost notes never get redeemed but the backing assets remain on the Fed's books.

This is not theft, but it is not neutral either. Lost cash is a regressive transfer: the people most likely to lose cash are the people who use cash most (the elderly, the unbanked, low-income workers paid in cash). The beneficiary is whoever issued the cash, generally the central bank, ultimately the government.

A BUCK Note that is lost in a fire, dropped down a storm drain, or hidden in a wall by a paranoid grandparent is not permanently extracted from the system. The face value sits in the pool's ERC-20 balance, with the pool's _indexAtLastTouch drifting further behind cumIndex_now as the pool sits untouched. No spend ever happens.

Two effects balance:

1. The BUCK backing the lost note stays in the pool indefinitely. It does not vanish.
2. Other live-note spenders, through transferCarrying, inherit a share of the pool's stale index at each spend. Because the lost note's backing weighs on balanceOf(notes) without a corresponding spend to drain it, the lost-note's implicit demurrage is paid installment-style by subsequent spenders on their next outgoing transfer.

Over decades, the pool's index-gap (cumIndex_now - idx_pool) on the lost-note backing accumulates the demurrage that would have been owed had the BUCK been held in a regular account. The autonomous Jubilee growth continues regardless. Net effect: /the 5-10% of currency that physical cash systems lose forever, BUCK Notes returns to the commons within a generation/, via the steady demurrage pressure that the lost face value applies to live spenders inheriting the pool's stale index.

This has cascading consequences:

1. Money supply self-correction. No system-wide accounting tail of "missing" currency that the central authority must track and write off. Lost notes write themselves off through the pool-age mechanism.
2. Anti-hoarding incentive matches on-chain balances. A BUCK held in your wallet or in your pocket as paper decays at the same rate (via the age-share that will eventually be absorbed on redemption). There is no advantage to converting on-chain BUCK to paper to evade demurrage; the demurrage clock runs the same way in both forms.
3. Inheritance is automatic. A grandparent who hides 100,000 BUCK in paper notes and forgets to tell anyone does not extract 100,000 BUCK from the economy on their death. The value flows back through the Jubilee to BUCK issuers – broadly, back into the same economy where the grandparent originally earned it.
4. No central bank profit from currency loss. The seigniorage that accrues to central banks today from unrecoverable cash does not exist in BUCK Notes. Lost value does not benefit the issuer; it benefits the system as a whole.
5. Counterfeit recovery is automatic. Even if a note printed years ago were somehow forged (which is cryptographically impossible, but humour the counterfactual), the value at stake is bounded by the demurrage decay. An attacker forging old notes would be forging paper whose backing BUCK has already been largely absorbed by live redemptions.

This is, I believe, the first monetary system in history where lost cash returns to the commons by automatic mechanism rather than by accounting fiat. Physical cash cannot have this property, because physical cash has no clock. It emerges naturally from BUCK's existing demurrage mechanism applied to the note-pool primitive.

A second elegance worth pointing out: the effective demurrage rate on a BUCK Note – as absorbed by the recipient at deposit – is the same as the demurrage rate on an on-chain BUCK balance that lived in the pool for the same duration. This is by design, and it matters.

If paper BUCK Notes demurraged faster than on-chain BUCK, holders would prefer on-chain (and paper would be discouraged, defeating the design's purpose). If on-chain BUCK demurraged faster than paper notes, holders would race to print all their on-chain balances as physical notes (and the chain would lose its primary use as a settlement layer).

The matching demurrage rate makes the choice between on-chain and paper purely about use case fit: on-chain for routine commerce, automated payments, large transactions; paper for offline payments, gifts, savings under the mattress, disaster preparedness, and so on. Neither form is privileged by the demurrage mechanism.

At mint time the issuer holds the full commitment preimage \( (v, \rho, \text{id-payload}, \text{predicate}) \) including any randomness \( r' \) it generated to re-randomize the recipient's encrypted Identity. The question is whether that knowledge, by itself or combined with any later-acquired secret, lets anyone other than the intended recipient spend the note.

Both A1 and A2 bind a specific recipient at mint time. The note carries the re-randomized ElGamal ciphertext \( E_{\text{note}} = (R_r + r'\cdot G,\; C_r + r'\cdot pk_{\text{rec}}) \) of \( M_{\text{rec}} \) under the recipient's pubkey. The A-spend predicate is a Chaum-Pedersen proof of equality (Theorem 6) that the depositor's registered credential decrypts to the same \( M_{\text{rec}} \) that \( E_{\text{note}} \) encrypts.

The consequence is that no amount of mint-time knowledge helps a non-recipient spend:

• The issuer knows \( r' \) and can re-derive \( E_{\text{note}} \), but cannot produce a CP-equality proof without a registered credential encrypting \( M_{\text{rec}} \).
• An attacker who copies \( \rho \) cannot spend either; the pool contract binds \( \rho \) to the recipient's side of the equality.

A1 and A2 differ only in whether \( M_{\text{issuer}} \) is on-chain in the clear (A1) or encrypted for the recipient (A2). Neither affects who can spend.

The B-spend predicate is a Schnorr PoK of knowledge of \( \rho \) plus any valid registered depositor credential. There is no recipient binding: whoever publishes the nullifier first wins the deposit. The issuer, having minted the note, knows \( \rho \); so does anyone who later observes \( \rho \) – including anyone the issuer accidentally leaks it to (database row, printed backup, compromised signing device) and anyone who photographs an unsealed physical cheque.

This is not a cryptographic failure; it is the point of a bearer instrument. The B1 flavor replaces cryptographic recipient binding with civil-law recourse:

• The issuer's Identity \( M_{\text{issuer}} \) is public on the note. An issuer who prints a cheque and then races to deposit it is visibly on chain as the double-spender. The registered Identity is subpoena-able and the issuer cannot repudiate having printed the note.
• A holder who discovers their B1 has been cashed by someone else has a named counterparty to pursue in civil or criminal court. The chain proves who deposited; the note's commitment and signature prove who issued it.

The practical rule: treat B1 like a cashier's cheque. Cash within hours to days. Use only issuers whose operational discipline and legal standing you are willing to rely on. Do not use B1 for long-term savings, inheritance, or cold storage; addressed A1 or A2 instruments serve those needs with cryptographic rather than institutional trust.

The consequence: /addressed (A) notes are cryptographically safe to hold; bearer (B1) notes rely on issuer operational discipline and civil recourse./ Placing an A1 or A2 cheque in cold storage for a decade trusts only the cryptography and the recipient's Identity recovery capability. Placing a B1 in the same vault trusts the issuer not to retain \( \rho \) for ten years.

Mapping to use cases:

• Long-term savings, cold storage, self-wormhole: A2 (you are the recipient).
• Estate, inheritance, named gifts: A1 or A2 – A1 when the recipient and heirs want public attribution of the issuer; A2 when discretion is preferred.
• Payroll, B2C disbursements, audit-visible transfers: A1, cashed at the recipient's pace.
• Bearer instruments – cashier's cheques, physical coupons, prize vouchers: B1, cashed promptly.

A printed BUCK Note has three concentric layers of security:

The inner layer is the cryptographic core: as long as \( \rho \) (and the flavor-specific material packed into id-payload) is unknown, the note cannot be spent. This is unconditional protection against any threat that does not include observing those secrets.

The middle layer matters only for bearer B1 notes, where the spend predicate is "any registered holder of \( \rho \)." An unsealed B1 QR photographed by any observer allows that observer to race to spend. Sealing the QR under a tamper-evident covering means the note can be displayed (passed hand-to-hand, stored in a wallet, mailed in an envelope) without exposure. The seal must visibly damage on opening so that recipients can verify they were the first to expose the secret. (This does not rescue B1 from the issuer-race risk – the issuer who printed the note could still have retained \( \rho \) before sealing – which is why B1 remains unsafe for long-term holding. The seal addresses post-printing observation, not issuer trust.)

The outer layer makes addressed A1/A2 notes safe to publicly distribute. An addressed note can be photographed with no security implication: the photographer cannot spend it without also holding a registered credential encrypting the bound M_rec. The targeting binding is cryptographic, not physical. For addressed flavors, no physical seal is required.

A practical BUCK Note specification, suitable for industrial-scale printing:

• Substrate. Cotton-blend banknote paper or polymer (Bank of Canada-style). Steel or titanium plates for high-denomination "permanent" notes.
• Printing. Standard inkjet or laser printing of QR codes is sufficient for cryptographic correctness. For visual anti-confusion (so people can tell a legitimate note from a printout), use UV-reactive ink, microprinting, or watermarks – the same techniques used for traditional banknotes. These do not add cryptographic security; they add reassurance.
• Seal. Peelable hologram covering the secret QR (bearer B1 only), or scratch-off panel covering a separate code (also B1), or no seal at all (addressed A1/A2, since the cryptography handles exclusivity).
• Redundancy. Print the QR twice (front and back) with Reed-Solomon error correction. A note that loses one QR to wear or damage can still be deposited via the second. For higher-value notes, also print the secret as base32 digits in human-readable form.
• Issuer mark. A non-cryptographic logo identifying the issuer (the Alberta Buck reserve, a credit union, a commercial issuer). This is for visual recognition only; the cryptographic authenticity check is the on-chain commitment.
• Denomination indication. Visible face value for human convenience. The actual value is what the on-chain commitment encodes; the printed face value is metadata. A wallet app that scans an apparent 1,000 BUCK note and reads "actual value: 100 BUCK" from the commitment warns the user before deposit.

For digital "send at the moment of payment," an A2 note targeted to the payee's registered M is ideal: the recipient receives a message-note that only they can deposit, and the issuer's Identity is exchanged bilaterally through the commitment payload without any on-chain edge. For truly paper bearer cash – a note that anyone who holds the paper can spend – a B1 cheque with hologram seal fills the role, issued by a trusted public party (credit union, commercial issuer) who publicly warrants erasure of \( \rho \) after printing.

Most walking-around use cases – paying for a coffee, tipping, splitting a bill with a friend – are better served by A2 message notes exchanged at the moment of payment. The paper B1 form is the right choice when one party has no digital wallet at hand or when strict bearer-on-paper semantics are required. If you are going somewhere that would be best to avoid taking your phone, or just because you want to retain complete anonymity, such a note might be appropriate.

Notes always yield the current pool demurrage rate, so neither encourage nor discourage rapid circulation rather than hoarding. The wallet-app status codes give immediate VALID / DEAD / FAKE feedback on scan. These public issuer / any depositor Notes always bear some non-zero risk of theft or an untrustworthy issuer who retained a copy of the note, so should be deposited promptly.

A paper BUCK Note is just paper. It crosses borders in pockets, envelopes, and parcels at zero marginal cost. An A2 note targeted to the recipient's registered M makes the transfer useless to anyone except the intended recipient, so loss in transit is not a financial risk.

This compares favorably to the existing remittance industry, which extracts roughly 6.5% in fees globally on $700+ billion in annual transfers.¹³ A paper-note remittance has a fixed cost: print

• mail. The mail might cost $1; print costs fractions of a cent;

deposit gas costs a few dollars at most. At any reasonable remittance value, the fee compression is enormous.

The recipient does not need a smartphone or internet at the moment of receipt – they need them only at the moment they want to convert the note to on-chain BUCK or to local fiat. In countries with intermittent connectivity, this is a major usability improvement over digital remittance services.

A sheet of small-denomination B1 bearer notes, perforated for tear-off, can be left next to a tip jar or a donation box. Patrons take notes (denominated at, say, 2 BUCK each), scan them with their phone, and the value flows to the jar's registered identity.

This works without any intermediary, payment processor fee, or opening of an account. The patron pays in paper; the recipient receives in on-chain BUCK. B1 is appropriate here because the turnaround is fast: the jar's operator empties the day's receipts to their main account nightly.

An A2 self-issued note (issuer = recipient, both the same registered M), stored in a fireproof safe, is a more durable form of cold storage than a 12-word seed phrase. The note is self-evidently an instrument of value – a customs officer, a relative, or your future self immediately recognizes a paper labeled "1,000 BUCK Note" as something worth keeping safe. A seed phrase, by contrast, is opaque to anyone who has not been trained to recognize it.

For disaster preparedness: a small folder of BUCK Notes in a fireproof safe survives infrastructure failures that would render exchange accounts and even hardware wallets unusable. As long as the chain is reachable somewhere in the world, the notes can be deposited. In a true grid-down emergency, the notes circulate hand-to-hand at face value (with the matching pool-rate demurrage clock running uniformly, so prices remain stable in BUCK terms even during a multi-week outage).

A2 (issuer = recipient) is the correct choice for self-directed cold storage; A2 or A1 targeted to a designated heir's M is the correct choice for estate-directed cold storage. The cold-storage bundle must include both the note opening and the mint-time \( sk_{\text{rec}} \): A-notes are bound to the specific key pair used at mint and are unspendable under Identity re-issuance alone (see "Key-Pair Binding and Loss Semantics" above). Practically, this means the safe-deposit box or heir-accessible vault holds a sealed record of both the commitment opening and the private key material that decrypts \( E_{\text{note}} \).

A2 notes targeted to your heir's registered M, stored in a safe-deposit box: zero probate process, zero tax-event delay, zero court intervention. The heir scans on your death, deposits, the BUCK is theirs. A1 is the same instrument with the issuer publicly attributable – appropriate where the heir or executors need the origin on-chain for tax or legal reasons.

For larger estates, additional conditional-spend predicates (time locks, death-certificate oracle attestation) can be composed into the commitment's predicate field. The SNARK does not care what the predicate is as long as it is well-defined at mint time.

A traditional gift card carries the risk that the issuing merchant goes bankrupt between purchase and redemption (cumulative consumer losses to bankrupt gift-card issuers run into the hundreds of millions annually in North America¹⁴). An addressed A1 or A2 BUCK Note carries no issuer risk: the value is on chain in the BUCK reserve, not on the merchant's books.

Specialized merchant gift cards become unnecessary – replaced by BUCK Notes of appropriate denomination, optionally bundled with a paper merchant receipt indicating the intended use.

An employer paying a contractor in BUCK Notes faces the same tax-reporting obligations as paying in cash: payment is income and must be reported. The on-chain issuance trail makes this easier to comply with than paper cash, not harder – the employer's mint transaction is an auditable record of the payment, even though the contractor's deposit is private.

For employees: employers can issue A1 notes targeted to each employee's registered Identity, automating payroll while preserving employee privacy from external observers.

This is, perhaps, the most important use case.

The Bank of Canada estimates 1-2% of Canadians are unbanked, with rates an order of magnitude higher in rural and Indigenous communities.¹⁵ Globally the World Bank estimates 1.4 billion adults are unbanked.¹⁶

For these populations, paper cash is not a privacy preference; it is the only viable financial instrument. A digital-only currency (CBDC, stablecoin, traditional e-payment) excludes them by definition. BUCK Notes includes them: a person without a bank account, without a smartphone, without literacy in the local language, can hold and transfer BUCK Notes by physical handover, exactly as they hold and transfer paper currency today.

When and if they choose to interact with the digital economy, they deposit a note and the value moves on chain. Until then, they participate in the BUCK economy on exactly the terms they participate in the cash economy. The issuer of the paper – a credit union, a reserve-backed issuer like ATB, or a local community organisation – takes on the role that the central bank currently plays for physical fiat, while the recipient retains the anonymity of a cash user.

Consider an analytics firm that purchases KYC-linked address data from a large wallet provider. Today, such a firm can reconstruct much of a BUCK user's economic life: regular payroll deposits, recurring vendor relationships, counterparties' other clients, timing patterns. Under Notes, the on-chain trace of a typical legitimate transaction is:

1. Payer's account transfers BUCK to the Notes contract (mint). The observer sees only that some amount entered the pool.
2. Some time later – minutes to months – a recipient deposits a note. The observer sees only that some amount left the pool to some registered account.

There is no observable edge between payer and recipient. The payer's account activity shows only "sent N BUCK to pool." The recipient's account activity shows only "received M BUCK from pool." Correlating the two requires either (i) complicity of one of the two parties, or (ii) subpoenaed disclosure by either party.

The BUCK Identity invariant – that both endpoints of any value transfer can decrypt each other's M – is preserved. The payer learns the recipient's M when they read the recipient's IdentityRegistry entry to construct \( E_{\text{note}} \). The recipient learns the payer's M when they verify the note (from \( m_{\text{issuer}} \) for A1/B1, from the paired \( E_{\text{issuer-for-rec}} \) ciphertext for A2).

Neither party sees the other's wider on-chain activity from the Note alone. The payer sees only the specific M of the recipient, not the recipient's other counterparties or balances. The recipient sees the same narrow slice of the payer's life.

The threat Notes defeat is undifferentiated bulk observation:

• A KYC-provider subpoena scoped to "all transactions of clients X, Y, Z for the last five years" yields only direct pool-to-client and client-to-pool transfers. It cannot reconstruct who X paid, or who paid Y, or whether X and Y ever transacted.
• A chain-analytics firm selling behavioural fingerprints cannot build the edge graph at all; there are no edges to cluster.
• An insurer, employer, or landlord who gains read access to a counterparty's on-chain address learns that address's pool-inflow and pool-outflow amounts, not its counterparties.

The threat Notes do not defeat is targeted investigation with proper authorization:

• A warrant served on party X to a specific Note compels X to reveal the counterparty's M and the associated context.
• A criminal probe that identifies a "mule" account depositing many Notes can compel that mule to disclose each note's issuer M (the income source) and each outgoing note's recipient M (the onward payment), walking the graph one cooperating party at a time.
• Sanctioned or frozen Identities are blocked at the contract level regardless of Note use.

This is the posture of a bank cheque or personal cheque, not a $20 bill: the parties to any specific instrument are identified to each other and compellable on individual warrant, but no omnibus order reaches across the system.

A regulator investigating illicit flows has a clean single-target path:

1. Identify a suspect account (by KYC on a wallet provider, a prior investigation, or a direct complaint).
2. Compel the suspect's wallet, via warrant, to disclose the plaintext M of every counterparty the suspect has transacted with via Notes, together with the note metadata (issuer / recipient, amount, time). This is entirely derivable from material the suspect already possesses: their own registry keys and the payloads they decrypted at scan or mint time.
3. Serve the next warrant on the resulting named counterparty. Repeat.

The audit is depth-first on named parties, not breadth-first across the chain. The origination of any specific note remains traceable through the on-chain mint record plus the issuer's own records; a bearer $20 bill has no analogous trail.

A reasonable regulatory regime around BUCK Notes:

• Issuers must be identity-registered and may face reporting obligations on large issuances (analogous to current cash-withdrawal reporting).
• Depositors face the reporting obligations that attach to cash deposits at a bank today.
• Holders who pass notes hand-to-hand have no reporting obligation, the same way there is no obligation to report carrying $200 in a wallet.
• Named parties to a specific note are compellable to disclose that note's counterparty and surrounding context on warrant.
• Pool-rate demurrage makes long-term cash hoarding economically unviable, bounding the value of Notes-as-store-of-wealth for illicit actors.

The regime is strictly more privacy-preserving than the current surveilled-electronic-transfer regime (which exposes every edge to aggregators and KYC providers) and strictly more compliance-friendly than the current paper-cash regime (which exposes no issuance trail at all, regardless of who is investigating).

China's e-CNY, the European Central Bank's proposed digital euro, the Bank of Canada's CBDC research – all of these designs include either explicit or implicit surveillance capabilities. The central bank can see, freeze, expire, restrict, geofence, or retroactively examine any holder's balance.²

This is not an accident of the technology; it is a design goal. The pitch to governments is precisely that CBDCs give them visibility into civilian payment flows that paper cash denies them.

BUCK Notes is the opposite posture. Visibility is at the edges of a single instrument (the two named parties to a specific note), never across the system. The bearer-circulation phase of B1 notes is private in the way cash is private; the addressed A1/A2 phase is private between the two named parties the way a sealed letter is private. A jurisdiction adopting BUCK Notes gets better per-instrument compliance tools than paper cash provides today without enabling the population-scale surveillance a CBDC would.

David Chaum's blind-signature scheme⁴ introduced the core idea: an issuer (a bank) signs a token blinded by the holder so that the bank cannot link the issuance to the redemption. When the holder spends the token, the merchant verifies the signature without revealing who originally received it.

This is a beautiful design and operationally similar to BUCK Notes in spirit. Its failures were institutional, not cryptographic:

• Required a centralized issuer (the bank)
• Required online verification at spend time (no offline transferability)
• Two-sided market never bootstrapped (no merchants accepted, so no consumers held)
• DigiCash (the commercial implementation) went bankrupt in 1998

BUCK Notes has the same privacy properties without the centralized issuer (any identity-registered party can mint notes against their own on-chain BUCK). Spend-time verification is on chain rather than via the issuer (so the issuer cannot selectively block redemptions). The two-sided market problem is mitigated by BUCK's existing on-chain ecosystem – BUCK already exists as a usable currency, so adopting BUCK Notes is a UX upgrade rather than a greenfield bootstrapping.

Stefan Brands' scheme⁵ addressed the offline-spend problem: a divisible coin can be spent in pieces without contacting the issuer, but double-spending mathematically reveals the spender's identity.

This is the "deterrent rather than prevention" model. It works in theory but has two operational issues:

• The deterrent only deters if identity revelation has consequences (it relied on a legal/social enforcement layer external to the cryptography).
• The complexity of divisible-coin management was substantial and never produced a shipped product.

BUCK Notes handles double-spend by prevention (global nullifier set), not deterrence. No legal layer is required. Divisibility is achieved by issuing multiple notes at mint time rather than by a single divisible coin.

Mike Caldwell's Casascius coins³ were physical Bitcoin: a brass or silver coin with a holographic seal covering a private-key QR code. Snap the seal, scan the QR, the coin's Bitcoin balance was yours.

Casascius coins remain the closest existing analogue to paper BUCK Notes. What they lacked:

• Native integration with the underlying token (the Bitcoin protocol does not understand bearer-coin form; the coin is an aftermarket wrapper).
• Targeting (all coins were pure bearer; no way to issue a coin claimable only by a specific recipient).
• Demurrage (a Casascius coin holds its full Bitcoin balance forever, unrelated to any economic mechanism).
• Programmable predicates (only one mode: bearer).
• Issuer was a single individual, who eventually stopped issuing in 2013 due to FinCEN money-transmitter concerns – an issuance bottleneck that BUCK Notes distributes to all identity-registered participants.

BUCK Notes is, in essence, what Casascius would have been if Bitcoin had been designed with bearer-paper as a first-class instrument from the start, and if the underlying token had a demurrage and identity layer.

Encrypted Bitcoin private keys printed on paper, with a passphrase needed to spend. BIP-38 paper wallets are an aftermarket bearer instrument similar to Casascius but without the physical coin form factor.

Same limitations as Casascius (no native integration, no targeting, no demurrage, no predicates), plus the additional UX burden of remembering or transmitting the passphrase.

Ben-Sasson, Chiesa, Garman, Green, Miers, Tromer, and Virza's Zerocash⁷ gave us the first scalable on-chain commitment-and-nullifier UTXO model with full zero-knowledge. Zcash deployed it in 2016.

Zcash provides on-chain shielded transactions but does not extend the model to physical bearer instruments, targeted cheques, or identity-linked issuance. All Zcash value lives on chain in shielded notes. No mechanism exists for printing a shielded Zcash note as a paper instrument that someone else could deposit later.

BUCK Notes uses Zerocash's commitment-and-nullifier primitive for its on-chain machinery and extends it with the Identity-binding layer and the physical-paper surface. The contribution is in the extension, not the primitive.

Aztec's predicate-encrypted notes⁸ generalize Zerocash to private smart contract calls – a note can encode arbitrary state operated on by arbitrary predicates. This is the cryptographic ancestor of the predicate field in the BUCK Note commitment.

Aztec does not have physical bearer instruments either. Its predicates are designed for on-chain DeFi applications (private DEX trades, private lending), not for paper notes or identity-bound cheques. BUCK Notes applies the same predicate machinery to a different problem: specifying spend conditions for a private bearer instrument that is issued against an identity-registered reserve.

Tornado Cash⁹ was the simplest possible commitment-and-nullifier mixer: fixed-denomination deposits in, anonymous withdrawals out. Sanctioned by OFAC in 2022 for money-laundering use.

Privacy Pools (Buterin, Schaefer, Tromer, et al., 2023)¹⁰ extends Tornado with per-spend "association sets" – a depositor can prove their deposit is in a non-incriminating subset, allowing compliance without identification.

Both are mixer designs, not cash-instrument designs. Their relevance to BUCK Notes is the lineage: the Note Pool is a Tornado-style global anonymity set, but with predicates and Identity bound in. The selective-disclosure compliance story borrows from Privacy Pools' association-set ideas, but with issuer identity substituting for the depositor-declared non-incrimination proof.

The "Native" column captures whether the bearer-paper instrument is a first-class designed primitive of the system (as opposed to an aftermarket wrapper or absent entirely). BUCK Notes is the first design that fills every column. This is not because the prior art was incompetent; it is because the four required pieces (commitment-pool primitive, identity layer, demurrage, jurisdictional reserve) finally converged in one system.

A more direct comparison aimed at a non-cryptographer reader: how does BUCK Notes stack up against physical cash and central bank digital currencies?

The dominant insight from this table: /BUCK Notes combines the privacy properties of physical cash with the compliance and durability properties of CBDC, while preserving infrastructure independence that CBDC abandons./

The single property where physical cash is genuinely irreplaceable – "works without internet for deposits" – is moderated for BUCK Notes but not eliminated. Holders can transfer BUCK Notes hand-to-hand offline, indefinitely; they need internet only when they want to convert the bearer instrument to an on-chain balance. In a disaster scenario, BUCK Notes circulate as cash for the duration of the outage, then deposit normally when the chain becomes reachable again.

The following are unchanged from Identity v1 and are used directly:

1. Pointcheval-Sanders issuer signature \( \sigma \) on the Identity scalar \( m \). Re-randomization continues to serve unlinkable credential generation (Identity Fountain). No change.
2. ElGamal registered credential \( E = (R, C) = (r G, M + r \cdot pk) \) where \( M = m \cdot G \). Continues to be the on-chain identity witness, re-randomized by the issuer at mint time to produce \( E_{\text{note}} \) bound to a specific recipient. No change.
3. Chaum-Pedersen equality of discrete logs (Theorem 6). Used verbatim by the A-spend predicate to prove that the depositor's current registered credential decrypts to the same M that \( E_{\text{note}} \) encrypts. This is the same proof the approve flow produces outside a SNARK; in Notes it is embedded in the spend circuit.
4. Schnorr signature on \( cm \). Used in the mint circuit to bind A1 and B1 notes to their public issuer. Standard construction.
5. Schnorr PoK of \( sk \) for registered \( pk \). Used by the B-spend predicate to bind the depositing account to a registered identity. Single-statement case of CP.
6. IdentityRegistry mapping between on-chain addresses and registered credentials (PS signatures, ElGamal ciphertexts, isPublicIdentity flags set by bindContract).

Notably absent: a stealth-address construction is not used by Notes. Recipient binding is handled directly by re-randomizing the recipient's registered ElGamal credential and verifying via CP-equality – the same mechanism Identity already uses to defeat the BUCK mutual-decryptability requirement.

A SNARK-friendly commitment hash \( H_{\text{cm}} \) (Poseidon) is needed to compute the commitment inside the spend circuit. The hash is deterministic, collision-resistant over the note's field, and efficient in R1CS; Poseidon over the BN254 scalar field is the natural choice and is already used by the Aztec and Zcash Sapling circuits.

No novel cryptographic construction; only a circuit-level primitive that is standard in modern SNARK systems.

The nullifier PRF is Poseidon-based, keyed differently per spend shape:

• A-spend: key = \( M_{\text{rec}} \) (the recipient's identity point, recovered in-circuit by ElGamal decryption of \( E_{\text{note}} \) under the depositor's witness \( sk_{\text{dep}} \)). Nullifier = \( H_{\text{nf}}(\text{A} \| M_{\text{rec}} \| \rho) \). Keying on \( M_{\text{rec}} \) – not on \( sk_{\text{dep}} \) – makes the nullifier value independent of which specific signing key performed the decryption (a hash-determinism property) and precludes a pathological scenario in which a recipient simultaneously holds multiple valid credentials for the same M from yielding distinct nullifiers and double-depositing. This does not provide key-loss recovery: the decryption step itself requires the specific \( sk_{\text{rec}} \) paired with the mint-time \( pk_{\text{rec}} \), so a recipient who loses that key cannot produce the nullifier at all (see "Key-Pair Binding and Loss Semantics" above). The issuer cannot pre-compute \( nf \) because she never decrypts \( E_{\text{note}} \) (no knowledge of \( sk_{\text{rec}} \)); see proofs.org Theorem 10 for the IND-CPA reduction.
• B-spend: key = \( \rho \) itself; nullifier = \( H_{\text{nf}}(\text{B} \| \rho) \), publicly computable by anyone who knows \( \rho \). This is the first-come-first-served property of bearer B1 notes.

A domain-separator byte (A vs. B) in the PRF input keeps the nullifier namespaces disjoint across flavors.

The issuer looks up the recipient's registered credential \( E_r = (R_r, C_r) \) in IdentityRegistry, picks fresh \( r' \leftarrow \mathbb{Z}_q^\ast \), and computes

\[ E_{\text{note}} \;=\; (R_r + r' G,\; C_r + r' \cdot pk_{\text{rec}}) \;=\; ((r_r + r') G,\; M_{\text{rec}} + (r_r + r')\, pk_{\text{rec}}). \]

This is a single additional ElGamal re-randomization under the recipient's existing \( pk_{\text{rec}} \). The issuer does not learn any additional secret; they compute \( E_{\text{note}} \) from public data (\( E_r \), \( pk_{\text{rec}} \)) and their own chosen \( r' \). Single curve multiplications on BN254 G_1. No pairing, no new hardness assumption.

For A1, the issuer additionally signs \( cm \) under their own \( sk_{\text{issuer}} \) and embeds \( (m_{\text{issuer}}, \sigma) \) in the payload. For A2, no such signature; the issuer's M is instead carried as an encryption for the recipient to satisfy the mutual-decryptability invariant.

The depositor produces a CP-equality proof (Theorem 6) showing that \( E_{\text{note}} \) and the depositor's currently registered credential \( E_{\text{dep}}^{(\text{reg})} \) decrypt to the same M. The extractable witness is \( sk_{\text{dep}} \); because \( sk_{\text{dep}} \) is bound (by registration) to M, the proof establishes the depositor owns the registered credential encrypting the recipient's M.

This is identical in structure to the CP proof Alice produces during approve, lifted into the SNARK circuit rather than verified on-chain as a Fiat-Shamir NIZK. No new assumption.

A B-spender produces a Schnorr PoK of \( sk_{\text{dep}} \) for their registered \( pk_{\text{dep}} \), Fiat-Shamir bound to the spend transaction. This anchors the deposit in a registered Identity (so KYC/FINTRAC obligations attach) while leaving the deposit open to any registered holder of \( \rho \). Standard Schnorr; no novelty.

Only the Poseidon hash family is new, and it is already standard in the SNARK ecosystem. No novel hardness assumption is introduced. The current Notes spend predicates are covered by Theorems 7-11 of the companion Proofs document.

The per-leaf on-chain Poseidon insertion that Phase 7 shipped was gas-cost-fatal at realistic batch sizes (~800K gas/leaf; N=16 alone exceeds the block limit). Phase-7-bis moves the Merkle-tree update inside the SNARK: the circuit consumes oldRoot as a public input, folds N commitments onto it using witness sibling paths, and exposes the resulting newRoot as a public output. On-chain mint cost becomes essentially constant in N – ~380K + ~500 gas/leaf of calldata. The design memo is alberta-buck-notes-rollup-mint.

Public inputs (5 entries, N-independent).

• oldRoot – the live note root the prover read from chain
• newRoot – the root after folding cm_1..cm_N
• nextLeafIndex – the live tree size the prover read from chain
• totalFace – \( \sum v_i \), range-bounded to 128 bits
• cmBatchHash – \( H(\text{cm}_1, \ldots, \text{cm}_N) \), letting the contract bind calldata to the SNARK without making every cm_i its own public input (keccak on chain; Poseidon reserved for a future in-field variant)

Witnesses. For each leaf \( i \): \( (\text{flavor}_i, v_i, \rho_i, \text{idHash}_i, \text{predHash}_i) \) plus the TREE_DEPTH sibling hashes pathSiblings_i[0..19] needed to fold \( cm_i \) into the rolling tree.

Constraints.

1. totalFace \( = \sum v_i \) (amount conservation).
2. Each \( cm_i = \text{Poseidon5}(\text{flavor}_i, v_i, \rho_i, \text{idHash}_i, \text{predHash}_i) \) (opening binding).
3. Each \( v_i \in [0, 2^{128}) \) and totalFace \( \in [0, 2^{128}) \) via Num2Bits(128).
4. Rolling Merkle insertion: threading oldRoot and nextLeafIndex through N successive single-leaf insertions (Switcher + Poseidon-T3 per level, per leaf), the result equals newRoot. About 4.3K constraints per leaf; total ~6K R1CS per leaf including the opening.
5. Calldata binding: cmBatchHash \( = H(cm_1, \ldots, cm_N) \).
6. Belt-and-suspenders: \( cm_i \neq 0 \) and \( cm_i \neq \text{ZERO\_VALUE} \) per leaf.

Pinned N set. Each pinned N has its own compiled circuit, trusted setup, and deployed verifier. Recommended initial set: \{16, 128, 1024\}. The wallet rounds any requested split up to the smallest pin \( N^* \geq N_\text{requested} \) and pads with v = 0 dummy openings; dummies are valid commitments in the tree but spendable for zero BUCK.

Contract side. The Notes contract checks oldRoot and nextLeafIndex against its live state, recomputes cmBatchHash from the calldata cms[], dispatches to mintVerifiers[cms.length] to verify the proof, pulls totalFace BUCK from the caller via the standard ERC-20 path, writes newRoot into the ring buffer, advances nextLeafIndex by cms.length, and bumps noteFaceSum by totalFace. A single Minted event covers the whole batch; per-leaf Appended events from Phase 7 are gone.

Public inputs. noteRoot, nullifier, face, recipient, chainId.

Witnesses. \( (\text{flavor}, v, \rho, \text{idHash}, \text{predHash}, \text{leafIndex}, \text{path}[20]) \).

Constraints. Five groups, mirroring the circuit's section labels:

• (R) Range bounds: \( v \in [0, 2^{128}) \) and \( \text{face} \in [0, 2^{128}) \) via Num2Bits(128) on each, and \( \text{face} \equiv v \) (face exposed publicly equals the witness face).
• (C) Commitment opening: \( cm = \text{Poseidon5}(\text{flavor}, v, \rho, \text{idHash}, \text{predHash}) \).
• (M) Merkle membership: walk path[20] with Switcher selectors and Poseidon-T3 at each level, asserting the result equals noteRoot.

• (N) Nullifier: \( \text{nullifier} = \text{Poseidon3}(ρ, \text{idHash},

  1. \). The constant tag 4242 is the B-spend domain

  separator; the same idHash can mint an A-flavor note and a B-flavor note without nullifier collision (different flavor in the commitment), but both today share this circuit and tag.

• (B) Ghost binding: recipient and chainId are constrained into the witness via \( x \cdot x \) so the proof cannot be replayed against a different recipient or chain (replay protection by Fiat-Shamir on the public inputs).

Contract side. Notes.spend(proof, root, nullifier, face, recipient) requires root to be in the recent roots ring, requires nullifier unused, verifies the Groth16 proof through SpendVerifierAdapter, sets nullifiers[nullifier] = true, decrements noteFaceSum by face, and finally calls buck.transferCarrying(recipient, face) to deliver the funds plus the pool's accumulated demurrage share.

Bearer semantics for B-shape spends. Anyone holding the opening \( (\rho, \text{idHash}, \text{flavor}, v, \text{predHash}) \) can produce a valid B-spend proof and direct the proceeds to any recipient registered (or registered as system-public) in IdentityRegistry. This is the correct semantics for a B1 bearer note. A-flavor identity binding is now shipped via the V2 spend_a.circom + Notes.spendACP path: the SNARK enforces a Poseidon-8 binding gate that pins the publicly-revealed E_n to the leaf, and IdentityRegistry.verifySpendCP confirms the spender's sk_dep satisfies the equal-plaintext relation between E_n and their registered E_reg. See "Phased Rollout" below and test/SpendAVerifier.t.sol for the end-to-end exercise.

Constraint counts for the Notes circuits (BN254 Groth16):

Measured (M) via snarkjs r1cs info build/snark/mint_batch_n${N}.r1cs on the shipped pinned-N set {1, 2, 4, 8, 16, 32}; projected (P) linearly from the N=16 / N=32 baseline (~21,800 R1CS per leaf, ~half of which is the dual Merkle walk that pins oldRoot and advances newRoot against the same witness siblings). The PTAU power is the smallest 2^k ceremony whose FFT domain accommodates the circuit plus snarkjs setup overhead.

The spend circuit is comparable to Zcash Sapling's Spend circuit (~25,000) and Aztec's basic note-spend circuit; on-chip proving on a modern smartphone: a few seconds. mint_batch at N=16 is a ~6-second proof on a dev laptop (snarkjs); N=32 is ~12 s; N=128 is minutes (rapidsnark territory); N=1024 requires a beefy machine and roughly an hour, with the on-chain verification cost still bounded by a single Groth16 verify regardless of N. The 2²⁵ ceremony is the ceiling that fixes the largest pinned N – raising it would require a fresh trusted setup.

Shared library used by both circuits:

• Poseidon hash (T3 for Merkle pairs; T6/Poseidon5 for commitment opening; T4/Poseidon3 for nullifier)
• Tornado-style Merkle inclusion (Switcher + Poseidon at each level)
• Num2Bits range proofs on field elements

spend_a.circom V2 adds two extras on top of this base: an A-tag nullifier domain separator and a Poseidon-8 binding gate that pins E_n to the committed idHash (~265 R1CS). The Chaum-Pedersen equality between E_n and the depositor's registered E_reg is verified off-chain by Notes.spendACP via IdentityRegistry.verifySpendCP using EIP-196 BN254 precompiles (~36K gas), avoiding the prohibitive ~+250K R1CS cost of non-native G1 arithmetic in circom.

Because the pool is a regular BUCK account and transferCarrying moves only nominal balance (no fee burn, no totalSupply change), no Notes-specific demurrage invariant is needed. The system-wide BUCK invariant

\[ \sum_{\text{all accounts}} B_X \;=\; \text{totalSupply (incl. Jubilee)} \]

holds trivially through every spend: transferCarrying moves exactly face BUCK from pool to recipient, leaving the sum unchanged. The recipient's _indexAtLastTouch weighted-merge is pure bookkeeping; no balance sum is touched.

The Notes contract only needs to maintain two auxiliary local invariants:

1. noteFaceSum \( \geq 0 \) (no negative note face sum).
2. Every face appearing in a spend equals the \( v \) that appeared in the corresponding mint (enforced by the SNARK via the Merkle inclusion of \( cm \) binding \( v \), and the circuit's \( \text{face} \equiv v \) constraint).

Both are trivial. The only new BUCK mechanism is transferCarrying, itself a simple state-machine operation weighted-merging the recipient's _indexAtLastTouch toward the pool's index.

• spend_a.circom V2 (Phase 4). Shipped. In-circuit Poseidon-8 binding gate that pins E_n to the leaf, paired with off-chain Chaum-Pedersen DLEQ verified in IdentityRegistry.verifySpendCP via EIP-196 BN254 precompiles (~36K gas) and called from Notes.spendACP. Exercised end-to- end by test/SpendAVerifier.t.sol (26 tests).
• A1 issuer-signature-in-payload (Phase 5). Schnorr verification inside the spend circuit and corresponding wallet UX. ~2 weeks.
• Sealed-QR print flow for B1 (Phase 6). Hologram-vendor integration, QR templates, paper-redemption UX. ~2 weeks.
• Programmable predicates (Phase 7). Bounded predicate DSL compiled into the spend circuit. Multi-month engineering; deferred until production demand materialises.
• Off-chain re-targeting via PRE (Phase 8). Identity Guardians coordination; deferred.

• Recipient scan loop: trial-decrypt A1/A2 payloads against registry credential; detect B1 broadcasts: ~1 week.
• A2 self-wormhole mint flow (issuer = recipient): ~1 week.
• A1 identified-cheque creation and deposit UX: ~2 weeks.
• A2 addressed-cheque creation and deposit UX: ~1 week (reuses A1 code paths).
• B1 bearer-cheque creation, sealed-QR print flow, redemption UX: ~2 weeks.
• QR-print templates, hologram-seal vendor integration: ~1 week.
• Prover service integration for thin clients: ~2-3 weeks.

• Cryptographic review of the spend circuit (and the forthcoming spend_a.circom): 4 weeks, external auditor with SNARK-circuit expertise.
• Economic model validation (pool-rate demurrage carrying in stress scenarios: low turnover, high turnover, mint/spend mismatch, large accumulated lost-note face sum): 2 weeks.
• End-to-end fuzz and property-based testing: 2 weeks.

The engineering work is naturally phaseable:

Phases 1-4 are shipped and exercised end-to-end by the test suite (test/MintVerifier.t.sol, test/MintBatchVerifier.t.sol, test/SpendVerifier.t.sol, test/SpendAVerifier.t.sol) on real Groth16 fixtures. The B-shape spend circuit is a single flavor-agnostic verifier: any commitment the prover knows the opening for can be redeemed to any IdentityRegistry-verified or system-public recipient (the correct semantics for B1 bearer notes). The A-shape spend_a.circom V2 adds the in-circuit Poseidon-8 idHash binding gate that pins E_n to the leaf at mint time, paired with off-chain CP-DLEQ verification in IdentityRegistry.verifySpendCP, called from Notes.spendACP.

Phase 4 closes the A-flavor gap in two layers, both shipped. V1 ships spend_a.circom (A-tag nullifier, flavor constraint) without the identity gate. V2 layers the identity binding using two cooperating components:

1. In-circuit Poseidon-8 binding gate (constraint (I) in the revised spend_a.circom): the SNARK now publishes E_n.R and E_n.C as four additional public inputs (the spender's note ciphertext, in BN254 G1 affine coordinates), and enforces \[ \mathsf{Poseidon\text{-}8}(\mathsf{E_n.R.x}, \mathsf{E_n.R.y}, \mathsf{E_n.C.x}, \mathsf{E_n.C.y}, \mathsf{issuerData}[0..3]) \;\equiv\; \mathsf{idHash} \pmod{F_R}. \] This pins the publicly-revealed E_n to the leaf at mint time (~265 R1CS) without requiring any non-native BN254 arithmetic in the circuit.

2. Off-chain Chaum-Pedersen DLEQ verification in IdentityRegistry.verifySpendCP, called from Notes.spendACP via the EIP-196 BN254 precompiles (~36K gas). The verifier reads the spender's registered (pk_dep, E_reg) from storage and confirms a single sk_dep satisfies both ~pk_dep = sk_dep

   • G~ and the equal-plaintext relation between E_n and E_reg.

This split is forced by the prohibitive cost of non-native BN254 G1 arithmetic in circom (~+250K R1CS per CP constraint set); moving the DLEQ verification on-chain costs ~36K gas via precompiles instead. Notes.spendACP(proof, root, nullifier, face, recipient, E_n, cpProof) calls both the Groth16 verifier (which checks the binding gate) and IdentityRegistry.verifySpendCP (which checks the equality of plaintexts) atomically. All A1/A2 identity, security, and privacy properties documented above – including the Theorem 10.1 invariant – remain in force; only the verification location moved (off-chain CP via precompiles, not non-native G1 in circuit). End-to-end exercised by 26 forge tests in test/SpendAVerifier.t.sol.

Phases 5-8 are optional extensions deferred until the core system is production-proven.

In parallel with engineering, the legal and regulatory work:

• Confirm that BUCK Notes falls within Alberta's provincial jurisdiction over property and civil rights (s 92(13)) – the analysis in the Legal Foundation document covers the underlying primitive; bearer notes are an extension that may warrant additional treatment.
• Engage FINTRAC on the issuance-side reporting model.
• Engage the Office of the Superintendent of Financial Institutions (OSFI) on reserve treatment.
• Coordinate with Alberta Treasury Branches (ATB) as a candidate first issuer of paper notes under a public-warranty of \( \rho \)-erasure for the B1 walking-around-cash surface.

Donations to the Notes contract weighted-merge idx_pool forward toward cumIndex_now, lowering the per-BUCK fee owed by the pool and therefore reducing the index gap every subsequent redeemer inherits. The benefit spreads across all future redemptions rather than accruing to a single lucky first-redeemer. A donation immediately before a large redemption benefits that redemption more (because the merge uses the donation's relative weight against the pool's existing balance), but every subsequent redemption benefits in proportion to the freshened index. No special smoothing logic is needed.

Residual donation principal (after all notes drain) is not lost: it sits in balanceOf(notes) with a _indexAtLastTouch close to whatever cumIndex it last touched at, available to subsidise the next generation of mints, or recoverable by governance sweep per Notes-contract policy.

A lost note contributes to noteFaceSum indefinitely. The BUCK backing that note sits in the pool, where its share of accumulated demurrage stays attached to idx_pool. Each spend of a live note inherits a slice of that accumulated index gap on its delivered face – so over time the lost note's implicit demurrage is paid instalment-style by subsequent live noteholders on their next outgoing transfers. At 1%/yr loss and 2%/yr demurrage, the long-term tendency is that the pool absorbs the lost-note demurrage as a small pool-wide overhead.

A reclaim path is possible: after a very long period (say 99 years), the contract could allow the issuer to submit a zero-knowledge proof that a specific note commitment remains unspent, and reclaim the residual principal less accrued demurrage. Requires issuer-side recordkeeping; deferred.

The transferCarrying weighted-index merge involves one integer division \( ( br \cdot \text{idx}_r + v \cdot \text{idx}_p ) / (br + v) \) for the recipient's new index. Truncation rounds the recipient's inherited fee down by at most one cumIndex unit per spend – trivially small (sub-wei demurrage on any realistic balance) and not drift-accumulating: the lost fraction never exceeds the recipient's prior index gap. Floor rounding is fine; no banker's logic required.

Keeping three fixed flavors simplifies the circuit count. Adding programmable predicates (time locks, oracle conditions, multi-sigs) re-introduces most of the complexity that the fixed flavor scheme was chosen to avoid. A compromise: support a bounded predicate language in the circuit (time-lock + oracle-condition + up-to-3-sig) rather than a fully general one. The bounded language covers 90%+ of the programmable-predicate use cases while keeping the verifier compact.

Phase 4 deployed two distinct spend verifiers: spend.circom (universal B-shape) and spend_a.circom V2 (A-shape with the Poseidon-8 idHash binding gate and 9 public inputs). The wallet selects between Notes.spend and Notes.spendACP based on the note's flavor field. The alternative – one "super-spend" verifier branching internally on flavor – was rejected: the A-shape circuit publishes four extra public inputs (E_n.R/C coordinates) and an additional binding constraint, and unifying the two verifiers would force every B-spend proof to carry the A-only public-input overhead. Two verifiers, two trusted-setup ceremonies (both pot15), is the shipped configuration.

Jurisdictional regulators (FINTRAC, OSFI) have rules around bearer instruments and tax treatment of negative-interest accounts. BUCK's on-chain demurrage was argued through separately, and the Notes contract inherits that treatment with no pool-specific novelty – the contract is just another BUCK account.

The one new wrinkle is the transferCarrying primitive itself: ordinary BUCK transfers carry only balance (recipient gets "fresh" BUCK and resets _indexAtLastTouch to cumIndex_now), whereas Note redemptions weighted-merge the recipient's _indexAtLastTouch toward the pool's stale index. This means a Note recipient's post-redemption spendable value is less than their nominal balance – the difference being the demurrage they will pay on their next outgoing transfer. For tax and reporting purposes, whether the "face" or the "spendable" number should be used as the income figure is a question for tax counsel. The on-chain state (balanceOf and _indexAtLastTouch) is fully transparent either way.