The Alberta Buck - Identity and Receipts (v1.0)

A citizen with income, savings, inheritance, and walking-around-money accounts should not have those accounts linkable to each other by any outside observer. Ethereum balances are public; if all of Alice's accounts trace back to the same identity credential, her entire financial life is exposed to anyone who notices the link.

The identity fountain solves this. It gives every citizen the ability to derive unlimited, unlinkable identity credentials – each independently verifiable as issued by the same authority – from a single KYC ceremony. The construction uses Pointcheval-Sanders (PS) rerandomizable signatures² over the alt_bn128 curve.

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
})

identityRegistry.registerCredential(
    alice_new_address,
    pk_new,          // identity public key
    E_new,           // ElGamal ciphertext (4 uint256)
    sigma_prime,     // rerandomized PS signature (2 G_1 points)
    pi               // NIZK proof linking sigma' to E_new
)

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))
  Rerandomized PS signature sigma' verified 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"

Statement 3 is the core. The left side decrypts E_alice (only Alice can compute this, since she knows sk_alice), yielding the message point M. The right side extracts M from E_bob (only Bob could alternatively compute this with sk_bob). If Alice encrypted different data I_fake, then I * G != I_fake * G and no valid proof exists – it is not merely hard to compute, it is mathematically impossible under the discrete logarithm assumption.

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)    -- Fiat-Shamir challenge and responses

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

Critical implementation requirement: E_alice is read from on-chain storage (the IdentityRegistry), not supplied by Alice as calldata. This anchors the proof to the registered credential. If Alice could supply her own E_alice, she could substitute a fake credential and produce a valid proof against it.

The Fiat-Shamir challenge must bind all public inputs and context to prevent replay and malleability:

e = H(G, pk_alice, pk_bob, R_a, C_a, R_b, C_b, T1, T2,
      msg.sender, spender, block.chainid)

Including msg.sender and spender (Ethereum addresses) binds the proof to the specific transaction context. Including block.chainid prevents cross-chain replay. On-chain, msg.sender is authenticated by ECDSA and spender is a calldata argument to approve(), but including them in the hash explicitly prevents a proof generated for one (sender, spender) pair from being replayed in another context. This is standard Fiat-Shamir domain separation, not an additional cryptographic assumption.

Alice is a sanctioned individual. She completed KYC under her real identity and received a legitimate PS-verified credential E_alice containing her true identity I. She now wants to transact with Bob but wants Bob (and any future court) to believe she is someone else – say, her clean associate Carol.

Alice constructs a fake re-encryption using Carol's identity I_fake:

E_bob_fake = (r' * G,  r' * pk_bob + I_fake * G)

She submits E_bob_fake to approve() and attempts to produce a Chaum-Pedersen proof tying it to her registry credential.

The Chaum-Pedersen verification checks:

C_a - sk_alice * R_a  ==  C_b - r' * pk_bob

Expanding the left side (from the registered E_alice in the registry):

(r_a * pk_alice + I * G) - sk_alice * (r_a * G)
  = r_a * sk_alice * G + I * G - sk_alice * r_a * G
  = I * G

Expanding the right side (from Alice's fake E_bob):

(r' * pk_bob + I_fake * G) - r' * pk_bob
  = I_fake * G

The proof requires I * G == I_fake * G, which requires I == I_fake. Since I != I_fake (Alice is not Carol), these are distinct curve points. Under the discrete logarithm assumption, Alice cannot produce valid proof scalars (s1, s2) that satisfy the verification equations. The proof does not exist – not "hard to find," but mathematically non-existent.

approve() reverts: "Re-encryption proof invalid." The transaction fails on-chain. Alice cannot complete the identity handshake with false data. The revert is indistinguishable from a malformed transaction – no information about Alice's intent leaks.

She wasted gas on a failed transaction. Her address is still associated with her real registered credential in the registry. Nothing has changed.

Alice never completed KYC, or completed KYC but wants a credential with different identity data. She picks a fabricated identity scalar m_fake = H(fake_data), generates a random PS-like signature, creates an ElGamal ciphertext, and fabricates a NIZK proof:

m_fake       = H("Carol Smith, Alberta, ...")
sigma_fake   = (random_h, random_s)         -- not a valid PS signature
E_alice_fake = (r * G,  m_fake * G + r * pk_alice)
pi_fake      = ...                          -- fabricated NIZK

She attempts to register this credential in the IdentityRegistry.

The IdentityRegistry verifies the Pointcheval-Sanders signature against trusted issuer public keys registered in the TrustedIssuersRegistry (part of the ERC-3643 framework⁶). Registration checks the pairing equation:

e(sigma'_1, X + m * Y) == e(sigma'_2, g_2)

where (X, Y) is the trusted issuer's public key in G_2. Alice does not know the issuer's secret key (x, y), so she cannot produce a sigma' that satisfies this equation for any m – let alone for m_fake. The PS signature is unforgeable under the q-SDH assumption.

Even if Alice could somehow produce a valid-looking PS signature (she cannot), the NIZK proof pi must prove that the ElGamal ciphertext E_alice encrypts the same m that the PS signature covers. Forging the proof requires breaking the discrete logarithm assumption.

Two independent barriers must both be broken. Neither has been broken in the history of elliptic curve cryptography.

registerCredential() reverts: "Invalid issuer signature." Alice is not registered; isVerified(alice) == false. She cannot participate in any BUCK operation requiring identity.

Alice and Bob are both criminals. Both have legitimate PS-verified credentials (they passed KYC under their real identities). They want to transact with each other, but want the encrypted identity records to show different people – so that if a court later compels Bob to decrypt Alice's identity blob, it points to an innocent third party.

They agree: Alice will encrypt a false identity I_fake for Bob and submit it. Bob will claim (if asked) that the decrypted identity is genuine.

Alice's approve() call must pass Chaum-Pedersen verification. The contract reads E_alice from the IdentityRegistry – not from Alice's calldata.

// Inside approve():
E_alice = identityRegistry.getCredential(msg.sender);
require(chaumPedersenVerify(E_alice, E_bob_submitted, proof));

Alice cannot substitute a different E_alice because the contract reads it from storage. She cannot produce a valid Chaum-Pedersen proof linking her fake E_bob to the real E_alice because the message points differ (same math as Attack 1).

Bob's willingness to accept false data is irrelevant. The proof was verified against the registered credential before E_bob was stored. If approve() succeeded, E_bob necessarily contains Alice's real identity. When a court later compels Bob to decrypt, he produces Alice's true identity – regardless of any prior agreement between them.

Bob cannot produce a different plaintext from the same E_bob (ElGamal decryption is deterministic given the private key). Bob cannot claim the E_bob is unrelated to Alice (the on-chain IdentityExchange event records that Alice submitted it during approve, and the proof verification succeeded).

If Alice submits false data: approve() reverts ("Re-encryption proof invalid") – same as Attack 1.

If Alice submits real data (because she has no choice): approve() succeeds, and E_bob provably contains her real identity. The laundering scheme fails silently – Alice and Bob transacted, but the identity trail is genuine and court-recoverable.

Alice transacted legitimately with Bob (a law-abiding merchant). Later, Alice is investigated. She claims she never transacted with Bob, or that the identity Bob received was fabricated by Bob. Alice hopes that because the re-encrypted blob is opaque to everyone except Bob, a court cannot verify its authenticity without trusting Bob's word.

The on-chain record contains everything needed to verify, without trusting Bob:

1. The IdentityExchange(alice, bob, E_bob) event is on-chain, emitted during Alice's approve() call. It was sent from Alice's address (verified by msg.sender).
2. The approve() transaction succeeded on-chain, which means the Chaum-Pedersen proof verified against Alice's registered E_alice from the registry. This is an immutable execution fact.
3. Therefore E_bob provably encrypts the same identity as E_alice. This follows from the soundness of the Chaum-Pedersen protocol – it is a mathematical fact, not testimony.
4. When the court compels Bob to decrypt E_bob, the resulting plaintext I is provably Alice's issuer-certified identity. The chain of trust:

Issuer PS-signed Alice's identity m           (verified at registration)
E_alice stored in IdentityRegistry            (on-chain, immutable)
Alice called approve() with E_bob + proof     (on-chain tx, msg.sender = alice)
Chaum-Pedersen proof verified on-chain         (execution succeeded)
==> E_bob encrypts Alice's real identity       (mathematical fact)
Bob decrypts E_bob --> I                       (compelled, deterministic)
I is Alice's issuer-certified identity         (proven)

An unbroken, cryptographically verified chain from issuer to decrypted identity. Alice's repudiation is contradicted by on-chain proof verification records that she cannot alter or dispute.

Bob is a criminal merchant. Alice (law-abiding) transacted with Bob. Authorities investigate Bob. Bob claims he never received Alice's identity and cannot produce it – hoping to deny knowledge of his counterparties, or to shield Alice from being identified as his customer.

The IdentityExchange(alice, bob, E_bob) event is on-chain and immutable. The court retrieves E_bob directly from the blockchain – Bob's cooperation is not needed to find the ciphertext.

Bob is compelled to decrypt:

M = C_b - sk_bob * R_b

If Bob claims he "lost" his identity private key (the alt_bn128 key, which is distinct from his Ethereum signing key):

• The court holds Bob in contempt, as it would for any refusal to produce subpoenaed records. "I lost the key" is no more credible for a cryptographic key than for a filing cabinet – particularly when the key was generated during a KYC ceremony and Bob accepted transactions requiring its use.
• Even without Bob's cooperation, the court can establish from the on-chain proof verification that E_bob does contain a genuine identity. Bob's refusal to decrypt is itself evidence of obstruction.

Bob cannot claim E_bob is meaningless or fabricated: the successful Chaum-Pedersen proof verification is an on-chain fact.

E_bob is on-chain. The proof that it contains Alice's real identity is on-chain. Bob decrypts or faces contempt. The cryptographic record is self-authenticating.

Eve is a surveillance actor (competitor, stalker, rogue state). She observes that Alice's address called approve for multiple counterparties: Bob, Carol, and Dave. Eve collects the IdentityExchange events:

IdentityExchange(alice_addr, bob_addr,   E_bob)
IdentityExchange(alice_addr, carol_addr, E_carol)
IdentityExchange(alice_addr, dave_addr,  E_dave)

Eve wants to learn Alice's real identity, or to determine whether these transactions reveal a pattern (e.g., Alice's spending habits).

Each re-encryption uses independent randomness:

E_bob   = (r_1 * G,  r_1 * pk_bob   + I * G)
E_carol = (r_2 * G,  r_2 * pk_carol + I * G)
E_dave  = (r_3 * G,  r_3 * pk_dave  + I * G)

The ciphertexts are IND-CPA secure (semantic security of ElGamal): each is computationally indistinguishable from a random pair of curve points. Eve cannot decrypt any of them without the counterparty's private key. She cannot determine from the ciphertexts alone what identity they encode, nor can she compare them to determine if they encode the same identity.

What Eve does know: all three events originate from alice_addr. But this is exactly the information already visible in standard ERC-20 Approval events. The encrypted identity blobs add zero additional linkability beyond Ethereum's inherent pseudonymous address model.

What Eve does not know: Alice's name, jurisdiction, ID number, or any attribute of her identity. She sees an address; she does not see a person.

Pseudonymous Ethereum addresses and opaque ciphertexts that are computationally indistinguishable from random. The same view she has of any ERC-20 token, plus meaningless (to her) encrypted blobs.

A stronger version of this attack: Eve suspects that addresses addr_1, addr_2, and addr_3 all belong to Alice. She examines each address's registered credential in the IdentityRegistry.

Each credential was derived independently through the Identity Fountain: different rerandomized PS signatures, different identity key pairs, different ElGamal ciphertexts with independent randomness. PS rerandomization is statistically unlinkable – not merely computationally hard to correlate, but information-theoretically impossible. The credentials contain zero bits of mutual information.

Eve's only path to linking accounts is off-chain analysis: timing, amounts, behavioral patterns. The cryptographic identity layer gives her nothing.

Alberta Buck provides identity privacy (no observer can determine who owns an address from the credential) and credential unlinkability (no observer can cryptographically link two credentials to the same person). It does not provide transaction graph privacy: Ethereum balances and transfer events are public, and standard chain-analysis techniques – timing correlation, amount matching, funding-source tracing – apply to BUCK as they do to any ERC-20 token.

Transaction graph privacy is a distinct problem solved by different primitives (confidential transactions, mixing protocols, or fully shielded transfers as in Zcash). These are orthogonal to the identity layer and could complement it in the future. The identity system's guarantee is narrower but sufficient: even if Eve links Alice's addresses through behavioral analysis, she cannot learn Alice's name or identity data from any on-chain artifact. The cryptographic identity layer ensures that linking addresses reveals spending patterns, not people.

A natural concern: if Alice derives ten accounts from the Identity Fountain, and each counterparty who decrypts their re-encrypted ciphertext recovers the same \( M = m \cdot G \), doesn't that break unlinkability?

No. The identity scalar \( m = H(\text{identity\_data}) \) is intentionally invariant because it is Alice's identity. If each account used a different \( m \), the two-channel verification would break: Bob couldn't verify that the identity_data he received matches what the issuer certified. The Identity Fountain protects the credential wrapping (\( \sigma' \), \( pk \), \( E \)), not the identity scalar itself.

The privacy boundary is:

Before approve, Alice's accounts are unlinkable to everyone. After approve, only that specific counterparty learns Alice's identity for that account. Counterparties who already know Alice's name gain nothing new from comparing \( M \) values.

See the worked example for the full argument and the AMM pool subpoena scenario.

Alice's identity credential was revoked by the issuer (e.g., her Alberta residency expired, fraud was detected in her original KYC documents, or she is subject to new sanctions). Alice still holds her old E_alice and sigma and attempts to continue transacting.

The IdentityRegistry tracks credential validity. When the issuer revokes Alice's credential:

identityRegistry.revokeIdentity(alice_address)

Subsequent calls to isVerified(alice) return false. Alice's approve call – and any transfer or transferFrom – reverts at the identity check, before the Chaum-Pedersen proof is even evaluated.

Alice's old credential and proofs remain mathematically valid (the cryptography is eternal), but the contract refuses to accept them because her registration is no longer active. The revocation is a separate on-chain state, controlled by the trusted issuer.

isVerified(alice) == false. Transaction reverts immediately. The still-valid-but-revoked credential is never consulted.

Bob is a law-abiding merchant running a BUCK-accepting storefront. Alice is a criminal who passed KYC (perhaps before she was sanctioned, or under a jurisdiction that has not yet flagged her). Alice sends BUCK to Bob through a normal transaction. Bob has no way to know Alice is a criminal at the time of the transaction.

Later, authorities investigate Alice. Bob is concerned: did he unknowingly participate in money laundering? Can Alice's identity in the receipt exonerate him?

Bob received Alice's re-encrypted identity E_bob during the approve handshake (or Bob pre-approved Alice via approve(alice, 0, ...) to receive from her). The Chaum-Pedersen proof verified on-chain, so E_bob provably contains Alice's real, issuer-certified identity.

When authorities investigate:

1. Bob decrypts E_bob and produces Alice's identity I.
2. The on-chain proof record establishes that I is genuine (not something Bob fabricated to frame Alice, and not something Alice fabricated to deceive Bob).
3. Bob can demonstrate he had no way to know Alice was a criminal: the identity he received was a valid, PS-verified credential at the time of the transaction. The revocation (if any) came later.
4. Bob's good faith is supported by the cryptographic record: he accepted a transaction from a verified participant and holds a court-presentable receipt.

The system protects honest participants by creating a tamper-proof record of who they transacted with. Bob is not liable for Alice's criminality; he is protected by the same cryptographic chain that convicts Alice.

Bob holds a provably genuine receipt. Alice's identity was valid at transaction time. Bob acted in good faith. The receipt is evidence of Bob's compliance, not his complicity.

Alice has (m, sigma_1, sigma_2) from the issuer. She produces sigma' = (t * sigma_1, t * sigma_2).

Can she produce a sigma' that signs a different m_fake?

PS verification checks:

e(sigma'_1, X + m * Y) = e(sigma'_2, g_2)

Rearranging:

e(sigma'_1, Y)^m  =  e(sigma'_2, g_2) * e(sigma'_1, X)^(-1)

The right side is fixed by sigma' (which Alice chose). The left side is determined by m. For sigma' derived from the issuer's signature on m, this equation holds only for the real m. Alice cannot produce a valid PS signature on any m_fake without the issuer's secret key (x, y). Blocked by q-SDH unforgeability.

Alice provides (sigma', E_new, pk_new, pi). The NIZK proof proves knowledge of (m, r) satisfying:

a) e(sigma'_1, X + m * Y) = e(sigma'_2, g_2)   -- sigma' signs m
b) C = m * G + r * pk_new                       -- E_new encrypts m
c) R = r * G                                    -- consistent randomness

Can she use a valid sigma' (signing m) but create E_new encrypting m_fake?

The sigma protocol uses a single response scalar s_m that must simultaneously satisfy conditions (a) and (b):

• For condition (a): s_m encodes the real m (the value sigma' signs)
• For condition (b): s_m encodes whatever is in E_new

If E_new encrypts m_fake != m, no single s_m satisfies both checks. Blocked by sigma protocol soundness.

Can she forge the Fiat-Shamir challenge? The challenge e = H(sigma', E_new, pk_new, commitments) depends on all public inputs. Finding inputs that yield a favorable challenge requires a keccak256 preimage attack. Blocked by random oracle assumption.

At approve() time, Alice provides E_bob and a Chaum-Pedersen proof. The contract reads E_alice from storage.

Can she re-encrypt a different identity? The proof requires:

C_a - sk_alice * R_a  =  C_b - r_b * pk_bob

Both sides must equal the same message point M = m * G. If Alice encrypts M_fake != M, the equation is unsatisfiable. Blocked by DLog hardness. (Same mathematics as Attack 1.)

Can she supply a different E_alice? No – read from storage, not from calldata.

If Alice sets sigma' = (O, O) where O is the point at infinity:

e(O, X + m * Y) = 1   (pairing with identity is trivial)
e(O, g_2)       = 1   (same)

The pairing equation 1 = 1 holds for any m. Alice could register a credential encrypting any m_fake she wants, produce a valid-looking NIZK proof (because condition (a) is trivially satisfied), and the verification would pass.

She achieves this by picking t = 0 in the rerandomization: sigma' = (0 * sigma_1, 0 * sigma_2) = (O, O).

The fix is standard: the PS signature specification requires sigma'_1 != O. The registration contract must check this before evaluating the pairing:

require(sigma_prime[0] != 0 || sigma_prime[1] != 0, "Degenerate signature");

On BN254, G_1 has prime order (cofactor 1), so there are no small-order points. The identity check sigma'_1 != O is the only degenerate case.

Without this check, the entire fountain is broken. With it, the system is sound.

Off-curve points: post-Istanbul, the ecPairing precompile validates that inputs lie on alt_bn128 and reverts otherwise. Alice cannot use off-curve points to confuse the pairing computation.

Subgroup attacks on G_2: the ecPairing precompile validates G_2 subgroup membership (EIP-197). Alice cannot exploit small subgroups in the twist curve.

Eve copies Alice's registered credential: Eve can read (pk, E, sigma', pi) from the chain and re-register it for her own address. But Eve cannot use it – the Chaum-Pedersen proof requires knowledge of sk_alice (condition 1: pk_alice = sk_alice * G). A stolen credential is useless without the corresponding secret key.

Alice shares raw credential material: Alice can give (m, sigma) to an accomplice, who can then derive valid credentials containing Alice's identity. But the decrypted identity is always Alice's – the consequences fall on her. This is inherent in any bearer credential system; it is no different from handing someone your driver's license.

The system is sound against an untrustworthy Alice who is willing to lie about every artifact she produces. She cannot forge any artifact that would cause a verifier to accept a false identity. The three layers – PS unforgeability, NIZK soundness, Chaum-Pedersen soundness – chain together so that breaking any link requires breaking a standard hardness assumption.

One critical implementation requirement: sigma'_1 != O must be checked at credential registration. This is a standard requirement of the Pointcheval-Sanders scheme and costs negligible gas.

The transfer and transferFrom functions require that both parties' identities are available to each other. For private accounts, this means both must call approve:

// 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

Both identity fragments must exist before BUCK can move. If Bob is a public account (e.g., a Uniswap pool operator), step 2 is unnecessary: isPublic(bob) == true satisfies the bilateral check, and Alice can look up Bob's identity_data directly from the IdentityRegistry.

This means a public pool operator receives BUCK from any verified private account that has done a single approve – no per-counterparty setup on the pool's side. Two public accounts can transfer with no approve at all – a standard ERC-20 transfer with identity verification.

Both parties in a transfer hold each other's plaintext identity_data (either from approve + Holochain, or from the public IdentityRegistry). Both hold the transfer data (from the on-chain event). If the receipt format is canonical (deterministic field order, encoding), either party can independently construct the identical receipt and compute H(receipt). The receipts match without coordination.

The receipt model varies by visibility mode:

For transfers involving private accounts, the contract cannot compute H(receipt) because it never sees plaintext identities. The on-chain BuckTransferReceipt event provides anchoring data (the ElGamal ciphertext hashes from approve) that binds the off-chain receipt to the on-chain transfer.

For two public accounts, no receipt hash is needed: every input to the receipt is already public on-chain. The transfer is a standard ERC-20 transfer with identity verification – no Holochain wallet, no off-chain coordination required.

Alice does not reuse a single Holochain agent across multiple BUCK accounts. For each Ethereum address she creates, her wallet application spawns a new Holochain agent:

• A fresh Holochain key pair (Ed25519) is generated.
• A new source chain is initialized.
• The hApp DNA is the same (same code, same hash), but the agent identity is distinct.
• Alice copies her identity_data into the new agent's Private store and derives a credential from it (rerandomizing her PS signature, generating a fresh alt_bn128 key pair, encrypting via ElGamal, computing the NIZK proof).

Why agent isolation matters: Holochain's DHT uses agent public keys as identifiers. If Alice used a single Holochain agent for all her BUCK accounts, a DHT observer could correlate them: "agent X stored credentials for addresses addr_1, addr_2, addr_3." With separate agents, each agent's DHT presence is independent. No Holochain observer can link Alice_1 to Alice_2, just as no Ethereum observer can link addr_1 to addr_2.

Practical operation: Alice's wallet application (a Holochain Launcher or custom conductor) manages multiple agent instances internally. From Alice's perspective, she sees a unified wallet with multiple accounts. Under the hood, each account is a separate Holochain agent with its own source chain. The wallet stores a master seed (protected by Alice's passphrase or biometrics) from which all agent keys are deterministically derived, allowing backup and recovery without storing raw keys.

What is NOT shared across agents: Holochain key pairs, source chain entries, Ethereum addresses, alt_bn128 identity key pairs, ElGamal ciphertexts, PS signature rerandomizations, NIZK proofs. What IS shared (locally, within Alice's wallet, never on any network): Alice's plaintext identity_data and the master PS signature (m, sigma) from the issuer.

Holochain provides agent-centric, cryptographically auditable storage: the hApp DNA is identified by hash, so anyone can verify the exact code that runs on each participant's node. However, Holochain is not the trust anchor: Alice runs her own node and could run modified code. The on-chain verifications are the trust anchors – PS signature verification at registration and Chaum-Pedersen proof verification at transaction time are mathematically verifiable on-chain regardless of what software generated them. Holochain provides the execution environment; the proofs provide the guarantees.

Alice has k_s (her identity private key) and can recompute k_e from the on-chain receipt event:

k_e = keccak256(receipt_anchor)       // deterministic from on-chain data
K_r = identityRegistry.getIdentityKey(to)   // look up receiver's key
shared_1 = ECDH(k_s, K_r)            // she has k_s
shared_2 = ECDH(k_e, K_r)            // she has k_e
encryption_key = keccak256(shared_1 || shared_2)

Bob has k_r (his identity private key) and looks up Alice's identity public key from the registry:

K_e = G * k_e                         // computable: k_e from receipt anchor
K_s = identityRegistry.getIdentityKey(from)  // Alice's identity public key
shared_1 = ECDH(k_r, K_s)            // he has k_r
shared_2 = ECDH(k_r, K_e)            // he has k_r
encryption_key = keccak256(shared_1 || shared_2)

A court subpoenas Bob to decrypt a specific transaction receipt:

// Court provides: the transaction hash
// Bob looks up: the BuckTransferReceipt event from that transaction
// Bob computes (using his identity private key k_r):
K_s = identityRegistry.getIdentityKey(from)
K_e = G * keccak256(receipt_anchor)
shared_1 = ECDH(k_r, K_s)
shared_2 = ECDH(k_r, K_e)
encryption_key = keccak256(shared_1 || shared_2)
receipt = AES-GCM-decrypt(encryption_key, ciphertext_from_holochain)

Bob reveals only the decrypted receipt. He never reveals k_r. He cannot decrypt receipts where he is not a party.

A regulatory authority's public key K_reg adds a third shared secret:

shared_3 = ECDH(k_e, K_reg)
encryption_key = keccak256(shared_1 || shared_2 || shared_3)

The regulator can compute shared_3 (they have k_reg, and K_e is deterministic from the on-chain event). They can also compute shared_2 = ECDH(k_e, K_r) since the ephemeral key k_e is deterministic from public on-chain data. But they cannot compute shared_1 = ECDH(sk_sender, K_receiver) – this requires the sender's or receiver's private key. Without a participant's cooperation, the regulator holds two of three ECDH components and cannot reconstruct the encryption key. No unilateral surveillance.

This is the deliberate design: a court compels a participant to decrypt; the escrow key merely lets the regulator verify the decryption (by independently recomputing the same key once a participant cooperates). Contrast with custodial key escrow, where the authority holds a master decryption key and can surveil at O(1) cost. Here the cost is O(N) – one subpoena per participant, per transaction.

Alice's wallet (Holochain hApp) prepares the identity exchange locally, then Alice calls approve on the BUCK contract:

// 1. Off-chain (Holochain hApp on Alice's node -- milliseconds):
//    - Read E_alice from her source chain
//    - Decrypt: M = C_a - sk_alice * R_a  (extract message point)
//    - Look up the pool operator's identity public key pk_bob
//    - Re-encrypt: E_bob = (r' * G,  r' * pk_bob + M)
//    - Generate Chaum-Pedersen proof:
//        "E_bob encrypts the same M as E_alice"
//        (2 scalar muls + 1 hash -- instantaneous)

// 2. On-chain:
buck.approve(
    uniswapRouter,                     // spender
    500e18,                            // amount
    [R_b.x, R_b.y, C_b.x, C_b.y],    // E_bob (ElGamal ciphertext)
    [e, s1, s2]                        // Chaum-Pedersen proof
)

The BUCK contract:

1. Sets allowance[alice][uniswapRouter] = 500e18
2. Reads E_alice from IdentityRegistry (PS-verified, immutable)
3. Verifies Chaum-Pedersen proof: E_bob encrypts same M as E_alice
   (4 ecMul + 4 ecAdd + 1 keccak256 = ~29,000 gas)
4. Stores keccak256(E_bob) in _receiptFragments[alice][0xPOOL]
5. Emits IdentityExchange(alice, 0xPOOL, E_bob)
   -- the event contains ONLY the opaque ElGamal ciphertext
   -- no identity address, no public key, no linkable identifier

This is the critical moment. Alice is directly calling the BUCK contract, so she can provide the re-encrypted ciphertext and proof. By the time transferFrom is called later (by the router), the verified identity fragment is already stored.

Note: the pool (0xPOOL) is a public account – its identity_data is registered publicly in the IdentityRegistry. Alice's wallet can look it up directly, so the pool does not need to call approve for Alice. The bilateral identity check in transferFrom passes because isPublic(0xPOOL) == true satisfies the pool-side requirement.

// Alice initiates the swap (standard Uniswap call -- no BUCK-specific data)
uniswapRouter.exactInputSingle(
    tokenIn:  BUCK,
    tokenOut: USDT,
    fee:      3000,        // 0.3% fee tier
    recipient: alice,
    amountIn: 500e18,
    amountOutMinimum: 490e6,  // slippage protection
    sqrtPriceLimitX96: 0
)

No identity data passes through this call. The router is a standard Uniswap contract that knows nothing about BUCK identity.

Inside the router, the swap triggers:

buck.transferFrom(alice, 0xPOOL, 500e18)

The BUCK contract executes (no identity data passes through the router):

function transferFrom(address from, address to, uint256 amount) ...
{
    _spendAllowance(from, msg.sender, amount);
    require(identityRegistry.isVerified(from), "Sender not verified");
    require(identityRegistry.isVerified(to),   "Receiver not verified");
    require(compliance.canTransfer(from, to, amount), "Compliance");

    _transfer(from, to, amount);
    compliance.transferred(from, to, amount);

    // Emit minimal receipt -- ONLY hashes of pre-stored ElGamal ciphertexts
    emit BuckTransferReceipt(
        from, to, amount,
        _receiptFragments[from][to],     // keccak256 of Alice's E_bob
        _receiptFragments[to][from]       // keccak256 of Bob's E_alice
    );

    return true;
}

What the public sees: the same from/to/amount as the standard ERC-20 Transfer event, plus two opaque hashes. No identity addresses. No public keys. No linkable identity information beyond the pseudonymous Ethereum addresses.

What the contract verified (during approve, earlier): the Chaum-Pedersen proof that Alice's re-encrypted ElGamal ciphertext encrypts the same identity as her registered credential.

Alice's wallet (Holochain hApp) observes the BuckTransferReceipt event and the IdentityExchange events to construct the full receipt:

// 1. From on-chain events (trusted, immutable):
transfer_data = {from, to, amount, block.number, tx_hash}
receipt_hashes = {fromIdentityHash, toIdentityHash}

// 2. From IdentityExchange event (emitted during approve):
E_bob = Alice's re-encrypted identity for Bob (ElGamal ciphertext)

// 3. Alice already knows her own identity (she submitted it at KYC):
alice_identity = alice_identity_data   // local, never on-chain

// 4. From Bob's IdentityExchange (if Bob also did approve for Alice):
E_alice_from_bob = Bob's re-encrypted identity for Alice
M_bob = C_b' - sk_alice * R_b'    // Alice decrypts with her key
bob_identity_data = receive_via_holochain(bob)  // off-chain data channel
assert H(bob_identity_data) * G == M_bob        // bind to on-chain proof

// 5. Construct full receipt with decrypted identities
full_receipt = {
    transfer:      transfer_data,
    sender_name:   alice_identity.name,      // "Alice Johnson"
    receiver_name: bob_identity.name,         // "Bob Smith, DeFi Ops Inc."
    operation:     "Uniswap V3 swap BUCK -> USDT",
    pool:          "0xPOOL",
    timestamp:     block.timestamp
}

// 6. Encrypt the full receipt with 3-party ECDH
//    (see Cryptographic Receipts section)
receipt_anchor = abi.encode(from, to, amount, receipt_hashes, block.number)
k_e = keccak256(receipt_anchor)
K_bob = identityRegistry.getIdentityKey(to)  // look up from registry
shared_1 = ECDH(sk_alice, K_bob)
shared_2 = ECDH(k_e, K_bob)
encryption_key = keccak256(shared_1 || shared_2)
ciphertext = AES-GCM(encryption_key, encode(full_receipt))

// 7. Store on Holochain (both parties' source chains)
holochain.store(alice_chain, ciphertext)
holochain.store(bob_chain,   ciphertext)

The Uniswap pool sends USDT to Alice. Since USDT is not an Alberta Buck token, the USDT transfer has no BUCK identity requirements (it follows whatever rules USDT imposes, which is typically none).

On-chain (public):
  - ERC-20 Transfer event: alice_addr -> 0xPOOL, 500 BUCK
  - BuckTransferReceipt: same addresses + two opaque bytes32 hashes
  - IdentityExchange (from approve): alice_addr + opaque ElGamal ciphertext
  - Swap event: BUCK/USDT pool, 500 BUCK in, ~495 USDT out
  - Chaum-Pedersen proof verified (29K gas, no identity content leaked)

Off-chain (Holochain, encrypted):
  - Full encrypted receipt on Alice's and Bob's source chains
  - Alice's re-encrypted identity (ElGamal ciphertext, only Bob can decrypt)
  - Bob's re-encrypted identity (ElGamal ciphertext, only Alice can decrypt)
  - PS-signed identity on issuer's source chain (audit trail)

What anyone can see:
  - Two pseudonymous addresses transacted 500 BUCK
  - Both addresses pass isVerified (they are KYC'd participants)
  - Opaque ElGamal ciphertexts and hashes (indistinguishable from random)
  - A Chaum-Pedersen proof was verified (the ciphertexts are genuine)

What Alice can see:
  - Her own identity (trivially)
  - Bob's identity (decrypt his ElGamal ciphertext with her key)
  - Full receipt with names, amounts, purpose

What Bob can see:
  - His own identity (trivially)
  - Alice's identity (decrypt her ElGamal ciphertext with his key)
  - Full receipt with names, amounts, purpose

What a court can compel (via subpoena of Bob):
  - Bob decrypts Alice's ElGamal ciphertext for the specific transaction
  - On-chain Chaum-Pedersen proof record authenticates the result
  - Reveals Alice's identity for that one receipt
  - Bob never reveals his private key

What the public CANNOT see:
  - Alice's real name or identity details
  - Bob's real name (as pool operator)
  - Any linkable identity across transactions
  - The purpose or terms of the transaction