> ## 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. # Confidentiality model > How Shield Swap separates public market state, confidential participant data, encrypted records, and selective disclosure. Shield Swap combines a public concentrated-liquidity market with confidential participant records. Prices, liquidity, routes, amounts, and accounting state remain available for consensus and market verification. Wallet ownership and token-record ownership are carried through Aleo private inputs and encrypted records. Public observers can inspect prices, liquidity, routes, amounts, and accounting changes. The intended confidential paths omit participant wallet addresses from public AMM fields. Investigator disclosure and correlation through public data remain possible. The protocol also creates encrypted compliance records for initial position mints and swaps. Those records give a designated investigator account access to signer and caller attribution without publishing that attribution to the market. ## Four data layers ### Public market state The program stores pools, slots, ticks, positions, pending swap outputs, administrative state, pause state, token eligibility, and position freezes in public mappings. These mappings are the shared ledger used by finalization. Public state includes: * Pool token identifiers, fee tier, and enabled state * Current price, active liquidity, tick, fee growth, and protocol fees * Initialized tick liquidity and linked-list pointers * Position range, liquidity, fee checkpoints, and owed amounts, keyed by `token_id` * Swap output and remaining original input, keyed by `swap_id`, until claim * Administrative and control state See [Public data](./public-data) for the operation-level inventory. ### Private proof inputs Leo inputs marked `private` are supplied to the proof without becoming ordinary public arguments. The core program uses private inputs for: * The mint nonce * The mint owner recipient and immutable withdrawal address * Swap and claim blinding factors * Mint, collect, and claim freezelist proofs Aleo records persist on chain as encrypted state. Traders and LPs supply token or `PositionNFT` records to the prover when funding or authorizing an operation. ### Encrypted records Records carry confidential ownership and value. Record fields in this program do not declare explicit visibility, so their values are encrypted for the record owner. The core program returns: * `PositionNFT` records to position owners * Dynamic token change records to token owners * Token output and refund records to claim signers * Token payout records to immutable position withdrawal addresses * Compliance records to `SWAP_INVESTIGATOR_KEY` An encrypted record is different from a public mapping entry. The record owner can decrypt and spend the record. Public finalization still updates the shared accounting state required by the AMM. ### Public pseudonyms Swaps use a public `blinded_address` as both the stored caller and recipient. The confidential address is derived from the program address, a domain constant, the signer, and a private blinding factor. The confidential address is a public, one-use execution pseudonym that omits the signer wallet from public swap fields while remaining bound to the signer and private factor for claims. See [Confidential addresses](./confidential-addresses) for the derivation and claim flow. ## Participant and disclosure views Different parties see different parts of the same operation. | Party | Available information | | ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | Public observer | Public inputs, transaction timing, mapping state, pool changes, routes, amounts, token IDs, position IDs, confidential addresses, and claim activity | | Trader | Public market data, the trader's input and change records, blinding material, and claimed token records | | LP | Public position accounting and the LP's encrypted `PositionNFT` and token records | | Investigator-key holder | Public data plus decrypted mint and swap compliance records owned by `SWAP_INVESTIGATOR_KEY` | | Administrator | Public control state and admin authority. The admin has no extra record visibility unless it also controls the investigator key | | Token program | The token-specific transfer state and restrictions enforced by that program | The initial `DEPLOYER` and `SWAP_INVESTIGATOR_KEY` constants contain the same address. That creates an initial overlap between administration and disclosure access. An admin transfer changes the `admin` mapping but does not change the hardcoded investigator key. ## Trading path A single-hop confidential swap follows this sequence: 1. The trader supplies a token record and a private blinding factor. 2. The trader supplies public market parameters, including pool, direction, amount, limits, deadline, and token identifiers. 3. The contract verifies the public confidential address against the program, signer, domain, and private factor. 4. The token program transfers the input amount from a record into the AMM's public balance. 5. Finalization updates public pool and tick state and writes a public `SwapOutput`. 6. The transition emits an encrypted `SwapComplianceRecord` to the investigator key. 7. A later claim proves the same signer-bound confidential address and supplies the exact public output values. 8. The token program creates token records for the signer. 9. Finalization removes the pending `swap_outputs` entry. Multi-hop execution follows the same model. The route, hop directions, hop price limits, and refund values remain public. ## Position path Position confidentiality uses records rather than swap-style confidential addresses. 1. Mint consumes two token records. 2. The mint owner, immutable withdrawal address, and nonce are private inputs. 3. The program computes a public `token_id` from the public request, private owner, and private nonce. 4. Finalization creates public position accounting under that token ID. 5. The owner receives an encrypted `PositionNFT` that binds the withdrawal address. 6. The investigator receives an encrypted `MintComplianceRecord` containing token ID, nonce, signer, caller, owner, and withdrawal address. 7. Increase, decrease, and collect consume and reissue the PositionNFT while retaining the same token ID. 8. Burn consumes the PositionNFT and removes the public position row after liquidity and owed balances reach zero. `burn` does not return `self.signer` as a public output. The public token ID remains. Position activity is therefore linkable to one pseudonymous position identifier, but the burn output does not directly publish the wallet that signed it. ## Compliance boundary The program supplies selective-disclosure records and operational controls. Legal identity, jurisdiction, participant eligibility, disclosure authority, and retention remain off-chain responsibilities. Compliance records are created only for: * `mint` * `swap` * `swap_multi_hop` They are not created for increase, decrease, collect, burn, claim, freeze, unfreeze, pool creation, or protocol-fee collection. See [Compliance records](./compliance-records) for schemas and lifecycle coverage. ## Confidentiality and compliance boundaries Participant attribution and record ownership are confidential in the intended execution paths. Trade amounts, routes, prices, timing, and public position accounting remain observable. Investigator-owned records provide selective attribution, while legal compliance depends on deployment-specific policies and controls. See [Confidential data limitations](../security/confidential-data-limitations) for the threat and correlation boundaries.