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

# Compliance records

> Schemas, recipients, lifecycle coverage, integration requirements, and limits of encrypted attribution records.

Shield Swap emits encrypted attribution records for initial position mints and swaps. The records are owned by a designated investigator account and are not readable from ordinary public state.

Compliance records supply transaction-attribution data. Participant eligibility, sanctions screening, transaction approval, reporting, and lawful disclosure remain operator functions.

## Recipient

Every compliance record sets:

```leo theme={"languages":{"custom":["/languages/leo.tmLanguage.json"]}}
owner: SWAP_INVESTIGATOR_KEY
```

`SWAP_INVESTIGATOR_KEY` is a compile-time address constant. The program initially assigns it the same address as `DEPLOYER`.

The recipient is not read from the `admin` mapping and cannot be changed by an admin transition. Transferring administration does not transfer investigator access.

## SwapComplianceRecord

| Field             | Meaning                                                      |
| ----------------- | ------------------------------------------------------------ |
| `owner`           | Hardcoded investigator recipient                             |
| `swap_id`         | Public identifier for the pending output                     |
| `token_in`        | Input token program ID                                       |
| `token_out`       | Output token program ID                                      |
| `request`         | Complete `SwapRequest`                                       |
| `caller`          | Immediate account or program that invoked `swap`             |
| `signer`          | Top-level account that signed the transaction                |
| `blinded_address` | Public swap pseudonym bound to the signer and private factor |

The embedded `SwapRequest` contains:

* Pool
* Direction
* Input amount
* Minimum output
* Square-root price limit
* Confidential recipient address
* Nonce
* Deadline

## MultiHopSwapComplianceRecord

| Field             | Meaning                                           |
| ----------------- | ------------------------------------------------- |
| `owner`           | Hardcoded investigator recipient                  |
| `swap_id`         | Public identifier for the routed output           |
| `request`         | Complete `SwapMultiHopRequest`                    |
| `caller`          | Immediate account or program that invoked the AMM |
| `signer`          | Top-level account that signed the transaction     |
| `blinded_address` | Public routed-swap pseudonym                      |

The embedded request contains:

* Input and output token IDs
* Input amount and minimum output
* Confidential recipient address
* Up to three hop structs
* Pool, direction, and price limit for every hop
* Hop count
* Nonce and deadline
* Request-level confidential caller address

## MintComplianceRecord

| Field       | Meaning                                          |
| ----------- | ------------------------------------------------ |
| `owner`     | Hardcoded investigator recipient                 |
| `token_id`  | Public position identifier                       |
| `token0_id` | Pool token 0 program ID                          |
| `token1_id` | Pool token 1 program ID                          |
| `request`   | Complete `MintPositionRequest`                   |
| `caller`    | Immediate account or program that invoked `mint` |
| `signer`    | Top-level account that signed the transaction    |
| `recipient` | Confidential owner selected for the PositionNFT  |

The embedded request contains pool, tick range, desired amounts, minimum amounts, and insertion hints.

Mint can have three distinct actors:

* Signer that funds and authorizes the transaction
* Caller program that routes the operation
* Recipient that owns the position record

The record retains all three.

## Parser requirements

The current records retain both `caller` and `signer`. This gives investigators the immediate integration path and the top-level account attribution for routed calls.

Clients that decrypt and parse these records must match the current field sequence. A parser that omits `signer` can fail or silently mislabel data.

The supplied TypeScript types include:

* `SwapComplianceRecord`
* `MultiHopSwapComplianceRecord`

The supplied TypeScript types do not include `MintComplianceRecord`. Compliance integrations must provide and test a typed parser for that record.

## Emission coverage

| Action                  | Compliance record emitted |
| ----------------------- | ------------------------- |
| Initial mint            | Yes                       |
| Single-hop swap         | Yes                       |
| Multi-hop swap          | Yes                       |
| Increase liquidity      | No                        |
| Decrease liquidity      | No                        |
| Collect                 | No                        |
| Burn                    | No                        |
| Claim                   | No                        |
| Freeze or unfreeze      | No                        |
| Pool creation           | No                        |
| Protocol-fee collection | No                        |

The mint record gives the investigator the token ID, position owner, and immutable withdrawal address. The token ID can correlate later public position state. Every collect pays the recorded withdrawal address.

## Storage and discovery

Compliance records are encrypted record outputs, not mapping rows. The AMM does not maintain an investigator inbox or a public index of record commitments by case.

An operator needs to:

1. Scan accepted `mint`, `swap`, and `swap_multi_hop` transitions.
2. Identify record outputs owned by the investigator account.
3. Preserve ciphertext, transaction ID, block reference, program edition, and schema version.
4. Decrypt inside an approved key boundary.
5. Normalize the record into a controlled evidence store.
6. Link the public token ID or swap ID to public execution state.
7. Apply access, retention, and disclosure policy outside the contract.

The AMM exposes no transition to acknowledge, consume, rotate, re-encrypt, or classify a compliance record.

## Data interpretation

The `signer` field identifies an Aleo account. It does not prove:

* A person's civil identity
* Beneficial ownership
* Institutional mandate
* Geographic location
* KYC status
* Sanctions status
* Source of funds

An external identity system must bind an Aleo address to those claims. The record provides transaction attribution once that binding exists.

The `caller` field identifies the immediate integration path. It is useful for distinguishing a direct invocation from a router, custody program, or other intermediary. It should not be treated as the funding account when it is a program address.

## Related pages

* [Caller and signer](./caller-and-signer)
* [Compliance controls](./regulator-and-compliance-review)