Why You Don't Get What You Were Quoted
melvin··9 min readYou're swapping 1 SOL. The app says you'll get 142.7 USDC. You hit confirm. The wallet shows 141.3 USDC. You check the transaction after it lands: 141.9 USDC. Three different numbers for the same swap.
I get asked about this a lot. Which number was right? Why did they all disagree? Did something go wrong?
Nothing actually went wrong. The numbers differ because each one reflects a different moment in time, and liquidity moves between those moments. This is slippage. I've seen a lot of integrators treat it as a configuration problem, something you solve by tuning slippageBps and moving on. But slippage is really a physics problem. And the way we approach it at Jupiter is fundamentally different from what most people expect.
The quote is an ETA, not an arrival time
Google Maps says 14 minutes to your destination. You start driving. A truck merges onto the highway. Two lights turn red. Construction closes a lane. You see the time estimation changes along the way and you arrive in 19 minutes.
The 14-minute estimate wasn't wrong. It reflected real conditions at the moment you asked. But traffic didn't freeze while you drove. Conditions changed between the estimate and the arrival, and all Maps could do was to update your ETA constantly.
Swap quotes work the same way. A quote reflects liquidity at the instant you asked. By the time your transaction lands on-chain, other trades have executed, liquidity has shifted, a market maker has updated their position, a bot has consumed the pool you were going to use. The quote was accurate. The market just didn't wait for you.
Solana produces a block every 400ms. That sounds fast, but with $1B+ in daily volume, liquidity at the top of the book can be consumed and replenished multiple times in a single block.
So the quote said 142.7 but the chain said 141.9. Both were honest, they were just answering the question at different times.
Why the quoted price is wrong
Three things account for most of the gap.
Block latency
Your transaction sits in a queue waiting for a leader to include it. During that wait, other transactions change the pool state your quote was based on. Even at Solana speeds, one or two blocks of delay means the pool you're hitting has different reserves than when you asked.
MEV extraction
Searchers watch the transaction pipeline for profitable opportunities. A sandwich attack places a buy before your trade (pushing the price up) and a sell after (capturing the difference). Your user pays a worse price. The attacker pockets the spread. It's effectively a tax on every swap that touches a public mempool.
Prop AMM quote inflation
This is probably the most misunderstood problem in swap comparison today.
A growing class of Proprietary AMMs on Solana quote dynamically. Some quote aggressively to win the routing competition but then execute at far worse prices. A quote of 150 tokens that executes at 50 is worse than a quote of 100 that executes at 95.
| Route | Quoted | Executed | Slippage |
|---|---|---|---|
| Route A (traditional AMM) | 100 tokens | 95 tokens | 5% |
| Route B (Prop AMM) | 150 tokens | 50 tokens | 66% |
Route B wins the quote comparison. Route A delivers nearly 2x more tokens to the wallet. Platforms that display "best quote" without tracking executed price are comparing promises, not results.
Don't trust the quote. Estimate the execution.
Most routing engines work like this:
- Ask every route for a quote
- Pick the best quote
- Set a slippage tolerance
- Hope for the best
At Jupiter we don't take the quote at face value. Instead of trusting what routes promise, we estimate what they'll actually deliver based on what data we've observed. This is the core shift in Metis v8, our routing engine: routing decisions are now made on estimated execution, not quoted price.
RTSE: estimate the executed price of each market
This is where our Real-Time Slippage Estimator (RTSE) comes in. RTSE is the signal that Metis v8 routes on. For every market a route touches, RTSE estimates the executed price for that market at the current trade size, not the quoted price.
It does this by learning from observed execution data:
- Per-market execution history: for each market, RTSE tracks the gap between quoted and executed price across recent trades at different sizes. Not a category lookup ("stablecoin pool = low slippage"), but observed data for this specific market.
- EMA algorithms: Exponential Moving Averages on recent execution data per market. This smooths out noise from individual trades and follows the actual trend of how a market is delivering right now.
- Real-time failure rate monitoring: if transactions through a market start failing, RTSE adjusts its estimate before your next trade hits the same wall.
RTSE trains on millions of swaps daily. For every market on Solana, it builds a picture of what that market actually delivers at a given trade size, at a given time, under a given level of concurrent volume. It knows which Prop AMMs consistently deliver on their quotes and which ones inflate. It knows which markets hold up under volume and which ones don't.
All of that feeds back into routing.
How RTSE changes route selection
Two candidate routes for a SOL to USDC swap:
| Route A | Route B | |
|---|---|---|
| Quoted price | 142.0 USDC/SOL | 143.5 USDC/SOL |
| Estimated executed price | 141.5 USDC/SOL | 139.0 USDC/SOL |
| Estimated slippage | 0.35% | 3.1% |
A naive router picks Route B because it offers a better price.
Metis v8 picks Route A because RTSE has observed Route B's markets delivering 3%+ below their quotes at this trade size. With Route A's markets delivering within 0.5% of their quotes, its estimated executed price is better even though its quoted price is worse.
This is the key insight: the best quote is not the best swap. The best swap is the one that delivers the most tokens to the wallet. And the only way to know that before execution is to estimate it based on what we've observed across millions of trades.
Predictive Execution: simulate, then decide
RTSE provides the statistical model. We also layer on-chain simulation on top of that.
Before your transaction goes on-chain, we simulate every candidate route against current on-chain state:
- Aggregated routers return their best quotes.
- Each route is simulated on-chain to predict the executed price.
- The route with the best predicted executed price wins, not the best quoted price.
A Prop AMM quoting 150 tokens that simulates at 50 loses to a traditional AMM quoting 100 that simulates at 98.
So RTSE provides the historical signal ("this market tends to slip X% at this size") and Predictive Execution provides the real-time signal ("right now, this route simulates at Y"). Together, Metis v8 routes on estimated reality, not quoted promises.
The result is something I'm genuinely proud of: Jupiter swaps execute with an average of +0.63 bps positive slippage. Users on average receive slightly more than quoted, not less.
The rest of the stack
Of course, accurate estimates only matter if you also minimize the window where things can go wrong. A great ETA model is less useful if your car idles in traffic for 20 minutes before the route starts.
Jupiter Beam: close the gap between quote and execution
Every millisecond between your quote and execution is a millisecond where the market can move against you. Jupiter Beam lands transactions in 50-400ms (0-1 blocks) using our own validator infrastructure and direct gRPC connections to leaders.
Compare that to standard RPC submission at 400ms-1.2s (1-3 blocks). Fewer blocks waiting means the market state at execution is closer to the market state at quote time, which in turn makes RTSE's estimates more accurate.
JupiterZ: when the estimate can be exact
For eligible pairs, JupiterZ routes through RFQ (Request-for-Quote) with 20+ market makers. These are firm quotes: the market maker commits to a price and executes at that price. Zero slippage by design.
JupiterZ handles roughly $100M in daily volume with zero slippage. When your trade is eligible, there's no estimation needed. You literally get what you were quoted.
MEV protection: preserve the estimate
RTSE estimates execution in a world where your transaction isn't being attacked. If a sandwich bot extracts value between your quote and execution, even the best estimate is wrong.
Jupiter Beam routes transactions through our own infrastructure — no third-party RPCs, no external landing services. Nothing leaves our stack. Independent measurements show up to 34x lower value extraction compared to leading trading terminals (verified at sandwiched.me).
This matters because MEV protection isn't really separate from slippage estimation. It's what makes the estimates trustworthy in the first place.
What this means for your integration
If you're using Jupiter's Swap API with /order, you inherit all of this automatically. Metis v8 routes on RTSE estimates, Predictive Execution simulates routes against live state, Jupiter Beam minimizes the execution window, JupiterZ provides zero-slippage routes when eligible, and MEV protection preserves the estimate. No configuration needed.
If you're using /build for custom transaction construction, you can opt into RTSE with slippageBps=rtse and use /submit for our landing pipeline.
Markets move. Liquidity shifts. Perfect execution at the quoted price is physically impossible when the quote and execution happen at different times. But you don't have to take the quote at face value. You can estimate the real outcome from observed data, route on that estimate, simulate against live state, shrink the execution window, and protect the transaction from extraction.
What you see will never be exactly what you get. But the gap can be engineered to near-zero, and we've found that it can often be flipped in your favor.
Further reading
- Slippage Estimation: how RTSE works on
/orderand/build - Order & Execute: the default swap flow with automatic RTSE
- Routing: how the Swap API routes across multiple engines
- Ultra V3: The Ultimate Trading Engine: the full technical deep dive