Every trader eventually runs into the same wall: a trade size that would move a pool's price uncomfortably if it landed all at once. The obvious fix — "just find a deeper pool" — only works until the trade itself outgrows whatever pool is available. STON.fi's actual answer to this problem isn't a single deeper pool. It's splitting the order itself, deliberately, across multiple sources at once, using an architecture built specifically for that purpose.
This is a question that comes up constantly among anyone moving real size on TON, usually framed defensively: "how do I avoid getting destroyed on slippage for a trade this big?" The honest answer isn't a trick the trader has to perform manually — it's infrastructure that's already doing this work automatically, whether or not the trader ever thinks about it.
This piece goes further than a surface explanation of "smart routing." It walks through the actual data structures, the decision logic behind where each piece of a trade actually goes, a concrete numerical illustration of why that logic outperforms forcing a trade through one pool, and the real, measured outcomes behind order splitting on STON.fi.
🗨️ "Omniston figures out the best route, whether it uses one pool or splits the trade across multiple DEXs. All I see is the final, optimized rate." — STON.fi user writeup, Medium, 2025
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
🏗️ Why Splitting Exists as a First-Class Feature, Not a Fallback
The instinct is to assume splitting only kicks in for unusually large trades — a special mode reserved for whales. That's not how it's actually built. Omniston's underlying protocol represents every route as an array of what are technically called "SwapChunks," meaning the default representation of any trade is already a list of pieces, not a single monolithic instruction:
♦️ Each chunk carries its own destination contract address — which specific pool or protocol will process that portion
♣️ Each chunk carries protocol-specific extra data, since a chunk headed to STON.fi v2 needs different parameters than one headed to DeDust or TonCo
♠️ A trade that only needs one chunk simply produces an array with a single entry — splitting isn't a separate code path, it's the same mechanism scaled down
This matters because it changes the honest answer to "does STON.fi split my order?" The answer isn't "only if it's large." The answer is "your order is always represented as a set of chunks — for most everyday trades, that set just happens to contain exactly one."
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
The Actual Problem Splitting Solves: Diminishing Returns on Any Single Pool
To understand why splitting genuinely improves outcomes rather than just adding complexity, it helps to look at why a single pool degrades the way it does as trade size grows.
🗨️ "Two pools can carry identical TVL and behave completely differently the moment real size hits them, because price impact scales with the ratio of trade to pool, not the pool's raw number."
On a constant-product AMM, every unit of additional size pushed through one pool costs slightly more than the unit before it — the curve steepens as you consume more of the available liquidity. This means a $100,000 trade forced entirely through one pool doesn't just cost 10x what a $10,000 trade would; it costs disproportionately more, because the later portions of the trade are executing against an already-shifted, less favorable price. Splitting exists specifically to avoid pushing any single pool that far down its own curve. Instead of one trade eating deep into one pool's steep region, several smaller pieces can each stay in the shallower, more favorable part of several different pools' curves.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
⚖️ The Actual Logic Behind Where Each Piece Goes
This is the part most explanations skip entirely: splitting isn't arbitrary, and it isn't simply "divide the trade evenly across however many sources exist." The underlying principle — common across well-designed liquidity aggregators, and consistent with how Omniston's RFQ and pool-aggregation approach is described — is that an optimal split allocates more of the trade to sources with better pricing and more depth, and less to sources that would degrade quickly under additional size.
♥️ Marginal price equalization, conceptually. The intuitive way to think about optimal splitting: keep shifting small increments of the trade from whichever source currently offers the worst next unit of price to whichever source currently offers the best next unit, until no further reshuffling improves the blended outcome. Each source's "next unit" cost rises as more size gets allocated to it, which is exactly why the optimal split usually isn't an even division — it's a distribution that accounts for how steeply each source's price degrades with additional volume.
To make this concrete: imagine three sources for the same pair, each starting at an identical headline price, but with different depth behind that price. The first hundred units routed to the shallowest source might already push its effective price noticeably worse than the same hundred units would on the deepest source. An algorithm equalizing marginal price across sources would recognize this immediately and shift more of the total trade toward the deeper source, continuing until the next unit would cost roughly the same no matter which source it went to. That equalization point — not an even three-way split — is what actually minimizes the blended cost of the whole trade.
♦️ Depth-weighted allocation across pools. A deep STON.fi pool and a shallower DeDust pool trading the same nominal pair don't get treated as interchangeable — the deeper pool can typically absorb a larger share of the trade before its marginal price catches up to the shallower pool's, so the split naturally weights toward it, without forcing the shallow pool to zero. The shallow pool still gets some allocation, though, right up to the point where its price has degraded enough to match the deep pool's currently-degrading price — beyond that point, sending more volume its way would actually make the blended outcome worse, not better.
♣️ Resolver quotes get weighed the same way pools do. RFQ resolvers respond with their own pricing for whatever size they're asked about, and those quotes get evaluated on the same basis as pool liquidity — price and depth together, not price treated as if it were guaranteed at unlimited size.
♠️ Multi-hop paths factor into the same calculation. When a direct pair lacks sufficient depth anywhere, part of a trade can route through an intermediate token instead — meaning the "sources" being compared aren't always direct pools for your exact pair; sometimes the better path genuinely goes through a completely different asset first.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
🎛️ A Concrete, Illustrative Walkthrough
Numbers here are illustrative, meant to show the mechanics rather than represent a specific live trade — but the shape of the math is accurate to how a constant-product curve actually behaves.
Imagine a trader wants to swap a size large enough that pushing it entirely through one pool would produce meaningfully worse pricing on the back half of the trade than the front half. A single-pool execution would price the entire amount against one continuously worsening curve — the last portion of the trade paying a real premium purely because it's trading against a pool that's already absorbed everything ahead of it. If the first tenth of the trade executes at a rate close to the quoted headline price, the final tenth might be executing meaningfully worse, purely as a mechanical consequence of how much of the pool's available liquidity has already been consumed by that point.
A split execution instead divides that same total size across, say, a STON.fi pool, a DeDust pool, and a smaller portion routed through an intermediate token where a third venue offers meaningfully better depth for that specific leg. None of those three pieces individually pushes as far into its own pool's steep region as the full trade would have on a single venue. The blended result — averaging the effective price across all three pieces — comes out better than the single-pool alternative would have, precisely because no individual piece was forced deep enough to suffer the worst part of any one curve.
It's worth noting what this walkthrough is deliberately not claiming: it isn't saying every large trade gets split into exactly three pieces, or that the specific pools used here are always the right combination for every pair. The actual number of pieces, and where each one routes, depends entirely on real-time conditions across whatever sources are connected at that moment — sometimes two pieces are enough, sometimes the optimal route involves four or five smaller allocations across a wider set of venues. The shape of the underlying math, though — that splitting reduces the average degradation compared to forcing everything through one increasingly unfavorable curve — holds regardless of exactly how many pieces the specific trade ends up broken into.
This is also exactly the outcome STON.fi's own measurements have quantified in aggregate: cross-DEX optimization through this kind of splitting has been measured delivering roughly 32% lower price impact compared to routing the same trade through a single source. That figure isn't a theoretical best case — it's a measured result of this splitting logic actually running against real liquidity conditions, averaged across the kinds of trades that actually benefit from it most.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
🧵 What Splitting Doesn't Solve — and What Does
It's worth being precise about the limits here, because splitting is genuinely powerful but not infinite.
Splitting redistributes existing depth. It doesn't create depth that isn't there. If a pair genuinely has no meaningful liquidity anywhere across the connected pools — STON.fi's own AMM, DeDust, TonCo, and whatever resolvers are watching that pair — dividing a trade across those empty or near-empty sources doesn't produce a better outcome. There's simply nothing there to redistribute toward.
🗨️ "Omniston's original proposition was to connect all TON DEX pools and find the best route. But aggregating public liquidity has a ceiling. If nobody has added liquidity to a particular pair, no amount of smart routing helps." — Fedorov, STON.fi team, via BeInCrypto
This is precisely the gap that a separate mechanism — escrow swaps — exists to fill. Rather than trying to squeeze a large trade through inadequate public pools, escrow swaps tap into private liquidity from professional resolvers acting as dedicated on-chain market makers, running as a parallel path alongside standard pool-splitting rather than replacing it. For a genuinely illiquid pair, the answer to "how does the system handle a large order here?" often isn't more sophisticated splitting across the same thin pools — it's routing to this entirely separate liquidity source instead.
The distinction matters practically, not just architecturally. A trader hitting a wall on a thin pair might reasonably assume the system simply can't handle their trade size well, and manually break the order into several smaller manual swaps spread over time, accepting worse pricing on each one and extra gas cost on top. Understanding that escrow swaps exist as a dedicated answer to exactly this situation means that assumption is often wrong — the better move is usually letting the routing engine attempt the trade as-is, since it may already have access to private resolver liquidity that a public pool's TVL number gives no visibility into at all.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
🕸️ Execution Guarantees on Every Split Piece
Splitting a trade into multiple pieces raises an obvious question: what happens if one piece fails while the others succeed? This is where the guarantees built into each individual chunk matter as much as the splitting logic that decided where the pieces go. It's a fair concern — a system that split your trade into four pieces and then let three succeed while one silently failed, leaving you holding a mismatched, partially executed position, would be worse than not splitting at all.
Each SwapChunk carries its own min_ask_amount — a minimum acceptable output for that specific piece, not just the trade as a whole. Combined with TON's native transaction atomicity, this means a route with multiple chunks doesn't quietly deliver a worse outcome on one piece while succeeding cleanly on the others. If conditions have shifted enough that any individual chunk can't meet its own minimum, the failure on that step reverts the entire transaction rather than leaving a trader holding a partially executed, mismatched position across some pools but not others. The whole route either lands as calculated, or none of it does — there's no documented middle state where three-quarters of a split trade goes through and the last quarter simply vanishes into an unresolved status.
For cross-chain legs specifically — relevant when a split trade includes a leg moving between TON and another chain — the same all-or-nothing guarantee gets enforced through HTLC-based atomic settlement instead of native single-chain atomicity, since two separate blockchains don't share that guarantee automatically. A hash condition and a time condition together ensure that even a cross-chain piece of a larger split trade either completes on its agreed terms or automatically refunds, rather than sitting in an ambiguous, stuck state while the rest of the trade has already settled. Either way, "split across multiple pools" doesn't mean "exposed to multiple independent points of partial failure." It means multiple pieces, each protected by its own enforced floor, combined into a single outcome that either genuinely completes as calculated or doesn't happen at all.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
⚔️ Comparing on the Dimensions That Actually Matter
💧 Single-pool execution vs. split execution. A single pool wins when it can genuinely absorb the full trade without pushing meaningfully into its steeper pricing region. Splitting wins the moment that stops being true — the crossover point depends entirely on trade size relative to available depth, not a fixed threshold.
🧭 Even splitting vs. depth-weighted splitting. A naive even split across available sources ignores that different pools have different depth and different price sensitivity. Depth-weighted splitting — allocating more to sources that can absorb more without degrading — consistently outperforms an even division for the same total trade size.
⏱️ Public pool splitting vs. escrow liquidity. Splitting across public pools works when liquidity genuinely exists somewhere in the connected graph, just fragmented. Escrow swaps solve the different problem of liquidity that isn't meaningfully present anywhere public at all.
⚖️ Per-chunk guarantees vs. whole-trade guarantees. Because each individual chunk carries its own enforced minimum, a split trade isn't riskier than a single-pool trade from an execution-guarantee standpoint — it's protected piece by piece, not just in aggregate.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
✅ What Genuinely Makes Splitting Work
It's the default architecture, not a special case. Every route is technically an array of chunks; a "single-pool" trade is just an array with one entry, not a different mechanism.
The split is depth-weighted, not evenly divided. Sources with better pricing and more available depth absorb more of the trade, minimizing how far any single piece pushes into its own steep pricing region.
Every individual chunk carries its own execution guarantee. A minimum ask amount per chunk, backed by TON's transaction atomicity, means a split trade fails cleanly as a whole rather than partially succeeding across some pools and not others.
⚠️ What's Worth Understanding Correctly
Splitting can't manufacture liquidity that doesn't exist. For genuinely illiquid pairs, escrow swaps — not more sophisticated pool-splitting — are the actual answer.
The 32% price impact reduction is a measured aggregate outcome, not a guarantee on any single trade. Actual results depend on the specific pair, available depth, and market conditions at execution time.
More sources means more complexity to coordinate correctly, not just more available depth. STON.fi's own team has acknowledged that scaling multi-hop, multi-protocol routing surfaces real engineering edge cases as usage grows.
🏁 Bottom Line
Splitting a large order across multiple pools on STON.fi isn't a special mode that activates for whales — it's the underlying architecture every trade already runs through, built around a data structure specifically designed to divide a trade into depth-weighted pieces across STON.fi's own pools, external AMMs like DeDust and TonCo, and multi-hop paths through intermediate tokens when needed. Each piece carries its own enforced minimum, meaning a split execution is genuinely protected end to end rather than exposed to partial failure. The measured 32% reduction in price impact isn't marketing language — it's the concrete, quantified result of this splitting logic doing exactly the job it was built for.
