> ## 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.

# Protocol boundaries

> What the Shield Swap program enforces, what the API exposes, and what clients and operators must supply.

`shield_swap.aleo` is the accounting and control core. It is not a wallet, indexer, custody system, or operating policy. `shield_swap_router.aleo` and `shield_swap_lp_router.aleo` adapt wrapped assets to the core program.

## Responsibility matrix

| System                | It is responsible for                                                                             | It is not responsible for                                                              |
| --------------------- | ------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- |
| Shield Swap program   | Pool state, tick accounting, swaps, positions, fees, pending claims, and protocol controls        | Route discovery, record storage, key custody, finality monitoring, or policy decisions |
| Token program         | The concrete transfer functions and token-record behavior it implements                           | AMM pricing, position accounting, or Shield Swap controls                              |
| REST API and indexer  | Indexed data, routes, history, events, and current transaction input schemas                      | Signing, proving, submission, finality, or record reconciliation                       |
| Wallet or application | Records, signing, proving, submission, claims, retries, and user-visible transaction state        | Changing contract invariants or bypassing program controls                             |
| Operator              | Deployment identity, administration, monitoring, key custody, asset policy, and incident response | Rewriting finalized program behavior through documentation or policy                   |

## Visibility matrix

| Data                                                                               | Visibility                                         |
| ---------------------------------------------------------------------------------- | -------------------------------------------------- |
| Pools, prices, ticks, liquidity, fee growth, and controls                          | Public                                             |
| Trade tokens, amounts, routes, output, refund, and timing                          | Public                                             |
| Position range, liquidity, fees, and owed-token accounting                         | Public                                             |
| Token-record and `PositionNFT` ownership                                           | Confidential in the intended execution flow        |
| Participant attribution in mint and swap investigator records                      | Encrypted to the configured investigator recipient |
| Keys, decrypted records, intended orders before submission, and custody procedures | Off-chain client or operator responsibility        |

Shield Swap keeps participant ownership out of ordinary public mappings. It does not make market activity anonymous.

## Program boundary

The program enforces:

* canonical pool and token ordering
* concentrated-liquidity and initialized-tick accounting
* single-hop and multi-hop execution limits
* LP and protocol fee accounting
* position creation, replacement, freeze, unfreeze, and burn rules
* pending swap output and refund accounting
* confidential-address verification for swaps and claims
* encrypted investigator records for mint and swap creation
* admin gates, token eligibility, pause controls, and fee settings

## Token boundary

The AMM calls the dynamic `IARC20` interface. A production integration must verify the exact token program's transfer behavior, decimals, record shape, authorization rules, issuer controls, upgrade authority, and wrapper redemption path.

Included wrappers and test tokens do not prove that every production asset behaves the same way.

## Client boundary

A production wallet or application must supply:

* record discovery, reservation, and spent-state tracking
* change and replacement record storage
* confidential-address factor creation, retention, and recovery
* nonce uniqueness
* transaction construction, proving, submission, and finality monitoring
* mapping reads and nested Leo parsing
* quote simulation and conservative transaction limits
* claim submission after swap acceptance
* reconciliation between public mappings and wallet-held records

The test harness demonstrates parts of this work. It does not remove the responsibility from a production client.

## Routing boundary

The contract executes the route supplied by the caller. It does not compare pools, choose a fee tier, split an order, or estimate price impact across alternatives. The router must construct a valid token chain and a directionally valid price limit for every hop.

## Compliance boundary

The program creates encrypted investigator records for mint and swap creation and exposes administrative controls. It does not decide whether a participant may trade, whether a disclosure request is valid, what data-retention period applies, or which jurisdiction governs an operator.

Those decisions require deployment-specific policy, authorization, custody, audit, and reporting systems.

## History boundary

Public mappings hold current consensus state, not a durable event archive. Entries can change or disappear after claim, burn, or unfreeze. Historical reporting requires an independent transaction and mapping-change archive.

Continue with [Security model](../security/security-model) for threats and assumptions, or [Choose an integration path](../developers/integration-path) for implementation ownership.