> ## 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 data limitations > Information exposure, correlation surfaces, lifecycle gaps, and recovery risks in the confidential execution model. Aleo private inputs, encrypted records, and confidential addresses omit direct participant attribution from ordinary public AMM state. Amounts, routes, prices, ranges, token IDs, and timing remain observable. ## Amounts are public Swap input amount, minimum output, exact output, and refund values are public. Mint desired and minimum amounts are public. Increase, decrease, collect, and claim amounts are public. Token records keep their owner and stored token amount confidential from ordinary public state, but the amount transferred into or out of the AMM is part of the public execution interface. Distinctive sizes can support correlation with off-chain orders, custody movements, or other chain activity. ## Routes and market effects are public Single-hop swaps publish pool and direction. Multi-hop swaps publish every pool, direction, price limit, and hop count. Pool, tick, price, liquidity, fee-growth, and protocol-fee changes are public. A market participant can reconstruct the economic effect of an execution even when the wallet address is absent from the AMM's public fields. Order size, route, price impact, and execution timing remain public. ## Confidential addresses are public pseudonyms A confidential address is a public, one-use pseudonym. The private factor and its relation to the signer remain confidential, subject to correlation and investigator disclosure. The contract binds it to the signer and private factor. `used_blinded_addresses` prevents a second successful swap with the same pseudonym. Public data can still correlate transactions by: * Amount * Route * Price movement * Submission and claim timing * Network metadata * Client behavior * Off-chain order information * Reuse of surrounding accounts or infrastructure The TypeScript client derives factors from a view key and counter. If production adopts that scheme, a party with the view key and enough counter context may be able to reconstruct confidential addresses. A separate derivation secret may provide a better boundary, but it requires its own backup and recovery design. ## Mint does not use confidential addresses Mint computes the public token ID from the public request, private position owner, and private nonce. The `PositionNFT` is encrypted to that owner and also binds a private immutable withdrawal address. The public token ID remains stable through increase, decrease, collect, and burn, allowing observers to link those actions to the same position. The investigator can connect that token ID to the initial signer, caller, owner recipient, and withdrawal address through `MintComplianceRecord`. ## Position activity is linkable by token ID Public position state includes range, liquidity, fee checkpoints, and owed amounts. Position-changing transitions return or use the same token ID. `burn` does not return the direct signer as a public output, but the public `token_id` still links the burn to earlier position activity. ## Investigator access The investigator-key holder can decrypt the compliance records. The investigator receives: * Top-level signer * Immediate caller * Mint recipient or swap confidential address * Public transaction identifiers * Full request data The initial deployer and investigator use the same address, so compromise of that account can affect both administration and record confidentiality. There is no in-contract key rotation. View-key compromise can expose records accessible to that investigator account, and a program change can redirect only future records. ## Lifecycle attribution is incomplete The contract emits compliance records for initial mint and swaps only. It does not emit them for: * Increase * Decrease * Collect * Burn * Claim * Freeze or unfreeze `collect` pays the immutable private `withdrawal` address embedded in the `PositionNFT`. The mint compliance record discloses that withdrawal address to its investigator owner. Swap claims always direct records to `self.signer`, but no new claim compliance record is emitted. ## Signer is not verified identity Compliance records preserve top-level account attribution across intermediary programs through the `signer` field. The field is still an Aleo address. It does not prove: * Natural-person identity * Beneficial ownership * Institutional authority * Jurisdiction * KYC or sanctions status Those assertions require external evidence. ## Mapping removal affects current visibility Current mappings are not complete event history. * Claim removes `swap_outputs`. * Burn removes `positions`. * Accepting admin removes `pending_admin`. * Unfreeze removes `frozen_position`. The freeze block height exists only while the freeze is active. Durable history requires transaction and state-diff indexing. ## Claim values are public and exact Claimants supply output and refund amounts as public inputs. Finalization checks exact equality with the stored `SwapOutput`. Exact equality rejects amount substitution. Rejected claim inputs remain public, so clients must read canonical values from public state. ## Recovery can fail A claim requires the signer and private blinding factor that reproduce the stored public address. The contract cannot recover lost blinding material. Wallet backup must cover: * Account keys * Factor or deterministic derivation state * Domain and program version * Pending swap identifiers * Record discovery state Counter reuse can cause one of two prepared swaps to reject because the address is already used. Counter loss can also prevent deterministic factor recovery. ## Token-program confidentiality varies The AMM calls a dynamic `IARC20` implementation. Record schema, authorization, wrapper behavior, and issuer controls belong to that token program. Token programs can implement different record, authorization, wrapper, and issuer-control behavior. Verify each token before enabling it in a market. ## Integration requirements Production integrations should cover: * Routed compliance records with `caller != signer` * Field-level assertion of the new `signer` member * Swap compliance-record decryption * Multi-hop compliance-record decryption * Key rotation * View-key compromise containment * End-to-end collection attribution Provide a typed `MintComplianceRecord` parser in any integration that ingests mint attribution records. ## Confidentiality terminology `Confidential` applies to participant attribution and record ownership, not transaction economics. Amounts, routes, prices, timing, and lifecycle identifiers remain public. Compliance records permit investigator access but do not establish legal compliance. ## Related pages * [Confidentiality model](../confidentiality/model) * [Public data](../confidentiality/public-data) * [Confidential addresses](../confidentiality/confidential-addresses) * [Trust and key boundaries](./trust-and-key-boundaries)