For much of its history, STON.fi was primarily understood as an automated market maker (AMM) and decentralized exchange on TON.
That description is still accurate, but it no longer captures the entire architecture.
STON.fi now operates Omniston as a separate liquidity aggregation and cross-chain execution layer. Instead of relying on a single AMM pool, Omniston can request quotes from multiple liquidity sources, compare executable routes, and coordinate settlement. Its newer cross-chain architecture extends that model beyond TON.
The distinction matters.
STON.fi is the AMM and DEX. Omniston is the routing, aggregation and execution layer that can sit above multiple liquidity sources.
Understanding that separation is important for anyone trying to understand what STON.fi has actually built.
❑ From an AMM to a broader execution architecture
An AMM, or automated market maker, allows users to trade against liquidity pools rather than directly matching with another trader.
In a conventional AMM model, a user selects a token pair and the protocol calculates the exchange rate from the assets held in the relevant pool.
That model works, but it has an obvious limitation: liquidity is fragmented.
A trader may find one price on STON.fi, another on DeDust, and another from a market maker. The user or application then needs a mechanism for determining which route provides the most suitable execution.
This is the problem Omniston was initially designed to address.
STON.fi's documentation describes Omniston as a liquidity aggregation protocol that pulls liquidity from multiple sources and determines routes across DEXs and resolvers. Its developer guide demonstrates swaps involving STON.fi V1, STON.fi V2 and DeDust.
That means Omniston should not be confused with another AMM pool.
It is an aggregation layer.
❑ The important change was moving from pools to quotes
The central mechanism behind Omniston is an RFQ — Request for Quote.
Instead of simply asking one pool for a price, an application can request quotes from participating liquidity sources.
The basic sequence is:
Request → Quote → Selection → Execution → Settlement
Resolvers are entities that provide executable quotes to Omniston. Multiple resolvers can compete for an order, after which a quote is selected for execution.
This creates a different liquidity model from a conventional AMM.
An AMM commits liquidity to a pool.
A resolver can instead respond to individual orders with a price and execution proposal.
For users, the practical implication is that liquidity does not necessarily have to come from one pool or even one DEX.
❑ Why aggregation matters on TON
Liquidity fragmentation is a structural issue in decentralized markets.
If liquidity is distributed across several exchanges, applications have two choices.
They can integrate with each exchange separately, or they can use an aggregation layer that handles those connections.
STON.fi's Omniston documentation describes the second approach: a single integration can query multiple liquidity sources and route trades through the appropriate source.
The developer documentation also provides an example in which an application requests an RFQ and Omniston determines a route across multiple DEXs.
This is particularly relevant for applications that do not want to maintain separate integrations with every DEX.
The architecture therefore changes the role of STON.fi.
Instead of only asking:
Which pool should execute this trade?
the application can ask:
Which available liquidity source can provide an executable route for this trade?
That is a substantially different layer of abstraction.
❑ October 2025 marked an important transition
Omniston was not always the default execution path for STON.fi users.
In October 2025, STON.fi announced that Omniston had moved from an optional feature to the default smart-routing system in its dApp.
The announcement stated that Omniston would source liquidity from multiple DEXs and that the system had already processed more than 29 million swaps and over $6.5 billion in transaction volume at that point.
This is an important historical distinction.
Omniston began as an aggregation mechanism, but its integration into the main STON.fi trading interface made it part of the normal execution path.
The next stage was to take the same architecture beyond a single blockchain.
❑ Cross-chain execution changes the problem
Moving tokens between blockchains introduces another layer of complexity.
A conventional cross-chain workflow often involves a bridge or intermediary infrastructure that transfers value between networks.
Omniston takes a different approach.
Its current architecture uses resolvers and linked HTLCs — Hash Time-Locked Contracts — to coordinate the two sides of a cross-chain transaction.
The current STON.fi architecture describes the flow as:
1. A user requests a cross-chain swap.
2. Omniston sends an RFQ to resolvers.
3. Resolvers return executable quotes.
4. The selected liquidity is locked in linked HTLC contracts.
5. The transaction either settles atomically or the parties are refunded.
The important concept here is that the destination liquidity is supplied by the resolver.
STON.fi describes resolvers as providing destination-side liquidity for individual orders rather than requiring an application to maintain pre-funded balances across every supported network.
❑ HTLCs are what connect the two sides
HTLC stands for Hash Time-Locked Contract.
The mechanism combines two conditions.
A hashlock requires knowledge of a secret before funds can be claimed.
A timelock establishes a deadline after which the transaction can be cancelled and funds returned.
In a cross-chain atomic swap, these conditions can connect the source-side and destination-side transactions.
The intended result is straightforward:
Either the swap completes according to the agreed conditions, or the funds can be returned.
STON.fi's current Omniston description explicitly states that linked HTLC contracts are used across chains and that the swap settles atomically or participants are refunded.
That does not mean the architecture is risk-free.
The security of such a system still depends on the correctness of the contracts, the participating chains, the resolver implementation and the execution conditions.
The relevant point is narrower: Omniston's cross-chain design attempts to coordinate native-asset swaps through atomic settlement rather than depending on a conventional wrapped-asset bridge model.
❑ Omniston does not eliminate the role of liquidity providers
It changes where liquidity can come from.
For a traditional AMM, liquidity providers deposit assets into pools and receive LP tokens representing their position.
With Omniston's resolver model, a resolver responds to RFQs and, for cross-chain transactions, provides the destination-side liquidity required to complete an order.
STON.fi says resolvers compete on pricing and execution, with the winning resolver supplying the required destination liquidity.
This creates a market structure where liquidity providers can compete for order flow.
The resolver is therefore not simply another backend API.
It is an execution participant.
❑ The resolver model introduces a new trust and infrastructure layer
Resolvers must interact with Omniston's technical infrastructure and respond to quote requests.
STON.fi's documentation describes a resolver as an entity that provides quotes and executes trades through the aggregation protocol.
This creates several dependencies that are worth recognizing.
The system depends on:
accurate quotes;
functioning resolver infrastructure;
settlement contracts;
blockchain execution;
RFQ deadlines;
correct HTLC behaviour;
and sufficient resolver liquidity.
The architecture therefore shifts some of the complexity away from the user and application developer, but that complexity does not disappear.
It moves into the execution layer.
❑ Cross-chain support has expanded beyond TON
The current Omniston website lists TON, TRON, Ethereum, Base, BNB Chain, Polygon, Arbitrum, Avalanche and Robinhood Chain as live networks.
There is an important documentation discrepancy worth recording.
Some older Omniston documentation still describes TRON as upcoming, while the current product page lists TRON as live.
Rather than treating the older documentation as definitive, the safest interpretation is that the documentation and production rollout were updated at different times.
For actual availability, the live RFQ infrastructure is the more relevant operational source.
This is also why supported-chain lists should be treated as time-sensitive rather than permanent protocol specifications.
❑ The architecture is also designed for developers
Omniston is not only intended to be used through the STON.fi interface.
STON.fi provides developer tooling for applications that want to integrate the system.
The documentation includes SDK-based integration for requesting quotes, constructing transactions and tracking trades. The current guide demonstrates integration with React and TON wallet connectivity, while the Omniston platform provides SDK, API/RFQ and widget infrastructure.
That distinction is significant.
If Omniston were only a feature inside the STON.fi application, its architectural role would be relatively narrow.
By exposing the execution infrastructure to other applications, STON.fi is attempting to make Omniston a reusable liquidity and execution layer.
The architecture is therefore better understood as infrastructure rather than simply a front-end trading feature.
❑ Fees are part of the execution model
The current Omniston product page describes two fee components:
a protocol fee determined per asset pair;
an integrator fee configured by the application using Omniston.
The stated integrator-fee range is 0.01 to 100 basis points, with the fee collected in the destination asset and enforced at the smart-contract level.
A basis point is one hundredth of a percentage point.
Therefore:
1 basis point = 0.01%
10 basis points = 0.10%
100 basis points = 1%
The existence of configurable fees means Omniston is not simply an open routing API with no economic layer.
It has an execution model in which integrators can incorporate their own fee into the quoted transaction.
❑ The scale question needs careful interpretation
STON.fi currently presents Omniston as powering every swap on STON.fi and describes the system as processing tens of millions of swaps and billions of dollars in volume.
However, there is an important analytical limitation.
Public data does not cleanly isolate Omniston-only volume from the historical volume of the underlying STON.fi DEX.
This matters because Omniston became the default routing mechanism only after its integration into the STON.fi dApp.
DefiLlama currently reports STON.fi as a TON-based AMM with approximately $27.15 million TVL and $104.21 million in 30-day DEX volume at the time of its latest retrieved snapshot. It also reports approximately $8.50 billion in cumulative DEX volume.
These figures describe the STON.fi protocol according to DefiLlama's methodology.
They should not be presented as independently verified Omniston-only statistics.
That distinction is important when evaluating the scale of the execution layer.
❑ Security evidence exists, but it has boundaries
Security claims should also be separated by scope.
STON.fi's broader AMM v2 contracts were reviewed by Trail of Bits in January 2025.
Separately, STON.fi announced that its Omniston escrow contracts underwent an audit by TonTech in August 2025.
These are useful security signals, but an audit is not equivalent to proving that a protocol is secure.
An audit represents a review of the specified code and scope at a particular point in time.
The cross-chain architecture also introduces multiple components and networks, meaning the security question extends beyond a single smart contract.
For that reason, the appropriate conclusion is that Omniston has undergone documented security review of relevant components, while the existence of an audit should not be interpreted as a guarantee against future vulnerabilities.
❑ What Omniston changes for STON.fi
The evolution can be viewed in three stages.
1. AMM
STON.fi provides liquidity pools and automated market-making infrastructure on TON.
2. Aggregator
Omniston connects multiple liquidity sources and uses RFQs to determine executable routes.
3. Cross-chain execution layer
The newer architecture extends RFQ-based execution beyond TON and coordinates source and destination liquidity using atomic settlement mechanisms.
That progression changes the scope of the infrastructure.
The AMM is primarily a liquidity venue.
Omniston is an execution coordinator.
The two systems are related, but they are not interchangeable.
❑ The unresolved questions are as important as the architecture
Several details remain difficult to verify from publicly accessible material.
The exact number of active resolvers is not clearly disclosed in current public documentation.
The complete list of DEX liquidity sources aggregated at any given moment is also not presented as a permanent public list.
Exact HTLC timeout parameters can depend on the execution flow rather than being represented by one universal number.
And the publicly available data does not provide a clean, independent dashboard showing Omniston-only volume across every integrated application and chain.
These are not necessarily flaws in the architecture.
They are simply limitations on what can currently be established from public evidence.
A research-based assessment should preserve those distinctions rather than filling them with assumptions.
❑ Where Omniston fits in the broader STON.fi architecture
The simplest way to understand the system is to separate its components.
STON.fi AMM:
Provides automated market-making and liquidity pools on TON.
Omniston:
Aggregates liquidity and requests executable quotes.
Resolvers:
Provide quotes and, for cross-chain execution, destination-side liquidity.
HTLC settlement:
Coordinates the source and destination sides of supported cross-chain transactions.
SDK/API:
Allows external applications to integrate the execution infrastructure.
Together, these components represent a move from a single decentralized exchange toward a broader liquidity-routing and execution architecture.
Whether that architecture ultimately becomes widely used across applications and chains is an adoption question that cannot be answered simply from the existence of the technology.
What can be established today is more specific:
Omniston has evolved from TON-focused liquidity aggregation into the cross-chain execution infrastructure that STON.fi uses for its own swaps and makes available for external integrations.
That is the more precise description of what the system is.
❑References
Official Sources
STON.fi — Omniston
https://ston.fi/omniston
STON.fi Documentation — Omniston Overview
https://docs.ston.fi/developer-section/omniston/overview
STON.fi Documentation — Omniston Resolvers
https://docs.ston.fi/developer-section/omniston/resolvers
STON.fi Documentation — Omniston Developer Guide
https://docs.ston.fi/developer-section/quickstart/omniston
STON.fi GitHub — Omniston SDK
https://github.com/ston-fi/omniston-sdk
STON.fi Blog — Omniston now powers every swap on STON.fi https://blog.ston.fi/omniston-now-powers-every-swap-on-ston-fi/
STONfi x
https://x.com/ston_fi
Research & Analytics
DefiLlama — STON.fi Metrics
https://defillama.com/protocol/ston.fi
Trail of Bits — STON.fi TON AMM DEX v2 Security Review https://github.com/trailofbits/publications/blob/master/reviews/2025-01-stonfi-ton-amm-dex-v2-securityreview.pdf
HackenProof
— STON.fi DEX Smart Contracts v2 Bug Bounty https://hackenproof.com/programs/ston-dot-fi-dex-smart-contracts-v2
CertiK — STON.fi Security Profile https://skynet.certik.com/projects/ston-fi
Community & Program Sources
STONbassadors — Official Program https://ston.fi/stonbassadors
STONbassadors Guidelines https://ambassadors.ston.fi/
Written by Binnoreen
X: https://x.com/Bin_noreen
Telegram https://t.me/binnoreen