A swap exchanges assets through one or more execution mechanisms. A trading venue supplies a market; an aggregator compares routes and quotations. The final transaction authorises specific actions and bounds, and its account changes establish what you paid and received.

Where an exchange price comes from

A token swap needs someone or something willing to provide the output asset. An automated market maker uses pool balances and programmed rules. An order book matches available orders. A market-maker quote offers terms under another supported execution flow.

The website is an interface to those mechanisms. Selecting USDC and SOL does not itself establish which program or source will execute the exchange. The route and transaction determine that.

Different venues can quote different amounts because their liquidity, fees and available offers differ. A large pool value is not the same as enough depth at every price along the path of your order.

The pool guide derives a simple automated-market-maker quote. Here we follow the complete user action from that quote to the final account changes.

An aggregator searches for a route

An aggregator compares ways to exchange a given input for an output. It can use a direct pool, multiple steps through an intermediate token or supported quotations from other sources. Some constructions can split work across routes.

Jupiter's current Swap API documents a meta-aggregator path and a route-building path. The former compares supported routing and market-maker sources, while the latter gives builders instructions for a more customised construction. This illustrates why quote generation and network execution are separate jobs.

Raydium and Orca supply examples of AMM markets with their own liquidity rules. An aggregator can use an available venue without becoming the same program as that venue.

For a user, the useful evidence is the selected input/output mints, amount, route, charge treatment and accepted outcome. A route name by itself cannot replace those details.

Read a complete quote

Choose a teaching quote of 100 USDC for 0.5 SOL. This is a made-for-explanation exchange rate, not a current market price. The request should identify the precise input and output mints and whether it is exact-input or exact-output.

In an exact-input operation, you specify the input and constrain the output. In an exact-output operation, where supported, you specify the output and cap the required input.

Read whether the quoted output includes pool and integrator fees. Separate extra SOL expenses, setup funding and tips. Two quotes with different inclusion rules cannot be compared solely by their largest displayed number.

A quote is based on observed conditions or an offer under a stated mechanism. It is not a reservation of every account and price the request may encounter before execution. The signed bounds define what the actual program may accept.

A chosen output bound

A chosen output bound. Chosen input: 100 USDC. Chosen quoted output: 0.5 SOL. Tolerance: 0.5%. Illustrative minimum: 0.4975 SOL.
Teaching quote and tolerance. Actual instruction bounds and rounding control execution.

Compare the net result of two complete quotes

Use two fictional exact-input offers for the same 100 USDC, observed under the same conditions. Offer A shows 0.5100 SOL after trading fees, with another 0.0030 SOL of explicitly excluded network and delivery charges. Offer B shows 0.5085 SOL after trading fees, with 0.0002 SOL of excluded charges.

On that chosen basis, A adds 0.5070 SOL net and B adds 0.5083. B's smaller headline output produces 0.0013 SOL more net because its separately paid charges are lower. If the quote already includes a charge, do not subtract it again.

Keep a refundable account reserve in a separate column. Funding an account can reduce immediately spendable SOL without consuming that amount as a fee. A later closure can return lamports under its authority rules; it cannot refund the network's processing charge. Decide whether your comparison concerns available wallet balance, economic cost or both.

Also compare execution limits and route conditions. A higher expected output with a much weaker minimum is a different offer, and an old quote cannot establish the currently available result. After the trade, use the actual input, credited output and separately identified expenses to close the same ledger.

For an automated order, the timing and custody also change. Limit orders and DCA explains how a later trigger differs from approving an immediate swap.

Turn the quote into acceptable conditions

For a simple exact-input teaching quote of 0.5 SOL and an adverse tolerance of 0.5%, the human-unit lower bound is 0.4975 SOL. The actual instruction uses integer units and the route's precise contract.

Increasing tolerance permits a less favourable outcome. It does not add liquidity or improve the quoted exchange rate. Automatic tolerance is still a policy chosen by the application; read the resulting accepted terms.

The program can reject a trade that falls outside its signed bound. It can also fail for unrelated funding, account or resource conditions. Diagnose the error instead of using a larger tolerance as a universal repair.

For extension-bearing tokens, confirm that the route supports the asset's actual behaviour and understand which quantity the bound measures. The minimum-received guide explains that distinction.

Review setup and token movements before signing

The application builds the transaction and asks your signing system to approve. Inspect source account, mints, amounts, programs and relevant permission changes.

A first-time route can create a token account. A SOL route can wrap native SOL for token-program use and later close an eligible temporary account. Those additional actions should be explainable by the trade you requested.

The signed message binds the constructed request. If it changes, required signatures must cover the final construction. Wallet preview and simulation provide useful information about that request, while the actual executed result is checked afterward.

Save the signature when the request is submitted. If the send response is lost, investigate the existing attempt before authorising a replacement that could repeat the exchange.

Reconcile what the swap actually did

Read execution success, then compare the input debit and output credit for the intended mints. For our teaching request, the starting comparison is 100 USDC spent and the observed SOL amount received, with the effective signed bound retained.

Then read SOL costs and cleanup movements. The net change of an ordinary SOL account can include the fee and returned storage balance as well as the trading output. Follow the instructions rather than mistaking that net number for one pure price.

Compare actual output with the quote under the same input and fee convention. That difference is the quote-to-execution observation; it is separate from how the quoted route compared with the pre-trade reference price.

Keep quote, accepted terms and signature together when reviewing a trade. The price-impact guide explains the two price effects, and the explorer guide shows how to follow the resulting accounts.

Common questions

Is an aggregator the same as a liquidity pool?

No. An aggregator compares and constructs routes; a pool supplies a particular programmed market. A route can use several mechanisms.

Why can the best-looking quote cost more overall?

It may use different fee inclusion or require additional charges and setup. Compare the same input, output and cost basis.

Does a successful swap mean I received the exact quote?

The accepted result depends on signed bounds and program rules. Reconcile the actual receipt with the effective terms and original quote.

Sources and documentation

Found an error or an outdated detail? Send a correction.