To execute a Solana swap at an acceptable price, treat every quote as temporary and enforce its minimum output when the transaction executes. The exact expiry and execution rules depend on the route, so your integration should check them again immediately before asking the user to sign.

What should a quote mean in your app?

A quote should describe a specific trade, not promise a fill. For an exact-input swap, record the input and output token mints, the input amount in the token’s smallest units, the expected output, the minimum acceptable output, and the route used. Keep raw integer amounts for calculations; format them into decimal token amounts only for display.

Slippage is the difference between an expected price and the execution price. Investopedia’s financial glossary uses the term for price movement between placing and completing a trade; on Solana, your transaction’s minimum-output condition turns that tolerance into a clear execution limit. For example, if a quote returns 2.00 SOL and the user accepts 0.5% slippage, the minimum output is 1.99 SOL, subject to the venue’s rounding rules.

Why can the route change the integration?

A swap can use an on-chain concentrated liquidity pool (CLMM), where the trade moves through pool liquidity, or an off-chain Request-for-Quote (RFQ), where a market maker supplies a price for a specific trade. Byreal combines CLMM and RFQ execution and can also route through external Solana liquidity, so a quote adapter should preserve the route type and any route-specific expiry or signing requirements.

When deciding whether to expose one generic quote-and-swap flow, read Byreal on Solana because its CLMM and RFQ paths have different execution assumptions: a pool quote can move with pool state, while an RFQ offer may be valid only for a short time or specific transaction details. Present the user with a consistent summary, but keep those distinctions in the execution layer.

How do you turn a quote into a safe transaction?

Build the flow around a checkout that swaps USDC for SOL to pay a user’s network fee. Request a fresh quote for the precise input amount, show the expected output and route, then rebuild or refresh if the user takes too long to approve it. Solana Documentation explains that a transaction includes instructions, authorizing signatures, and a recent blockhash; the blockhash expires, and failed transactions can still incur fees.

  1. Validate the pair and amount. Check token mints against your supported-token list, reject zero or malformed amounts, and convert using each token’s decimals. This prevents a ticker collision or decimal mistake from silently changing the trade.
  2. Request and normalize a quote. Ask the integration’s supported quote interface for the exact input, then store expected output, minimum output, route, fee details, and any expiry or transaction constraints. Do not assume a quote response is itself a signed or executable transaction.
  3. Set a user-facing price limit. Choose a slippage tolerance appropriate to the app’s use case and calculate the minimum output using integer arithmetic. For a volatile token or a large trade, a tight limit can cause more failed swaps; a loose limit permits a worse fill.
  4. Refresh before signing. If the quote has expired, the route changed, or the minimum output is no longer acceptable, request a new quote and show the updated result. Do not silently replace the user’s approved price.
  5. Simulate, sign, and confirm. Simulate the transaction where supported, inspect its fee payer and instructions, then request the user’s signature. After submission, track confirmation and report the actual token balance change, not merely the quoted output.

What should you show after submission?

Separate the swap’s trading fee from Solana’s network and priority fees, and explain whether account rent may be needed for a token account. Byreal’s fee documentation distinguishes on-chain pool fees from RFQ execution costs, while Solana’s fee documentation explains that base and priority fees may be charged even when a transaction fails. Display the confirmed output and transaction status so a retry does not accidentally submit a second swap.

Keep the quote, user-approved minimum, and confirmed result together in your logs. That gives support and monitoring a useful record when a quote expires, a transaction fails, or a route executes differently than expected.