Every time someone requests a quote on STON.fi through Omniston, something closer to a live auction happens than a lookup. A group of independent market makers — resolvers — get notified simultaneously, and they compete, in real time, for the right to fill that specific order. Most traders never see this happen. This piece looks at the actual mechanics of that competition, not the marketing shorthand of "best price guaranteed."
🗨️ "A resolver is a service that provides token exchange rates and executes trades... when a trader sends a quote request, they will first receive a QuoteRequestAck containing the rfq_id that uniquely identifies their request." — STON.fi, "How to Become a Resolver" documentation
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
🎪 Why This Is Genuinely an Auction, Not a Price Feed
The distinction matters more than it sounds. A price feed is passive — one number, updated periodically, the same for everyone who checks it. What Omniston runs instead is active and request-specific:
⬢ A trader's quote request gets broadcast to every connected resolver simultaneously, not looked up from a shared table
⬡ Each resolver independently decides what price it's willing to offer for that specific size, at that specific moment
⬟ The system compares every response and selects the winner — the resolver offering the best terms takes the trade
Two people requesting the same nominal trade seconds apart aren't reading the same number off a board. They're each triggering their own independent round of competitive bidding among resolvers deciding, in real time, what they're willing to offer.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
What's Actually Happening on the Wire
This isn't a vague "competition happens somewhere" claim — it's a defined, technical protocol with named stages, and understanding those stages is what makes the pricing mechanism legible rather than a black box.
🗨️ "The resolver API uses a bidirectional gRPC stream." — STON.fi resolver integration documentation
Resolvers connect to Omniston over a persistent, two-way gRPC stream — not a one-off API call per quote, but an ongoing connection kept open specifically so resolvers can react to requests the moment they arrive. When a trade request comes in, connected resolvers receive a QuoteRequestedEvent. Each resolver's own pricing logic decides, in that moment, what rate it's able to offer for that specific size and pair — informed by its own inventory, its own risk appetite, and its own read of where the broader market is trading. That response becomes a QuoteAcceptedEvent if it clears validation, carrying a quote_id that ties it back to the original request.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
🕰️ The Sequence, Step by Step
🔓 Step one: the request gets a fingerprint The moment a trader submits a swap request, they receive a QuoteRequestAck containing an rfq_id — a unique identifier tying every subsequent quote, acceptance, and execution back to that exact request. Nothing about this trade's pricing exists independently of this specific, timestamped ask.
🛰️ Step two: every connected resolver hears it at once Rather than the trader polling sources one at a time, the request goes out to every resolver in the connected network simultaneously via the open gRPC stream, as a QuoteRequestedEvent. Whichever resolvers are online and willing to price that pair all see the same request at effectively the same moment.
🧨 Step three: independent, competing pricing decisions Each resolver decides on its own terms what it's willing to offer — this isn't coordinated or shared between resolvers. A resolver holding more inventory of the requested output token, or with a more aggressive risk model that day, might quote tighter than one that's cautious or thin on that specific asset. This genuine independence is what makes it competition rather than a cartel reading from the same sheet.
⬠ Step four: validation and selection Quotes that clear come back as QuoteAcceptedEvents, each carrying its own quote_id. Omniston compares what's actually come back and selects the winning terms — not necessarily just the single best headline number in isolation, but weighed against depth and reliability, consistent with how the broader routing engine treats any liquidity source.
⬣ Step five: execution against the winning quote Once a quote is selected, execution proceeds against those specific terms — for same-chain trades, through standard TON settlement; for cross-chain trades, through resolver-funded HTLCs on the destination side paired against the trader's locked funds on the source side, so the resolver's win doesn't create counterparty risk for the trader even after being selected.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
🧑💻 What This Actually Looks Like in Code
Since this is genuinely an engineering topic underneath the trading language, it's worth seeing the real shape of it — both sides of the wire, illustrated in the style of STON.fi's documented SDK and resolver API patterns (simplified for clarity, not copied verbatim from the official docs).
On the trader side, requesting a quote through the Omniston SDK looks something like this:
import { Omniston, blockchain, settlementMethod } from '@ston-fi/omniston-sdk'; const omniston = new Omniston({ apiUrl: 'wss://omni-ws.ston.fi' }); // Every request gets its own tracked identity, per rfq_id const { rfqId } = await omniston.requestQuote({ quoteRequest: { offerAsset: { blockchain: blockchain.Ton, address: 'EQC...offer_jetton', }, askAsset: { blockchain: blockchain.Ton, address: 'EQC...ask_jetton', }, amount: { offerAmount: '1000000000' }, // 1 unit, 9 decimals settlementMethods: [settlementMethod.Swap], }, }); // Stream quotes as resolvers respond — the "auction" arriving in real time omniston.trackQuote({ rfqId }).subscribe((event) => { if (event.type === 'quoteUpdated') { console.log('New competing quote:', event.quote.askAmount); } });
On the resolver side, the market maker's own service is listening on that open gRPC stream for exactly this kind of request, and answers independently:
resolverStream.on('data', (event) => { if (event.type === 'QuoteRequestedEvent') { const { rfqId, offerAsset, askAsset, offerAmount } = event.quoteRequest; // This resolver's own pricing logic — inventory, risk, market read const myAskAmount = computeCompetitivePrice(offerAsset, askAsset, offerAmount); resolverStream.write({ type: 'QuoteResponse', rfqId, askAmount: myAskAmount, signature: signWithEd25519(rfqId, myAskAmount), // resolver's own key }); } });
Nothing coordinates these two snippets except the shared rfqId. The trader's client is just listening for whatever comes back; the resolver's service is independently deciding what to offer. That gap — no shared logic, only a shared identifier — is the actual mechanical definition of "competition" in this system, not a figure of speech.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
🔓 Why This Genuinely Helps Even Thin, Unusual Pairs
Resolver competition isn't just a marginal improvement on liquid pairs — it's specifically valuable for the trades a pure AMM pool struggles with most.
🗨️ "RFQ functionality, where 'resolvers' (smart quote engines) compete to offer the best rates, ensures competitive pricing even for low-liquidity tokens." — independent Omniston SDK writeup, Medium, 2025
A public AMM pool for an obscure pair might simply not have meaningful depth — no amount of routing sophistication fixes liquidity that was never deposited. Resolvers don't have that same constraint, because they're not limited to whatever's sitting in a public pool. A resolver can price a trade based on inventory it's holding off-chain-adjacent, or its own hedging capability elsewhere, offering competitive terms for a pair that would otherwise slip badly through thin public liquidity alone.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
✅ What Genuinely Makes This Competitive Pricing Work
Every quote request is independently broadcast, not looked up. There's no shared, stale price table — each rfq_id triggers its own fresh round of bidding.
Resolvers price independently, not in coordination. Genuine competition, not a shared formula, is what creates pressure toward tighter pricing.
The protocol, not the trader, verifies and selects. Validation and selection happen inside Omniston's own logic, removing the burden of manually comparing raw resolver responses.
⚠️ What's Worth Understanding Correctly
A resolver's quote isn't guaranteed forever. Quotes carry their own validity window; conditions that shift between quoting and execution can change what's actually available.
More resolvers online doesn't guarantee a better price on every single request. It raises the odds of competitive pricing, but any individual resolver can choose not to quote tightly on a given trade for its own inventory reasons.
Cross-chain resolver settlement still relies on HTLC-based atomicity for safety. Winning a quote auction and completing settlement safely are two different guarantees, and the second one is what actually protects a trader's funds.
🏁 Bottom Line
The price shown on a STON.fi swap isn't pulled from a static table — it's the outcome of a live, per-request auction among independent resolvers, run over a persistent connection and tracked end to end by a unique request ID from the first ping to final execution. That structure is exactly why resolver-based pricing tends to hold up even on pairs a public AMM pool alone would struggle to price well, and why two seemingly identical requests can genuinely produce two different, equally legitimate outcomes.
This article reflects independent research based on STON.fi's public resolver and protocol documentation as of mid-2026. Resolver participation and protocol mechanics evolve as the network grows — always verify current functionality directly on docs.ston.fi before making decisions involving real funds.
$GRAM
