What Is a DEX — The Math Behind AMMs

I know how Solana accounts work. I know how to read them through RPC. I can pull raw bytes off the blockchain and decode them into meaningful data. But here's what I want to understand next: the data I'm reading from — those liquidity pool accounts on decentralized exchanges (DEXs) — I don't actually understand what they represent. Not really. I know they contain token reserves and some configuration parameters. I know that when the reserves change, prices change, and somewhere in that shift there might be an arbitrage opportunity. But the mechanism? The math that an automated market maker (AMM) uses to determine why one pool says SOL is worth $150 and another says it's worth $148? That's still a black box.

I'm cracking it open now.

Because if I'm going to build a bot that finds price discrepancies across decentralized exchanges, I need to understand — at a fundamental level — how those exchanges determine prices in the first place. Not at the "I've read the Wikipedia summary" level. At the "I can compute the exact output of a trade given the pool's current state" level. The math matters. It's the entire foundation.

The World I Already Know: Order Books

Before diving into how decentralized exchanges work, it helps to anchor on what I already understand — traditional exchanges. Because the whole point of a DEX is to solve problems that traditional exchanges can't solve in a decentralized context, and you can't appreciate the solution without understanding the problem.

A traditional exchange — whether it's the New York Stock Exchange, Nasdaq, or any centralized crypto exchange — runs on an order book. The concept is straightforward. Think about the floor of a stock exchange, the way it looked in old movies before everything went electronic. Buyers standing on one side shouting the price they're willing to pay. Sellers on the other side shouting the price they're willing to accept. A specialist in the middle, matching them up whenever a buyer's price meets a seller's price. That's an order book in its most physical form.

In the digital version, the shouting is replaced by limit orders. A buyer places an order: "I want to buy 10 SOL at $148 each." A seller places an order: "I'm willing to sell 15 SOL at $150 each." These orders sit in the order book, waiting. The $148 bid and the $150 ask don't match, so nothing happens. They just sit there. The gap between the best bid and the best ask — in this case, $2 — is called the spread.

Then a new buyer comes in: "I want to buy 5 SOL at $150." Now there's a match. The matching engine pairs this buyer with the seller at $150, the trade executes, and both orders are updated. The buyer gets 5 SOL. The seller delivers 5 SOL and receives $750. Clean. Simple. Price discovery happens organically through the collective behavior of all the buyers and sellers posting their orders.

This system works beautifully when it works. The stock market floor has operated on this principle for over a century. And centralized crypto exchanges — Coinbase, Binance, Kraken — do the same thing digitally. They run massive matching engines that process thousands of orders per second, maintaining order books for every trading pair, matching buyers and sellers with microsecond precision.

But there's a catch. Actually, there are several catches, and they all matter in the blockchain context.

First: the matching engine is centralized. One company runs it. That company can go down, get hacked, freeze your account, or simply decide you're not allowed to trade anymore. If you've ever had a brokerage account frozen during a volatile market — or watched it happen to someone else — you know how that feels. You're locked out of your own money at exactly the moment you need access most.

Second: liquidity is fragmented. Every exchange has its own order book. The SOL/USDC order book on Exchange A is completely separate from the SOL/USDC order book on Exchange B. A buyer on A can't be matched with a seller on B. This means the "true" price of SOL is never in any single place — it's spread across dozens of independent order books, each with its own supply and demand dynamics. Arbitrageurs exist specifically to close these gaps, buying on the cheap exchange and selling on the expensive one until prices converge. That's been the arbitrage game for decades.

Third — and this is the big one for decentralized systems — order books require market makers. Someone has to be posting those bid and ask orders, maintaining tight spreads, providing the liquidity that allows trades to happen. On traditional exchanges, these are professional firms with sophisticated algorithms, dedicated servers co-located next to the exchange, and deep pockets. They're doing the exchange a service by keeping the order book liquid, and in return they make money on the spread.

On a blockchain, running a traditional order book is brutally impractical. Every order placement is a transaction. Every cancellation is a transaction. Every modification is a transaction. Professional market makers adjust their orders thousands of times per minute as prices move. On a blockchain where each transaction costs a fee and takes time to confirm, this model falls apart. The gas costs alone would eat market makers alive. And the speed — even on Solana, the fastest major blockchain, a slot takes about 400 milliseconds. Try running a competitive market-making strategy when your order modifications take 400 milliseconds instead of 400 microseconds.

So the decentralized finance world needed a different approach. An approach that doesn't require a centralized matching engine, doesn't depend on professional market makers posting and canceling thousands of orders, and can provide continuous liquidity without any human intervention at all.

That approach is the AMM.

The AMM: A Vending Machine for Tokens

AMM stands for Automated Market Maker, and the name is more descriptive than it might seem at first glance. It's a market maker — something that provides liquidity and determines prices. It's automated — it runs on a smart contract, executing without human intervention. And it makes the market — it's always willing to trade, at any time, in any size (within limits), with anyone.

The best analogy I've found is a vending machine. Not a perfect analogy — no analogy ever is — but it captures the essential nature of the thing.

A traditional exchange is like a farmer's market. Buyers and sellers show up, negotiate, haggle, and trade directly with each other. The prices emerge from those negotiations. If nobody's selling tomatoes today, you can't buy tomatoes. If twenty people are selling tomatoes and only one person is buying, prices drop until more buyers show up. The market requires active participation from both sides.

An AMM is like a vending machine. The machine is always there. It always has inventory (tokens). It always has a price. You walk up, put in your money, press a button, and out comes your token. You don't need to find a seller. You don't need to negotiate. The machine handles everything. And here's the critical detail: the machine adjusts its prices automatically based on its remaining inventory. As the machine runs low on a particular item, that item gets more expensive. As the machine gets restocked with something, that thing gets cheaper. No human is standing behind the machine turning price dials. The pricing is baked into the machine's logic.

This is what an AMM does. It holds a pool of two tokens — say, SOL and USDC. Anyone can come along and trade SOL for USDC or USDC for SOL. The AMM always quotes a price. The price is determined by a mathematical formula based on the current quantities of each token in the pool. No order book. No matching engine. No market makers placing and canceling orders. Just a formula, applied to the current state of the pool, producing a price.

The simplicity is almost suspiciously elegant. You replace an entire infrastructure of order books, matching engines, and professional market makers with... a formula. One formula. And it works. Not perfectly — there are trade-offs, and they matter — but well enough to handle billions of dollars in daily trading volume across thousands of token pairs.

So what's the formula?

x * y = k

This is it. The entire pricing engine of the most common type of AMM — the constant product market maker — boils down to three characters and two operators.

x * y = k.

Let me break it down, because the simplicity is deceptive. There's a lot of depth hiding behind those five symbols.

x is the quantity of Token A in the pool. Let's say SOL.

y is the quantity of Token B in the pool. Let's say USDC.

k is a constant — the product of x and y. And here's the rule: after every trade, k must remain the same. The quantities of x and y can change — in fact, they change with every trade — but their product must stay constant.

That's it. That's the rule. And from this single constraint, everything else follows.

Let me walk through a concrete example, because this is where the abstract becomes tangible.

Imagine a pool that starts with:

• 100 SOL (that's x)
• 50,000 USDC (that's y)
• k = 100 × 50,000 = 5,000,000

What's the current price of SOL in this pool? It's y/x = 50,000/100 = 500 USDC per SOL. Simple ratio. If the pool has 50,000 USDC and 100 SOL, then each SOL is "worth" 500 USDC according to the pool's reserves.

Now someone comes along and wants to buy SOL with USDC. They want to put in 5,000 USDC and get SOL in return. How much SOL do they get?

This is where the formula does its work. After the trade:

• The pool will have 50,000 + 5,000 = 55,000 USDC (y went up because the trader added USDC)
• k must still equal 5,000,000
• So x must equal k / y = 5,000,000 / 55,000 = 90.909... SOL

The pool started with 100 SOL and now has 90.909 SOL. The difference — about 9.09 SOL — is what the trader receives. They put in 5,000 USDC and got 9.09 SOL.

Wait. If SOL was priced at 500 USDC, shouldn't 5,000 USDC buy exactly 10 SOL? That's what 5,000 / 500 equals. But the trader only got 9.09 SOL. Where did the "missing" 0.91 SOL go?

It didn't go anywhere. This is the formula working exactly as designed. And this right here is the single most important concept to grasp about AMMs: the price moves against you as you trade.

Before the trade, the price was 500 USDC/SOL. After the trade, the new price is 55,000 / 90.909 = 605 USDC/SOL. The act of buying SOL pushed the price of SOL up. The trader didn't pay a flat 500 for each of their 9.09 SOL — they paid an average of about 550 USDC per SOL (5,000 / 9.09 ≈ 550). The first tiny fraction of SOL they bought was near 500, but each subsequent fraction was slightly more expensive, because each tiny purchase changed the ratio of tokens in the pool, shifting the price.

This is exactly like buying in bulk at a yard sale where the seller has limited stock. "How much for these old records?" you ask. "A dollar each," says the seller. "I'll take all fifty." The seller pauses. "Well, I only have fifty, and I wasn't planning on selling all of them... tell you what, first twenty for a dollar each, next twenty for two dollars, last ten for five dollars." The scarcer the supply gets, the more each additional unit costs. The AMM does this continuously, on a smooth mathematical curve, rather than in discrete price tiers. But the principle is identical: more demand against fixed supply drives prices up.

The Beauty of the Curve

Here's what makes x * y = k so clever. Let me plot this mentally.

If k = 5,000,000, then y = 5,000,000 / x. This is a hyperbola — a curve that approaches but never touches either axis. As x gets very large (lots of SOL in the pool), y gets very small (almost no USDC), and the price of SOL in USDC terms approaches zero. As x gets very small (almost no SOL left), y gets very large (lots of USDC), and the price of SOL goes toward infinity.

This has a beautiful property: the pool can never be fully drained of either token. You can't buy all the SOL in the pool, because as you buy more and more, the remaining SOL gets exponentially more expensive. To buy the last fraction of SOL, you'd need to add essentially infinite USDC. The curve asymptotically approaches both axes but never touches them.

This means the AMM is always willing to trade. There's always some SOL to buy and some USDC to buy. The price might be terrible if the pool is severely imbalanced, but a trade is always possible. Compare this to an order book, where if no one has placed a sell order for SOL, you literally cannot buy SOL at any price. The AMM's "always open for business" property is what makes it so useful as a decentralized primitive.

It's like a gas station on a lonely stretch of highway. The station might charge you $8 a gallon because it's the only one for a hundred miles and it's running low on supply. The price is awful. But at least you can fill your tank. An order book exchange in the same situation would be a gas station with a sign that says "No gas available — no supplier showed up today." The AMM is expensive but never closed. The order book might have great prices but might also have nothing.

Slippage: Why Size Matters

The phenomenon I described above — where a larger trade gets a worse effective price — has a name: slippage. And it's one of the most important concepts in DeFi trading.

Slippage is the difference between the price you expect and the price you actually get. In the example above, the "expected" price was 500 USDC/SOL, but the actual effective price was about 550 USDC/SOL. That's roughly 10% slippage. Not great.

The relationship between trade size and slippage is nonlinear. Small trades relative to the pool size experience almost no slippage. Large trades experience a lot. Let me illustrate with the same pool (100 SOL, 50,000 USDC, k = 5,000,000):

Tiny trade: Buying with 100 USDC

• New USDC: 50,100
• New SOL: 5,000,000 / 50,100 = 99.80 SOL
• SOL received: 0.20 SOL
• Effective price: 100 / 0.20 = 500 USDC/SOL
• Slippage: essentially zero

Small trade: Buying with 1,000 USDC

• New USDC: 51,000
• New SOL: 5,000,000 / 51,000 = 98.04 SOL
• SOL received: 1.96 SOL
• Effective price: 1,000 / 1.96 = 510 USDC/SOL
• Slippage: about 2%

Large trade: Buying with 10,000 USDC

• New USDC: 60,000
• New SOL: 5,000,000 / 60,000 = 83.33 SOL
• SOL received: 16.67 SOL
• Effective price: 10,000 / 16.67 = 600 USDC/SOL
• Slippage: about 20%

Massive trade: Buying with 25,000 USDC

• New USDC: 75,000
• New SOL: 5,000,000 / 75,000 = 66.67 SOL
• SOL received: 33.33 SOL
• Effective price: 25,000 / 33.33 = 750 USDC/SOL
• Slippage: about 50%

See the pattern? The 100 USDC trade barely moves the needle. The 25,000 USDC trade — which represents half the pool's total USDC reserves — results in paying 50% more than the "spot" price. This is the constant product formula doing exactly what it's supposed to do: protecting the pool from being drained by making large trades progressively more expensive.

This has massive implications for someone building a trading bot. If I find an arbitrage opportunity that only exists in a small price window, I can't just throw a huge amount of capital at it. The trade itself will move the price, potentially eating up the entire profit margin. There's an optimal trade size for every opportunity — large enough to be worth the transaction costs, small enough that slippage doesn't kill the profit. Finding that optimal size requires understanding the math precisely, not approximately.

It's like Costco bulk pricing, but in reverse. At Costco, buying more gets you a better per-unit price. In an AMM, buying more gets you a worse per-unit price. The pool is essentially saying: "Sure, I'll sell you SOL. But the more you want, the more I'm going to charge per unit, because you're depleting my inventory."

Fees: The Pool's Cut

I've been omitting something from the math above to keep things clean, but it matters: trading fees.

In practice, AMM pools charge a fee on every trade — typically somewhere between 0.01% and 1%, depending on the DEX and the specific pool. This fee is deducted from the trade before the constant product formula is applied.

So in reality, when someone puts in 5,000 USDC to buy SOL, the pool might take a 0.3% fee first. That's 15 USDC. Only 4,985 USDC actually goes into the pool's reserves. The formula x * y = k is applied to this net amount, and the trader gets slightly less SOL than my fee-free calculation above suggested.

Where does the fee go? It goes to the liquidity providers — but I'm getting ahead of myself. Let me explain who they are first.

Liquidity Providers: Who Fills the Vending Machine?

The vending machine analogy raises an obvious question: who stocks the vending machine? Where do the 100 SOL and 50,000 USDC in the pool come from?

They come from liquidity providers — LPs. These are people (or entities) who deposit their tokens into the pool, making them available for traders to swap against. In return, LPs earn a share of the trading fees generated by the pool.

The mechanics work like this. An LP who wants to provide liquidity to the SOL/USDC pool deposits equal value of both tokens. If SOL is worth 500 USDC and the LP wants to provide $10,000 worth of liquidity, they deposit 10 SOL (worth $5,000) and 5,000 USDC ($5,000). In return, they receive LP tokens — a receipt that represents their share of the pool.

As trades happen and fees accumulate, the value of the pool grows (because fees are added to the reserves). When the LP eventually withdraws their liquidity by returning their LP tokens, they get back their proportional share of the now-larger pool. The difference — the fees that accumulated during their time providing liquidity — is their profit.

Think of it as owning a piece of a lemonade stand. You put up the money for lemons and sugar. The stand sells lemonade all day. At the end of the day, you get back your original investment plus a cut of the day's sales. You didn't stand behind the counter squeezing lemons. The stand operated itself (the smart contract). Your contribution was the capital — the raw materials that made the business possible.

This is a fundamentally different model from traditional market making. Traditional market makers actively manage their positions, placing and canceling orders, adjusting spreads, hedging risk. LP-ing on an AMM is passive. You deposit, walk away, and the smart contract handles everything. The trade-off is that you have less control — you can't set your own prices or decide which trades to accept — and you're subject to something called impermanent loss, which I'm still wrapping my head around. But the barrier to entry is dramatically lower. Anyone with tokens and a wallet can be a liquidity provider. You don't need a trading desk, a quant team, or a co-located server.

Why Prices Diverge: The Arbitrage Opportunity

Now I'm getting to the part that matters most for my project.

Remember the order book problem I mentioned earlier? Every exchange has its own order book, with its own supply and demand dynamics, producing its own price. The same is true for AMM pools — and arguably more so.

On a centralized exchange, at least the prices are driven by human participants who are watching global markets and adjusting their orders accordingly. If SOL is trading at $500 on Coinbase and some trader on Binance tries to sell at $480, other traders on Binance will snatch it up instantly, pushing the price back toward $500. Human attention and greed keep prices roughly aligned across centralized exchanges.

AMM pools don't have this self-correcting mechanism built in. An AMM pool doesn't know what SOL is trading at on Coinbase. It doesn't know what the pool across the street is quoting. It only knows its own reserves — its own x and y — and it mechanically applies the formula. If someone makes a big trade that pushes the price of SOL in Pool A down to $480, Pool A just sits there at $480. It doesn't think "hey, that seems low compared to the global market." It's a vending machine. It doesn't have opinions.

This means AMM pool prices diverge from each other constantly. Every trade changes the reserves, which changes the price. Different pools get different trades at different times. Pool A might have just processed a large SOL buy, pushing its price to $510. Pool B might have just processed a large SOL sell, pushing its price to $490. For a brief moment, there's a $20 gap between them.

And that's the arbitrage opportunity. Buy SOL from Pool B at $490. Sell it to Pool A at $510. Pocket the $20 difference (minus fees and transaction costs). In doing so, the arbitrageur actually performs a service: they push Pool B's price up (by buying SOL from it) and Pool A's price down (by selling SOL to it), bringing both pools closer to the "true" market price. Arbitrageurs are the correction mechanism that AMM pools lack internally.

This is why arbitrage bots exist. Not because the system is broken, but because the system is designed this way. AMM pools are deliberately simple — they apply a formula to their current state and quote a price. They don't try to track external markets. They rely on arbitrageurs to keep their prices aligned with reality. The arbitrageurs earn a profit for performing this service. It's a symbiotic relationship.

Now multiply this across the Solana ecosystem. There isn't just one SOL/USDC pool. There are dozens. Different DEX protocols. Different pool configurations. Different fee tiers. Different amounts of liquidity. Each one operating independently, each with its own x, y, and k. And because trades hit different pools at different times, prices are constantly diverging and reconverging. The landscape is alive with tiny, fleeting price discrepancies.

That's what my bot is trying to find. Not the big, obvious $20 gaps — those get captured in milliseconds by faster, better-capitalized bots. The small ones. The ones that require mathematical precision to even detect. The ones where the profit is measured in fractions of a percent and the window of opportunity is measured in fractions of a second.

Beyond x * y = k

I should note that x * y = k isn't the only AMM formula out there. It's the simplest and most common — Raydium's standard AMM pools use it, and it's the foundational design that most people learn first. But the DeFi ecosystem has evolved, and different DEXs use different formulas optimized for different use cases.

Some pools use concentrated liquidity, where LPs can specify a price range for their capital rather than spreading it across the entire curve. This is more capital-efficient — a dollar of liquidity in a concentrated range provides more depth than a dollar spread across the full curve — but it's also more complex. The math gets more involved, and LPs need to actively manage their positions.

Some pools use different curve shapes entirely. Stable pairs — like USDC/USDT, where the price should always be very close to 1:1 — use flatter curves that provide better pricing near the peg at the cost of worse pricing far from it. If you're swapping one dollar-pegged stablecoin for another, you don't need the protection that x * y = k provides against draining the pool. You need tight spreads at the expected price.

And there are DEXs that use order-book-style designs adapted for blockchain, maintaining on-chain limit orders with enough optimizations to make it workable despite the inherent challenges I described earlier.

Each of these designs has different math, different slippage characteristics, and different fee structures. For my bot, this means I need to understand not just one formula, but the specific pricing logic of every DEX I want to monitor. A price that looks like an arbitrage opportunity under x * y = k assumptions might not be an opportunity at all if the pool uses a different curve. The math has to match reality precisely, or my bot will see phantom opportunities that evaporate the moment it tries to capture them.

Why This Math Is My Foundation

I started this article asking a question: how do decentralized exchanges determine prices? The answer turns out to be elegant but consequential.

CEXs use order books — explicit bids and asks from human participants, matched by a centralized engine. The price emerges from collective human behavior. It works, but it requires centralized infrastructure and professional market makers.

DEXs using AMMs take a completely different approach. They replace the entire order book apparatus with a mathematical formula. x * y = k. Three variables, one constraint. The formula determines the price. The formula executes the trade. The formula adjusts the price after the trade. No humans in the loop. No matching engine. No market makers frantically updating their quotes. Just math, applied to the current state of a pool, producing a deterministic output.

The implications for someone building an arbitrage bot are profound. Every trade on every pool changes the pool's state. Every state change produces a new price. Different pools drift apart and get pulled back together. The entire system is a continuously churning mathematical landscape, with temporary inefficiencies appearing and disappearing faster than any human could track.

But a bot can track them. A bot that understands the math — that can take a pool's current reserves, apply the correct formula, and compute the exact output of any hypothetical trade — can scan thousands of pools per second, looking for combinations where buying from one pool and selling to another yields a profit after fees.

The formula x * y = k is public knowledge. It's right there in the source code of every constant product AMM. Every bot operator knows it. The competitive advantage doesn't come from knowing the formula — it comes from how fast you can apply it, how accurately you model the real-world complications (fees, slippage, gas costs, competing bots), and how quickly you can execute when you find something.

I'm starting to see the shape of the problem I'm solving. It's not a knowledge problem — the math is straightforward. It's an engineering problem. Speed, precision, and scale. Take a simple formula, apply it to thousands of pools in real-time, find the needles in the haystack, and act on them before anyone else does.

The formula is the easy part. Making it run fast enough to matter — that's where the real work begins.