# 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