Raydium limits are CLMM minimum order and tick-placement rules

Off-grid prices and wrong-side ticks stop order creation

One invalid tick rejects a Raydium CLMM limit order before the token deposit moves into the pool vault.

Placement validates five related constraints. The target tick must divide evenly by the pool’s spacing, remain inside the limit-order range, and lie beyond the current tick in the sell direction. The net amount must produce at least one output base unit. Both swap status bit 4 and limit-order status bit 5 must permit activity, while the owner’s input and output token accounts must remain transferable. These checks run together, so correcting only the displayed price leaves a size or account failure unresolved.

Together, these Raydium limits define an admissible order before any fill logic matters.

Raydium, Jupiter, OpenBook, and Orca apply different price constraints

Four execution models separate pool-bound prices, routed triggers, order-book lots, and concentrated-liquidity ranges on Solana.

A Raydium native limit order commits tokens to one CLMM pool and one legal tick. Jupiter Trigger Orders use USD conditions and a routed, vault-based execution workflow rather than one pool’s tick grid. OpenBook markets expose a central limit order book whose market configuration defines price ticks and order lots. An Orca Whirlpools position selects a liquidity range, earns pool fees while active, and remains a liquidity position rather than a fixed-output order. The deciding dimensions are price representation, liquidity dependency, custody workflow, and whether the position earns fees.

The minimum size begins with one output base unit

One output base unit is the hard lower bound for every accepted Raydium CLMM limit order.

Raydium evaluates the input after any Token-2022 transfer fee. For a token0 sale, the program rounds down input multiplied by the tick price. For a token1 sale, it rounds down input divided by that price. The smallest valid input is therefore the first integer producing an output of at least 1 in the output mint’s raw units.

In a hypothetical equal-decimal pair priced at 0.25 output units per input unit, four input base units produce one output base unit.

The accepted implied-output range runs from 1 through 18,446,744,073,709,551,612 base units. That upper boundary comes from the unsigned 64-bit amount representation; the guard rejects its top three values. Wallet balances, mint supply, and pool vault balances impose much smaller operational ceilings. For ordinary orders, the useful calculation is the lower bound: convert at the chosen tick, round down, and confirm the result remains at least one raw output unit.

Token decimals translate the raw floor into a display amount

Six decimals make one USDC equal 1,000,000 base units on Solana for order validation and settlement.

Wrapped SOL uses 9 decimals, so one token equals 1,000,000,000 raw units. A minimum of one output base unit therefore means 0.000001 USDC or 0.000000001 wrapped SOL, not one whole token. Raydium stores the CLMM ratio as token1 per token0 and sorts the two mints by public key, not by ticker. A client must adjust the raw ratio for both decimal counts and invert it when displaying the opposite quote direction. Reading only the rounded wallet amount can hide a one-unit threshold failure.

Tick spacing determines every placeable price

One tick multiplies the raw token1-per-token0 price by exactly 1.0001 inside Raydium CLMM mathematics.

In that configuration, Raydium CLMM defines tick prices with 1.0001 raised to the tick across the mathematical range from -443636 through 443636. Limit orders use only spacing-aligned ticks strictly inside those endpoints. If spacing is 8, legal indices include -16, -8, 0, 8, and 16; an index of 10 fails even when its displayed price looks reasonable.

Spacing also determines price granularity. A spacing of 1 creates approximately 0.01% between adjacent legal prices, spacing 8 creates approximately 0.080028%, and spacing 64 creates approximately 0.6420%. The configuration caps tick spacing at 1000. Raydium copies spacing into the pool at creation, and that field does not change with the market. The associated trade-fee rate belongs to the same pool configuration, but administrators can update the fee rate without rewriting the established tick grid.

Order direction keeps the target beyond the current tick

Two direction values decide whether the legal target lies above or below the pool’s current tick.

With zero-for-one set to true, the order sells token0 for token1 and requires a target tick greater than the current tick. With zero-for-one set to false, it sells token1 for token0 and requires a lower target. A target exactly equal to the current tick fails, even when it matches the spacing. The limit-order check also excludes -443636 and 443636 themselves, leaving the unaligned inner range from -443635 through 443635 before spacing removes additional values.

This direction rule prevents an order from opening at a price the swap path has already crossed. Compare the selected tick index, not merely the human-readable quote, because mint order and decimal adjustment can invert the displayed market.

A four-stage lifecycle preserves the recovery trail

Four stages cover preparation, opening, settlement, and closure for a native Raydium CLMM limit order.

Opening selects one nonce-account index stored as an unsigned 8-bit value, giving indices from 0 through 255. The order itself receives a program-derived address, or PDA, tied to the owner and nonce state. Settlement accepts the owner or Raydium’s designated operational signer, yet proceeds always target the owner-controlled output account. Closure follows the same authority boundary, and its rent refund always returns to the recorded order owner. Save identifiers at opening rather than reconstructing the history from rounded balance changes.

Partial fills freeze additions to the older cohort

One partial fill advances the tick cohort and blocks further increases to an order from the older phase.

Typically, Raydium groups waiting orders at a tick by order phase. The matching engine consumes an older partially filled cohort before moving into newer order amounts. Within a cohort, an unfilled-ratio snapshot allocates the remaining amount across its orders. Once matching changes the tick’s phase, IncreaseLimitOrder rejects an addition whose stored phase no longer matches. Settle or decrease the existing order, then open a fresh order for additional size at the same legal tick.

Partial settlement uses integer arithmetic. When proportional division is inexact, the calculation withholds at most 1 output base unit for the segment and recovers that unit after the order fills completely. The displayed fill percentage may therefore move before a spendable balance changes for a very small order.

Cancellation settles fills before returning unused input

One positive decrease amount starts cancellation, while a zero amount fails the instruction before any state changes.

DecreaseLimitOrder first calculates and pays output already filled, then returns no more than the remaining unfilled input. Requesting a decrease larger than the remainder does not overdraw the order; the program caps the withdrawal at the available amount. The amount_min field checks the returned input after any Token-2022 transfer fee. If a partial decrease leaves an open remainder, that remainder must still imply at least one output base unit at the original tick.

Closing is a separate action. CloseLimitOrder succeeds only when the unfilled amount equals 0, after a full fill or complete decrease. The account rent then returns to the owner address embedded in the order state. This sequence makes settlement, cancellation, and account cleanup independently verifiable.

Token-2022 changes net amounts and account checks

Two token programs matter: the original SPL Token Program and Token-2022 with supported extensions on Raydium CLMM.

For a Token-2022 mint carrying a transfer-fee configuration, Raydium subtracts the transfer fee from the gross opening deposit before applying the one-output-unit test. The same net treatment applies when increasing an order. Output settlement also uses the mint’s checked transfer path, so a configured output transfer fee reduces the owner’s spendable receipt. The percentage and maximum fee belong to the mint configuration, not the Raydium order.

Opening requires owner-controlled accounts for both input and output mints, even though only the input account funds the order. Neither account can be frozen. Interfaces such as Phantom and Solflare commonly present associated token accounts, while the program verifies mint and owner relationships directly. This two-sided validation ensures later output has an eligible destination.

Verification follows the pool, order PDA, and token accounts

Three identifiers - the pool address, order PDA, and opening signature - anchor a reliable Raydium limit-order record.

After opening, inspect the order owner, pool identifier, tick index, direction flag, total amount, filled amount, and opening time. Confirm the tick divides by pool spacing and remains on the required side of the current tick. Solscan exposes transaction instructions and account addresses, while Phantom or Solflare shows resulting token balance changes. A chart crossing the displayed target proves only market movement; order state shows whether swap flow matched the tick. Settle filled output, verify the destination account, and close the order after its unfilled amount reaches 0.

The order account does not refresh its filled amount during every matching swap because swaps update the tick cohort, not each member account. Settlement or decrease reconciles the order against the cohort’s unfilled ratio and then refreshes its filled amount. Tick state and order state therefore belong in the same verification pass.