1Introduction

Hindsight is a system for confidential USDC payments on Solana whose amounts stay sealed after Q-Day, the point at which a cryptographically relevant quantum computer can solve the discrete-logarithm problems that today's elliptic-curve cryptography rests on. Each amount is recorded on chain as a Pedersen commitment. The commitment's opening, meaning the amount together with the random scalar that blinds it, reaches two parties only: the payee and the pool's auditor. Each receives it inside an X-Wing envelope, a hybrid of X25519 and ML-KEM-768, followed by AES-256-GCM. This chapter describes the payments Hindsight is built for, the adversary it is built against, the deadlines that put a date on that adversary, what the system provides, and the overall shape of the design.

1.1Payments whose amounts outlive the payment

Hindsight is built for employers, payroll platforms, treasury teams, suppliers and stablecoin issuers that settle in USDC on Solana, a chain that held about USD 15.7 billion in stablecoins when the DefiLlama total was fetched on 2026-10-15. Their payments fall into a small number of recurring flows.

• Payroll. An employer funds a pool account and pays each employee or contractor every cycle. A salary is personal data with no expiry date, and the employer's payment pattern ties each amount to a named person.
• Supplier payments. A buyer pays invoices under multi-year contracts. The amounts disclose unit prices and volumes, which stay commercially sensitive for the life of the contract and after it.
• Treasury movements. A company moves funds between its own entities, counterparties and hedging venues. Treasury and hedging positions, confidential legal settlements and advisory fees paid before an M&A announcement belong to the same class.

Most retail payment amounts lose their value within weeks. These keep it for ten years or more. On a public ledger that requirement is demanding, because the ledger is also a permanent archive: validators and archival RPC providers retain every transaction ever posted, ciphertexts included, and anyone can copy them.

Solana already offers amount confidentiality through Token-2022 confidential transfers. Observers cannot see amounts, sender, recipient and timing stay visible, and an optional auditor key per mint can read every amount. Wallets, explorers and institutions have adopted this model of hidden amounts and visible parties, and Hindsight keeps it. What Hindsight changes is the cryptography beneath the hidden amount. Token-2022 protects amounts with twisted ElGamal encryption over the Ristretto group, whose security is the hardness of the discrete logarithm in that group.

1.2Harvest now, decrypt later

A harvest-now-decrypt-later adversary records ciphertexts today and decrypts them once it can break the underlying public-key problem. Against a public blockchain the recording step costs nothing beyond disk space. The adversary intercepts no traffic, compromises no party and does not have to exist at the time of the payment; it downloads the ledger whenever it is ready.

For Token-2022 confidential transfers the decryption step is short. Every account's ElGamal public key is stored on chain. Shor's algorithm recovers the secret key from that public key, and the secret key opens every ciphertext ever addressed to the account through a discrete-logarithm search small enough for an ordinary computer. The mint's auditor key concentrates the exposure: one discrete logarithm on the auditor's public key opens every transfer amount the mint has ever carried. The Background chapter works through the construction step by step.

Confidentiality and soundness age differently under this adversary. A forged range proof or signature matters only if it is accepted when the transaction is verified, and a quantum computer built later cannot reach back and forge transactions the chain has already settled. A disclosed salary, in contrast, stays disclosed. NIST IR 8547 draws the same line: an authentication system "remains secure as long as" its algorithms are secure when the authentication is performed, whereas encrypted data is exposed to harvest-now-decrypt-later. Hindsight is built on this asymmetry. Confidentiality is post-quantum from the first transfer. Soundness, which rests on range proofs, commitment binding and Ed25519 signatures, is checked at transaction time with classical cryptography and follows Solana's own post-quantum migration.

1.3Q-Day and the deadlines

No one knows when Q-Day will come, and the published resource estimates keep falling. Gidney (2025) estimates that RSA-2048 can be factored in under a week with fewer than a million noisy qubits. Litinski (2023) describes an architecture that recovers one 256-bit elliptic-curve key every ten minutes. The Global Risk Institute's 2024 expert survey concludes that the threat may be nearer than earlier estimates suggested.

The date itself matters less than Mosca's inequality. Let $x$ be the number of years the data must stay confidential, $y$ the number of years needed to migrate the system that protects it, and $z$ the number of years until a cryptographically relevant quantum computer exists. The data is exposed when

On a public ledger the migration term gives no relief for data that has already been posted. Once a ciphertext is in the archive, re-encrypting the live state leaves the archived copy unchanged, so for that ciphertext the condition reduces to $x>z$. A salary that must stay confidential for $x\ge 10$ years is exposed by any $z$ shorter than that, whatever migration follows.

Regulators have turned the inequality into dates that buyers of payment systems answer to:

Elliptic-curve ElGamal is one of the quantum-vulnerable public-key mechanisms these documents retire. Payroll and long-term supplier terms posted to a public ledger are a direct instance of the EU rule. Their confidentiality requirement exceeds ten years, so their protection has to be quantum-resistant by the end of 2030, and for amounts already on chain it has to have been quantum-resistant at the moment they were posted.

1.4What Hindsight provides

Hindsight consists of one on-chain program, a client SDK, a hosted relay and indexer, an auditor service and a buyback crank. Together they provide the following.

• Amounts as perfectly hiding commitments. Every balance and every payment is a Ristretto Pedersen commitment $C=vG+rH$. Perfect hiding means that the commitment carries no information about $v$, even to an adversary with unbounded computation, quantum or classical.
• Post-quantum delivery of openings. The opening $(v,r)$ and a 32-byte memo travel to the payee and to the auditor, each in a 1,208-byte envelope: a 1,120-byte X-Wing ciphertext followed by 88 bytes of AES-256-GCM. No ElGamal decryption handle exists anywhere in the system.
• Credit only after a check. A balance grows only through accept, which the payee signs after decrypting its envelope and checking that $vG+rH=C_{\text{note}}$. When the pool requires attestation, the auditor first performs the same check on its own envelope and calls attest. An envelope that fails to open harms only its sender: the payee sends the note back with return_note, and the sender, who chose the opening, accepts it into its own balance.
• Full 64-bit amounts. No party ever recovers an amount by solving a discrete logarithm, so amounts are full unsigned 64-bit USDC base units, with no 48-bit cap and no split into halves.
• One transaction per transfer. The range proof, the transfer instruction and both envelopes fit in a single v1 transaction. Measured on a local Agave 4.3.0 validator, one transfer is 4,024 of 4,096 bytes and consumes 226,570 compute units.
• An accountable auditor per pool. Each pool names one auditor, with an Ed25519 attestation key and one X-Wing key per epoch. The auditor service attests in batches and produces ledger exports and selective-disclosure reports.
• $HINDSIGHT, and the one fee that feeds it. The only fee sits where amounts are already public: 5 basis points on deposits and withdrawals. Transfers carry none, so no fee depends on a hidden amount. The protocol's whole share goes, in the same transaction, to a program account no key signs for, there to buy $HINDSIGHT on the market and burn it. The program does both itself: one transaction claims the fees, swaps them for $HINDSIGHT and burns every token bought, or none of it happens. The supply of 1,000,000,000 went in full to one public launch, and no payment ever needs the token.

The visibility model is the one Token-2022 established. Senders, recipients and timing are public. USDC enters and leaves through a public vault, so deposit and withdrawal amounts are public as well. Between those two points, every amount exists on chain only as a commitment.

1.5The shape of the design

A transfer begins in the payer's client. The client picks the amount $v$ and a fresh random blinding $r$, computes $C_{\text{note}}=vG+rH$, and produces one batched range proof showing that both $v$ and the payer's remaining balance lie in $[0,2^{64})$. It seals the opening twice, once to the payee's X-Wing key and once to the auditor's, and submits one v1 transaction: the native VerifyBatchedRangeProofU128 instruction, followed by transfer.

The Hindsight program reads the preceding instruction and checks that it verified exactly the commitments $[C_{\text{note}},C_{\text{bal}}-C_{\text{note}}]$ at 64 bits each. It then subtracts $C_{\text{note}}$ from the payer's balance commitment and creates a Note account that holds $C_{\text{note}}$ and the SHA-256 hash of the two envelopes. The envelopes themselves remain in the transaction's instruction data. The auditor opens its envelope, checks the opening and attests. The payee opens its envelope, checks the opening and accepts, which adds $C_{\text{note}}$ to its own balance commitment and closes the note.

The program never sees a hidden amount and holds no secret. Everything the chain keeps about a hidden amount is either perfectly hiding, as the commitments are, or encrypted: the envelopes under X-Wing, and each owner's balance opening under that owner's AES-256 key.

The Background chapter reviews the Solana facilities Hindsight builds on and the Token-2022 construction it replaces. The System overview chapter then introduces the actors and their keys, the components, the split between on-chain and off-chain data, and the life of one note.

2Background

This chapter reviews the Solana facilities Hindsight builds on, then the Token-2022 confidential-transfer construction it replaces and the reason that construction's amounts become readable at Q-Day. It ends with what Hindsight keeps from Token-2022 and what it changes.

2.1Solana as Hindsight uses it

2.1.1Programs and accounts

A Solana program is executable code with no state of its own. State lives in accounts, each owned by one program, and only the owner can write an account's data. Hindsight is one program, hindsight, written with Anchor 0.31.1. Each of its accounts begins with an 8-byte discriminator that identifies the type, and the program checks owner and discriminator whenever it loads an account, so a caller cannot present an arbitrary byte array as a Pool or a Note.

Every account holds a refundable rent-exempt deposit of $(\text{size}+128)$ times the cluster's lamports per byte, read live from the Rent sysvar, which is returned when the account closes. A sender pays the deposit for each Note it creates, and accept returns it to that sender; an owner pays for its KeyRecord and ConfAccount, and close_key_record and close_account return them.

The seven account types, with their actual allocations including the discriminator:

2.1.2Program-derived addresses

A program-derived address (PDA) is computed from a list of seeds and a program ID and lies off the Ed25519 curve, so no private key for it exists. The deriving program signs for it by presenting the seeds and a one-byte bump. Every Hindsight account is a PDA, which fixes each address by its meaning: the ConfAccount of owner $o$ in pool $p$ can only be the PDA of ["acct", p, o], and the Note created by sender $s$ at sequence $n$ can only be the PDA of ["note", p, s, n]. For the notes that attest and accept receive as a list, the program recomputes each address with create_program_address from the stored sender, sequence and canonical bump, and rejects a mismatch with InvalidNote.

Custody needs no private key either. The vault's authority is the Pool PDA, and the program signs each withdrawal with the seeds ["pool", mint, bump]. The protocol's fee and $HINDSIGHT token accounts belong to the PDA ["protocol"], which the program signs for only inside a buyback. No key controls the vault, so none can be stolen, by a quantum computer or otherwise. Jump Crypto's analysis of Solana's quantum migration paths makes the same observation about PDAs.

2.1.3Transactions, v1 and compute units

A transaction is an ordered list of instructions that executes atomically, and a program can read the other instructions of its own transaction through the instructions sysvar. Hindsight uses both properties to bind a proof to a balance update. The native program verifies the range proof in one instruction, and the Hindsight instruction immediately after it reads that instruction's data and checks that the proof covered exactly the commitments it is about to use. A failed verification aborts the whole transaction.

Legacy transactions are limited to 1,232 bytes, less than the 2,416 bytes of two envelopes. Version 1 transactions (SIMD-0296 and SIMD-0385), live on mainnet since epoch 1035 on 2026-09-15, allow 4,096 bytes and use no address lookup tables. They set the compute-unit limit and the loaded-account-data limit in the message configuration instead of through compute-budget instructions, so no other instruction sits between the proof and the transfer that consumes it. The SDK's builder sets both limits explicitly and refuses any transaction whose wire encoding exceeds 4,096 bytes. One transfer, measured on a local Agave 4.3.0 validator with native proof verification enabled:

A transaction may use up to 1.4 million compute units (CU). Native verification of a U128 batched range proof costs 200,000 CU and of a U64 proof 111,000 CU. The measured transfer consumed 226,570 CU, against a design target of at most 300,000; the measured withdrawal was 1,479 bytes and 140,575 CU.

2.1.4The ZK ElGamal Proof program

The ZK ElGamal Proof program (ZkE1Gama1Proof11111111111111111111111111111) is a native program that verifies zero-knowledge proofs about Pedersen commitments and twisted ElGamal ciphertexts over Ristretto. Token-2022 uses its sigma proofs and range proofs; Hindsight uses only its batched range proofs. The program is live on mainnet: the reenable_zk_elgamal_proof_program feature activated at slot 424,224,000, the first slot of epoch 982.

A batched range-proof instruction carries a context of up to eight compressed commitments $C_i$ with bit lengths $n_i$, and a Bulletproof, which needs no trusted setup, that each $C_i$ opens to a value in $[0,2^{n_i})$. For an aggregate width $N={\sum }_i{n}_i$ the proof occupies $(2{\log }_{2}N+9)\times 32$ bytes.

The instruction is one discriminator byte followed by the 264-byte context and the proof, with no length prefixes:

Unused slots hold the identity point with bit length zero. With $b$ the balance behind $C_{\text{bal}}$ and $a$ a public withdrawal amount, Hindsight proves two statements:

The program computes $C_{\text{bal}}-C_{\text{note}}$ and $C_{\text{bal}}-aG$ itself from the stored balance. It requires the proof instruction to come immediately before the Hindsight instruction at the top level, to target the native program, to carry no accounts and to leave every unused slot empty. The native program can also store a verified context in a context-state account for a later transaction; Hindsight accepts only the inline form (ProofContextStateUnsupported otherwise), so a proof and the balance change it authorizes always share one atomic transaction. Clients generate the proofs with a pinned Rust/WASM wrapper around solana-zk-sdk 7.0.1, the version family of the Agave 4.3.0 native verifier, and verify each proof locally before signing.

2.1.5Curve25519 syscalls

Solana exposes Ristretto group operations to programs as syscalls: validation, addition, subtraction and scalar multiplication, with addition at 521 CU and multiplication at 2,208 CU. Hindsight's balance updates are built from them:

The owner tracks the matching openings off chain. The program rejects any caller-supplied commitment that is not a valid Ristretto point (InvalidCommitment) and uses the solana-zk-sdk generators: $G$ is the Ristretto basepoint and $H$ is the Ristretto map of SHA3-512 of the compressed $G$, which lets the native verifier check proofs about commitments the program computes. Because the native context reserves the identity for unused slots, a new ConfAccount starts at $C_0=r_{0}H$, a commitment to zero whose blinding is derived publicly from the pool, the owner and the key epoch, so that an emptied balance is still a point a U64 proof can state.

2.2Token-2022 confidential transfers

2.2.1Twisted ElGamal over a Pedersen commitment

The confidential-transfer extension of Token-2022 gives each token account an ElGamal keypair over Ristretto. In the twisted variant the secret key is a scalar $s$ and the public key is

An amount $x$ encrypted to $P$ with randomness $r$ is the pair

$C$ is exactly a Pedersen commitment to $x$, and $D$ is a decryption handle. The commitment part can be shared across recipients: a transfer carries one commitment to the amount and three handles, $D_{\text{src}}=r{P}_{\text{src}}$, $D_{\text{dst}}=r{P}_{\text{dst}}$ and $D_{\text{aud}}=r{P}_{\text{aud}}$, one for each party that can decrypt. Sigma proofs show that the handles are consistent with the commitment, range proofs show that the amounts are in range, and the ZK ElGamal Proof program verifies both. Incoming amounts accumulate in a pending balance, which the recipient later applies to its available balance.

2.2.2Decryption as a small discrete logarithm

The holder of $s$ removes the blinding:

What remains is $xG$, and recovering $x$ from $xG$ is a discrete logarithm. It is tractable only because $x$ is small. Token-2022 therefore caps a transfer amount at 48 bits and encrypts it as two halves,

so that each ciphertext holds a value of at most 32 bits, small enough for a baby-step giant-step search. The 48-bit cap and the lo/hi split follow from decryption by discrete logarithm, not from the token: USDC amounts are 64-bit base units.

2.2.3The auditor handle

A mint with the extension may name one auditor ElGamal public key $P_{\text{aud}}$ in its configuration. Every confidential transfer under that mint then carries $D_{\text{aud}}=r{P}_{\text{aud}}$ next to its commitment, so the auditor can decrypt every amount. One key serves the whole mint, for its whole history.

2.2.4What a quantum adversary recovers

Shor's algorithm computes discrete logarithms in the Ristretto group. Given a public key $P=s^{-1}H$ from the chain, it computes $s^{-1}={\log }_{H}P$ and from it $s$. The classical steps above then apply to every ciphertext ever sent to $P$: $C-sD=xG$, followed by a search over at most $2^{48}$ candidate amounts, which baby-step giant-step completes in about $2^{24}$ group operations.

The commitment is not what fails: Pedersen hiding is information-theoretic and survives Shor. The handle fails, because it is only computationally hiding and sits next to a public key on chain. Key derivation does not help, since the attack starts from that public key rather than from the wallet. A related fact shapes Hindsight's own key rules: Shor run against an Ed25519 wallet key recovers the derived scalar but not the seed it came from. The auditor key turns one quantum computation into a mint's entire amount history, every salary paid through the mint included.

2.3What Hindsight keeps and what it changes

Hindsight keeps the parts of the Token-2022 design that hold against a quantum adversary and replaces the part that does not.

It keeps the Pedersen commitment, with the same generators $G$ and $H$, as the on-chain form of every amount. It keeps the native ZK ElGamal Proof program and its Bulletproofs range proofs, which need no trusted setup and are verified by the runtime rather than by Hindsight's own code. It keeps the model of hidden amounts and visible parties, the auditor as a named role, and the separation between incoming and spendable value, with notes in the place of Token-2022's pending balance.

It removes the decryption handles. The opening $(v,r)$ and a 32-byte memo go to the payee and to the auditor in X-Wing envelopes, each a 1,120-byte X-Wing ciphertext followed by AES-256-GCM over the 72-byte plaintext. Recovering an opening requires breaking ML-KEM-768 as well as X25519, and Shor's algorithm breaks only X25519. Envelopes travel in instruction data and the Note stores their SHA-256 hash, so they are part of the chain's history but not of its account state. With no decryption by discrete logarithm, amounts are full 64-bit values, and one U128 batched proof covers the note and the remaining balance at 64 bits each.

The envelopes are not proven consistent with the commitment. By the estimates made when the design was chosen, proving an ML-KEM envelope in a SNARK would take at least $10^5$ constraints, and replacing ElGamal with an additively homomorphic lattice scheme would take 12.8 KB to 51 KB of ciphertext per transfer over 4 to 13 v1 transactions. Hindsight uses a rule in place of the proof: no one is credited with a commitment they cannot open. The payee accepts a note only after decrypting it and checking $vG+rH=C_{\text{note}}$, and where the pool sets attest_required, the auditor attests the same check on its own envelope first. A malformed envelope leaves its sender with a note to take back through return_note.

The auditor becomes a per-pool role with keys organized by epoch. Each Pool names its auditor and the epoch of the auditor's current X-Wing key, and each Note records the payee and auditor key epochs its envelopes were sealed to. Under attest_required the auditor also gates settlement: a note cannot be accepted before the auditor has opened and checked it. Custody moves to a classic SPL Token vault whose authority is the Pool PDA. USDC enters through deposit and leaves through withdraw, both with public amounts, and in between it moves only as commitments.

3System overview

This chapter introduces the parties that use Hindsight and the keys each one holds, the components of the system and the boundaries between them, which data lives on chain and which off chain, and the life of one note from the payer's client to the payee's balance.

3.1Actors and their keys

Payer and payee are roles in a payment rather than kinds of account. Every participant holds the same keys and opens the same kind of ConfAccount, and an employer that pays salaries becomes the recipient of any note returned to it.

Wallet key. The owner's Ed25519 wallet signs the transactions that change its account and pays their fees and deposits; in the measured transfer and withdrawal it is the only signer. It also signs the one-use challenge that opens an API session. It never contributes to confidentiality. No encryption key is derived from a wallet signature, because such keys can be phished, differ between MPC and hardware wallets, and would tie confidentiality back to a classical key.

X-Wing keypair. The private key is a 32-byte seed generated from fresh entropy in the client. register_key writes the 1,216-byte encapsulation key into the immutable KeyRecord at ["kem", owner, epoch] and rejects any other length (InvalidKeyLength), so a new key is a new epoch. The ConfAccount's key_epoch names the epoch its owner receives on, transfer accepts only that payee KeyRecord (InvalidKeyEpoch), and each Note records the epoch it was sealed to, so an older seed kept in the client still opens older notes.

Self-record key. A non-extractable AES-256 key generated in the client. Every balance-changing instruction stores a new 68-byte self-record in the ConfAccount: AES-256-GCM over the balance and its blinding, bound to the pool, the account, the sequence and the balance commitment. With this key alone the owner recovers its balance opening from chain state.

Auditor keys. Pool.auditor is the Ed25519 key that alone can sign attest (InvalidAuthority). Pool.auditor_kem_epoch selects the auditor's KeyRecord at ["kem", Pool.auditor, Pool.auditor_kem_epoch], the only auditor key transfer accepts. Both keys sit behind the custody interface AuditorHsm, which separates opening and checking envelopes from signing transactions.

Pool authorities. init_pool must be signed by the program's upgrade authority (InvalidBootstrapAuthority), so only the deployment's governance creates the canonical pool for a mint. The same authority signs configure_buyback, once, which fixes the buyback's $HINDSIGHT mint, keeper and minimum-output ratio, and initialize_rent_recovery, once, which creates the registry that keeps every pool's auditor KeyRecord from being closed. The admin and freeze authorities are signers controlled by an external multisig with timelock, whose threshold and delay the policy records. A frozen account cannot change its balance or receive a transfer, while return_note still works on its notes.

The relay and indexer hold credentials for sessions and request integrity but no protocol key, and clients check every envelope against the hash in its Note. Three rules apply to all key material: post-quantum keys come from fresh entropy, never from a wallet signature; note blindings come from a CSPRNG and are never reused; envelopes have a fixed size and memos are padded to 32 bytes.

3.2Components

3.2.1The program

hindsight is one Anchor program with the seven account types described in the Background chapter and seventeen instructions: init_pool, register_key, open_account, deposit, transfer, attest, accept, return_note, withdraw, close_account, close_key_record, freeze, thaw, initialize_rent_recovery, configure_buyback, claim_buyback and complete_buyback. It holds no secret and decrypts nothing.

Only the owner changes a balance: deposit, transfer, accept and withdraw require the ConfAccount owner's signature and the account's current sequence (StaleSequence otherwise), and each increments it. No other party's transaction can therefore make a proof stale. transfer and withdraw bind to the preceding native range proof over exactly $[C_{\text{note}},C_{\text{bal}}-C_{\text{note}}]$ and $[C_{\text{bal}}-aG]$. attest and accept check every note of a batch for pool, address and duplicates (DuplicateNote), and accept refunds each note's deposit only to its original sender (InvalidRentDestination).

The pool's public accounting bounds the hidden amounts. Pool.principal is total deposits less total withdrawals. With sound range proofs, the hidden balances $b_j$ and the hidden amounts $v_i$ of unsettled notes satisfy

transfer, accept and return_note leave principal unchanged. USDC sent to the vault outside deposit is public surplus and creates no confidential credit.

Each pool carries its policy, set at init_pool:

Every field must be given explicitly (ConfigurationRequired); the program assumes no default. The deposit cap may not exceed the pool cap (InvalidPolicy). The ramp fee is 5 basis points (the program accepts up to 100); the flat transfer fee is zero, and the program refuses any other transfer fee with FeeCustodyNotConfigured.

The whole ramp fee goes to the protocol fee account, the token account of the program address ["protocol"] for the pool's mint, and leaves it only through the buyback. configure_buyback creates the global BuybackConfig, which fixes the $HINDSIGHT mint, the one keeper and a minimum-output ratio. The keeper's transaction runs claim_buyback, a swap and complete_buyback last; the completion requires the whole claim to have been spent and at least the minimum to have reached the protocol token account, then burns everything that arrived.

3.2.2The SDK

@hindsight/sdk is a browser-safe TypeScript package that performs all confidential work on the client, and @hindsight/contract supplies the typed API calls and protocol constants. The SDK implements no cryptographic primitive itself.

• Commitments and envelopes. Ristretto commitments over the solana-zk-sdk generators, X-Wing through @noble/post-quantum 0.7.1, HKDF-SHA256 and AES-256-GCM through WebCrypto. Sealing binds role, pool, sender, original payee wallet, sequence, key epoch and commitment, and open returns an opening only after checking it against the commitment.
• Range proofs. The pinned WASM wrapper around solana-zk-sdk 7.0.1, run in a browser Worker. Witnesses never leave the client, and every proof is verified locally.
• Transactions and signing. Builders produce unsigned v1 transactions from current chain state. The wallet adapter accepts browser-injected, Wallet Standard and mobile deep-link wallets, excludes USB hardware wallets, and verifies that the signature covers the unchanged message.
• Openings and self-records. Helpers such as openingAfterTransfer and openingAfterAccept carry the balance opening through every instruction with exact u64 and scalar-field arithmetic.
• Payroll. A CSV with payee,amount and optional row_id,memo columns is planned across lanes, each the ConfAccount of a distinct payer-controlled wallet. Preparation checks the Pool and every account and KeyRecord of the batch on chain before sealing anything, then prepares every note, intermediate opening, envelope and self-record. Plan and journal are encrypted locally; lanes run concurrently, each in order, and every signed transaction is persisted before submission.

3.2.3Relay and indexer

The relay stores envelope pairs by hash. A sender uploads its pair under a wallet session before submitting the transfer. The relay checks that both envelopes are exactly 1,208 bytes and that the pair hashes to $SHA256(e_{\text{payee}}\Vert e_{\text{auditor}})$, and serves an upload as verified only after reconciling it with the Note on chain. Anyone may fetch a pair by its hash, since it is ciphertext, so recipients do not depend on archival RPC history.

The indexer reads the chain over RPC and websocket. Finalized snapshots populate the projections of Pools, ConfAccounts, KeyRecords and Notes; confirmed observations speed up discovery but never credit a balance or settle a note. Each cycle commits atomically in PostgreSQL, missing history is recorded as an explicit gap, and finalized events feed per-wallet notifications.

3.2.4API

The hosted API exposes the relay, the projections and the notifications through typed calls. A wallet session starts with authChallenge, a one-use message bound to wallet, origin, service audience, cluster, program, genesis, nonce and expiry, and authVerify, which checks the Ed25519 signature and sets an HttpOnly cookie; mutations carry a CSRF token. Public calls serve pools, the vault balance and KeyRecords; owner-scoped calls serve accounts, inbox, outbox, notes and public ramp history. Notifications arrive through notifications or the server-sent event stream GET /v1/events. Payroll progress records only plan digests and note references.

The API never generates a proof, opens an envelope or self-record, or signs a transaction. On a cluster whose RPC endpoint carries a provider key, the browser's JSON-RPC calls, sendTransaction included, pass through the API's restricted relay (POST /v1/rpc), which forwards the wallet's signed bytes unchanged and keeps the key on the server. Its database has no column for a hidden amount, an opening, a memo, a payroll CSV or a private key.

3.2.5Auditor service

The auditor service runs in its own domain, with its own process, origin, database and credentials. It discovers notes through a read-only feed of the indexer's public tables and treats that feed as untrusted: before opening an envelope, and again before signing, it fetches the Note, the Pool and the KeyRecord from the chain and checks owner, address, pool, parties, commitment, epochs, current auditor and envelope hash. It then opens its envelope, checks $vG+rH=C_{\text{note}}$ and attests in batches.

Each note is a durable job that moves from QUEUED through VERIFIED, SUBMITTED and CONFIRMED to FINALIZED. An envelope that fails to open or check is held in FAILED_TO_OPEN or OPENING_MISMATCH and never attested. Signed batch bytes are persisted before submission, so a retry resends the same transaction. Ledger and exports are encrypted at rest under an auditor-only key. The console provides the queue, attestation history, metrics, key epochs, CSV and ledger exports and selective-disclosure reports, scoped per pool and operator role. The attestation target is a p95 under 10 seconds.

3.2.6Buyback crank

The buyback crank is the keeper's side of the buyback: npm run buyback, run as its own scheduled service with the keeper key named in the BuybackConfig. Each run reads the protocol fee balance, takes an exact-input USDC-to-$HINDSIGHT quote from Jupiter on mainnet-beta whose minimum output meets the on-chain floor, and submits claim_buyback, the swap and complete_buyback as one transaction. It has no database and needs no USDC of its own; the bought tokens go straight to the protocol token account, where complete_buyback burns them.

3.2.7Applications

The reference web app at /app runs the SDK in the browser and keeps keys in client storage, with views for the account and its key backup, sending, the inbox with sent notes, payroll and withdrawing. The auditor console is served from its own origin. The landing page runs a real seal in the browser: fresh X-Wing keys, a commitment and two envelopes, each opened and checked.

3.3On chain and off chain

The adversary described in the Introduction archives everything in the on-chain rows, envelopes included. What it obtains is a set of commitments that carry no information about amounts, envelopes that open only if ML-KEM-768 is broken as well as X25519, and self-records under AES-256.

3.4The life of one note

A note is the unit of payment. transfer creates it, it waits in the payee's inbox, and it ends when it is accepted, by the payee or, after a return, by its sender.

1. Prepare. The payer's client reads from the chain the payee's ConfAccount, the payee's KeyRecord at that account's key epoch, and the auditor's KeyRecord at the pool's current epoch. It picks $v$ and a fresh $r$, computes $C_{\text{note}}=vG+rH$, seals the opening into the two envelopes, generates the U128 proof in a Worker, and seals the next self-record for the remaining opening $(b-v,r_{\text{bal}}-r)$.
2. Upload. The client uploads the envelope pair to the relay under its hash.
3. Submit. The wallet signs one v1 transaction, VerifyBatchedRangeProofU128 followed by transfer, and the client submits it to RPC. The program checks the proof context, the sender's sequence, the payee's key epoch and frozen flag and both envelope lengths, debits $C_{\text{note}}$, and creates the Note at ["note", pool, sender, sequence], with the sender paying its deposit.
4. Attest. The auditor service picks up the note, checks it against the chain, opens its envelope, checks the opening and includes the note in an attest batch.
5. Open. The payee receives a notification, fetches the pair by hash, checks it against Note.envelope_hash, opens its envelope and checks $vG+rH=C_{\text{note}}$.
6. Settle. If the check holds, the payee calls accept, which adds $C_{\text{note}}$ to its balance, closes the note and refunds the deposit to the sender. If it fails, the payee calls return_note, which re-targets the note to its sender, and the sender accepts it with the opening it kept, without attestation. If the payee does nothing, the sender may return the note itself once return_timeout_slots have passed since created_slot.

A returned note cannot be attested or returned again (NoteAlreadyReturned), and original_recipient keeps the payee's identity after re-targeting, which the auditor's disclosure reports use. A payroll run repeats this life once per row: each lane is an ordered chain of notes from one ConfAccount, with every intermediate commitment and opening prepared before the first transaction of the run is signed.

4Cryptographic construction

Hindsight places two kinds of cryptographic object on chain. A Pedersen commitment over Ristretto255 stands in for every amount that must stay confidential: the balance of each confidential account and the value of each note in transit. The opening of a note commitment is carried to exactly two parties, the payee and the pool's auditor, inside X-Wing envelopes. The envelopes travel in the data of the transfer instruction, and the Note account stores their hash. Around these two objects sits the machinery that keeps the ledger sound: batched Bulletproofs range proofs, verified by Solana's native ZK ElGamal Proof program, and a 68-byte encrypted self-record that lets an account owner recover its own balance opening from chain state alone.

Each amount-bearing object in the archive is therefore either free of computational assumptions or encrypted under a key that a quantum computer cannot recover from public data. Commitments are perfectly hiding, and the range proofs are treated as perfectly zero-knowledge. Envelopes are protected by ML-KEM-768 inside the X-Wing combiner. Self-records are encrypted under an AES-256 key that never leaves the owner. Soundness, the guarantee that no one spends more than they hold, rests on the discrete-logarithm problem and on the soundness of Bulletproofs, and it is needed only at the moment a transaction is verified. This chapter specifies each object as the SDK (@hindsight/sdk) and the on-chain program (hindsight) define it: the group and its encodings, commitments, balance arithmetic, range proofs, envelopes and self-records, and then the confidentiality argument that follows from them.

4.1Notation and groups

4.1.1The group and its scalar field

All curve arithmetic takes place in Ristretto255, the prime-order group constructed over Curve25519. Its order is

and its scalar field is ${\mathbb{Z}}_{\ell }$. A group element is written as its 32-byte canonical compressed encoding, and decoding rejects any non-canonical byte string. The identity element encodes as 32 zero bytes. That encoding matters later, because the native proof format uses it as the sentinel for an unused commitment slot. A scalar is a 32-byte little-endian integer, and it is canonical only when its value is less than $\ell$. The SDK rejects non-canonical scalars wherever it reads one: in commitments, openings, envelope plaintexts, self-records and proof witnesses.

The program never implements curve arithmetic itself. It calls Solana's curve25519 syscalls through the maintained solana-curve25519 wrapper: validate_ristretto, add_ristretto, subtract_ristretto and multiply_ristretto. An addition costs 521 CU and a multiplication 2,208 CU. The SDK uses the noble Ristretto255 implementation, and it does not implement a curve, KEM or symmetric primitive of its own either.

4.1.2The generators G and H

The value generator $G$ is the standard Ristretto basepoint, compressed as

e2f2ae0a6abc4e71a884a961c500515f58e30b6aa582dd8db6a65945e08d2d76.

The blinding generator $H$ is derived from $G$ by hashing:

The 32-byte encoding of $G$ is hashed with SHA3-512, and the 64-byte digest is mapped into the group with the Ristretto one-way map, which maps each 32-byte half and adds the two points. This is exactly the construction in solana-zk-sdk's encryption/pedersen.rs (RistrettoPoint::hash_from_bytes::<Sha3_512>(G_compressed)). The program pins the result as the constant PEDERSEN_H:

8c9240b456a9e6dc65c377a1048d745f94a08cdb7f44cbcd7b46f34048871134.

The SDK computes the same point with noble's Ristretto map over the SHA3-512 digest and exports both encodings as PEDERSEN_GENERATORS. The browser SDK and the Rust tests check the generator byte for byte. Two properties of this choice carry the rest of the design. First, the native ZK ElGamal Proof program proves ranges over Pedersen commitments with exactly these generators, so a commitment formed under any other $H$ could not be range-proven by it. The SDK documentation therefore rules out substituting RFC 9380 hash_to_curve, which produces a different point. Second, $H$ is the output of a hash, so no one knows the discrete logarithm $\eta$ with $H=\eta G$. Binding depends on that.

4.1.3Encodings

Every value that enters a hash, an AEAD's associated data or an account has one fixed encoding.

A public amount enters the group as a scalar. The program's public_commitment(a) writes ${\mathrm{LE}}_8(a)$ into the first eight bytes of a zeroed 32-byte scalar and multiplies $G$ by it, which yields $aG$. In memory, the SDK holds amounts, sequences and epochs as exact bigint values in $[0,2^{64})$, and JSON carries them as decimal strings, so no value passes through a floating-point number.

4.2Pedersen commitments

4.2.1Definition

A Pedersen commitment to an amount $v$ with blinding $r$ is

The pair $(v,r)$ is the opening. The SDK's commit(amount, { blinding, memo }) returns the 32-byte commitment together with a NoteOpening of amount, blinding and a 32-byte padded memo. The memo travels with the opening inside envelopes, but it is not part of the commitment; only $v$ and $r$ determine $C$. When $v=0$ or $r=0$, the SDK uses the identity for the corresponding term instead of multiplying by zero, so every amount and blinding in range has a defined commitment.

4.2.2Hiding

Pedersen commitments are perfectly hiding. Fix a commitment $C=vG+rH$ and an arbitrary alternative amount $v^{\prime }$. Since $H=\eta G$ for some nonzero $\eta$, the equation $v^{\prime }G+r^{\prime }H=C$ has exactly one solution,

When $r$ is drawn uniformly from ${\mathbb{Z}}_{\ell }$, the commitment $C$ is a uniformly distributed group element whatever $v$ is, and every candidate amount is consistent with it through exactly one blinding. An adversary with unbounded computation, one that knows $\eta$, still learns nothing about $v$ from $C$. This is the property that lets commitments sit in a permanent public archive.

4.2.3Binding

Binding is computational. Two different openings of the same commitment,

give $(v-v^{\prime })G=(r^{\prime }-r)H$ and therefore $\eta =(v-v^{\prime })(r^{\prime }-r{)}^{-1}$. Opening a commitment in two ways is as hard as computing the discrete logarithm of $H$ with respect to $G$. Binding is what makes a range proof about $C$ a statement about the amount the committer actually holds. It is a soundness property: it must hold when a proof is verified. A later break of the discrete-logarithm problem lets an adversary open old commitments to any value, but the commitments still carry no information about the amounts behind them.

4.2.4Fresh canonical random blindings

Every note blinding is sampled fresh by randomBlinding() with exact rejection sampling over canonical scalars:

The reduction modulo $2^{253}$ is implemented by masking the top three bits of byte 31 (candidate[31] & 31). Since $\ell$ lies just above $2^{252}$, a candidate is accepted with probability $\ell /2^{253}$, slightly above one half, and the accepted value is exactly uniform over ${\mathbb{Z}}_{\ell }$. Rejected candidates are zeroed before the next draw. The randomness comes from the platform CSPRNG.

A blinding is never reused. If two notes shared $r$, their difference $C_1-C_2=(v_1-v_2)G$ would carry no blinding at all, and the relation between the two amounts would no longer be hidden. Fresh, independent openings are also what keeps a balance blinding secret: every transfer subtracts a new uniform $r$ from the sender's balance blinding, and every accepted note adds one to the payee's.

4.2.5Full 64-bit amounts

No party ever recovers an amount by solving a discrete logarithm. The payee and the auditor read $v$ directly from the envelope plaintext, and an owner reads its balance from its self-record. Amounts can therefore use the full unsigned 64-bit range, $0$ to $18,446,744,073,709,551,615$ base units, with no 48-bit cap and no split into 16-bit and 32-bit halves as in Token-2022 confidential transfers. Every range proof in the protocol uses a bit length of 64, and the SDK accepts values above JavaScript's safe-integer limit without loss.

4.2.6Checking an opening

An opening is checked by recomputation. checkOpening(C, (v, r, memo)) decodes $C$ as a valid group element, recomputes $vG+rH$ from the opening, and compares the two encodings byte for byte. The same check guards every point at which an opening enters or leaves a client:

• seal refuses with OPENING_MISMATCH to encrypt an opening that does not match the note commitment it will be bound to.
• open returns an opening only after it has matched the note commitment supplied in its context.
• The range-proof wrapper recomputes each commitment from its amount and blinding before proving.
• sealSelfRecord and openSelfRecord check the balance opening against the balance commitment.
• The auditor service checks the recovered opening before it signs an attestation.

4.3Balances

4.3.1The balance commitment

Each owner holds one confidential account per pool, a ConfAccount at the PDA seeds ["acct", pool, owner]. It stores the balance as a commitment $C_{bal}=bG+\rho H$, together with the encrypted self-record that carries $(b,\rho )$ for the owner. The program's 190-byte allocation is laid out as follows.

Only the owner can change $C_{bal}$. Every balance-changing instruction (deposit, transfer, accept, withdraw) is signed by the owner and runs ensure_mutable, which requires the account not to be frozen (AccountFrozen), its sequence to be below the last value of its 32-bit range (SequenceRangeExhausted) and the caller's expected_sequence to equal the stored sequence (StaleSequence). update_balance then increments the sequence with checked arithmetic and writes the new commitment and the new self-record together. A range proof built against $C_{bal}$ cannot be made stale by anyone else's transaction, because no one else can move that commitment. Incoming value waits in Notes until the owner accepts it.

4.3.2The initial zero balance

open_account sets the initial balance to a commitment to zero with a public, deterministic blinding $r_0$, derived by the program from the pool, the owner and the owner's key epoch $e$ (the epoch of the KeyRecord the account is opened with). For a retry counter $j=0,1,2,\dots$:

The preimage is 113 bytes: the 37-byte ASCII domain string, the raw 32-byte pool address, the raw 32-byte owner address, the epoch as eight little-endian bytes and the counter as four little-endian bytes. The reduction modulo $2^{252}$ is implemented by clearing the high four bits of digest byte 31 (digest[31] &= 0x0f). The result is canonical without further checks, because $2^{252}<\ell$. An all-zero result is retried with the next checked u32 counter, and the program returns InitialBalanceDerivationFailed if the counter is exhausted. The program computes initial_balance_blinding and initial_balance_commitment itself, so a caller supplies only the encrypted self-record and cannot select an initial commitment. The SDK's deriveInitialBalanceOpening({ pool, owner, keyEpoch }) returns the same opening $(0,r_0)$, so the client can seal its first self-record against $C_0$ before the account exists.

The blinding is deliberately public. The account's amount is known to be zero, so its opening hides nothing, and every later public deposit is visible anyway. The reason for a nonidentity start lies in the native proof format. The ZK ElGamal Proof program reads the commitments of a batched context up to the first all-zero encoding, which marks the unused slots, so an identity commitment cannot be an active proof statement. If accounts started at the identity, an owner who deposited $a$ and later withdrew all of it would leave a remaining balance of $0\cdot G+0\cdot H$, the identity, which the mandatory U64 proof could not cover. Starting at $r_{0}H$ leaves $r_{0}H$ after such a withdrawal, a nonidentity commitment to zero that the proof covers in the normal way. The program still rejects any proof statement that equals the identity (IdentityProofContextUnsupported), with no exception that skips verification.

$r_0$ is used only for this known-zero initial state, never as a note blinding. Before an account's first confidential operation, its amount is the public total of its deposits and withdrawals. The first fresh note blinding subtracted from it (by a transfer) or added to it (by an accept) makes the balance blinding secret to everyone who does not hold that note's opening.

4.3.3Homomorphic updates

Each instruction updates the balance commitment by group operations alone, and the owner's client applies the matching update to the opening with the SDK's opening helpers. The program never sees an opening.

Blinding arithmetic is in ${\mathbb{Z}}_{\ell }$; amount arithmetic is exact unsigned 64-bit arithmetic.

Deposit. The amount is public, and so is its ramp fee $f$. The program requires $0<a\le$ deposit_cap and that the pool's public principal plus $a-f$ stay within pool_cap. It moves $a-f$ from the owner's token account into the vault and $f$ into the protocol fee account with classic SPL Token transfers, and adds the public commitment:

The blinding is unchanged, so openingAfterDeposit returns $(b+a-f,\rho )$.

Transfer. The payer chooses $v$, draws a fresh $r$, and forms $C_{note}=vG+rH$. The program checks that $C_{note}$ is a valid Ristretto encoding (InvalidCommitment) and computes the remaining balance from the stored commitment, never from a caller-supplied field:

It then requires the preceding instruction to have proven both $C_{note}$ and $C_{bal}^{\prime }$ to lie in $[0,2^{64})$, creates the Note holding $C_{note}$, and stores $C_{bal}^{\prime }$. openingAfterTransfer returns $(b-v,\rho -r\mathrm{mod}\ell )$ and fails if $b<v$, so an honest client never builds a transfer it could not prove.

Accept. The recipient passes its Notes as (Note, original sender) account pairs. For each pair, the program validates the Note's PDA from its stored seeds and bump, requires the Note's current recipient to be the signer (InvalidRecipient) and the rent destination to be the Note's sender (InvalidRentDestination), and enforces the pool's attestation policy (AttestationRequired). It rejects duplicate Notes in a batch (DuplicateNote). It then adds every commitment and closes every Note, refunding rent to the sender:

openingAfterAccept takes only openings that have already been recovered from envelopes and checked against their on-chain commitments. It adds them in ${\mathbb{Z}}_{\ell }$ and checks the running amount against $2^{64}-1$ after each addition.

Return. return_note changes no balance. It re-targets the Note to its sender (recipient ← sender), sets returned, and clears attested. The recipient may return a Note at any time; the sender may return it once the current slot reaches created_slot + return_timeout_slots (computed with saturating addition). openingAfterReturn preserves the sender's current opening unchanged. The sender created the Note's opening and keeps it; when it accepts the returned Note, it adds that retained $(v,r)$ through openingAfterAccept like any other note.

Withdraw. The amount is public, $a>0$, and the destination must not be the vault (InvalidDestination). The program computes

requires a U64 proof that $C_{bal}^{\prime }$ opens to a value in $[0,2^{64})$, pays $a$ from the vault under the Pool PDA's signature, and decreases principal with checked arithmetic. openingAfterWithdraw returns $(b-a,\rho )$ and fails if $b<a$.

4.3.4Ordered chains

Because only the owner moves its balance, a client can precompute a whole sequence of transfers. The SDK's payroll preparation does this for each lane, a ConfAccount that sends its rows in order. With $C^{(0)}$ the current balance and $(b^{(0)},{\rho }^{(0)})$ its checked opening, step $k$ produces

with a fresh $r_i$ per Note and a self-record sealed against $C^{(k)}$ at sequence $s_0+k$. All intermediate commitments, openings, envelopes and self-records are fixed before the first transaction is sent. The U128 proof for step $k$ is generated at execution over $[C_{note,k},C^{(k)}]$. A retried transaction keeps its Note PDA, sequence, commitment, opening, envelopes and self-record, and no new payout randomness is drawn.

4.3.5The solvency invariant

The Pool keeps a public counter, principal, which starts at zero, increases by $a-f$ on every deposit of $a$ with ramp fee $f$ and decreases by $a$ on every withdrawal; the fee itself goes to the protocol fee account and never enters the vault. Transfers, accepts and returns leave it unchanged. Let $\mathcal{A}$ be the pool's open confidential accounts with balance openings $(b_i,{\rho }_i)$, and let $\mathcal{N}$ be its outstanding Notes with openings $(v_j,r_j)$. The invariant the program maintains is

with equality on the right in every flow that receives no unsolicited token transfers. A direct SPL transfer into the vault creates public surplus, which credits no confidential balance, consumes no pool cap and cannot be withdrawn without a valid balance proof.

The commitment arithmetic gives the same statement in the group. A transfer moves $C_{note}$ from an account to a Note, an accept moves it back into an account, only deposits and withdrawals add or remove $aG$, and close_account sets aside an account's last commitment, which its proof shows to be a multiple of $H$. With $\mathcal{K}$ the account generations closed so far and $C_{close,k}$ the commitment each held when it closed, summed over the pool,

Every term on the right is public, because each $r_{0,i}$ is derived from public account fields, and each $C_{close,k}$ is a commitment the chain held, so the identity can be checked from chain state alone. With binding, and with every $C_{close,k}$ proven to open to zero, it gives the amount equation modulo $\ell$, and the range proofs make that an equality of integers. Every note amount and every balance left by a transfer or withdrawal is proven to lie in $[0,2^{64})$, and deposits and accepts only add nonnegative values. The left-hand side is then a sum of nonnegative integers far below $\ell$, so the congruence is an equality, and because principal is a u64, every balance stays below $2^{64}$. The accepted run on a local Agave 4.3.0 validator recorded both invariants as holding: the balance and outstanding-note openings summed to principal, and the vault backed principal.

4.3.6Closing a zero balance

close_account returns a ConfAccount's rent to its owner and removes the account, so it must not remove value. A balance commitment opens to zero exactly when it has no $G$ component, $C_{bal}=0\cdot G+\rho H=\rho H$, and the owner shows this with a noninteractive Schnorr proof of knowledge of $\rho$ with respect to $H$. After a full withdrawal the owner's opening is $(0,\rho )$, and generateZeroBalanceProof computes

where $seq$ is the account's current sequence and $n$ the RentRecoveryRegistry's close nonce. The nonce $k$ comes from 32 bytes of the platform CSPRNG with the high four bits of byte 31 cleared, redrawn if zero, and is zeroed once $s$ is computed. The proof is the pair $(R,s)$, 64 bytes. The program recomputes $c$ from its own ID and the state of the instruction's accounts, requires $s$ to be canonical, $R$ to be a valid point other than the identity and $C_{bal}$ to be valid, and checks

with the multiply and add syscalls. An honest proof passes because $sH=kH+c\rho H=R+c{C}_{bal}$.

Soundness. Two accepting responses $s\ne s^{\prime }$ to the same $R$ under challenges $c\ne c^{\prime }$ give $\rho =(s-s^{\prime })(c-c^{\prime }{)}^{-1}$, a representation $C_{bal}=\rho H$. If the same commitment also opened to $bG+{\rho }^{\prime }H$ with $b\ne 0$, then $bG=(\rho -{\rho }^{\prime })H$ would give $\eta =b(\rho -{\rho }^{\prime }{)}^{-1}$, the discrete logarithm of $H$. Closing an account whose balance is not zero is therefore as hard as breaking binding, under the same assumption on $G$ and $H$ that the rest of the ledger rests on, with the challenge modeled as a random oracle.

Zero knowledge. The pair $(R,s)$ can be produced without $\rho$: choose $s$ and $c$ at random, set $R=sH-c{C}_{bal}$, and program the hash to return $c$. In a real proof, $s=k+c\rho$ is masked by a fresh $k$ that is uniform over the nonzero scalars below $2^{252}$, which leave out a negligible part of ${\mathbb{Z}}_{\ell }$ because $\ell$ lies just above $2^{252}$; so the real and simulated pairs are statistically indistinguishable. The proof therefore reveals nothing beyond its statement that $C_{bal}$ commits to zero: not the current blinding $\rho$, and not any earlier amount or blinding of the account. A nonce is never reused, for the same reason a note blinding is not: two responses under one $k$ would give $\rho$ by the equation above.

Binding to one close. The challenge names the program, the pool, the ConfAccount, the owner, the sequence, the close nonce, the commitment and $R$, so a proof verifies only for the account and state it was made for. Every close_account advances the close nonce, which makes each proof single-use: once any close in the deployment has advanced the nonce, its own included, the proof no longer verifies, even for an account reopened at the same PDA.

4.4Range proofs

4.4.1The statements

The program cannot see amounts, so it relies on two range statements, each verified by the native ZK ElGamal Proof program in the same transaction.

For a transfer, a batched proof over two 64-bit components, VerifyBatchedRangeProofU128, proves knowledge of openings for the note and for the remaining balance:

For a withdrawal of a public $a$, a single 64-bit proof, VerifyBatchedRangeProofU64, covers the remaining balance:

These statements imply that no one spends more than they hold. Suppose $C_{bal}$ opens to an amount $b\in [0,2^{64})$. By binding, $b\equiv v+b^{\prime }(\mathrm{mod}\ell )$. Since $v+b^{\prime }<2^{65}<\ell$, the congruence is an equality of integers, $b=v+b^{\prime }$, and therefore $v\le b$. Without the second component, a payer could commit to a $v$ larger than its balance and leave a remaining commitment to $b-v+\ell$, which is a valid group element but no valid amount. The first component rules out the mirror case, a "negative" note that would add value to the payer. The withdrawal statement gives $a\le b$ in the same way.

4.4.2Batched Bulletproofs

Both proofs are Bulletproofs range proofs aggregated over the batch, with no trusted setup. A proof over an aggregate of $n$ bits consists of $2{\log }_{2}n+9$ group and scalar elements of 32 bytes each:

Native verification costs 111,000 CU for U64 and 200,000 CU for U128. The proof's Fiat–Shamir transcript uses the SDK's batched-range-proof-instruction domain and absorbs the full context, including all eight commitment slots and bit lengths, so a proof is valid only for the exact context it was built with. The program's proof parser is pinned to solana-zk-sdk 2.3.13, a version family that includes the patched range-proof transcript binding the inner-product values before the batching challenge is derived. Clients prove with solana-zk-sdk 7.0.1, the version the native verifier of Agave 4.3.0 depends on. Each generation uses fresh proof randomness, so two proofs of the same statement differ in their proof bytes while sharing the same context.

4.4.3The proof instruction and its context

The proof travels as an inline instruction to the native program at ZkE1Gama1Proof11111111111111111111111111111, with no accounts. Its data is a one-byte discriminator followed by the exact POD proof-data struct, context first and proof second, with no length prefix.

The context is the 264 bytes at offsets 1 to 264: eight 32-byte commitments followed by eight bit lengths. The complete instruction is 937 bytes for U64 and 1,001 bytes for U128. Unused slots hold the identity encoding, written $0$ below, with a bit length of zero. The contexts Hindsight accepts are fixed:

Both the SDK's proof wrapper and its transaction builder check this exact shape before a transaction is assembled: active slots nonidentity with a bit length of 64, inactive slots zero.

4.4.4How the program checks the proof instruction

Native verification runs as its own instruction earlier in the same atomic transaction. If the proof is invalid, the transaction fails before Hindsight runs. What remains for the program is to establish that the instruction it relies on was a proof of exactly the right statement. verify_range_context does this from the instructions sysvar, whose canonical address the account constraints check, before any balance changes or tokens move:

• The requested proof type matches the operation: U128 with two expected commitments for transfer, U64 with one for withdraw (InvalidProofType).
• No expected commitment is the identity (IdentityProofContextUnsupported).
• The current instruction index is greater than zero (MissingRangeProof), and the current instruction belongs to Hindsight itself. A call through another program's CPI is rejected (ProofCpiUnsupported).
• The instruction at index minus one targets the ZK ElGamal Proof program (InvalidProofProgram) and carries no accounts. The context-state and proof-account routes are not accepted (ProofContextStateUnsupported).
• Its discriminator names the required proof type (InvalidProofType), and its data parses as the exact POD struct for that type, with no truncated or trailing bytes (InvalidProofData).
• Each context slot equals the expected commitment with a bit length of 64, or the identity with a bit length of zero (ProofContextMismatch).

For a transfer, the expected commitments are the caller's $C_{note}$ and the program's own $C_{bal}-C_{note}$, computed from the stored balance with the subtraction syscall. For a withdrawal, the expected commitment is $C_{bal}-aG$, computed with public_commitment(a) and the subtraction syscall. Since the native verifier has accepted the proof for this context, and the transcript binds the context, the proof is a proof about this balance transition and no other. The sequence check binds it further to this particular state of the account.

4.4.5Proof generation in the client

Proofs are generated in the payer's browser, in a Worker, or in a payer-controlled process. No hosted service receives a witness. The SDK ships a thin Rust wrapper compiled to WebAssembly, pinned to solana-zk-sdk 7.0.1, that calls the official U64 and U128 builders and verifier and reimplements no Bulletproof, generator or transcript code. The asset's SHA-256 digest is checked before initialization, and a mismatch fails closed. Before proving, the wrapper rejects an all-zero commitment, a non-canonical scalar or an opening that does not recompute to its commitment, and after proving it verifies the proof locally and checks the strict context shape. generateRangeProof returns the 264-byte context and the proof bytes separately, and the transaction builder prepends the discriminator and places the proof instruction immediately before the Hindsight instruction. In a v1 transaction the compute-unit and loaded-data limits live in the message configuration, not in compute-budget instructions, so nothing intervenes between the two.

Measured end to end, a transfer with its U128 proof and both envelopes is 4,024 of the 4,096 bytes a v1 transaction allows and consumes 226,570 CU, of which native verification accounts for 200,000. A withdrawal with its U64 proof is 1,479 bytes and 140,575 CU. Both figures come from one accepted run on a local Agave 4.3.0 validator with native proof verification enabled, each transaction signed by its owner alone.

4.5Envelopes

4.5.1What an envelope carries

A commitment is useless to a recipient without its opening, and the opening must reach exactly two parties: the payee, who will accept the note, and the pool's auditor, who sees every amount. Hindsight carries the opening in envelopes. An envelope is a hybrid public-key encryption of a 72-byte plaintext: an X-Wing key encapsulation followed by AES-256-GCM, with the key and nonce derived by HKDF-SHA256 and with associated data that binds the ciphertext to the identity of the Note it belongs to. The program checks an envelope's length and hashes it, but it cannot check its contents, and envelopes are not proven correct. Instead, no one is credited with a commitment they cannot open, as described at the end of this chapter.

4.5.2X-Wing keys and encapsulation

X-Wing is the hybrid KEM of the IETF draft draft-connolly-cfrg-xwing-kem (draft 11), combining X25519 with ML-KEM-768. The SDK uses @noble/post-quantum 0.7.1 (ml_kem768_x25519) through a provider interface, and checks its key generation, encapsulation and decapsulation against the draft's published test vectors byte for byte.

Encapsulation runs both component KEMs against the recipient's public key. The X-Wing combiner hashes the ML-KEM-768 shared secret, the X25519 shared secret, the X25519 ciphertext, the X25519 public key and a fixed label with SHA3-256 into the 32-byte $ss$. The combined secret is unpredictable as long as either component holds, and against a quantum adversary the ML-KEM-768 component carries it.

Public keys live on chain. register_key(epoch, encapsulation_key) writes exactly 1,216 bytes (InvalidKeyLength otherwise) into an owner-signed KeyRecord at ["kem", owner, LE_8(epoch)], one immutable record per epoch. The private key is a 32-byte seed drawn from fresh entropy. It is never derived from a wallet signature, and authentication signatures never serve as X-Wing seeds. Decapsulation in the SDK first checks that the public key derived from the seed equals the supplied public key. An ML-KEM-768-only profile, with 1,184-byte public keys and 1,088-byte ciphertexts, would need its own versioned key registry and envelope format. The SDK reserves a profile selector for it and does not substitute such keys into X-Wing fields.

4.5.3Plaintext layout

The plaintext is the serialized opening, 72 bytes of fixed size.

padMemo encodes a string as UTF-8 (or takes raw bytes) and pads it with zeros to 32 bytes. It rejects any input longer than 32 bytes, so a memo is limited to 32 bytes, not 32 characters. decodeMemo strips trailing zeros. Because the plaintext has a fixed size, every envelope has the same length whatever the amount or memo.

4.5.4Associated data

Each envelope is bound to its Note through 167 bytes of associated data:

The pool, sender and sequence together are the Note's PDA seeds, ["note", pool, sender, LE_8(seq)], so the associated data names exactly one Note, and it adds that Note's payee and commitment. The recipient field is the original payee's wallet address in both envelopes. The auditor envelope differs only in its role byte and its key epoch, and it is encrypted to the auditor's X-Wing key. The KEM public key selects who can decrypt, while the associated data says which payment the plaintext belongs to. The transfer instruction itself names the payee by its ConfAccount address, and clients resolve that account's owner wallet for the associated data, keeping the two addresses distinct.

4.5.5Key and nonce derivation

The AES-256-GCM key and its 96-bit nonce are derived from each fresh shared secret with HKDF-SHA256:

The salt binds the full recipient public key and the full KEM ciphertext, both their ML-KEM and their X25519 parts, into the derivation. The info string is the 42-byte ASCII domain followed by the 167-byte associated data, 209 bytes in all, so the key and nonce themselves depend on the Note's identity, the role and the key epoch, in addition to the GCM tag's check of the same associated data. The derivation outputs 352 bits, split 32/12 into $K$ and $N$. A new encapsulation is performed for every envelope, so each $(K,N)$ pair is used for exactly one encryption and no nonce needs to be transmitted. This keeps the AEAD part at 88 bytes.

4.5.6The 1,208-byte envelope

The plaintext $P$ is encrypted under $K$ and $N$ with the associated data and a 128-bit tag:

The program requires both envelopes in TransferArgs to be exactly 1,208 bytes (InvalidEnvelopeLength). Together they make up 2,416 of the 2,540 bytes of transfer instruction data. The domain strings carry version tags (v0 for the envelope codec), so a revised framing is a distinct, versioned format rather than a reinterpretation of existing bytes.

4.5.7Opening and checking an envelope

open({ envelope, recipientKeyPair, context }) reverses the construction and returns an opening only if every step succeeds:

• The envelope is exactly 1,208 bytes, and the key pair is a 1,216-byte public key with the 32-byte seed it derives from.
• The associated data is rebuilt from the context, which the recipient takes from the Note on chain: pool, sender, original_recipient, sequence, the epoch for its role and commitment.
• The first 1,120 bytes are decapsulated to $ss$; $K$ and $N$ are derived as above; the remaining 88 bytes are decrypted and authenticated.
• The 72-byte plaintext is parsed, and its blinding must be canonical.
• The recovered $(v,r)$ must satisfy $vG+rH=C_{note}$.

Failures return fixed messages with no upstream error or supplied value: ENVELOPE_OPEN_FAILED for key, decapsulation and authentication failures, and OPENING_MISMATCH when the plaintext authenticates but does not open the commitment. The shared secret and plaintext buffers are zeroed after use on a best-effort basis.

4.5.8The envelope pair hash

Envelopes are instruction data. The Note does not store them, only a commitment to both:

computed by the program over the two envelopes in TransferArgs, payee first. The SDK computes the same value with envelopePairHash. A relay stores envelopes by this hash and serves them to recipients without being trusted. It checks exact lengths and the ordered hash on upload, and every client checks the bytes it receives against Note.envelope_hash before opening them, so substituted bytes are rejected before decryption. Recipients also do not depend on archival RPC history to find their envelopes.

4.5.9Payee and auditor roles, key epochs

The two envelopes of a transfer are sealed together by sealToRecipients, which requires the roles to be payee and auditor and the pool, sender, recipient, commitment and sequence of both contexts to be identical. Only the key epoch differs between the two contexts. The program pins which keys are current. The Transfer accounts include the payee's KeyRecord, which must belong to the payee ConfAccount's owner (InvalidRecipient) and carry that account's key_epoch (InvalidKeyEpoch), and the auditor's KeyRecord at ["kem", pool.auditor, pool.auditor_kem_epoch], owned by the pool's auditor identity (InvalidAuthority). The Note records both epochs, recipient_key_epoch and auditor_kem_epoch, so each recipient knows which private key opens its envelope, including for historical Notes after a key has been replaced. The auditor's X-Wing keys are held per pool and per epoch in the auditor service's own trust domain, behind an HSM interface that separates opening and checking from transaction signing. The hosted API never loads that key and never opens an envelope.

4.6Self-records

4.6.1Purpose

An owner needs the opening $(b,\rho )$ of its balance to build every proof and every update. The self-record stores that opening on chain, encrypted under a symmetric key only the owner holds, so a client can recover it from the ConfAccount alone. Every instruction that sets the balance (open_account, deposit, transfer, accept, withdraw) takes a new 68-byte self-record and writes it together with the new commitment. The program treats the 68 bytes as opaque; their integrity comes from the AEAD and from the opening check on recovery.

4.6.2Layout

The key $K_s$ is a 256-bit AES-GCM key generated by generateSelfRecordKey() as a non-extractable WebCrypto key. Like the X-Wing seed, it never comes from a wallet signature. Unlike an envelope key, it is long-lived, so every seal draws a fresh random 96-bit nonce and transmits it in the record.

4.6.3Associated data

129 bytes: the 25-byte ASCII domain, the raw pool address, the raw ConfAccount address, the sequence and the balance commitment. The sequence and commitment are the values the account holds after the instruction that writes the record. A record sealed for open_account uses the account's initial sequence, close_nonce << 32, which is 0 until the first close in the deployment, and $C_0=r_{0}H$, and a record for any later instruction uses the incremented sequence $s+1$ and the new $C_{bal}^{\prime }$. The associated data therefore ties each record to one account at one point in its history: a record copied to another account, replayed at another sequence or paired with another commitment fails authentication.

4.6.4Recovering and checking a balance

To recover its balance, a client reads its ConfAccount, takes pool, its own address, sequence and balance_commitment from it as the context, and calls openSelfRecord. The function decrypts the 56 bytes after the nonce under the rebuilt associated data, parses $b$ and $\rho$, and returns them only if

A wrong key, modified ciphertext, wrong context, wrong sequence or an opening that does not match the commitment all return the same fixed failure. A successful recovery is therefore a checked statement: the client holds the exact opening of the commitment the chain stores. Payroll preparation relies on this. Before it seals any envelope, it opens every source account's self-record against its current on-chain sequence and commitment and compares the result with the opening it was given.

4.7Confidentiality after Q-Day

4.7.1What the archive holds

An adversary who records the chain and the relay from the first transfer onward holds, for every pool:

• every balance commitment and every note commitment, 32 bytes each;
• every range proof, 736 bytes per transfer and 672 bytes per withdrawal, with its 264-byte context;
• every envelope, 1,208 bytes, two per transfer, from instruction data or the relay;
• every self-record, 68 bytes per balance change;
• every zero-balance proof, a 32-byte nonce point and a 32-byte response per closed account;
• every KeyRecord's 1,216-byte X-Wing public key;
• the public amounts of deposits and withdrawals, the public initial blindings $r_0$, and the parties and timing of every operation.

Hindsight stores no ElGamal decryption handle. In Token-2022 confidential transfers, a handle $D=rP$ sits beside each commitment, with the public key $P$ on chain, so one discrete logarithm of $P$ leads to every amount encrypted to that key. Here, the only paths from the archive to an amount run through the envelopes and the self-records.

4.7.2What a quantum adversary can compute

A cryptographically relevant quantum computer computes discrete logarithms in elliptic-curve groups. Applied to the archive, this yields:

• $\eta ={\log }_{G}H$, with which it can open any commitment to any value it chooses;
• the X25519 private key behind each KeyRecord, and from it the X25519 shared secret of every envelope, since both the X25519 ciphertext and the X25519 public key are in the archive;
• the Ed25519 private scalar of every wallet and of the auditor's attestation key.

None of these values yields an amount. Knowing $\eta$ breaks binding, which is a soundness property needed at verification time and does not affect hiding. The X25519 shared secret is one of the two inputs to the X-Wing combiner. The wallet and attestation keys are unrelated to the X-Wing seeds and the self-record keys, which come from fresh entropy and never from a signature.

4.7.3Why amounts remain sealed

Commitments. For every commitment $C$ and every candidate amount $v^{\prime }$, there is exactly one $r^{\prime }$ with $v^{\prime }G+r^{\prime }H=C$. Writing $C=(v+r\eta )G$, the exponent $v+r\eta$ is uniform in ${\mathbb{Z}}_{\ell }$ for a fresh uniform $r$, whatever $v$ is. Knowledge of $\eta$ does not help, because the uncertainty is in $r$, not in the group. This holds for note commitments and, after the first confidential operation, for balance commitments, whose blindings are sums and differences of fresh note blindings.

Range proofs. Hindsight's security design treats the Bulletproofs as perfectly zero-knowledge: a proof's distribution depends only on the statement, which is the context of public commitments, so it adds nothing beyond the commitments themselves.

Zero-balance proofs. A closing proof $(R,s)$ can be simulated from the closed commitment alone, and the simulation argument uses no computational assumption, so the proof adds nothing beyond the commitment and the public fact that the account closed at zero.

Envelopes. The AES key and nonce are derived from $ss$, and $ss$ is a SHA3-256 hash of both component secrets. A quantum adversary recovers the X25519 secret but not the ML-KEM-768 secret, which would require breaking ML-KEM-768, the lattice KEM standardized in FIPS 203. Without it, $ss$ is unknown, so $K$ and $N$ are unknown and the 88-byte AEAD ciphertext reveals nothing. X25519 adds a classical hedge alongside ML-KEM-768. The envelope has a fixed size and the memo is padded, so length reveals nothing either.

Self-records. The AES-256 key never appears on chain or in any request. The record's associated data is public, but it identifies the account and the commitment, not the amount.

Confidentiality and soundness thus age differently. Confidentiality has to hold for as long as the data matters, which is why every amount-bearing object is either unconditionally hiding or protected by ML-KEM-768 from the first transfer. Soundness has to hold when a transaction is verified, so it rests on classical assumptions today and follows Solana's own post-quantum migration.

4.7.4Nobody is credited with a commitment they cannot open

Because envelopes are not proven correct, the protocol has to rule out a balance commitment whose opening its owner does not know. Such an account could neither prove a transfer or withdrawal nor read its own balance. Hindsight rules it out by construction, and an induction over the instructions shows it:

• open_account sets $C_0=r_{0}H$, whose opening $(0,r_0)$ is public.
• deposit and withdraw add or subtract $aG$ with a public $a$, which leaves the blinding unchanged.
• transfer subtracts a note whose opening the sender chose itself.
• accept is the only instruction that adds a commitment chosen by another party. The program executes it only on the recipient's signature, and the recipient's client signs only after it has checked the envelope bytes against Note.envelope_hash, opened its envelope and checked $vG+rH=C_{note}$.

Every balance commitment in the pool therefore has an opening its owner knows, and the self-record carries it.

The attestation gate repeats the same check for the auditor. When the pool's policy sets attest_required, accept requires each Note to be attested. Only the pool's auditor can set that flag, through attest, which rejects returned Notes (NoteAlreadyReturned). The auditor service treats the indexer and the relay as untrusted. Before opening, and again before signing, it fetches the confirmed Note, Pool and KeyRecord accounts and checks their owners, discriminators, PDAs, pool, sender, recipients, commitment, epochs and current auditor. It then checks the ordered envelope hash, opens its own envelope with the original payee's wallet in the associated data and the Note's stored auditor epoch, and checks $vG+rH=C_{note}$. A Note whose auditor envelope fails to open or does not match is held in the FAILED_TO_OPEN or OPENING_MISMATCH state and is never attested. A payee in such a pool can be credited only with a commitment that the auditor has also opened. Holding every note opening, together with the public $r_0$ values and the public deposits and withdrawals, the auditor can recompute any balance in the pool, which is the visibility the auditor role is defined to have.

A note with a garbage envelope therefore harms only its sender. The payee cannot open it and returns it with return_note, which re-targets the Note to its sender and clears attested. If the payee never acts, the sender can return the Note itself after return_timeout_slots. The sender created the opening, so it needs neither envelope: accept admits a returned Note held by its own sender without attestation (note.returned && note.recipient == note.sender), and the sender adds its retained $(v,r)$ to its balance opening. Every Note can therefore end in the balance of a party that holds its opening, and the solvency identity holds at every step. The accepted validator run exercised this path end to end. Both recipients opened and checked the honest envelopes, a Note with garbage envelopes was rejected, returned and accepted back by its sender, and every self-record opened and checked after each transition.

5The on-chain program

Hindsight's on-chain component is one Anchor program, hindsight. It keeps every confidential balance as a Pedersen commitment, carries value between accounts as notes, and holds the pool's USDC in a vault whose authority is a program-derived address. The program holds no secret key and stores no amount in plaintext. It never decrypts anything: the opening of each note travels to the payee and the auditor inside X-Wing envelopes, and the program only checks their length and stores their hash.

The program is written against Anchor 0.31.1. Commitment arithmetic runs on the curve25519 Ristretto syscalls through solana-curve25519, and proof-instruction parsing uses the official solana-zk-sdk decoders, both pinned to 2.3.13. Range proofs are verified by the native ZK ElGamal Proof program in the same transaction. Token custody uses the classic SPL Token program; the vault is an ordinary token account with no confidential-transfer extension. The buyback burns $HINDSIGHT through that token's own program, classic SPL Token or Token-2022.

This chapter describes the program as built: its model, its seven account types, its seventeen instructions with their accounts, arguments, checks and state changes, the proof-binding and buyback-binding routines, the zero-balance proof that closes an account, the solvency accounting and the error codes.

5.1Program model

5.1.1Commitments and generators

A value $v$ (an unsigned 64-bit amount of USDC base units, six decimals) with blinding scalar $r$ is committed over Ristretto255 as

where $G$ is the standard Ristretto basepoint and $H$ is the Ristretto map of SHA3-512 of the compressed $G$. These are the Pedersen generators of solana-zk-sdk, so a commitment built in the client, checked by the native proof verifier and updated by the program is the same group element in all three places. The program embeds both points as constants.

The program never learns $v$ or $r$ for a note. It works with two kinds of commitment. A public amount $a$, as in a deposit or withdrawal, becomes public_commitment(a) $=a\cdot G$, computed with the multiply syscall from the little-endian bytes of $a$. A confidential amount arrives as a 32-byte compressed point that the program validates and then adds or subtracts. The syscalls cost 521 CU for an addition and 2,208 CU for a multiplication.

Each balance-changing instruction is a homomorphic update of the stored balance commitment $C_{bal}$:

Because commitments are additively homomorphic, the openings follow the same arithmetic. If $C_{bal}$ opens to $(b,\rho )$ and $C_{note}$ to $(v,r)$, then $C_{bal}-C_{note}$ opens to $(b-v,\rho -r)$ with the blinding taken modulo the group order. The client tracks these openings; the program tracks only the points.

5.1.2Owner-only balances and sequence numbers

Only the owner of a confidential account can change its balance commitment. Every balance-changing instruction (deposit, transfer, accept, withdraw) is signed by the owner, names the owner's account through its PDA seeds, and carries an expected_sequence that must equal the account's stored sequence. On success the program increments the sequence with checked arithmetic and replaces the account's encrypted self-record.

Two properties follow. A range proof is computed against one specific $C_{bal}$, and since no other party can change that commitment, no other transaction can invalidate a proof the owner has built. And a transaction built against an older state fails with StaleSequence instead of being applied to a balance its author did not see. Incoming value never writes to the recipient's balance directly; it waits in a Note until the recipient's own accept, which is itself an owner-signed, sequence-checked update.

A sequence has two halves. open_account sets it to close_nonce << 32, which puts the RentRecoveryRegistry's global close nonce in the high 32 bits, and each balance update counts up in the low 32 bits. Each opening of an account at its PDA, a generation, therefore has its own range of $2^{32}$ sequence values above the ranges of its earlier generations, and a balance update refuses to leave that range (SequenceRangeExhausted). Before any account has been closed the nonce is zero and sequences start at 0.

5.1.3Notes as pending value

A transfer debits the sender immediately and creates a Note holding $C_{note}$, an account of its own that plays the part of a pending balance. The recipient accepts it after checking its opening, or returns it; when the pool requires attestation, the auditor marks it attested first.

5.1.4Proof binding

transfer and withdraw require the instruction immediately before them to be a native range-proof verification whose context names exactly the commitments of this balance transition, computed by the program from stored state. The routine is described step by step in its own section below.

5.1.5Public principal

The pool keeps one public counter, principal: deposits less withdrawals, in base units. Transfers, attestations, acceptances and returns leave it unchanged. It is what the pool cap limits, and it is the quantity the confidential balances and outstanding notes sum to.

5.1.6Protocol fees and the buyback

The ramp fee never enters the vault or a commitment. deposit and withdraw pay it into the protocol fee account, a token account of the program address ["protocol"], and the fees leave that account only through a buyback. A buyback is one transaction: claim_buyback hands an exact amount to the configured keeper, one or more swap instructions turn all of it into $HINDSIGHT delivered to the protocol's own token account, and complete_buyback, as the final instruction, burns everything that arrived. The BuybackConfig fixes the token, the keeper and the minimum output once. The instructions, and the routine that binds a claim to its completion, are described below.

5.1.7Rent recovery

close_account closes an owner's ConfAccount at a zero balance, shown by a Schnorr proof of knowledge of $\rho$ in $C_{bal}=\rho \cdot H$, and close_key_record closes a KeyRecord that no pool names as its auditor key; both pay every lamport of the account to its owner. The global RentRecoveryRegistry holds the close nonce each close consumes and the protected auditor keys.

5.2Encoding conventions

All program accounts and instruction arguments use Anchor's Borsh encoding.

PDA seeds are concatenated byte strings: literal seeds as UTF-8 (pool, vault, kem, acct, note, buyback, rent-recovery, protocol), public keys as their 32 raw bytes, and epochs and sequences as 8-byte little-endian u64. Every PDA the program creates uses the canonical bump, which is stored in the account as one byte and reused for later address checks.

Account sizes below are the exact declared allocations, including the discriminator. An account's rent is

read live from the Rent sysvar, and every participant account's rent returns to its payer when it closes: a Note's on accept, a ConfAccount's on close_account and a KeyRecord's on close_key_record.

5.3Accounts

The program owns six account types (Pool, KeyRecord, ConfAccount, Note, BuybackConfig, RentRecoveryRegistry) and creates one SPL token account (the vault). The pool's accounts and their references are shown below; the BuybackConfig and the RentRecoveryRegistry are global, and of the pool's accounts only the auditor KeyRecord is named by the registry.

5.3.1Pool

One Pool exists per token mint. It records the mint and vault, the auditor identity and the auditor's KEM epoch, the two governance signers, the policy, and the public principal.

• Seeds: ["pool", mint]
• Size: 238 bytes
• Discriminator: f19a6d0411b16dbc

The pool's auditor, its KEM epoch, its authorities and its policy are written once, by init_pool. No instruction rewrites them. A Note records the auditor epoch it was sealed to, so the key that opens each auditor envelope is fixed by the chain.

5.3.2Pool policy

PoolPolicy is a 53-byte struct inside the Pool. At initialization every field is supplied as an Option in PoolPolicyConfig, and init_pool fails unless every field is present; Some(false) is a valid attestation policy. No field has a default in the program.

The two fee fields put fees where amounts are already public or where a fixed price leaks nothing: a basis-point charge on deposits and withdrawals, and a flat charge per note. The ramp fee is in force: on an amount $a$ it is $f=\lfloor a\cdot \text{ramp\_fee\_bps}/10000\rfloor$, computed in 128-bit arithmetic and rounded down so the participant keeps the remainder. The flat transfer fee is zero, and init_pool refuses any other value with FeeCustodyNotConfigured.

All of the ramp fee goes to the protocol fee account: the associated token account, for the pool's mint, of the program address with seeds ["protocol"] (protocol_authority). No key signs for that address, and deposit and withdraw require the fee account by its derived address, so every fee lands there. The fees collected there buy $HINDSIGHT, the project's token, on the market, and the program burns what they buy: tokens leave the fee account only through claim_buyback, inside a transaction that must end with complete_buyback (see the protocol accounts and the buyback instructions below).

The last three fields describe the off-chain governance and key-rotation regime that surrounds the pool. The admin and freeze authorities are signer addresses intended to be held by an external multisig with a timelock; the program checks their signatures, and the threshold and timelock are recorded so the regime is published with the pool. The rotation interval is read by the auditor service. The program does not convert seconds to slots and no instruction evaluates these three fields.

The return timeout is measured in slots. Its upper bound, $2^{32}-1$, is an engineering bound on the configured delay, not a default.

5.3.3Vault

The vault is a classic SPL Token account for the pool's mint, created by init_pool.

• Seeds: ["vault", pool]
• Size: 165 bytes (SPL Token account)
• Mint: the pool's mint. Token authority: the Pool PDA.

The Pool PDA has no private key, so tokens leave the vault only through withdraw, where the program signs the token transfer with the seeds ["pool", mint, bump]. Every instruction that touches the vault checks its address against pool.vault, its PDA seeds, that its token authority is the Pool and that its mint is the pool mint.

5.3.4KeyRecord

A KeyRecord publishes one X-Wing encapsulation key (X25519 + ML-KEM-768) for one owner and one epoch. Payers seal the payee envelope to the payee's key, and the auditor envelope to the auditor's key.

• Seeds: ["kem", owner, epoch] with epoch as u64 little-endian
• Size: 1,265 bytes (rent paid by the owner and returned to it by close_key_record)
• Discriminator: 4703e028106f1ce6

A KeyRecord is immutable: while it exists, the same owner and epoch cannot be registered again, and a new key is a new epoch at a new address. Its owner can close it with close_key_record, which frees the address for a later register_key of the same epoch, unless the RentRecoveryRegistry lists it as a pool's auditor key. Key records belong to wallets, not to pools, so one KeyRecord can serve accounts in several pools and the auditor's KeyRecord exists independently of the Pool that names it. The X-Wing decapsulation key never reaches the chain; it is a 32-byte seed held by the owner's client, or by the auditor's custody.

5.3.5ConfAccount

A ConfAccount is one owner's confidential balance in one pool.

• Seeds: ["acct", pool, owner], so each owner has one ConfAccount per pool
• Size: 190 bytes (rent paid by the owner and returned to it by close_account)
• Discriminator: 850152477f986806

The self-record lets the owner recover its balance opening from chain state alone. Its 68 bytes are a 12-byte nonce followed by the AES-256-GCM encryption of the 8-byte balance and the 32-byte blinding scalar, with its 16-byte tag. The authenticated data binds it to the exact state it describes:

The key is an AES-256 key held by the owner's client. The program stores the record and replaces it on every balance update; it does not interpret it. A client opening a self-record checks that the recovered opening reproduces $C_{bal}$ before using it.

key_epoch is set by open_account from the KeyRecord passed to it. Every transfer to the account must present the KeyRecord of that epoch, so payers always seal to the key the account was opened with.

5.3.6Note

A Note is one confidential payment in flight: the commitment, who sent it, who may accept it, and which keys its envelopes were sealed to.

• Seeds: ["note", pool, sender, sequence], where sender is the sender's wallet and sequence is the sender account's sequence before the transfer, as u64 little-endian
• Size: 235 bytes (rent paid by the sender and refunded to the sender when the Note closes)
• Discriminator: cb4bfcc451d27a7e

The envelope hash is

in that order, over the two 1,208-byte envelopes exactly as they appeared in the transfer instruction data. The envelopes are not stored in the account. Anyone who holds the two envelopes, from the transaction itself or from the relay, can check them against the Note before opening them. The Note keeps original_recipient and both key epochs so that the right keys can still be found after a return has re-targeted it.

A sender's sequence only increases, across a close and a reopening too, since a reopened account starts at the current close nonce shifted into the high 32 bits, above every sequence of its earlier generations. The pair (sender, sequence) is therefore never repeated within a pool, and no Note address is ever reused, even after the earlier Note at a lower sequence has closed.

The flags give each Note one of four observable states:

5.3.7BuybackConfig

One BuybackConfig exists per deployment. It fixes what the protocol fees buy and who cranks the buyback, and it carries the burn counter and the claim of a buyback in progress. Pools can have different fee mints; the bought token is one global setting.

• Seeds: ["buyback"]
• Size: 209 bytes
• Discriminator: e21e278b429f99ab

configure_buyback writes every field once, with total_burned, sequence and every pending field zero, and no instruction rewrites token_mint, token_program, keeper or the ratio afterwards. The ratio counts $HINDSIGHT base units per fee-mint base unit: a claim of $a$ fee base units must name a minimum output of at least $\lceil a\cdot n/d\rceil$. claim_buyback fills the pending fields and complete_buyback, in the same transaction, clears them, so between transactions every pending field is zero.

5.3.8RentRecoveryRegistry

One RentRecoveryRegistry exists per deployment. It holds the global close nonce, which every zero-balance proof names and every close_account consumes, and the auditor KeyRecords that close_key_record refuses to close.

• Seeds: ["rent-recovery"]
• Size: $21+32N$ bytes for $N$ protected auditor keys: 21 bytes when created, 53 with one key
• Discriminator: 3859032794e7079c

initialize_rent_recovery creates the registry with close_nonce = 0 and no keys. A protected key is the address of a pool's auditor KeyRecord, ["kem", pool.auditor, pool.auditor_kem_epoch], derived by the program, so a pool's key is protected whether or not the KeyRecord has been registered yet. Adding a key that is already listed changes nothing; adding a new one grows the account by 32 bytes, with the instruction's payer first topping its lamports up to the rent-exempt minimum of the new size from the Rent sysvar. initialize_rent_recovery adds the key of every existing pool and init_pool the key of each new one. No instruction removes a key, resets the nonce or closes the registry.

5.3.9Protocol accounts

The program address protocol_authority, with seeds ["protocol"], has no data account, and no key signs for it. It is the token owner of two kinds of associated token account, each derived by the associated-token program from [protocol_authority, token program, mint]:

The protocol fee account is a 165-byte classic SPL Token account. Both are created by operator setup through the associated-token program, and the buyback transaction also creates the protocol token account idempotently before its claim. The program signs for protocol_authority, with the seeds ["protocol", bump], in two places only: the transfer in claim_buyback and the burn in complete_buyback.

5.3.10Allocation summary