How Solana Pools Move Tokens Through CPIs

A Solana pool moves tokens into and out of its vaults by calling the Token Program through cross-program invocations, or CPIs. The pool program validates the instruction, then asks the Token Program to transfer tokens between token accounts. The Token Program checks the transfer authority and updates the balances; the pool program handles its own liquidity accounting.

On a deposit, the user’s token account is the source and the pool vault is the destination. The user signs the transaction, and the pool program forwards that signer privilege with a CPI. The vault is a token account whose transfer authority is commonly a program-derived address, or PDA. For a closer look at the pool-side flow and liquidity accounting, see the byreal guide to pool deposits and concentrated liquidity.

How does a pool authorize a vault transfer?

The pool’s PDA authorizes withdrawals from a vault controlled by that PDA. A PDA has no private key; only the program ID used to derive it can sign for it, by supplying the correct seeds in an invoke_signed call. The pool builds a Token Program transfer instruction naming the vault, the recipient account, and the PDA authority. The runtime verifies the seeds and grants the PDA signer status for that CPI.

Deposits use a different authority path. The user or an approved delegate must authorize the source account’s transfer. The pool cannot use its own PDA to debit a user’s tokens. In both directions, the pool must pass the relevant accounts to the Token Program with the writable and signer privileges the transfer requires.

What does the pool program need to check?

The Token Program enforces transfer rules, but the pool program must make sure the supplied accounts belong to the intended pool action. It should validate that the vault is the expected vault for the pool and mint, that source and destination accounts hold the right mint, and that the authority matches the expected user, delegate, or PDA. A checked transfer also supplies the mint and decimals for validation.

These checks bind token movement to pool state. A transfer alone does not credit a deposit to a liquidity position or calculate a withdrawal. The pool instruction must update its own records using the amount actually permitted by the transfer path. In a concentrated-liquidity pool, that accounting may depend on the position’s price range and the assets required at the current price.

What are the trade-offs of using a CPI?

A CPI lets a pool reuse the Token Program’s transfer rules inside a larger instruction. The transfer and the pool’s state changes can succeed or fail together in the transaction. This keeps token balances and pool accounting from being committed separately, but it also means the pool instruction must supply the right accounts and fit within the transaction’s compute budget.

• A user signature authorizes deposits from that user’s token account.
• A PDA signer authorizes withdrawals from a vault it controls.
• The Token Program checks token-account transfer authority and mint compatibility.
• The pool program validates vault identity and updates its own liquidity records.

For users, the CPI is usually an internal step in a pool instruction. For operators and integrators, the practical check is whether the program ties each transfer to the correct vault, mint, authority, and corresponding pool-state update.