How Does Omniston Aggregate TON Liquidity on STONfi? TON's liquidity isn't sitting in one place waiting to be traded — it's scattered across STON.fi's own pools, other TON DEXs, and independe
How Does Omniston Aggregate TON Liquidity on STONfi?
TON's liquidity isn't sitting in one place waiting to be traded — it's scattered across STON.fi's own pools, other TON DEXs, and independent resolvers, all pricing the same assets slightly differently at any given moment. Omniston's entire job is making that fragmentation invisible.
Open STON.fi, request a swap, and what looks like a single price is actually the output of a small competition happening behind the scenes. TON's DeFi liquidity doesn't live in one unified pool the way a single AMM might imply — it's spread across STON.fi's own contracts, other independent TON DEXs, and resolvers holding their own capital, each pricing assets according to their own reserves or their own market view. Omniston exists specifically to take that fragmented landscape and turn it into one quote, one route, and one transaction — without the trader needing to know or care where the liquidity actually came from.
💭 The part of this that's easy to undersell is how unglamorous the actual problem is. Aggregation isn't a flashy feature — it's plumbing. But plumbing is exactly what determines whether a "good price" claim is real or just a headline number that falls apart the moment a trade gets big enough to matter.
Fragmentation isn't a flaw specific to TON — it's the natural result of a permissionless ecosystem where anyone can deploy a pool, and multiple independent DEXs can all list the same trading pair. STON.fi runs its own pools. Other TON DEXs run theirs. None of these are required to coordinate pricing with each other, and none of them are forced to maintain identical depth for the same pair. The practical consequence: the "real" best price for swapping asset A into asset B, at any given moment, might sit in a pool that isn't the one a trader happens to open first.
Left unaddressed, this pushes the burden of comparison onto the trader — manually checking multiple apps, comparing quotes, and picking the best one by hand before every trade. That's the exact friction aggregation exists to remove.
Omniston pulls together three distinct categories of liquidity into a single decision process for every swap request:
None of these three categories is treated as a fallback for when the others fail. They're evaluated together, for the same request, and whichever produces the better outcome for the trader is the one that actually executes.
The mechanics behind a quote are more involved than "check a few pools and pick the biggest number." Omniston's routing model breaks a swap down into what its own architecture describes as routes, steps, and chunks — allowing a single trade to be split across multiple liquidity sources rather than forced entirely through one.
This matters most for larger trades. A single pool's price moves more the larger a trade is relative to its own reserves — that's ordinary AMM price impact. Rather than pushing an entire large order through one pool and accepting that impact in full, Omniston can divide the order into chunks, sending each through whichever source can absorb that portion most efficiently. The trader still submits one trade and receives one combined result; the division happens entirely inside the routing layer.
It's tempting to think of AMM pools as the "default" liquidity and RFQ resolvers as a specialized backup for edge cases. That's not quite how Omniston treats them. For every quote request, resolvers are asked to respond in parallel with public pool pricing, and the two are compared directly — same request, same moment, competing outcomes.
This matters because pools and resolvers fail in different ways. A pool's price is entirely a function of its own reserves — if a pair is thin, or the trade is large relative to what's deposited, price impact grows regardless of how good the routing logic is. A resolver isn't bound by a fixed on-chain formula the same way; it can price from its own inventory and risk appetite, which often makes it more competitive exactly where public pools structurally struggle — thin pairs, larger trades, or newer assets that haven't attracted deep liquidity provision yet.
A natural question is why this comparison can't simply be computed once and reused — the same way a cached exchange rate might be used elsewhere. Liquidity conditions change too quickly for that to hold up. Pool reserves shift with every trade that passes through them. A resolver's willingness to quote, and at what price, can change from one moment to the next based on its own inventory and market view.
Omniston's quote requests are built around this reality: a request returns a live, subscribable stream of pricing rather than a single static response, so a quote reflects current conditions rather than a snapshot from whenever a cache was last refreshed. This is also why a quote carries its own validity window — it's a live, time-boxed offer built from current conditions, not a fact that stays true indefinitely.
None of the above is visible in the STON.fi interface directly, and that's deliberate. What a trader actually experiences is:
The complexity of comparing sources, splitting large orders into chunks, and re-quoting based on live conditions all sits underneath a single, simple action — which is the actual point of building an aggregation layer in the first place, rather than asking traders to do that comparison manually every time.
To make this concrete: imagine a trader wants to swap a mid-size amount of USDT into GRAM. STON.fi's own pool might offer a price reflecting its current reserves. A second TON DEX might have a deeper pool for that exact pair, offering slightly better depth. Meanwhile, a resolver with its own GRAM inventory might beat both, since it isn't bound by either pool's formula at all. Omniston doesn't ask the trader to check all three — it requests quotes from all three sources at once, compares the results after accounting for fees and expected price impact, and returns whichever produces the best net outcome. If the trade is large enough, it might even combine pieces of more than one source rather than picking a single winner outright, exactly as described in the routing section above.
Omniston's aggregation of TON liquidity isn't one clever trick — it's several coordinated mechanisms working together: pulling in STON.fi's own pools, other TON DEXs, and RFQ resolvers as equal competitors for the same request; splitting large trades across multiple sources through routes, steps, and chunks; and re-quoting continuously rather than relying on a static price. The fragmentation across TON's DeFi ecosystem doesn't go away — it's simply absorbed by the routing layer instead of being pushed onto the person trying to make a swap.
Does Omniston only use STON.fi's own liquidity pools?No. It aggregates STON.fi's own pools alongside other TON DEXs and independent RFQ resolvers, comparing all of them for each swap request rather than defaulting to one source.
Why would a trade ever get split across multiple pools instead of using just one?Splitting reduces combined price impact on larger trades. A single pool's price moves more the larger a trade is relative to its reserves, so dividing an order into smaller chunks routed to different sources can produce a better blended result than forcing the entire trade through one pool.
Are RFQ resolvers only used when a pool doesn't have enough liquidity?Not exactly — resolvers are evaluated in parallel with pool pricing for every request, not only as a fallback. They often end up winning specifically for thin pairs or larger trades, but the comparison happens regardless of pair or size.
Why can't Omniston just cache the best price and reuse it for a while?Because pool reserves and resolver willingness to quote change continuously — sometimes within seconds. A cached price would quickly stop reflecting actual, executable conditions, which is why quotes are delivered as a live stream with their own validity window instead of a static, reusable value.
