Press Enter on the composer. About 200 milliseconds later, a quote appears with the rate, the competitor strip, the settlement estimate, and a sentence of conversational narration. This post is the engineer's tour of that window — what happens, in what order, and why it has to fit in that budget.
A swap composer should feel instant. The user types, presses Enter, and a quote appears — not a spinner, not a "loading…" string, a real quote with the rate, the competitor comparison, the settlement window, and a sentence of conversational narration. We budget about 200 milliseconds for that round trip. This post is the engineer's tour of where those 200 ms go and why the budget is non-negotiable.
If the budget breaks, everything else suffers. The composer feels sluggish. Users edit their query while a stale response is still rendering. The "did it work?" loop fires in the user's head. We treat the latency budget the same way we treat the chain-aware spread floor — as a contract with the user, not a soft goal.
The pipeline at a glance
Seven steps run when you press Enter:
- 1. Intent parse — translate the typed message into structured fields
- 2. Mid-market lookup — read the current price for the pair
- 3. Chain-aware spread floor — apply the per-chain multiplier
- 4. Competitor guardrail — check the live Bestchange feed and beat the best
- 5. Liquidity check — confirm partner liquidity covers both sides
- 6. Quote assembly — package the rate, the strip, the settlement estimate
- 7. AI narration — generate the one-sentence conversational explanation
Steps 1 through 6 are deterministic and bounded — together they fit comfortably under 80 ms on a warm cache. Step 7 (the narration) is the variable budget item; it usually returns in 60–120 ms depending on model load. Add network round-trip and rendering, and we land near 180–220 ms end to end.
Step 1 — Intent parsing
The composer maintains a parser that runs on every keystroke and again on Enter. The Enter-time parse is the authoritative one. It produces a structured intent: category (Swap / Execute / Suggest / Compare / Help), from-currency, from-network, to-currency, to-network, amount, direction. The parser is regex-based with confidence scoring — it does not call a language model. The whole step typically lands under 5 ms.
After parsing, the pipeline validates the intent against the launch scope. Cambio supports 62,231 directional pairs. Anything outside that scope hard-rejects here, before any pricing work happens. The user sees an immediate "this pair is not supported" message with a suggestion of the closest supported alternative. Hard-rejecting early is the cheapest way to avoid downstream latency on requests that can never become quotes.
Step 2 — Mid-market price lookup
For every supported pair, we need a fresh mid-market price. We do not query individual exchanges in this hot path. Instead, we read from an in-memory cache that is fed by a background price-oracle service. The cache refreshes every 5 seconds. A read is a hash lookup — well under 1 ms.
The decision to read from cache rather than make a fresh upstream call is deliberate. Querying Binance or any other external price source on the user's critical path would add 50–200 ms of network round-trip and would expose every quote to upstream rate limits and occasional outages. The background refresh is fast enough that the cache is never more than 5 seconds old, which on a non-volatile minute is plenty fresh, and on a volatile minute the spread floor + competitor guardrail absorb the drift.
Step 3 — Chain-aware spread floor
Once we have the mid, we know the theoretical no-spread rate. The spread floor is what we apply on top of that to handle deposit-confirm drift risk. The floor is chain-aware — different multipliers per deposit chain — because the drift risk during the confirmation window is genuinely different by chain.
The base floor is 0.30%. The multipliers: Solana, BSC, Tron, and Arbitrum all run at 1.0x (0.30% effective). Ethereum runs at 1.3x (0.39%) because the confirmation window is longer. Bitcoin runs at 2.0x (0.60%) because the confirmation window can run from 10 to 60 minutes and the market can move meaningfully in that span.
This is the only mechanism Cambio uses to absorb time-window risk. We do not buy short-dated futures, we do not charge a separate fee, we do not surface a fixed-vs-float toggle. The chain-aware floor is the entire policy. The whole step is a constant-time lookup in a config table — under 1 ms.
Step 4 — Competitor guardrail
The pricing engine then reads the live Bestchange aggregator data for this pair. Bestchange data is also cached in memory; the refresh runs in the background on a 5-minute interval, matching what we surface on the live competitor strip. The cache read is sub-millisecond.
The guardrail finds the cheapest competitor rate for this pair and direction. We then set our quote to beat that rate by 10 basis points if and only if our spread floor allows it. If the cheapest competitor is already inside our floor (meaning beating them would mean quoting below our floor), we quote at our floor and the "Best Rate by Cambio" pill does not render. If the cheapest competitor is comfortably above our floor, we tighten the spread to beat them by exactly 10 bps and the pill renders.
The 10-bps target is the threshold that lets the pill render with confidence. Any smaller and the pill could blink in and out on noisy aggregator data. Any larger and we are leaving money on the table on swaps we would have won anyway. 10 bps is the practical sweet spot.
Step 5 — Liquidity check
Now we know the quote we want to offer. Before we package it, we verify that partner liquidity is available to honor it. The check is in-memory: we track our liquidity providers' available balances for each token on each chain, refreshed every few seconds from on-chain reads. If the to-side liquidity is below the quote amount, the entire swap rejects right here — before the user sees a quote that we could not actually fulfill.
Hard-rejecting at quote time instead of mid-swap is the most important UX guarantee in this pipeline. The worst user experience in instant exchange is "your deposit was received but we cannot pay out — we will refund you in 24 hours." We will not let that happen. If partner liquidity is short, we say so immediately, and the user moves on or comes back later. The liquidity check costs about 1 ms.
Step 6 — Quote assembly
With the rate locked in, the pipeline assembles the quote object. This includes the from and to amounts, the per-chain settlement window estimate (read from a static table — 15 seconds same-chain, ~5 minutes Ethereum cross-chain, deposit-chain confirmation time for Bitcoin sources), the competitor strip rows (already in memory), and the render flag for the Best Rate pill. The object is JSON; the assembly is under 5 ms.
Step 7 — AI narration
The last step is the conversational narration. The structured quote object is passed to Gemini 2.5 Flash Lite with a short prompt asking for a one-sentence explanation. This is the part of the pipeline where the AI actually contributes. It does not pick the route — that already happened. It does not set the rate — that already happened. It explains the result in plain language: "Cambio's liquidity providers are paying you out on BSC in about 15 seconds, beating the next-best aggregator by 47 basis points."
The narration call typically returns in 60–120 ms. This is the largest single block of latency in the pipeline. We use Gemini 2.5 Flash Lite specifically because the narration job — short structured input, short structured output — is well within the capability frontier of any modern fast model, and the latency profile of Flash Lite is meaningfully better than the larger frontier models. We have a dedicated post coming on the model selection.
If the narration call exceeds 500 ms, the composer falls back to a deterministic templated string ("Cambio partner-liquidity route, ~15 sec on BSC, beats best by 47 bps") and the swap proceeds. The trade does not depend on the model service being available. We treat the AI as an enhancement to the response, never as a blocker on it.
Where the 200 ms goes
A typical end-to-end breakdown on a warm pipeline:
- Intent parse: ~3 ms
- Mid-market lookup: <1 ms
- Chain-aware spread floor: <1 ms
- Competitor guardrail: ~2 ms
- Liquidity check: ~1 ms
- Quote assembly: ~3 ms
- AI narration: ~90 ms (typical)
- Network round-trip + rendering: ~80 ms
- Total: ~180 ms
The deterministic part of the pipeline — everything except the AI narration and the network round-trip — fits comfortably under 15 ms. The variability lives in the model call and the user's connection. Both are usually fast enough that the user perceives the response as instant.
Why speed is a contract, not a goal
A swap composer that takes 1.5 seconds to return a quote feels broken even when it is technically correct. The user starts second-guessing their input. They click around. They open a new tab. The conversational frame collapses. We treat the latency budget as part of the product specification, not a performance optimisation we get to whenever we have time.
The discipline this requires is: every new feature in the pipeline has to fit in the existing budget or be moved off the critical path. When we added the chain-aware spread floor (described in detail in a later post), we wrote it as a constant-time table lookup precisely so we could add it without expanding the latency envelope. When we eventually add support for additional pairs or chains, the new mid-market data has to be in the cache by the time the pipeline runs — not fetched on demand.
The conversation feel of the composer is what makes the AI surface work. The 200 ms budget is what makes the conversational feel possible. Everything else in the pipeline serves that constraint.
The next post in the series compares Cambio to agentic wallets — Bankr, the deBridge MCP server, and the broader category of products that put a software agent inside your wallet.
