Pool key
create_pool accepts two token identifiers, a fee tier, an initial square-root price, a tick spacing, and an initial tick. The program sorts the token identifiers before hashing:
Pair key
PairKey contains only sorted token0 and token1. It is used by pair_paused, so one pair pause affects every fee tier for that pair.
Tick key
Each tick mapping entry is keyed by the hash of:Position token ID
Mint computes the position identifier from:token_id are public. The recipient and nonce are private inputs. The token ID is therefore an opaque public handle, but it is stable across the position lifecycle. Anyone can follow public updates for that handle until burn removes the mapping entry.
The token ID is not derived from the confidential address formula used for swaps. It is also not, by itself, proof of ownership. The PositionNFT ownership record is the authority consumed by position entry points.
Swap ID
Single-hop swap hashes aSwapKey that includes pool, direction, amount, price limit, recipient, nonce, and caller. The recipient and caller slots both contain the same public confidential address. Its relationship to the signer is not disclosed in ordinary public state. Multi-hop swap hashes the complete SwapMultiHopRequest.
The contract rejects creation when swap_outputs already contains the resulting ID. Nonces should therefore be unique for the relevant request and address.
Token identifiers
Token identifiers arefield values used for dynamic dispatch through IARC20. The token-seeding script encodes a bare program name into a field by packing its UTF-8 bytes little-endian. That script is an API database utility, not a separate on-chain identifier rule.
Production integrations should obtain token identifiers from an approved registry or deployment manifest and verify that the field decodes to the intended program. Do not infer asset identity from a ticker symbol.