Skip to main content
Public swap and claim fields contain a signer-bound confidential address instead of the signer wallet. The blinding factor used to derive it is private. Swap amount, route, token identifiers, price limits, timing, and pool movement remain public.

​
Contract derivation

The contract defines one claim-or-swap domain constant and verifies:
The program calls Poseidon8::hash_to_address_raw over these values in verify_blinded_address. Including the program address limits cross-program reuse. Including the domain distinguishes this use from unrelated address constructions. Including self.signer means another account cannot claim the same confidential relationship using only a copied factor.

​
Client-side factor derivation

The TypeScript client derives a blinding factor from:
  • Program address
  • A client-side blinding-factor domain
  • Account view-key scalar
  • Local counter
The contract does not verify that the factor came from this view-key and counter scheme. It only verifies the final signer-bound confidential address. Production clients may use another secure factor-generation method if they preserve claim recovery and uniqueness. The contract stores only the public confidential address and a used-address marker. Wallets must preserve the factor or the inputs required to derive it.

​
Swap sequence

For a single-hop swap:
  1. The wallet selects or derives a private blinding factor.
  2. The wallet computes the public confidential address using the AMM program address, domain, signer, and factor.
  3. The wallet submits the token record and private factor.
  4. The wallet submits the confidential address and market parameters publicly.
  5. The contract recomputes the expected address and rejects a mismatch.
  6. The request stores the confidential address as its recipient.
  7. The swap ID also commits to the confidential address.
  8. Finalization stores the confidential address as both recipient and caller in SwapOutput.
  9. Finalization marks the confidential address used.
The multi-hop path stores the confidential address as request recipient and request caller, then applies the same one-use check.

​
Claim sequence

The claimant supplies:
  • Private blinding factor
  • Public confidential address
  • Public swap ID
  • Public token identifiers
  • Public output and refund amounts
The contract recomputes the expected address using the claim transaction’s self.signer. Finalization then requires the supplied confidential address to match both the stored caller and recipient and requires every supplied amount and token ID to match SwapOutput. Token records are created for self.signer. The claimant cannot provide a different payout recipient. Successful finalization removes the pending output.

​
One-time enforcement

used_blinded_addresses is a public mapping. A successful swap rejects an address that is already present and then sets it to true. The entry is not removed after claim. A confidential address is therefore one-use for successful swaps in this program. One-time enforcement does not replace wallet-side concurrency control. Two transactions prepared with the same factor can race. At most one can finalize successfully, and the other incurs a rejected execution path.

​
Recovery requirements

The claim depends on the same signer and factor relationship used for the swap. A production wallet needs to preserve enough state to reconstruct or retrieve:
  • Program ID or program address
  • Domain version
  • Signer account
  • Blinding factor, or its deterministic derivation inputs
  • Confidential address
  • Swap ID
  • Output and refund values read from public state
A backup that restores the account key but not the factor derivation state can leave an output difficult or impossible to claim. If factors are derived from a counter, restoration and concurrent submission must not cause counter reuse. The public used_blinded_addresses mapping can help detect reuse, but it is not a wallet state store and cannot reveal the private factor.

​
Security properties

The construction provides:
  • A public pseudonym that is bound to the transaction signer
  • A private secret required to reproduce the relation
  • Claim restriction to the signer that matches the confidential address
  • One-use enforcement for successful swaps
  • Separation from the program’s other address domains
The claim finalizer also verifies all public token and amount fields and removes the output, preventing cross-user and double-claim paths.

​
Limits

The construction does not provide:
  • Confidential amounts
  • Confidential route selection
  • Confidential pool or token identifiers
  • Confidential claim timing
  • Protection from all statistical correlation
  • Recovery of lost blinding material
  • A legal identity assertion
  • A general stealth-address system for mint or collect
The current TypeScript derivation uses the account view key. A party that receives that view key for wallet indexing may also be able to reproduce derived factors if it knows or can enumerate the counter scheme. Production design should evaluate whether factor derivation should use a separate wallet secret. Different factors generate different confidential addresses, but distinct public operations can still be correlated by amount, route, price movement, network timing, client behavior, or information outside the AMM.

​
Compliance disclosure

The public sees only the confidential address in swap attribution fields. The encrypted compliance record includes:
  • Confidential address
  • Immediate caller
  • Top-level signer
  • Swap ID and request details
The investigator can link the Aleo signer address to the public pseudonym. Linking that address to a legal identity requires an external account binding. See Caller and signer and Compliance records.