The Alberta Buck - Identity and Receipts (v2)

If I am suspected of a crime, an Alberta court can compel me to decrypt the participants in BUCK transactions they suspect are related to that crime, and reveal the identity of counterparties I've transacted with. I may resist, and face the consequences. But the organizations that Alberta tasks with overseeing the authenticity of my Alberta issued identity must not be able to simply authorize decryption of my counterparties' identities! They can only vouch for and reveal the identities they've directly issued, just as I can vouch for my daughter's – they can't decrypt arbitrary participants in each transaction.

This is how the cryptography enforces it: each re-encrypted identity is an ElGamal ciphertext under the specific counterparty's public key. Only that counterparty's private key can recover the plaintext. The identity issuer cannot decrypt it – they signed the identity, not the ciphertext; the encryption is mine alone. The government cannot decrypt it. No registry operator, no Holochain node, no subpoena served on anyone other than a direct participant can break this. A court must compel a specific participant to decrypt a specific transaction's counterparties' identity data. Every individual's credential must be attacked separately. The cost to surveil is O(N), not O(1). For the registration transcript this holds only with the A' presentation: the earlier published rerandomized signature let anyone holding an identity scalar test every registration against it at no cost.

identity_data = canonical_encode({
    given_name:    "Alice",
    family_name:   "Johnson",
    jurisdiction:  "Alberta, Canada",
    id_type:       "Alberta Identity Card",
    id_number:     "AIC-2026-4839201",
    date_of_birth: "1992-03-15",
    issuer_id:     "atb-financial-ca",
    issued_at:     "2026-01-20T14:30:00Z",
    epoch:         42
})

// Real entry point: register(issuer, pk, E, presentation, proof).  The
// registrant is msg.sender (NOT a passed address) -- it, the chain, the
// registry deployment, and the action/version domain
// (AlbertaBuck/FiatShamir/IdentityRegistry/Register/v2) are folded into
// the proof's Fiat-Shamir challenge, so a proof cannot be replayed across
// addresses, chains, registries or protocol versions.  A compatibility
// overload accepts identityLeaf only when it is zero; callers cannot
// insert an unconstrained accumulator leaf.
identityRegistry.register(
    issuer,          // trusted issuer whose PS key signed the credential
    pk_new,          // identity public key (G_1)
    E_new,           // ElGamal ciphertext (2 G_1 points)
    presentation,    // (A, B): the blinded credential (2 G_1 points)
    pi               // (e, s_m, s_b, s_r, s_sk, C1, T_C, T_R, T_key)
)                    // (msg.sender == the new account being registered)

I may be a citizen of Alberta and have a minor child. My child's identity is vouched by me, and my identity is vouched by Alberta. I have several accounts associated with encrypted copies of my identity (income, savings, etc) and several unencrypted accounts (walking-around money). I can transfer money from my savings to my walking-around account (anonymously, via my BUCK account at ATB).

My encrypted savings account identity has been authorized by ATB to send funds. My walking-around money account has a plaintext identity, so Starbucks' BUCK account doesn't need to pre-authorize incoming transactions – it accepts BUCK transfers from any BUCK account with a public identity.

This just cuts out the middleman, and gives every citizen what government and institutions already have: knowledge of the participants in transactions with public accounts. If I prefer, I can set up a Starbucks account, and ask them to authorize me to send money to them. Again, allowing with BUCKs what is already allowed with a pre-loaded Starbucks card – private transactions with a public account. Starbucks and Visa both know who paid to fund the Visa card, and who funded their Starbucks account with that card. Now, citizens can set up similar arrangements and retain that knowledge amongst themselves.

If a court compels one of the participants (for example, as the result of an arrest in a sting operation against some members of a group performing some illicit activity), then that person's transactions with other members of the group can be discovered. Otherwise: financial activity remains confidential, at the sole choice of the participants.

The expectation that any government or bank functionary – or any random attacker exploiting government or bank incompetence – can know the details of a citizen's financial activities is unacceptable. The attack cost must be O(N), not O(1): every individual's credential must be attacked separately, not extracted from one compromised custodian.

Each transaction is between parties identified to each other by provably untampered copies of their identity, encrypted by each party specifically for that counterparty.

The identity credential lifecycle:

1. Issuance: A trusted issuer (the Alberta government, ATB Financial, etc.) verifies Alice's identity through a KYC ceremony and produces a Pointcheval-Sanders signature on her identity scalar m = H(identity_data). Alice receives (m, sigma) and stores it in her Holochain wallet. (See The Identity Fountain for the full PS construction.)
2. Derivation: For each Ethereum account, Alice's wallet blinds the PS signature into a presentation (A, B), generates a fresh identity key pair, encrypts her identity under the new key using ElGamal, and produces a NIZK proof linking the presentation to the ciphertext and to the account key. This runs entirely offline.
3. Registration: Alice registers the derived credential (pk, E_alice, (A, B), pi) in the on-chain IdentityRegistry. The contract verifies the credential proof via the ecPairing precompile (443,892 gas measured, one-time). After registration, isVerified(alice) == true.
4. Re-encryption: When Alice must identify herself to counterparty Bob (e.g., during an approve call on the BUCK contract), she decrypts her credential locally (she knows sk_alice) and re-encrypts the identity under Bob's public key with fresh randomness: E_bob = (r' * G, r' * pk_bob + M) where M = m * G is the identity message point. She produces a Chaum-Pedersen proof³ pi that E_bob encrypts the same point M as her registered E_alice – without revealing m.

5. Verification: The BUCK smart contract verifies:

   • E_alice is read from the IdentityRegistry (not from Alice's calldata)
   • pi proves E_bob encrypts the same plaintext as E_alice

   Verification requires only 3-4 elliptic curve scalar multiplications (~29,000 gas via the alt_bn128 precompiles). No pairing operations at transaction time. The PS signature was verified once, at registration, and is never consulted again.

6. Decryption: Only Bob can decrypt E_bob (he has sk_bob). Only Alice can decrypt E_alice (she has sk_alice). The issuer cannot decrypt either – they signed Alice's identity scalar, they never encrypted under any key. No third party can decrypt any re-encrypted copy.

This is a two-channel design. The on-chain ElGamal ciphertexts and Chaum-Pedersen proofs form the proof chain: they bind Alice's registered identity to the re-encrypted ciphertext Bob receives, without revealing content. The actual identity_data (name, jurisdiction, ID number) travels via the data channel: Alice's Holochain hApp sends it to Bob's hApp, encrypted end-to-end. Bob verifies the binding:

M = C_b - sk_bob * R_b              // decrypt ElGamal ciphertext
assert H(identity_data) * G == M    // bind off-chain data to proof chain

EC-ElGamal decryption yields a curve point M, not the scalar m. Recovering m from M = m * G is the discrete logarithm problem. The proof chain never carries plaintext – it proves which identity was sent. The data channel delivers what that identity contains. The hash commitment H(identity_data) * G == M binds them cryptographically: Bob can verify the identity_data he received via Holochain is exactly the identity the issuer certified and Alice registered on-chain.

There is no need for Proxy Re-Encryption (PRE), because Alice is online when she calls approve and can perform the re-encryption directly. The Chaum-Pedersen proof is the trust anchor at transaction time: it is a mathematical guarantee – unforgeable under the discrete logarithm assumption – that Alice re-encrypted her genuine, registered identity and not a substitute. The PS signature is the trust anchor at registration time: it guarantees the credential was issued by an authorized issuer.

Alberta Buck mandates that all identity credentials, all participant key pairs, all re-encryption operations, and all issuer signatures use the alt_bn128 elliptic curve (BN254)¹ – the curve supported by Ethereum's precompiled contracts:

• ecAdd (address 0x06): point addition, 150 gas
• ecMul (address 0x07): scalar multiplication, 6,000 gas
• ecPairing (address 0x08): bilinear pairing check, 34,000 gas per pair + 45,000 base

This mandate is a design strength, not a limitation:

• Uniform proof verification: every Chaum-Pedersen proof and every Pointcheval-Sanders signature verification uses the same curve group, so a single on-chain verifier handles all identity operations.
• Precompile efficiency: per-transaction Chaum-Pedersen verification uses ecMul / ecAdd (29,000 gas). One-time credential registration uses ~ecPairing for the credential proof (443,892 gas measured).
• No cross-group compatibility issues: since all participants, issuers, and credentials use the same curve, re-encryption between any two participants is always algebraically compatible.

Participant key pairs for identity purposes are distinct from their Ethereum signing keys (which use secp256k1). The identity key pair is generated during credential derivation (not during the KYC ceremony – the KYC ceremony produces only the PS signature). The public key is registered in the IdentityRegistry alongside the participant's Ethereum address.

When Alice re-encrypts for N different counterparties, each re-encryption uses independent randomness. The resulting ciphertexts are IND-CPA secure: computationally indistinguishable from random curve points. An observer who collects all N ciphertexts cannot determine that they encrypt the same plaintext (without access to a counterparty's private key).

The Chaum-Pedersen protocol³ is a sigma protocol (Schnorr family) that proves two ElGamal ciphertexts encrypt the same message point, without revealing the message. Made non-interactive via the Fiat-Shamir heuristic, the proof is compact (the on-chain CPProof carries three scalars (e, s1, s2) and three G1 commitment points (T1, T2, T3)) and verification requires only 3-4 multi-scalar multiplications.

Registered credential (verified at registration via PS signature + NIZK):
  E_alice = (R_a, C_a) = (r_a * G,  r_a * pk_alice + M)
  where M = m * G  (identity encoded as a curve point, m = H(identity_data))
  Credential presentation (A, B) proven at registration (not consulted again)

Alice's re-encryption for Bob:
  E_bob = (R_b, C_b) = (r_b * G,  r_b * pk_bob + M)
  using the SAME message point M

"I know (sk_alice, r_b) such that:
  1. pk_alice = sk_alice * G                    -- I own this public key
  2. R_b = r_b * G                              -- I know E_bob's randomness
  3. C_a - sk_alice * R_a = C_b - r_b * pk_bob  -- same message point M"

Given public inputs:
  E_alice = (R_a, C_a)     -- from IdentityRegistry (PS-verified at
                              registration, read from storage -- NOT
                              supplied by Alice)
  E_bob   = (R_b, C_b)     -- from Alice's approve() calldata
  pk_alice                 -- from IdentityRegistry
  pk_bob                   -- from IdentityRegistry
  proof   = (e, s1, s2, T1, T2, T3)  -- challenge, two responses, and the
                                     -- three G1 commitments (CPProof struct)

Verify:
  Recompute challenge e from commitments
  Check consistency of s1, s2 against e, the public keys, and ciphertexts
  3-4 ecMul + 3-4 ecAdd operations

e = H(R_a, C_a, R_b, C_b, pk_alice, pk_bob, T1, T2, T3,
      msg.sender, spender, block.chainid, registry,
      keccak("AlbertaBuck/FiatShamir/IdentityRegistry/Approve/v2"))

Public inputs:
  (A, B)                         -- credential presentation (G_1)
  E_new  = (R, C)                -- ElGamal ciphertext (G_1)
  pk_new                         -- identity public key (G_1)
  (X, Y)                         -- issuer public key (G_2); Y1 = y*G is used by the holder only
  g_2                            -- generator (G_2)

Proof:  pi = (e, s_m, s_b, s_r, s_sk, C1, T_C, T_R, T_key)

Verifier computes:
  // (g) guards: A != O, B != O, pk_new != O, R != O; scalars canonical.
  //     A = O is security critical: the pairing product below then holds for every m.
  // (fs) Fiat-Shamir challenge reconstruction:
  e' = H(A, B, R, C, pk_new, C1, T_C, T_R, T_key,
         msg.sender, chainid, address(this), DOMAIN_v3)
  require(e' == e)
  // (b), (c) ElGamal consistency (pure G_1 arithmetic):
  //     s_m * G + s_r * pk_new  ==  e * C + T_C
  //     s_r * G                 ==  e * R + T_R
  // (k) account key:
  //     s_sk * G                ==  T_key + e * pk_new
  // (a') credential presentation via the ecPairing precompile, three pairs.
  //     The one commitment C1 = m~*A + b~*G covers both hidden exponents,
  //     so no proof field reveals m*A on its own; the only derivable
  //     point is L/e = m*A + b*G, uniform and the same for every m.
  L = ecMul(A, s_m) + ecMul(G, s_b) - C1                 // 2 ecMul + 2 ecAdd
  ecPairing([L, Y], [ecMul(A, e), X], [ecMul(B, -e), g_2]) == 1

Every certifying authority keeps subtrees of Poseidon leaves. An identity registry's are private, of depth 12, and its leaves are salted:

identity_leaf_salted(M, salt) = Poseidon(tag_S, M.x, M.y, salt)
receiving_leaf(m, k, salt)    = Poseidon(tag_R, m, k, salt)

The salt derives from the holder's wallet secret, never from m, so a party holding every scalar it ever certified and the whole published subtree decides no membership. The second form pairs an identity with the key its Notes are addressed to (Notes, "The Receiving Key"). Institutions whose membership is a fact they advertise – an insurer's licence, its permitted scopes – sit in public subtrees with the unsalted leaf Poseidon(tag_I, M.x, M.y). Each leaf function leads with its own AlbertaBuck/Accumulator/Leaf/.../v2 tag.

An aggregator's tree, of depth 20, has the subtree roots for leaves. Every level hashes alike, so a subtree path and an aggregator path compose into one path of 32 levels, and a proof can hide which authority certified the leaf. Governance appoints one root authority per deployment, which enrolls each subtree at an aggregator slot and appoints the aggregator; the aggregator alone posts roots, into a ring of 256 records with their posting times. Each consumer declares the oldest root it accepts – Notes seven days, the insurer gate one day – and that age is the protocol's statement of how long a revoked member can still prove membership.

Admission is certification. register and bindContract refuse a caller-supplied leaf, and must: a registration that accepted any leaf would accept one pairing any identity with any key.

A feature check is a proof the holder produces, not a lookup a verifier runs: one path per claimed subtree, all against one posted root, and the verifier names the subtrees it requires and the maximum root age it accepts. A counterparty that needs durable evidence – a merchant selling to adults, a lender checking residency – captures the proof in the payment's receipt. Nobody else learns the holder was asked.

Mutable facts, an address or a region, are re-associations: the authority inserts a fresh leaf under a new salt in the subtree for the new value and clears the old one, so the two leaves do not link for anyone lacking the authority's own records, and the authority keeps the current association only.

An insurance regulator is a periodic attestor with public subtrees, one per predicate: standing, a face band on a ladder of powers of ten, each permitted depreciation model, the maximum depreciation and premium rates, and each asset scope. Once per review period the insurer proves its memberships to BuckCredit.attestInsurer, together with an opening of its registered identity bound to its account, and the envelope is cached with an expiry; every createCredit then checks the credit's parameters against it (Ethereum, "The Insurer Gate"). The regulator attests what it already reviews; the chain holds it to the result.

The previous attacks target individual operations. This attack assumes Alice is willing to lie about every artifact she produces – hashes, proofs, signatures, ciphertexts – and asks whether she can deceive anyone about the validity or content of her identity.

The trust chain has three links. We attack each one.

e(A, X + m* * Y) = e(B - b* * Y1, g_2)

a') e(B, g_2) = e(A, X) * e(m * A + b * G, Y)   -- (A, B) presents m
b)  C = m * G + r * pk_new                       -- E_new encrypts m
c)  R = r * G                                    -- consistent randomness
k)  pk_new = sk * G                              -- account key ownership

C_a - sk_alice * R_a  =  C_b - r_b * pk_bob

e(s_m * O + s_b * G - C1, Y) * e(e * O, X) * e(-e * B, g_2)
  = e(s_b * G - C1, Y) * e(-e * B, g_2)

require(!isInfinity(A) && !isInfinity(B), "Degenerate presentation");

Every attack that involves substituting false identity data fails for the same fundamental reason: the Chaum-Pedersen proof is sound. A valid proof for a false statement does not exist.

The proof asserts:  E_bob encrypts the same M as E_alice
The contract reads: E_alice from the registry (PS-verified, immutable)
Therefore:          E_bob must encrypt Alice's real identity
Alice cannot:       supply a different E_alice (contract reads from storage)
Alice cannot:       produce a valid proof for different M (soundness)
Alice cannot:       forge the issuer's PS signature (PS unforgeability, committed-message key)
Alice cannot:       link her accounts to each other (hiding presentation; DDH for the ciphertexts)
Issuer cannot:      test a registration against an identity it certified (presentation is uniform)
Bob cannot:         produce a different plaintext (ElGamal decryption is deterministic)
Eve cannot:         decrypt E_bob (she lacks sk_bob)
Eve cannot:         link Alice's accounts (presentation: information-theoretic; ciphertext: DDH)

Three independent hardness assumptions protect the system:

1. PS signature unforgeability in the committed-message key form (Pointcheval-Sanders 2016, Section 6.1; the issuer publishes y * G): prevents forged credentials and forged registrations
2. Discrete logarithm hardness (alt_bn128), with DDH for the unlinkability of ciphertexts: prevents false Chaum-Pedersen proofs and unauthorized ElGamal decryption
3. ECDSA unforgeability (secp256k1): authenticates Ethereum transactions

DLog, DDH and ECDSA also underpin Ethereum itself. The PS assumption is the credential scheme's own, in the key form that publishing y * G requires; the A' presentation that rests on it is implemented on branch feature/a-prime and awaits independent review.

The relevant code in src/IdentityRegistry.sol:

/// An existing target authorizes this exact binder/identity/policy tuple.
function authorizeContractBinding(address binder, G1Point pk, ElGamalCT E,
                                  bool isPublicIdentity_, bool isCarrying_);

/// Copy an already-registered operator identity onto an authorized target.
/// `isPublicIdentity_` selects the receipt-fragment fallback policy; if
/// true, transfers may use the bound _identityHash on this side when no
/// per-pair CP fragment exists; if false (Encrypted-Identity contract)
/// the contract participates exactly like an EOA (no fallback).
/// `isCarrying_` selects the demurrage transfer flavour (service
/// contracts -- AMM pools, the Notes pool -- bind isCarrying_=true).
function bindContract(
    address              target,
    BN254.G1Point calldata pk,
    ElGamalCT     calldata E,
    bool                 isPublicIdentity_,
    bool                 isCarrying_
) external {
    require(target.code.length > 0, "target not a deployed contract");
    require(!_isRegistered(target), "already bound");
    require(_isRegistered(msg.sender), "binder not registered");
    require(_samePkE(msg.sender, pk, E), "uncertified identity");
    _consumeBindingControl(target, msg.sender, pk, E,
                           isPublicIdentity_, isCarrying_);
    _storeBinding(target, pk, E, isPublicIdentity_, isCarrying_,
                  msg.sender, issuerOf[msg.sender]);
}

/// A second overload verifies a target-bound PS credential and its
/// account-key ownership/policy authorization. Target control remains
/// mandatory.

/// A governance-approved adapter may bind a known-provenance contract.
/// The adapter supplies only the operator address; the registry copies
/// that registered operator's pk, E, and issuer from storage.
function bindContractFromAdapter(address target, address operator,
                                 bool isPublicIdentity_, bool isCarrying_);

(isVerified(target) is a view returning true once pk is written – both register and bindContract set it; reads use pkOf / ciphertextOf, not the illustrative getCredential / getIdentityKey names used elsewhere in this document.)

No separate register transaction is needed for the contract address. The certified-operator and adapter paths republish an already-registered (pk,E); the fresh-credential path verifies a PS credential directly during an explicitly target-authorized bind. Whoever holds the certified identity's secret key sk can decrypt every receipt that uses the bound ciphertext.

Public-Identity contracts compose with BUCK in two places. Both relax the per-pair receipt-fragment requirement, but neither bypasses the Chaum-Pedersen handshake on the sender's side.

1. Approve against any spender, including Public-Identity (Buck.approve). Approve always requires CP – there is no isPublicIdentity shortcut. The sender's wallet constructs E_spender by re-encrypting against the spender's published pk (read from IdentityRegistry), produces the CP proof, and the contract verifies it. This guarantees that a subpoena of the sender's records always recovers a full receipt for the counterparty's identity. See Why approve Is Always CP-Bound for the full rationale (consent vs. execution, BN254-key engagement, per-pair freshness, uniform audit semantics, and defence against future identity rotation).
2. Transfer with a Public-Identity counterparty (Buck._identityCheckedTransfer). Both parties must be isVerified. If a per-pair receipt fragment exists for a side, it is used as that side's identity material in the receipt. If a side has no fragment and isPublicIdentity[side] == true, the bound _identityHash(side) is used as that side's fragment. EOA<->EOA Encrypted-Identity transfers MUST have a prior CP receipt – there is no fallback for EOAs.

Production pool-admission sequence (the adapter suite exercises admission; the separate V2 integration test exercises AMM transfer mechanics):

1. Governance deploys and approves an UniswapV2BindingAdapter fixed to the registry and the intended Uniswap V2 factory. Approval is an audit decision about that exact adapter and factory, not a generic factory-call privilege.
2. The factory's registered feeToSetter calls adapter.createPairAndBind(BUCK, USDC). The adapter requires that no pair exists, calls createPair, verifies both-order getPair lookup and deployed code, then binds the pair Public/Carrying in the same transaction. The registry copies pk_op, E_op, and issuer from the registered feeToSetter; the adapter cannot substitute identity material. An already-created canonical pair uses bindExistingPair. V3 follows the same pattern with owner, getPool, and createPool. Stock routers do not expose an owner or governance identity and are not covered by these pool adapters. A deployment-specific router adapter would need to prove creation and bind in the same invocation; absent that, production must use a BUCK-aware wrapper/controller rather than attributing a router to the factory's governance by assumption.
3. If a separately justified deployment adapter has admitted an exact router, a verified user (Alice) approves that router for BUCK using the identity-bound approve overload. Alice's wallet reads pk_router from IdentityRegistry (which is pk_op), decrypts her own stored ciphertext to recover M, re-encrypts under pk_router to produce E_router, generates the CP proof, and submits. The contract verifies CP and stores _receiptFragments[alice][router] = H(E_router). She approves USDC using plain ERC-20 approve. Then router.addLiquidity(BUCK, USDC, ...). The router's internal safeTransferFrom calls land Alice's BUCK and USDC into the pair. The pair issues LP tokens to Alice.
4. Verified swappers (Bob, …) call router.swapExactTokensForTokens. BUCK->USDC: pair receives Bob's BUCK (verified from, Public-Identity to – allowed); pair sends USDC out (no BUCK identity check on the USDC side). USDC->BUCK: pair sends BUCK to Bob (Public-Identity from, verified to – the pair side falls back to _identityHash(pair) because no per-pair fragment exists from the pair to Bob).
5. An unverified user (Carol) trying to receive BUCK from a swap is rejected: the pair's _safeTransfer on BUCK reverts with "BUCK: recipient not verified", which the pair surfaces as "UniswapV2: TRANSFER_FAILED".

The pool's identity is the operator's identity. The bound (pk, E) is the operator's already-registered material; whoever holds the operator's sk can decrypt every receipt that uses the pool's _identityHash. Every BUCK transfer touching the pool emits a BuckTransferReceipt whose pool-side fragment is either a per-pair CP-bound ciphertext (if one exists) or the bound _identityHash(pool) (if none does). Auditors and subpoena responders can:

• On the sender's side: produce the CP-bound ciphertext from the sender's own records (always present – approve always requires CP).
• On the pool's side: ask the operator (whose key sk binds to pk) for the corresponding identity, just as for an EOA counterparty.

The operator is the legal counterparty. Setting up a BUCK/X AMM is permissionless at the factory level (anyone can call createPair). What gates the pool's usability for BUCK is bindContract, but an arbitrary first caller cannot claim it: an existing pool must authorize the exact binding, while an approved helper can bind a newly deployed target atomically. Once bound, the operator's identity is the contract's identity for audit purposes.

Governance does not select ordinary operators, but it does approve which factory helpers may use the atomic target-control exception. Existing contracts express control through their own controller/governance call to authorizeContractBinding.

Setting isPublicIdentity_=false in bindContract produces an Encrypted-Identity contract: the contract is bound and verified exactly like a Public-Identity contract, but it participates in transfers identically to an EOA – no per-side receipt-fragment fallback to _identityHash. Use this for treasury or escrow contracts whose interactions deserve full per-pair CP receipts on both sides without exposing a permanent _identityHash in receipts that lack a fragment.

In every transferFrom flow – DeFi routers, swap aggregators, multi-hop trades, allowance-based subscriptions – the spender is not the ultimate recipient and the approve precedes the transfer by an unbounded amount of time. Approve is the moment Alice says "I am authorising this address to draw against my balance"; the transferFrom is when the spender does the drawing, often weeks later. With CP-bound approve, that consent leaves a permanent per-pair commitment (_receiptFragments[alice][spender] = keccak256(E_spender)) plus an IdentityExchange event carrying the ciphertext. With plain ERC-20 approve, the only artifact is a standard Approval(alice, spender, amount) log – indistinguishable from a unit-test approval, a phishing approval, or any other context-free allowance write. The transfer event happens after the consent moment has been forgotten.

CP requires the sender's wallet to decrypt its own E_alice with sk_alice^{BN254}, re-encrypt under pk_spender, and produce a Schnorr-style transcript. That proves the holder of the identity key personally signed off on this counterparty – not merely the holder of the Ethereum tx-signing key. The two keys live in the same wallet today, but a custodian, a hardware wallet without BN254 support, a session key, or a compromised tx-signer can authorise plain ERC-20 approves without ever touching the identity layer. CP forecloses that gap. An EOA whose Ethereum key has leaked to an attacker can still be drained on-chain, but the leaked approves will not produce CP fragments and will be visibly non-conforming to a downstream audit.

_identityHash(spender) is the same value forever – it appears identically in every receipt that spender ever participates in. The CP fragment is per (sender, spender) pair and is committed at the moment of consent. Without it, a regulator looking at receipts for "Bob's pool" sees _identityHash(pool) against every counterparty and cannot, from chain data alone, separate "Alice deliberately authorised this pool" from "Alice was somehow drawn against by this pool." The existence of _receiptFragments[alice][pool] != 0 is itself the cryptographic proof of consent for that specific pair.

If approve were CP-optional for Public-Identity counterparties, every audit tool, every operator, and every regulator would have to handle two receipt flavours: "fragment present, sender-signed off-on" and "fragment absent, fall back to identity hash." Operators would route flow through the bifurcation to obscure consent trails (e.g., always approve the public router, never the EOA). Mandatory CP collapses both cases into one: the fragment is always present after a successful approve, and _identityHash fallback exists only on the transfer side, only between parties who never approved each other, and only for the side that is isPublicIdentity = true.

Today bindContract is one-shot, so a contract's identity is fixed at first bind. But any future revocation, rotation, or compliance-driven rebind would mean _identityHash(spender) changes. The CP fragment captures the spender identity that the sender actually authorised at this block height. Plain ERC-20 approve would capture only the address – useless if the operator changes hands later, since the address can outlive the binding.

The premium for the always-CP rule is 29K gas per approve (4 ~ecMul + 4 ecAdd + 1 keccak256) plus the storage write of one 32-byte _receiptFragments slot. Approve is amortised across many transferFrom calls – the per-transfer cost remains ~2K gas (one event + two SLOADs). In exchange, every BUCK authorisation leaves a sender-key-bound, per-pair, on-chain consent record that is openable on subpoena without the counterparty's cooperation and without trust in any operator.

The shortest version: the receipt event is reconstructable from registry data, but the consent event is not. CP at approve is what makes the BUCK identity layer's consent visible on-chain, not just its execution.

Events are public. Every emit on Ethereum is readable by every node. A naive design that emits identity addresses or public keys in receipt events creates a permanent, public, linkable identity graph of every BUCK transfer – defeating the entire privacy model.

The constraints that drive the on-chain design:

1. The EVM is transparent: every contract execution, every storage slot, every emitted event is publicly reconstructible. The BUCK contract cannot hold decrypted identity data, even transiently.
2. The contract must verify, not learn: the BUCK contract enforces isVerified and verifies Chaum-Pedersen proofs. It confirms that a re-encrypted identity ciphertext is genuine. It never learns the identity itself.
3. DeFi timing: in a transferFrom call, the Uniswap router cannot pass receipt data. Identity exchange must happen earlier, at approve time.

The ElGamal Chaum-Pedersen approach resolves all three. The contract reads E_alice from the IdentityRegistry (not from calldata), verifies a compact Chaum-Pedersen proof (~29,000 gas), stores a hash of the re-encrypted ciphertext, and emits only opaque curve point coordinates. No identity content touches the EVM in any form.

The ERC-20 approve function is the natural point for identity exchange. Alice is directly calling the BUCK contract – she can provide the re-encrypted ElGamal ciphertext and the Chaum-Pedersen proof:

// Real signature: E_spender is an ElGamalCT struct (R, C) and the proof
// is a CPProof struct (e, s1, s2, T1, T2, T3) -- three scalars and three
// G1 commitment points, not a bare (e, s1, s2) triple.
function approve(
    address spender,
    uint256 amount,
    ElGamalCT calldata E_spender,         // (R, C)
    CPProof   calldata chaumPedersen      // (e, s1, s2, T1, T2, T3)
) public returns (bool) {
    // Read the caller's registered credential from the registry
    // CRITICAL: read from storage, never from calldata.  (Real names:
    // ciphertextOf(msg.sender) / pkOf(spender); verifyApprove reads
    // E_alice itself from storage and binds the registry, sender, spender,
    // and chainid.)
    require(identityRegistry.verifyApprove(
                msg.sender, spender, E_spender, chaumPedersen),
            "BUCK: bad CP proof");

    // Store hash of the verified re-encrypted ciphertext for this pair
    bytes32 receipt = keccak256(abi.encode(E_spender));
    _receiptFragments[msg.sender][spender] = receipt;
    identity.markApproved(spender);
    _approve(msg.sender, spender, amount);

    // Emit ONLY the hash -- NOT the ciphertext itself.
    emit ApproveReceipt(msg.sender, spender, receipt);
    return true;
}

What the public sees in the ApproveReceipt event:

• Alice's address approved a spender (same as standard ERC-20 Approval)
• A single bytes32 hash of the re-encrypted ElGamal ciphertext
• No identity address, no public key, no linkable identifier

The opaque ciphertext E_spender itself is not emitted; it lives in the approve transaction's calldata, which is equally permanent and publicly recoverable on-chain. (This document elsewhere refers to an IdentityExchange event carrying the ciphertext; read that as shorthand for "the ciphertext recoverable from the approve calldata, anchored by the ApproveReceipt hash.")

What the contract verified (in ~29,000 gas):

• The ciphertext contains Alice's real identity (Chaum-Pedersen proof passed against the registered credential read from the registry)

What the spender (Bob / pool operator) can do:

• Decrypt E_bob using sk_bob: M = C_b - sk_bob * R_b
• Receive identity_data from Alice via Holochain (encrypted for Bob)
• Verify authenticity: H(identity_data) * G == M (binds off-chain data to the on-chain proof chain)
• Store verified identity for receipt construction on Holochain

// Alice (private) wants to transact with Bob (private):
// Step 1: Alice approves Bob -- re-encrypts her identity for Bob
buck.approve(bob, amount, E_alice_for_bob, chaumPedersenProof)

// Step 2: Bob approves Alice -- re-encrypts his identity for Alice
buck.approve(alice, 0, E_bob_for_alice, chaumPedersenProof)
// Amount = 0: no spending authorization, just identity exchange

The BUCK contract emits a minimal event that reveals only pseudonymous addresses (which the ERC-20 Transfer event already reveals) plus a reference to the pre-stored identity fragments:

event BuckTransferReceipt(
    address indexed from,
    address indexed to,
    uint256 amount,
    bytes32 fromIdentityHash,    // keccak256 of from's ElGamal ciphertext for to
    bytes32 toIdentityHash       // keccak256 of to's ElGamal ciphertext for from
);

The fromIdentityHash and toIdentityHash are keccak256 hashes of the opaque ElGamal ciphertexts stored during approve. They add no linkability beyond what the Transfer event already provides (the addresses are the same in both events).

The actual re-encrypted identity ciphertexts are retrievable:

• From the IdentityExchange events (emitted during approve)
• From Holochain (stored on the participants' source chains)

Only the counterparty (who has the identity private key to decrypt the ElGamal ciphertext) can recover the plaintext identity.

function transfer(address to, uint256 amount) public override returns (bool) {
    require(identityRegistry.isVerified(msg.sender), "Sender not verified");
    require(identityRegistry.isVerified(to),         "Receiver not verified");
    require(compliance.canTransfer(msg.sender, to, amount), "Compliance");

    // Bilateral identity check.  Each side's identity must be recoverable
    // from the receipt: a private endpoint must have laid down its OWN CP
    // fragment toward the counterparty; only a Public-Identity side may
    // fall back to its bound _identityHash.  The guard is per-side and
    // single-party (NOT an OR over both): the sender-fragment branch keys
    // on isPublicIdentity(sender), the recipient-fragment branch on
    // isPublicIdentity(recipient).  So a private party always needs its
    // own fragment, even against a public counterparty.
    bytes32 fromHash = _receiptFragments[msg.sender][to];   // sender's identity, for `to`
    bytes32 toHash   = _receiptFragments[to][msg.sender];   // recipient's identity, for sender

    if (fromHash == 0) {
        require(
            identityRegistry.isPublicIdentity(msg.sender),
            "BUCK: sender must identity-approve recipient"
        );
        fromHash = identityRegistry.identityHash(msg.sender);
    }
    if (toHash == 0) {
        require(
            identityRegistry.isPublicIdentity(to),
            "BUCK: recipient must identity-approve sender"
        );
        toHash = identityRegistry.identityHash(to);
    }

    _transfer(msg.sender, to, amount);
    compliance.transferred(msg.sender, to, amount);

    emit BuckTransferReceipt(
        msg.sender, to, amount,
        fromHash, toHash
    );

    return true;
}

The bilateral identity check enforces that both sides of the receipt event carry identity material. The fallback to a bound _identityHash is available only on the side that is bound under a Public Identity; a private endpoint must always supply its own per-pair CP fragment. In particular, a private EOA receiving BUCK out of a Public-Identity pool must itself have CP-approved that pool first – being a public sender does not exempt the private recipient. Approvals are always CP-bound; there is no isPublicIdentity shortcut at approve time.

The transferFrom path applies the same bilateral check. Receipt fragments were stored during approve, so no additional identity data passes through a DeFi router. Chaum-Pedersen verification ran once at approve time; subsequent transfers emit only the minimal receipt event (~2,000 gas plus two SLOADs for the fragments).

Alice's wallet (a Holochain hApp) performs all credential derivation and transaction preparation:

• Credential derivation: Alice's PS-signed identity (m, sigma) lives on her Holochain source chain. For each new account, the hApp blinds the PS signature into a presentation, generates a fresh key pair, creates an ElGamal encryption, and computes the NIZK proof. This runs entirely offline and can be batched – Alice can pre-generate credentials for future accounts.
• Identity data storage: Alice's plaintext identity_data is stored as a Private entry on her Holochain source chain, encrypted with her agent key and never published to the DHT. Only Alice's own agent can read it. This is the master copy from which m = H(identity_data) can always be recomputed.
• Credential storage: Each derived credential (pk, E_alice, (A, B), pi, sk) is also stored as a Private entry on the agent's source chain. The identity private key sk (an alt_bn128 scalar) is stored alongside the credential. The ElGamal ciphertext binds m to the credential; the plaintext identity_data that gives m meaning lives only in the Private entry, never on Ethereum.
• Identity data delivery (the data channel): When Alice re-encrypts her identity for Bob, her hApp also sends identity_data to Bob's hApp via Holochain, encrypted under Bob's Holochain agent public key. Bob's hApp decrypts it, computes H(identity_data) * G, and checks equality with M recovered from the on-chain ElGamal ciphertext. This verification binds the off-chain plaintext to the on-chain proof chain. The Holochain data channel carries the content; the Ethereum proof chain guarantees its authenticity.
• Non-publication detection: Bob's wallet watches for IdentityExchange events on Ethereum and checks for the corresponding DHT entry within a grace period. If Alice completes the on-chain approve but never publishes her identity_data to the DHT, Bob's wallet can flag the account as non-compliant, issue a Holochain Warrant citing the on-chain tx hash, and optionally revoke the approval. The warrant is independently verifiable: any agent can confirm the IdentityExchange event exists on Ethereum but the corresponding DHT entry does not. Alice's non-publication does not protect her regardless – Bob can still decrypt \( M \) from the on-chain ciphertext, and the regulator can obtain identity_data from the issuer.
• Re-encryption: The hApp decrypts E_alice locally (Alice has sk_alice), extracts the message point M, and re-encrypts for Bob: E_bob = (r' * G, r' * pk_bob + M). This is 2 scalar multiplications and 1 point addition – milliseconds on any device.
• Proof generation: The Chaum-Pedersen proof is a Schnorr-family sigma protocol. Generation requires 2 scalar multiplications and 1 hash – instantaneous on any modern device. Unlike Groth16 SNARK proofs (which require minutes of circuit evaluation and a trusted setup ceremony), Chaum-Pedersen proof generation is negligible.
• Receipt storage: Full encrypted receipts (with decrypted identity details, transaction metadata, purpose) are stored on both parties' Holochain source chains. The on-chain BuckTransferReceipt event provides only an anchor hash.

For a transfer from Alice to a DeFi pool operated by Bob:

The ephemeral key k_e is derived deterministically from the on-chain receipt event data (which is immutable and publicly verifiable):

// All fields are from the on-chain BuckTransferReceipt event:
receipt_anchor = abi.encode(
    from, to, amount,
    fromIdentityHash, toIdentityHash,
    block.number
)
k_e = keccak256(receipt_anchor)    // deterministic "private key"

Note: receipt_anchor contains only pseudonymous addresses and opaque hashes – no identity content. The identity public keys K_s and K_r are looked up from the IdentityRegistry (on-chain, public), not emitted in events.

The wallet (Holochain hApp) computes the encryption key via ECDH:

// Alice's hApp computes (knows k_s, k_e; looks up K_r from registry):
K_r = identityRegistry.getIdentityKey(to)     // Bob's identity public key
shared_1 = ECDH(k_s, K_r)          // sender-receiver shared secret
shared_2 = ECDH(k_e, K_r)          // ephemeral-receiver shared secret
encryption_key = keccak256(shared_1 || shared_2)

// Construct the full receipt with decrypted identity data:
full_receipt = {
    from, to, amount, block.number, tx_hash,   // from on-chain event
    sender_identity:   decrypt(E_alice),         // from Alice's source chain
    receiver_identity: decrypt(E_bob_for_alice), // from Bob's approve
    purpose: "Uniswap V3 BUCK->USDT swap"
}

// Encrypt:
ciphertext = AES-GCM(encryption_key, encode(full_receipt))

The encrypted receipt is stored on Holochain (both parties' source chains). A commitment hash can optionally be emitted on-chain to anchor the receipt:

event ReceiptCommitment(
    bytes32 indexed transferHash,    // hash of the BuckTransferReceipt event
    bytes32 receiptHash              // hash of the encrypted full receipt
);

Alice:
  1. Completed KYC with trusted issuer (off-chain ceremony)
  2. Issuer PS-signs Alice's identity: sigma = PS.Sign(sk_issuer, m)
     where m = H(identity_data)
  3. Alice receives (m, sigma) and stores in Holochain wallet
  4. Alice's wallet derives a credential for this account (offline):
     - Presents the PS signature: (A, B) = (a * sigma_1, a * sigma_2 + b * Y1)
     - Generates fresh identity key pair (sk_alice, pk_alice)
     - Encrypts: E_alice = (r * G,  m * G + r * pk_alice)
     - Computes NIZK proof pi linking (A, B) to E_alice and pk_alice
  5. Registers on-chain (443,892 gas measured):
     identityRegistry.register(
         issuer, pk_alice, E_alice, (A, B), pi)   // msg.sender = alice_wallet
  6. identityRegistry.isVerified(alice_wallet) == true

Pool operator Bob:
  1. Completed KYC (same ceremony as Alice).  His EOA is registered
     in IdentityRegistry with credential (pk_bob, E_bob).
  2. As the factory's registered feeToSetter, creates and binds the pair:
     uniswapV2BindingAdapter.createPairAndBind(BUCK, USDT)
     -> pair at address 0xPOOL bound under Bob's published (pk, E),
        with isPublicIdentity[0xPOOL] = true and
        isVerified[0xPOOL]       = true.
     Atomic create+bind leaves no interval for a competing binding; the
     registry accepts it only from the audited adapter approved for that factory.

After binding:
  isVerified(0xPOOL)       == true
  isPublicIdentity(0xPOOL) == true
  identityHash(0xPOOL)     == keccak(pk_bob, E_bob)
  -- Bob's EOA secret key sk_bob decrypts every ciphertext that
     uses the pool's bound identity.

A flash loan borrows and repays in a single transaction. The borrower's address must be verified, and the lending contract must be registered. The receipt covers the full borrow-repay cycle as a single atomic event.

A swap routed through BUCK -> WETH -> USDT involves two BUCK transfers (BUCK -> pool1, pool1 -> pool2 if intermediate). Each BUCK transfer generates its own encrypted receipt. The router contract must also be registered if it holds BUCK transiently.

When one DeFi contract sends BUCK to another (e.g., a yield aggregator moving BUCK between pools), both contracts must be registered. The receipt identifies both contracts' deployers as the parties. This creates a clear chain of custody: every BUCK movement has an identified legal operator at each end.

If BUCK is wrapped (WBUCK) for use on another chain, the wrapping contract must be registered. The wrap/unwrap generates receipts. On the destination chain, the bridged BUCK may operate under different identity rules (or no identity rules if the destination chain doesn't enforce ERC-3643). This is a known limitation – the Alberta Buck's identity guarantees only hold on chains where the IdentityRegistry is deployed.

The design has three gas-consuming identity operations:

Credential registration uses the ecPairing precompile to verify the Pointcheval-Sanders credential proof (443,892 gas measured on the A' branch, once per account). The Chaum-Pedersen proof verification uses ecMul / ecAdd (~29,000 gas per counterparty pair). Subsequent transfers emit only the minimal receipt event (~2,000 gas) with no additional proof work.

All encrypted identity data and full receipts are stored on Holochain, not on Ethereum. The only identity-related data emitted on-chain is the compact ElGamal ciphertext (4 curve coordinates = 128 bytes of calldata) during approve, and two bytes32 hashes during each transfer.

Under bindContract, the pool's identity is the operator's identity. isVerified(0xPOOL) == true and isPublicIdentity(0xPOOL) == true once the factory-specific adapter has bound the canonical pool to the operator's published (pk, E). The pool itself holds no decryption key; the operator does, and the operator's sk decrypts every receipt that uses _identityHash(pool).

Provenance, authority, and one-shot binding. The Uniswap adapters verify the pool against the immutable factory's canonical mapping and require the invocation from its current registered governance identity (feeToSetter for V2, owner for V3). They can create and bind atomically or bind an existing canonical pool. The first authorized binding remains final, but neither an unrelated caller nor a generic factory can select the target.

The registry records binderOf and the credential issuer. Once bound, the certified operator identity behind (pk_op,E_op) is the pool's accountability surface.

For commercial DeFi operators who want public branding ("DeFi Ops Inc., Alberta"), publication happens off-chain (their own website, the IdentityRegistry's optional plaintextIdentity claim on the operator's EOA, social channels) – bindContract supplies the on-chain link between contract and operator credential.

The alt_bn128 curve (BN254) offers ~128-bit security for discrete logarithm in G_1 but only ~100-bit security against pairing-based attacks, due to Kim-Barbulescu tower-NFS improvements (2016) to the Number Field Sieve in extension fields. This affects the PS signature verification (which uses pairings at registration) but not the Chaum-Pedersen proof (which uses only G_1 scalar multiplications at transaction time and remains at full ~128-bit security).

This is not specific to Alberta Buck. Every Ethereum application using the ecPairing precompile – Groth16 SNARK verifiers (zkSync, Polygon zkEVM), BLS signature schemes, any pairing-based construction – faces the same constraint. The alt_bn128 precompiles are the only pairing-capable curve available on-chain until EIP-2537 (BLS12-381 precompiles) is deployed.

Three mitigations apply:

1. A pairing break forges registrations, not certification: PS signatures are verified once, at registration. Everything that needs a person in good standing – Notes spends, attribute checks, the insurer gate – proves membership in a registry's subtree, which the registry fills from its own KYC records, not from the pairing. An attacker who forges a credential registers accounts that no registry has certified.
2. DLog security is unaffected: Per-transaction Chaum-Pedersen proofs rely on discrete logarithm hardness in G_1, which remains at ~128-bit security. An attacker who breaks pairings cannot forge re-encryption proofs or decrypt ElGamal ciphertexts.
3. BLS12-381 migration path: EIP-2537 introduces precompiles for BLS12-381 (~128-bit pairing security). When deployed, credential registration migrates to BLS12-381 for PS verification while the Chaum-Pedersen layer continues on alt_bn128 (or also migrates). The architecture's separation of registration-time pairings from transaction-time scalar multiplications makes this migration straightforward – only the register verifier changes.

The ~100-bit pairing security is adequate for the current threat model. The practical cost of a tower-NFS attack on BN254 pairings remains far beyond the value of any single Alberta Buck credential, particularly since a forged one earns no registry certification. The system shares this constraint with the entire Ethereum L2 scaling ecosystem.

In this approach, the issuer stores a Pedersen commitment C = v*G + r*H on-chain. Alice proves in zero knowledge (via a Groth16 SNARK) that her re-encrypted ciphertext E_bob encrypts the same value v committed in C.

Advantages:

• Extremely flexible: the ZK circuit can prove arbitrary predicates alongside re-encryption correctness (age > 18, jurisdiction membership, credit score in range, etc.)
• Information-theoretically hiding (Pedersen commitments hide v perfectly, vs. ElGamal's computational hiding)
• Well-supported toolchain (circom, snarkjs, Hardhat plugins)

Why Chaum-Pedersen is superior for Alberta Buck:

• Gas cost: Groth16 verification requires the ecPairing precompile (~113,000 gas base + per-pair costs), totaling ~200,000-300,000 gas. Chaum-Pedersen costs ~29,000 gas – 7-10x cheaper.
• Trusted setup: Groth16 requires a multi-party computation ceremony to generate proving/verification keys. A compromised ceremony allows forged proofs – the one thing the system cannot tolerate. Chaum-Pedersen has no setup of any kind.
• Proof generation time: Groth16 proof generation takes seconds to minutes (circuit evaluation, witness computation, FFTs over large fields). Chaum-Pedersen proof generation is 2 scalar multiplications and 1 hash – milliseconds on a phone.
• Complexity: Groth16 requires circuit definition (R1CS/circom), a prover library, and careful constraint engineering. A bug in the circuit silently compromises soundness. Chaum-Pedersen is ~50 lines of elliptic curve arithmetic with a well-understood security proof.
• Unnecessary generality: Alberta Buck needs exactly one thing: proof that two ElGamal ciphertexts encrypt the same message point. Groth16 can prove anything in NP; that generality is wasted here and only adds attack surface.

In PRE, Alice generates a re-encryption key rk_{A->B} that allows an untrusted proxy to transform E_alice into E_bob without decrypting. Umbral includes NIZK proofs of correct re-encryption.

Advantages:

• Alice does not need to be online at re-encryption time (the proxy acts on her behalf)
• Threshold PRE distributes trust across multiple proxies (no single point of compromise)
• Algebraic NIZK proofs are efficient (comparable gas cost to Chaum-Pedersen)

Why Chaum-Pedersen is superior for Alberta Buck:

• Alice is always online: in the Alberta Buck model, Alice calls approve directly – she is necessarily online. The proxy delegation feature of PRE is unnecessary complexity.
• No proxy metadata leakage: even with threshold PRE, the proxies learn metadata (who is re-encrypting for whom, how often). Direct re-encryption eliminates this metadata channel entirely.
• Simpler key management: PRE requires generating and distributing re-encryption keys per counterparty pair. Direct ElGamal re-encryption uses only the existing identity key pairs already registered on-chain.
• Protocol complexity: Umbral manages capsules, key fragments, and proxy coordination. Direct re-encryption with Chaum-Pedersen is two scalar multiplications and a sigma protocol – no capsules, no fragments, no proxies.
• PRE remains valuable in other contexts (e.g., encrypted email where the sender may be offline), but Alberta Buck's on-chain interaction model makes it unnecessary.

BBS+ (pairing-based multi-message signatures) allows an issuer to sign a vector of attributes. Alice can selectively disclose specific attributes while hiding others, with ZK proofs of signature validity. The W3C Verifiable Credentials standard is converging on BBS+ for exactly this use case.

Advantages:

• Attribute-level granularity: prove "jurisdiction = Alberta" without revealing name or ID number
• Unlinkable presentations (different proofs from the same credential cannot be correlated)
• Ecosystem alignment with W3C VC / DID standards

Why Chaum-Pedersen is superior for Alberta Buck:

• Gas cost: BBS+ verification requires pairing operations (~113,000+ gas). Chaum-Pedersen uses only scalar multiplications (~29,000 gas).
• Selective disclosure is the wrong primitive: Alberta Buck transfers require the full identity to be re-encrypted for the counterparty (for court-recoverable receipts). Selective attribute hiding would defeat the purpose: the counterparty needs the whole identity, and a court needs the whole identity.
• Different trust model: BBS+ proves "I hold a valid credential with these properties." Alberta Buck needs "this ciphertext contains my specific issuer-certified identity." The latter is a re-encryption correctness proof, not a selective disclosure proof.
• Cross-account unlinkability is addressed by the A' presentation: Pointcheval-Sanders signatures, blinded into a presentation, provide unlinkable credential derivation for different accounts (rerandomization alone does not: a rerandomized signature is testable by anyone holding the identity scalar). Within a single account, re-encryptions share a common Ethereum address regardless of the credential scheme, so BBS+ presentation unlinkability adds nothing.
• BBS+ could complement Chaum-Pedersen in the future – e.g., for compliance checks that verify jurisdiction eligibility without full identity disclosure. But it does not replace the core re-encryption mechanism.

A purpose-built primitive: encrypt a value and simultaneously prove that the plaintext satisfies a public relation, without revealing it.

Advantages:

• Theoretically clean: directly solves "encrypt for Bob, prove to everyone it's the right value"
• Can prove arbitrary relations on the encrypted plaintext

Why Chaum-Pedersen is superior for Alberta Buck:

• Camenisch-Shoup is the general framework; Chaum-Pedersen is its optimal specialization for the "same plaintext" relation. When the relation is "same plaintext as another ElGamal ciphertext in the same group," the Chaum-Pedersen protocol is the canonical, minimal-cost instantiation.
• General Camenisch-Shoup constructions are more complex and less efficient.

Pedersen commitments support homomorphic equality checking: given C_1 = v*G + r_1*H and C_2 = v*G + r_2*H, revealing delta_r = r_1 - r_2 lets the verifier check C_1 - C_2 == delta_r * H without learning v.

Advantages:

• Extremely cheap (1 point addition, 1 scalar multiplication)
• Information-theoretically hiding

Why this is insufficient for Alberta Buck:

• Pedersen commitments are commitments, not encryptions. They hide the value but do not allow a specific party to decrypt. Alberta Buck needs Bob to recover Alice's identity, not just to verify that two opaque commitments match. ElGamal provides both hiding and targeted decryption.
• Revealing delta_r to prove equality leaks the randomness difference, which is acceptable for on-chain verification but means the commitment scheme cannot support multiple independent equality proofs without additional blinding (each proof leaks one linear relation on the randomness).

ElGamal Chaum-Pedersen wins on per-transaction gas cost, has zero setup requirements, generates proofs instantly, supports targeted decryption, and requires minimal implementation. Combined with the Pointcheval-Sanders credential presentation for credential derivation (443,892 gas measured, once at registration), the system achieves both cross-account unlinkability and per-transaction re-encryption correctness – without the gas burden or trusted setup of SNARK-based alternatives.