> ## Documentation Index > Fetch the complete documentation index at: https://shield.fi/docs/llms.txt > Use this file to discover all available pages before exploring further. # Confidential addresses > Construction, use, recovery, one-time enforcement, and correlation limits for confidential swap addresses. 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: ```text theme={"languages":{"custom":["/languages/leo.tmLanguage.json"]}} blinded_address = Poseidon8( program_address, claim_or_swap_domain, signer_address, blinding_factor ) ``` 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](./caller-and-signer) and [Compliance records](./compliance-records). ## Related pages * [Confidentiality model](./model) * [Confidential data limitations](../security/confidential-data-limitations)