The Alberta Buck - Notes Flow (DRAFT v0.1)

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

• She owns 1,200 BUCK on-chain.
• She has decided on the denomination split: [1000, 100, 25, 25, 25, 25]. N=6, but the Phase-6 circuit is pinned at N=2 (see Phase 6); for the example we proceed as if a future Mint(6) circuit were already in place. The structure of every step is identical – only the circuit constant changes.
• She has chosen an idHash_i for each recipient (typically a Poseidon hash of the recipient's IdentityRegistry-bound ElGamal credential, derived once at out-of-band introduction time).
• Her CSPRNG produces six fresh rho_i nonces.

She now has six opening tuples in memory.

For i = 0..5 her wallet computes

cm_i = Poseidon5( flavor_i, v_i, rho_i, idHash_i, predicate_i )

This is pure off-chain Poseidon arithmetic in alberta_buck.wallet.notes. Six uint256 field elements drop out. Their order in the eventual on-chain array is fixed by Alice's local list – the contract preserves whatever order she submits.

Alice's wallet runs scripts/snark/prove_mint.js (or the production equivalent). The witness consists of:

• Public inputs: totalFace = 1200e18, cm = [cm_0, cm_1, cm_2, cm_3, cm_4, cm_5].
• Private witnesses: flavor[i], v[i], rho[i], idHash[i], predicate[i] for each i.

The mint.circom circuit checks two relations across the witness:

1. Per-note opening. For each i, cm[i] === Poseidon5(flavor[i], v[i], rho[i], idHash[i], predicate[i]). Six Poseidon evaluations, six equality constraints.
2. Sum conservation. sum(v[0]..v[5]) === totalFace. One linear constraint.

The witness is processed by snarkjs's Groth16 prover. A few hundred milliseconds later the wallet has a fixed-size proof object: (pi_A: G1, pi_B: G2, pi_C: G1). Encoded as ABI-static (uint256[2], uint256[2][2], uint256[2]) it is exactly 256 bytes.

Observation. The Groth16 proof reveals nothing about the witness. Soundness guarantees that no proofBytes can satisfy the verification equation unless a witness exists; zero-knowledge guarantees that the verification equation reveals nothing about which witness was used. Mallory, even with the proof in hand, cannot back out v[i], rho[i], idHash[i], flavor[i], or predicate[i].

Alice now broadcasts a single transaction T_mint calling

notes.mint(proofBytes, [cm_0..cm_5], 1200e18);

The honest EVM walks Notes.mint:

require(cms.length > 0, "Notes: empty mint");
require(mintVerifier.verifyMint(proof, totalFace, cms, msg.sender),
        "Notes: bad mint proof");
require(buck.transferFrom(msg.sender, address(this), totalFace),
        "Notes: transfer failed");
// ... append cms[i] to commitments[], assert no duplicates,
//     emit Minted(...).

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

1. The MintVerifierAdapter unpacks the 256-byte proofBytes into Groth16 form, builds the public-signal vector [totalFace, cm_0..cm_5], and invokes the MintGroth16Verifier. If the verifier returns false, the entire transaction reverts – nothing is written, no BUCK moves.
2. The BUCK ERC-20's transferFrom debits totalFace from Alice and credits the Notes pool. This is a normal allowance-driven pull, gated by Alice's prior approve(notes, 1200e18, ...). Because the Notes pool is registered as system-public in the IdentityRegistry, the bilateral identity check on the transfer leg succeeds without a Chaum-Pedersen receipt.
3. For each cm_i: the contract checks !commitmentExists[cm_i], marks it true, appends to commitments[], emits Appended(cm_i, startIndex+i). Finally a single Minted(Alice, 1200e18, startIndex, 6) event closes the call.

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

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

note_artifact_i = {
  txHash:    T_mint,                # Ethereum transaction ID
  index:     startIndex + i,        # position in Notes.commitments[]
  cm:        cm_i,                  # for cross-checking against the chain
  opening:   ( flavor_i, v_i, rho_i, idHash_i, predicate_i ),
  meta:      { issuer: Alice's IdentityRegistry handle, ... },
}

The chain itself never sees opening. cm_i is already on-chain; the artifact includes it only as a convenience so the recipient does not have to recompute it before locating his entry in commitments[].

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

1. Recompute and check. Bob computes cm_check = Poseidon5(flavor, 1000e18, rho, idHash, predicate) and asserts cm_check == cm. If this fails, Alice lied about the opening; Bob discards the artifact and demands a real one. (Binding of Poseidon makes substitution impossible.)
2. Look up the mint transaction. Bob reads T_mint on-chain, parses the call data into (proofBytes, cms[], totalFace, msg.sender).
3. Confirm msg.sender is Alice. Cross-check msg.sender against the IdentityRegistry: it must resolve to Alice's PS-credentialed identity. If Bob wanted an A1 identified cheque, the issuer field of his opening must match.
4. Confirm membership. Read Notes.commitments(index) via an eth_call and assert it equals cm. Bob now has chain-anchored evidence that cm is officially a commitment in the pool.
5. Confirm batch totals. Read totalFace from the call data. The chain's acceptance of T_mint is itself a proof that the Groth16 verifier accepted – which means sum(v[0..5]) === totalFace holds in the witness. Bob does not need to re-verify the proof; the EVM already did. But if he wants belt-and-suspenders, he can re-run MintGroth16Verifier.verify(proofBytes, [totalFace, cms...]) locally against the same on-chain bytecode, and get the same accept.

After (1)-(5) Bob knows:

• His note encodes exactly 1,000 BUCK. (Step 1.)
• It was minted in T_mint by Alice. (Steps 2, 3.)
• It is one of exactly six commitments produced by that mint, the others being cms[0..5] \ cm. (Step 4.)

• The hidden values of the other five sum to exactly 1200 - 1000 = 200 BUCK. (Step 5

  • the per-note opening relation: he knows his value, the chain attests to the

  sum.)

• He learns nothing else about the other notes – not their individual values, not their recipients, not their flavors. Each cm_j is hiding under a fresh rho_j he does not have.

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

MintGroth16Verifier.sol was emitted from the Groth16 verification key produced by the trusted setup (Phase 9 for production; dev-only entropy in scripts/snark/setup.sh today). Its bytecode is deployed once and immutable. Validators run whatever bytecode sits at that address; Alice cannot tamper with it without consensus-breaking the chain.

Knowledge soundness of Groth16 means: for every proofBytes the verifier accepts on public inputs [totalFace, cm_0..cm_N-1], there exists a witness (flavor[i], v[i], rho[i], idHash[i], predicate[i])_i such that:

• cm[i] = Poseidon5(flavor[i], v[i], rho[i], idHash[i], predicate[i]) for all i
• sum(v[i]) = totalFace

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

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

This means Alice cannot, for instance:

• Verify a proof, then refuse to pay – the verifier acceptance and the transferFrom live in the same call, gated by the same require.
• Pay 1,200 BUCK but then get away with appending only one cm and pocketing the delta – the loop appending commitments runs after transferFrom, in the same call, and a revert at any point unwinds the transfer too.
• Trick the contract into appending a duplicate cm – commitmentExists[cm] is checked per item.

The Groth16 verifier consumes the public-signal vector [totalFace, cm_0, .., cm_N-1]. The proof was generated against the specific values Alice committed to before submission. If Alice tries to submit the proof with a different totalFace or with the cms permuted, the verifier rejects.

This is the bedrock of the test suite in test/MintVerifier.t.sol – four explicit tamper paths (totalFace + 1, cm[0] ^ 1, wrong batch size, malformed proof bytes) each revert with Notes: bad mint proof or an ABI decode error. Soundness is not a proof of absence of attack, but every documented attack surface is closed by a test that triggers a verifier reject.

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

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

That requires either:

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

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

What about hostile-Alice trying to mint more commitment value than she escrowed? She would need a witness whose sum(v[i]) equals the integer totalFace that the EVM sees, but whose individual v[i] values actually sum to more. This is Open Question 1 in the proofs document: in F_r with r ~ 2^254 and no Num2Bits range check on v[i], the constraint sum(v[i]) === totalFace is satisfiable by witnesses whose integer sum differs from totalFace by a multiple of r. Currently this attack is dormant because Phase 2 has no spend path – Alice would have to escrow totalFace up front and then never be able to release more than totalFace back, since no spend mechanism exists. This dormant gap closes the moment Phase 7 ships, and the fix (Num2Bits(128) per v[i]) is tracked as a Phase-7 prerequisite in alberta-buck-ethereum.org.

When the spend circuit ships (Phase 7), Bob will be able to deposit his note without revealing which cm in the on-chain set he opened. The spend SNARK proves "I know an opening to some commitment in the published Merkle tree that hashes to this nullifier", with cm as a private witness rather than a public input.

That is when the unlinkability of spend events to mint events becomes a true chain-observable property. Today (Phase 6) Bob still has to point at a specific cm when redeeming – because no redemption path exists yet at all.

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

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

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

1. Commitment uniqueness. commitmentExists[cm_i] is set true on the first append. The second submission would revert at the first require(!commitmentExists[cm_i]) check. (Replay-of-cm with a different rho is structurally different and is simply a fresh mint, not a replay.)
2. Allowance and balance. Even if the prior call's state were somehow reverted, the second mint would re-debit Alice's BUCK and re-consume her allowance to the Notes pool.

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

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