Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.raydium.io/llms.txt

Use this file to discover all available pages before exploring further.

​
One-paragraph summary

The AMM Routing program bundles multi-hop swaps into a single on-chain transaction that chains liquidity across pools. You provide a route (a list of pools and intermediate mints) and one instruction with slippage parameters; the router executes all N hops in order, moving output from one pool into the input of the next. No separate on-chain router logic is needed for the price calculation—each hop’s fee and curve are handled by its own pool program via CPI—but the router orchestrates account passing and token movement.

​
Why a separate router program?

Raydium clients and aggregators can always stitch multi-hop swaps together in the client without using the router: build N swap instructions (one per pool) and submit them in a single transaction. Why, then, have a dedicated router program?

​
Reasons to use the router

  1. CPI from other programs. If your own program needs to invoke a route as part of a larger transaction (e.g., a liquidity manager that swaps fees for a target token), CPIing into the router is cleaner than bundling N child CPIs and managing all their accounts in your contract.
  2. Atomic account state. Every hop’s account list is validated in one instruction context. If an intermediate pool’s state is corrupted or a limit-price assertion fails, the entire route fails atomically with no partial settlement.
  3. Single instruction composition. SDKs and frontends can represent a multi-hop route as one logical operation, not as N separate instructions that happen to be consecutive.

​
Client-side stitching is still the default

For most applications, building separate Swap instructions for each pool and submitting them in order is simpler, more composable, and equally valid. The Raydium SDK’s Trade.makeSwapTransaction and similar flows do exactly this for most routes. The router is an alternative, not a replacement. Use it when:
  • You are implementing a program that needs to route as part of a larger atomic operation.
  • You are building an aggregator that wants a single “submit this route” operation.

​
How it works

A router instruction carries:
  • Swap args: exact input (amount_in, minimum_amount_out) or exact output (maximum_amount_in, amount_out).
  • Route specification: a list of program_id + child-program accounts for each hop, in order. The router reads the first account in each hop group to determine which program to invoke.
  • Limit prices (for CLMM): a VecDeque<u128> of sqrt_price_x64 bounds. Only used for hops into CLMM pools; empty deque is an error for older instruction variants.
The router then:
  1. Executes the first hop: transfers amount_in (or calculates the required input for exact-output) to the first pool’s input vault, invokes that pool’s swap, and collects the output.
  2. Chains subsequent hops: for each hop N, uses the output from hop N−1 as the input to hop N.
  3. Enforces slippage: at each CLMM hop, checks sqrt_price against the corresponding limit_price; at the final hop, checks total output against the global minimum_amount_out.
Intermediate tokens can flow either through user-controlled ATAs (one per hop, slower but transparent) or through a shared PDA-derived account (one address for all hops, faster, opaque).

​
Delegation of pricing and fees

The router does not compute prices itself. Each hop delegates to the child program’s curve:
  • AMM v4: uses the constant-product formula with OpenBook hybrid pricing.
  • CPMM: uses the constant-product formula with the configured fee tier.
  • CLMM: uses the concentrated-liquidity math with tick-based pricing.
  • Stable: uses the stable-swap curve for like-kind tokens.
Fees are charged by each pool according to its own configuration. The router takes no fee of its own.

​
When to avoid the router

  • Low hop count (1–2 hops). The account-passing overhead is minimal; just use two separate swap instructions.
  • Non-Raydium pools. The router only knows about the four Raydium pool types. For routes that cross external programs, stitch instructions in your client.
  • Conditional routing. If you need to branch on prices or pool states mid-route, on-chain routing is less flexible than client-side composition.

​
Mental model

Think of the router as a transaction-packing utility. It takes your route specification and packs it into one instruction, one transaction, one compute budget. Each hop internally CPIs into its pool program and handles the curve math there. The router’s job is to pass accounts correctly, move tokens between hops, and check slippage.

​
Where to go next