Skip to main content
Use this page to identify what the program protects and where security depends on token programs, client software, administrators, or key custody.

​
Threat boundaries

The program can reject an invalid state transition. It cannot make a compromised client, token program, administrator, or custody process trustworthy.

​
Protected assets

  • Token balances held by the AMM and user records
  • Position authority carried by PositionNFT
  • Pool price, active liquidity, ticks, fees, and owed-token accounting
  • Pending swap output and refund entitlements
  • Private blinding factors and record decryption material
  • Investigator view-key material and decrypted compliance data
  • Admin and upgrade authority

​
Core accounting invariants

  • Pool tokens are sorted, distinct, and bound to the expected token IDs.
  • The current square-root price lies in the current tick interval.
  • Active liquidity matches the ranges that contain the current tick.
  • An initialized tick’s gross and net liquidity reconcile with positions.
  • Linked-tick pointers are sorted and reciprocal.
  • Swap fees are applied to the liquidity active when earned.
  • Position settlement uses modular fee-growth deltas and the correct liquidity epoch.
  • A pending swap output can be claimed once and only with exact stored fields.
  • A position can be burned only after liquidity and owed balances reach zero.
The protocol completes initialized-tick crossing at an exact price limit, protects the zero-effective-input arithmetic path, and isolates fee ownership across liquidity epochs. Burn omits the signer from its public output, while encrypted compliance records preserve signer and caller attribution for the investigator.

​
Confidentiality assumptions

Records and private inputs rely on proof and encryption for confidentiality. Public protocol state still exposes amounts, pools, routes, ranges, token IDs, timing, and control actions. Confidentiality does not prevent statistical correlation. Control of the investigator key grants access to participant-attribution records and must be treated as disclosure authority.

​
External trust

The AMM delegates token transfers to dynamic token programs. Security depends on their code, state, upgrade authority, and transfer semantics. Clients are also part of the trust boundary. A client can leak private keys, view keys, blinding factors, decrypted records, or intended trades before proof submission.

​
Administrative trust

The operational admin can change market availability, configuration, protocol fee share, and position freeze state. Operational actions are not multisig-gated by the AMM itself. Program upgrade authorization is separate. The current Q128 storage layout requires a fresh deployment when migrating from a Q64 deployment, which creates a new configuration and migration trust boundary.

​
Compiler warnings

Leo 4.3.4 emits checks-effects-interactions warnings where some finalizers call token futures before later reads, assertions, or writes. Compilation and tests continue despite the warnings. Auditors should analyze atomic rollback and external token behavior at every warning site.

​
Failure posture

Arithmetic and assertion failures reject execution. Repeated rejections can reduce availability, so operators should distinguish malformed requests, stale state, unsupported assets, and invariant failures.