What Is an AMM? How Automated Market Makers Price Solana Tokens

Almost every price you see on a Solana token chart is quoted by a piece of code, not by a buyer and a seller agreeing on a number. That code is an automated market maker — an AMM — and it's the pricing engine underneath Raydium, Orca, Meteora, PumpSwap, and basically every decentralized exchange you'll trade through. Once you understand the simple math an AMM runs, a lot of things that feel mysterious — why your buy moved the price, why a small memecoin trade cost you ten percent, why aggregators exist at all — stop being mysterious. Here's the mechanism, without the academic notation.

What an AMM replaces: the order book

On a traditional exchange — a stock exchange or a centralized crypto exchange — price comes from an order book. Buyers post bids ("I'll pay this much"), sellers post asks ("I'll sell for that much"), and a trade happens when the two sides meet in the middle. Price is a live negotiation between thousands of participants, and someone always has to be on the other side of your order for it to fill.

That model is hard to run fully on-chain. It needs constant order placement and cancellation, professional market makers quoting both sides, and enough activity that there's always a counterparty waiting. For a token that launched ninety seconds ago with three holders, there is no order book — no one to negotiate with. An automated market maker solves this differently: instead of matching you against another trader, it lets you trade against a shared pool of two assets, and a fixed formula decides the price. There's no counterparty to find, because the pool itself is always the counterparty. That single choice is what made permissionless, instant trading of brand-new tokens possible at all.

The constant-product formula, made intuitive

The most common AMM design is the constant-product market maker, and its whole rulebook fits in five characters: x · y = k. The pool holds a reserve of one token (x) and a reserve of another (y) — say SOL and some token. k is just the two reserves multiplied together, and the AMM's one job is to keep that product constant on every trade. Nothing else. That's the entire engine.

The price falls straight out of the ratio of the two reserves. If the pool holds 1,000 SOL and 1,000,000 tokens, the implied price is one token per 0.001 SOL — the reserves' ratio, nothing more. You never set the price; the pool's balance sets it for you. When you buy, SOL goes into the pool and tokens come out: now there's more SOL and fewer tokens, the ratio shifts, and the quoted price rises. Sell and the reverse happens. The formula forces this — to keep x · y equal to the same k after a trade, the reserve you drained has to get more expensive in terms of the one you added.

The consequence to remember: the price is purely a function of the pool's current balances. No one decides it, no order book matches it — it's arithmetic on two numbers, recomputed after every swap. This is the same family of math a Pump.fun bonding curve uses — more on that resemblance below.

Why every buy moves the price (price impact)

Here's the part that trips people up. Because the price is the reserve ratio, and your trade changes that ratio, every nonzero trade moves the price. This isn't a glitch or a fee — it's the core mechanism. Each unit you buy comes out at a slightly worse price than the last, because each purchase makes the remaining tokens scarcer relative to the SOL you're adding. This is price impact: the gap between the price shown before your trade and the average price you actually paid for moving the pool.

People constantly confuse price impact with slippage tolerance, and getting it right costs real money. Price impact is what your own order does to the price, caused by the size of your trade relative to the pool. Slippage tolerance is a setting: the maximum extra movement you'll accept between the moment you click and the moment your transaction lands on-chain, where other trades may have moved the pool in the meantime. A 10% slippage setting doesn't mean you'll lose 10% — it means you're authorizing the trade to fill even if conditions drift that far against you. Set it too tight and your transaction fails; set it too loose on an illiquid token and a sandwich bot can push the price right up to your limit and pocket the difference. The full breakdown lives in slippage on Solana, explained — the single most expensive thing newcomers misunderstand.

The automated counterparty: liquidity providers

If you're always trading against the pool, where does the pool come from? From liquidity providers (LPs) — people who deposit a matched value of both tokens into the pool so that others can trade against it. In return, they earn a cut of the trading fee on every swap that touches their pool. The AMM is the algorithm; the LPs are the capital it runs on. Without deposited liquidity, the formula has nothing to quote.

So "the AMM is the counterparty" is true but incomplete. The AMM is the pricing logic; the LPs are the actual money on the other side of your trade, pooled together and managed automatically by that logic. They never place an order or pick a price — they fund the reserves, and the formula does the market-making on their behalf. The capital side — how LPs deposit, what they earn, and the risk they take (impermanent loss) — is its own subject. Read what a liquidity pool is on Solana for that half. The two posts are complementary: this one is the math, that one is the money.

Concentrated liquidity, in plain terms

The plain x · y = k design has a weakness: it spreads liquidity across every possible price from zero to infinity. Most of that capital sits at prices the token will likely never reach, doing nothing. For a stable pair that trades in a narrow band, that's hugely wasteful.

Concentrated liquidity fixes it by letting LPs concentrate their deposit into a specific price range instead of the whole curve. If you believe a pair will mostly trade between two prices, you put all your capital to work there — which means far deeper liquidity and lower price impact inside that band for the same money. That's the payoff: capital efficiency. The trade-off: liquidity only works while price stays inside the chosen range, so if price moves outside it your position stops earning fees until price returns or you reset the range. It turns providing liquidity from "set and forget" into active management. This is the headline difference between the older constant-product pools and the newer Solana DEX designs — exactly where the venues start to diverge.

How Solana's AMMs differ — and why thin pools hurt

On Solana you'll meet a few different AMM flavors, and the differences are mostly about how they handle liquidity placement:

• Raydium runs classic constant-product pools (the full-range x · y = k model) and also offers concentrated-liquidity pools. It's the venue many tokens graduate into, which is why it shows up everywhere. See what Raydium is for the concrete product.
• Orca popularized concentrated liquidity on Solana through its Whirlpools, where LPs manually choose and adjust their price ranges.
• Meteora uses a bin-based dynamic design that automates range selection and can adjust parameters with market conditions, aiming for very low slippage when price is in the active range. More in what Meteora is.
• PumpSwap is the AMM that graduated Pump.fun tokens land on once their bonding curve fills.

The fee percentages and exact mechanics vary by pool and venue, so don't anchor on a single number — what matters is the shared logic underneath. And that shared logic is exactly why thin pools punish you. Price impact scales with the size of your trade relative to the reserves. In a deep pool, a few thousand dollars barely nudges the ratio. In a freshly launched memecoin pool with a few thousand dollars of total liquidity, your trade is a huge fraction of the pool — so the curve steepens violently from your perspective and you eat brutal price impact in both directions. The same buy that's invisible in a SOL/USDC pool can cost you double digits in a thin memecoin pool. Learning to eyeball pool depth before you trade is a core skill; reading the pool on DexScreener shows you exactly where to look.

Why aggregators sit on top of every AMM

If there are many AMMs, each with its own pool for the same token, then the same token has a slightly different price on each one — and one pool might not be deep enough to fill your whole order cheaply. This is the problem aggregators solve. An aggregator like Jupiter doesn't hold liquidity itself; it sits on top of all the AMMs, scans their pools, and figures out the cheapest way to fill your trade.

The clever part is order splitting. Instead of forcing your whole order through one pool — and eating all the price impact there — an aggregator breaks it into pieces and routes each through a different venue. A large swap might go partly through an Orca pool, partly through a Raydium pool, and partly through an order-book venue, with the split chosen to minimize total price impact net of fees, recomputed fresh for every order. Because each pool only absorbs a slice, you move each one less and get a better blended price than any single venue could offer. That's why routing through an aggregator beats picking one DEX by hand — it does the price-impact math across the whole market for you on every order.

The bonding curve: a one-sided AMM

One more connection ties this together. A bonding curve — the thing pricing a token on Pump.fun before it graduates — is essentially a one-sided cousin of an AMM. It uses the same constant-product math (x · y = k), with a reserve of SOL and a reserve of tokens whose ratio sets the price. The difference: a bonding curve needs no outside liquidity providers. The curve is pre-funded by code, sells a fixed supply of tokens directly to buyers, and the contract itself plays both the AMM and the LP — which is why a Pump.fun token is tradable the instant it's created with zero starting capital. When the curve fills, its accumulated liquidity migrates into a normal two-sided AMM pool, and from there it prices like everything else in this post. Same math, different starting conditions.

How MoonHydra fits

MoonHydra doesn't run its own AMM or hold any pools — it's a non-custodial Telegram bot that sits on top of the AMMs, automated. When you paste a contract address and buy or sell, the bot routes the order through Jupiter, so your trade is split across whichever pools — Raydium, Orca, Meteora, PumpSwap — give the best blended price, with the price-impact math handled for you. You set your own slippage tolerance, so you stay in control of how much movement you'll accept on thin pools. MoonHydra adds no custom on-chain contracts of its own; it relies on Jupiter's audited routing, which is part of how it stays trustworthy — that plus keys encrypted with AES-256-GCM and a fully non-custodial design, so your funds never leave your control. The only fee it charges is a flat 1% per trade, on buys and sells alike, with no subscription, on top of the network and DEX fees you'd pay anyway. Limit orders, TP/SL, and copy-trading all execute through that same routing layer. None of it changes the underlying physics — the AMM still moves on your order, and a thin pool is still a thin pool — it just makes acting on it fast while keeping you custodial of your own keys.

Bottom line

An AMM is a pricing engine that replaces the order book with a formula. The most common design keeps x · y = k constant, so price is just the ratio of the two reserves — which means every trade moves that ratio and therefore the price (price impact), separate from the slippage tolerance you set as a safety limit. Liquidity providers fund the reserves and earn the fees; concentrated-liquidity designs let them focus capital into a price range for far better efficiency, the main thing distinguishing venues like Orca and Meteora from plain constant-product pools. Thin pools mean brutal price impact because your trade is a big fraction of the reserves — which is why aggregators like Jupiter split orders across many AMMs for a better blended price, and why a bonding curve is just a one-sided member of the same math family. Understand the formula, respect the pool depth, and the rest of memecoin trading gets a lot more legible.

Next: read what a liquidity pool is for the LP side of the same machine, slippage explained so price impact never surprises you, and what Jupiter is for the router that ties the AMMs together. Start trading at t.me/moonhydrabot.