How Token Swaps and DEXs Work on Solana

Swapping one token for another is one of the most common things people do on a blockchain — and one of the least understood. This article explains what actually happens under the hood on Solana: no advice, no recommendations, just the mechanics.

The problem: trading without a middleman

On a traditional exchange, a central company holds everyone's funds, keeps a ledger of buy and sell orders, and matches them. You trust the company to hold your money and settle honestly.

A decentralised exchange (DEX) has no such company. There is no central ledger and nobody holding your funds. So the question becomes: if there is no matchmaker, how do two people ever trade? The answer that most Solana DEXs use is surprisingly elegant.

Liquidity pools instead of buyers and sellers

Instead of matching a buyer to a seller, most DEXs use a liquidity pool: a smart contract holding a reserve of two tokens, say token A and token B. Anyone who wants to swap doesn't trade with another person at all — they trade with the pool. You put token A in, the pool sends token B back.

The reserves in that pool are supplied by people called liquidity providers, who deposit both tokens so the pool has something to trade with. Understanding why they'd do that is a separate topic; what matters here is that the pool is simply an on-chain account holding balances, which any program can interact with.

How the price is decided: automated market makers

With no order book, something has to decide the exchange rate. That job falls to a formula, which is why these systems are called automated market makers (AMMs).

The classic approach keeps the product of the two reserves constant. If a pool holds 100 of token A and 100 of token B, their product is 10,000. When you swap some token A in, the pool's A reserve rises and its B reserve must fall to keep that product roughly the same — and the ratio between the reserves is the price you get.

Two consequences fall straight out of this:

• Price moves as you trade. The bigger your swap relative to the pool, the worse the rate you get, because you're shifting the reserves as you go. This is usually called price impact or slippage.
• Deeper pools mean stabler prices. A pool with large reserves barely notices a small swap; a thin one moves sharply.

No human sets these prices. The formula and the current reserves determine them entirely.

What happens on Solana when you swap

Now the Solana-specific part. Recall from our architecture article that on Solana, all data lives in accounts, and programs are stateless code that operates on the accounts passed to them. A swap is a clean example of that model in action.

Step by step, roughly:

• You build a transaction containing an instruction that calls the DEX's on-chain program.
• The instruction declares every account it will touch: your token accounts, the pool's reserve accounts, and the pool's configuration account.
• You sign the transaction, proving you authorise moving tokens out of your account.
• The program validates everything: are these the right accounts, do you have the balance, does the resulting price fall within the limits you specified?
• If all checks pass, the program updates the balances — your token A moves to the pool, the pool's token B moves to you — and the transaction is recorded.

The whole thing either happens completely or not at all. If any check fails, the transaction reverts and nothing moves.

Why Solana's design matters here

Two architectural choices we covered previously show their value in this use case.

Declaring accounts up front enables parallelism. Because every transaction states exactly which accounts it will read and write, the network can execute swaps touching unrelated pools at the same time. Two people swapping in two different pools don't have to queue behind each other.

Low fees change what's practical. When each transaction costs a tiny fraction of a cent, small swaps and frequent adjustments become viable in a way they aren't on chains with high per-transaction costs. This is a direct consequence of the throughput design, not a separate feature.

Slippage limits: why transactions fail

Because prices shift between the moment you submit a transaction and the moment it executes, swap instructions almost always include a minimum amount you'll accept. If the market moves enough that the program can't meet that minimum, it rejects the transaction rather than giving you a worse deal.

This is why a swap sometimes simply fails. It isn't a bug — it's the safety check working as designed.

Aggregators: one more layer

There are many pools for the same token pair, spread across different DEX programs, each with different reserves and therefore different prices. An aggregator is a program that surveys them and routes a swap across whichever combination gives the best result — sometimes splitting a single swap across several pools at once.

From the user's point of view it's one action. Underneath, it may be several instructions bundled into one transaction, which Solana's model handles naturally.

Putting it together

A swap on Solana is not a trade with a person. It's a transaction that calls a program, which validates a set of accounts and updates balances in a pool according to a formula. The price comes from reserve ratios, the safety comes from checks in the program and limits you set, and the speed comes from the same architecture that makes everything else on Solana fast.

If the account model or parallel execution mentioned here is unfamiliar, our article on Solana's architecture covers both in detail — it's the foundation this all sits on.

This article explains how the technology works. It is educational content only and is not financial advice or a recommendation to use any particular protocol or service.