raydium-clmm-liquidity-withdrawal Specification

Purpose

Provide a narrowly scoped protected Raydium CLMM full liquidity decrease using the owner's existing Solana signing and submission primitives.

Requirements

Requirement: Full withdrawal preserves the reusable position

The operation SHALL validate the NFT owner, pool and positive current liquidity, decrease that complete liquidity into the same wallet, collect pool-token fees and preserve the position account, NFT and NFT token account. For each pool or reward mint it SHALL reuse an existing owner token holding, including a non-associated account, after validating its mint, owner, program and initialized state. It SHALL use or create an ATA only when no owner holding exists and SHALL NOT fall back to account creation when holdings discovery fails. Transaction/account details SHALL remain behind Raydium. It SHALL submit once and use existing confirmation behavior without close, burn or service-level retry.

Scenario: Full protected withdrawal

WHEN a wallet withdraws its position's complete liquidity
THEN the transaction names the expected wallet, pool, liquidity and nonzero minimum output protection and contains no close-position, NFT burn or token-account close instruction

Scenario: Wrong owner or changed position

WHEN ownership, pool or current position state is inconsistent with the requested withdrawal
THEN the operation fails before signing

Scenario: Existing non-associated token accounts

WHEN the wallet already has a pool-token or reward holding outside its ATA under either supported token program
THEN the withdrawal targets that validated account and creates no additional account for that mint, preserving subsequent wallet balance reads

Scenario: Existing holding cannot be trusted

WHEN holdings discovery fails or the selected account has a wrong mint, owner, token program or initialized state
THEN withdrawal fails before signing without creating a replacement token account

Requirement: Minimum output derives from precise state and explicit slippage

Withdrawal minimums SHALL derive from current Q64.64 pool state, exact CLMM tick/liquidity math and configured slippage with downward raw-token rounding. Both minimums SHALL NOT be unconditionally zero. Required legacy/Token-2022 accounts, tick arrays and bitmap extension SHALL follow the official decrease instruction. Unsupported token extensions SHALL fail safely before signing.

Scenario: One-sided principal and fees

WHEN the range is fully below the normalized current price
THEN SyrupUSDC principal is protected, any EVE fees return to the wallet and all received EVE remains there

Scenario: Precision and tiny position

WHEN expected principal is too small to provide a positive raw-unit minimum
THEN the operation fails rather than submitting an unchecked withdrawal

2.9 KiB Raw Blame History