It's one of the more disorienting moments in DeFi: you and someone else swap the exact same pair, roughly the same amount, within minutes of each other — and the prices don't match. The instinct is to assume something's wrong, or worse, that someone got a "better deal" through some hidden advantage. Almost always, neither is true. The reasons are structural, documented, and — on TON specifically — considerably more transparent than on most other chains.
This gets asked constantly in trading communities, usually phrased as a suspicion rather than a genuine question: "why did I get a worse rate than my friend, are we being scammed?" The honest answer is almost never dramatic, but it is genuinely worth understanding properly, because the same mechanics that cause an occasional price mismatch are also part of what makes the system fair in the first place.
This piece walks through every real factor that can cause two "identical" swaps to settle differently, in the order they actually matter — starting with the explanation people jump to first, and why it's usually wrong on this specific chain.
🗨️ "In the TON blockchain, deterministic transaction order plays a key role in preventing frontrunning... this system eliminates the possibility of manipulating the order of transactions for profit." — TON Foundation, official FAQ
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
⏱️ The Factor That Explains Most of It: Time Itself
Before anything else, it's worth ruling out the scariest-sounding explanation first, because TON's architecture genuinely removes it as a possibility here.
📍 On chains like Ethereum, validators can reorder transactions within a block, opening the door to sandwich attacks and other forms of manipulative frontrunning
🔖 TON uses deterministic transaction ordering instead — once a transaction enters the pool, its position is fixed and can't be altered by any participant for profit
🧷 TON also uses fixed network fees rather than a market-based priority auction, removing the "pay more to jump the queue" dynamic that fuels a lot of Ethereum-style MEV
So if two users get different prices, it isn't because someone paid to cut in line or manipulate the order around your trade. The actual explanation is almost always simpler: the pool's reserves genuinely were different at the two separate moments each trade actually executed. Every swap changes a pool's ratio slightly, and if any trade — yours, someone else's, an arbitrage bot's — landed between two people's "identical" swaps, the second one is trading against a pool that's already been nudged by the first.
It's worth being direct about why this distinction matters. On chains without deterministic ordering, a price discrepancy genuinely could mean someone extracted value at your expense — a real, adversarial explanation with a real victim. On TON, that specific mechanism is closed off by design, which means when a price difference does show up, it's almost always attributable to one of the ordinary, non-adversarial factors below, not to anyone gaming the system against another user.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The Part Most People Miss: "Same Swap" Rarely Means Identical Inputs
This is where a lot of confusion actually starts. Two trades that look identical from the outside — same pair, similar amount, same day — are often not identical in the inputs that actually determine price.
🗨️ "The number you're comparing might not be comparing the same thing at all."
Two people can genuinely differ on trade size (even a small difference matters more than people assume on a shallower pool), on which specific pool or route their swap actually got matched to, and on how much time passed between when each of them checked a rate and when they actually confirmed it. None of that is a flaw in the system — it's just that "same swap" as a casual description hides several variables that price is actually sensitive to.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
🔀 The Real Reasons, One by One
🔴 Trade size, even small differences On a constant-product or stableswap curve, output isn't linear with input size. A trade that's 5-10% larger than someone else's isn't just proportionally worse — it can move further into a steeper part of the pricing curve, especially in a shallower pool, producing a noticeably different effective rate for what looks like "roughly the same amount." This is exactly why comparing screenshots of two swaps casually described as "about the same size" is often misleading — a $500 swap and a $550 swap in a thin pool can produce a rate difference disproportionate to that 10% gap in size, because the curve itself gets steeper as more of a pool's available depth gets consumed.
🟡 Timing between simulation and execution Every swap's expected output is calculated fresh against live reserves at the moment it's requested. If minutes pass between checking a rate and actually confirming, and any trading activity happened on that pool in between, the two users are genuinely pricing against two different pool states — not a stale quote, an accurate one, just for two different moments in time. This is also why refreshing a rate right before confirming, rather than trusting a number you checked a few minutes earlier, tends to produce a more reliable outcome — the gap between "checked" and "confirmed" is exactly where this kind of drift accumulates.
🔵 Different routes through Omniston This is the one most people don't expect. Two users swapping the same pair at nearly the same time can get routed differently — one trade might execute against a single deep pool, while the other gets split across STON.fi, DeDust, and TonCo, or routed through an intermediate token, depending on what each request's competitive RFQ quoting actually returned at that specific moment. Resolver liquidity and quoted prices genuinely shift request to request, because resolvers are independently, continuously repricing based on their own market view. Two people typing an identical amount into an identical pair, seconds apart, can genuinely trigger two different competitive auctions among liquidity sources, simply because the pool of available resolvers actively bidding at that instant wasn't frozen in place between their two requests.
🟤 Slippage tolerance settings This one doesn't change the executed price directly, but it changes what each user is willing to accept. A tighter slippage tolerance can cause a transaction to fail and require resubmission at a later, possibly different price, while a looser tolerance sails through — meaning two users can end up executing at genuinely different moments in time purely because of a setting neither of them thought much about. Someone running a very conservative tolerance in a fast-moving pool may find themselves resubmitting two or three times before a trade actually clears, and each resubmission is, functionally, a brand-new simulation against whatever the pool looks like at that later point.
🟧 Pool selection when multiple pools exist for the same pair It's not unusual for a pair to have liquidity spread across more than one pool — a v1 pool and a v2 pool, for instance, or a standard pool alongside a weighted pool. Each pool can carry its own fee rate and its own reserve ratio, meaning two trades in "the same pair" can technically be executing against two different underlying pools with two different pricing curves. A trader manually picking a pool might land in a different one than the routing engine automatically selects for someone else, purely based on which pool happened to offer the best terms for each specific trade size at that moment.
🟢 Fee tier differences per pool STON.fi's typical trading fee sits around 0.30% total, but the exact rate — and the split between LPs and the protocol — is configurable per pool by that pool's owner. Two pools trading the same pair aren't guaranteed to carry identical fee rates, and that difference flows directly into the final output number. A half-percentage-point difference in fee rate sounds trivial until it's the entire explanation for why one trader's fill looked meaningfully worse than another's, despite both trades executing cleanly and as expected.
⚪ Live quote updates mid-request Because Omniston can update a quote in real time if a more favorable price arrives from a resolver while a user is still deciding, someone who confirms instantly and someone who waits a few extra seconds can genuinely see two different final numbers — neither one wrong, just captured at different points in an actively moving quote.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
🧮 Comparing on the Dimensions That Actually Matter
💧 Structural manipulation vs. legitimate timing. This is the most important distinction to walk away with: none of the factors above involve anyone manipulating anything at your expense. TON's deterministic ordering specifically closes off the kind of transaction reordering that causes price differences to feel unfair on other chains.
🧭 Same pool vs. different pool. Two trades executing against genuinely the same pool at nearly the same moment will differ only by reserve drift and trade size. Two trades executing against different pools or different routes entirely can differ for reasons that have nothing to do with timing at all.
⏱️ Quoted price vs. settled price. The number shown during simulation is a live forecast; the number that actually settles depends on exactly when the transaction executes relative to that forecast, and how much the pool moved in between.
⚖️ Fee-rate transparency. Because STON.fi's fee structure is visible per pool rather than hidden in a blended platform-wide number, a careful user can actually verify whether a price difference traces back to differing fee tiers rather than assuming it's unexplainable.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
🕵️ What You Can Actually Check the Next Time This Happens
Compare trade sizes exactly, not roughly. "About the same amount" is often not the same amount, and small differences matter more on shallower pools than intuition suggests.
Check the timestamp gap between the two trades. Even a minute or two on an active pool can be enough for reserves to shift meaningfully.
Ask which pool or route each trade actually executed through. Fee rate and depth can differ between pools trading the same nominal pair.
Consider whether one trade needed to resubmit. A failed transaction due to slippage tolerance, followed by a resubmit, means that trade is now pricing against a different moment entirely.
Remember TON's ordering guarantee rules out the scariest explanation first. Whatever the actual cause turns out to be, it isn't someone manipulating transaction order to profit at your expense — that's structurally very hard to do here.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
✅ What Genuinely Explains a Price Difference
Reserves are never frozen between two trades. Even a minute of separation, or one unrelated trade landing in between, changes the pool state each swap is actually pricing against.
Routing is genuinely dynamic, not fixed. Omniston can send two nominally identical requests down different paths depending on what resolvers are quoting at that exact moment.
Fee rates aren't platform-uniform. Per-pool configurability means the same pair can carry different effective costs depending on which specific pool a trade lands in.
⚠️ What's Worth Understanding Correctly
It's not frontrunning, and TON's design specifically prevents that particular explanation. Deterministic ordering and fixed fees remove the classic reordering-for-profit mechanism seen elsewhere.
A quoted price and a settled price are two different numbers by design. One is a live forecast; the other reflects whatever the pool actually looked like at execution.
"Same trade" is a casual description, not a technical guarantee. Size, timing, route, and pool selection all have to genuinely match for two trades to be truly comparable.
🏁 Bottom Line
Two users getting different prices for what looks like the same STON.fi swap almost never points to anything unfair happening — it points to how many legitimate variables actually sit behind a single swap: exact trade size, the precise moment of execution, which pool or combination of pools the route landed on, and that pool's specific fee configuration. TON's deterministic transaction ordering and fixed fee structure specifically remove the kind of manipulative reordering that causes this exact question to have a much darker answer on other chains. What's left, once you rule that out, is simply the ordinary reality of trading against a pool that never stops moving.
$GRAM
