Validate an integration
Establish acceptance criteria for swaps, liquidity changes, and custom pool behavior.
An integration is complete when the result shown to the user matches the authorized operation and its settled state. Use the criteria below for each market and hook configuration your application supports.
Swaps
- Parse amounts using the actual mint decimals and integer atoms.
- Match ExactIn or ExactOut to the user's intent, including partial-fill behavior.
- Enforce minimum net output or maximum input and the chosen price limit.
- Reconcile actual input, output, input fees, and optional output fees after success.
- Reject missing tick pages, unavailable hook evaluators, and unsupported token programs.
Use swap modes and quote consistency for the detailed contract.
Liquidity
Open a position with aligned endpoints, add liquidity within token maxima, remove principal within minima, collect fees, and close only an empty position. Cover both an active range and a one-sided range outside the current price.
A zap changes more than one balance. Attribute only operation-funded amounts, preserve user limits, and confirm that a failed conversion reverses the entire operation. See LP lifecycle and zaps.
Curves and graduation
Keep virtual reserves separate from spendable vault balances. Verify the real-inventory bound and net quote target. Graduation is a separate atomic instruction: confirm CLMM mode, the creator-owned position, unchanged pool identity and hook, and the recorded remainder.
The bonding-curve guide describes the transition.
Hooks and failure behavior
Validate identity, policy state, phase order, permissions, and reply bounds. Reject every enabled phase in a controlled scenario and compare all affected state before and after. Do not infer settlement from logs emitted by a transaction that failed.
Follow hook validation and security invariants. Record the exact program and interface versions associated with each supported flow.