THORChain - rapid swaps product decisioning

[gomesalexandre]

Overview

What it says on the box.

THORChain has docs / public repo work around Rapid Swaps, i.e. streaming_interval=0, but ShapeShift web currently does not expose any explicit configurability for this and our THOR swapper currently models THOR quotes as standard vs streaming only.

Tagging @shapeshift/product to decide what the intended user-facing behavior should be in web before engineering touches this:

• should this be transparent / default behavior
• should this be user-configurable
• should this stay implicit under existing streaming behavior
• should this have any user-facing copy at all

This issue is intentionally for product decisioning / requirements only, not implementation planning.

References and additional details

Relevant THORChain docs / public sources

• Streaming Swaps docs
  https://dev.thorchain.org/swap-guide/streaming-swaps.html

• Quickstart / quote docs
  https://dev.thorchain.org/swap-guide/quickstart-guide.html

• Advanced Swap Queue / Limit Swaps blog
  https://blog.thorchain.org/advanced-swap-queue-limit-swaps/

• 2026 roadmap / enablement context
  https://blog.thorchain.org/thorchain-q4-2025-ecosystem-report-2026-roadmap/

• THORNode MR updating quote timing for rapid swaps
  https://gitlab.com/thorchain/thornode/-/merge_requests/4337

ShapeShift web env context

Current web envs point THOR swap infra at ShapeShift-hosted THOR endpoints, not direct ninerealms:

• VITE_THORCHAIN_NODE_URL=https://api.thorchain.shapeshift.com/lcd
• VITE_THORCHAIN_MIDGARD_URL=https://api.thorchain.shapeshift.com/midgard/v2
• VITE_UNCHAINED_THORCHAIN_HTTP_URL=https://api.thorchain.shapeshift.com
• VITE_UNCHAINED_THORCHAIN_WS_URL=wss://api.thorchain.shapeshift.com
• VITE_UNCHAINED_THORCHAIN_V1_HTTP_URL=https://api.thorchain-v1.shapeshift.com

Dev equivalents point at dev-api.thorchain.shapeshift.com.

Important app context

For THOR swap quotes today:

• quotes/rates use VITE_THORCHAIN_NODE_URL
• Midgard is not the quote-generation path
• Midgard is more for status/history/LP/savers/pool-ish data

Relevant code:

• packages/swapper/src/swappers/ThorchainSwapper/getTradeQuote/getTradeQuote.ts
• packages/swapper/src/swappers/ThorchainSwapper/getTradeRate/getTradeRate.ts
• packages/swapper/src/thorchain-utils/getQuote.ts
• packages/swapper/src/thorchain-utils/getL1RateOrQuote.ts
• packages/swapper/src/thorchain-utils/getPoolDetails.ts

How THOR streaming works in ShapeShift web today

Current ShapeShift THOR quote behavior is:

• standard quote:
  • no streaming_interval
• streaming quote:
  • sends streaming_interval=<computed by app>
  • does not send streaming_quantity

So currently:

• quantity is effectively auto / omitted
• interval is not auto, ShapeShift computes it

Current interval selection logic in packages/swapper/src/thorchain-utils/getPoolDetails.ts:

• lower pool health -> 10
• medium pool health -> 5
• healthy pool -> 1
• fallback -> 10

So current ShapeShift THOR streaming is legacy intervaled streaming, not explicit rapid behavior.

Also important:

• there is currently no user-facing configurability for THOR streaming_interval
• there is currently no user-facing configurability for THOR streaming_quantity
• app/domain model today is effectively standard vs streaming, driven by isStreaming: boolean

Useful curls

Using the app quote backend:

Standard:

curl "https://api.thorchain.shapeshift.com/lcd/thorchain/quote/swap?amount=10000000000000&from_asset=THOR.RUNE&to_asset=ETH.ETH&destination=0x1111111111111111111111111111111111111111"

Streaming with interval 1:

curl "https://api.thorchain.shapeshift.com/lcd/thorchain/quote/swap?amount=10000000000000&from_asset=THOR.RUNE&to_asset=ETH.ETH&destination=0x1111111111111111111111111111111111111111&streaming_interval=1"

Rapid candidate:

curl "https://api.thorchain.shapeshift.com/lcd/thorchain/quote/swap?amount=10000000000000&from_asset=THOR.RUNE&to_asset=ETH.ETH&destination=0x1111111111111111111111111111111111111111&streaming_interval=0"

Also useful to compare against public THOR infra:

curl "https://thornode.ninerealms.com/thorchain/quote/swap?amount=10000000000000&from_asset=THOR.RUNE&to_asset=ETH.ETH&destination=0x1111111111111111111111111111111111111111"

curl "https://thornode.ninerealms.com/thorchain/quote/swap?amount=10000000000000&from_asset=THOR.RUNE&to_asset=ETH.ETH&destination=0x1111111111111111111111111111111111111111&streaming_interval=1"

curl "https://thornode.ninerealms.com/thorchain/quote/swap?amount=10000000000000&from_asset=THOR.RUNE&to_asset=ETH.ETH&destination=0x1111111111111111111111111111111111111111&streaming_interval=0"

Observed behavior during audit

As of March 19, 2026, live curls showed:

• standard quote -> standard memo / non-streaming behavior
• streaming_interval=1 -> streaming memo / streaming fields
• streaming_interval=0 -> in tested cases looked like standard / non-streaming behavior

So docs / merged THORNode work and observed live endpoint behavior were not cleanly aligned in this pass.

That mismatch is exactly why product should first decide the desired UX / requirements shape instead of engineering guessing.

More relevant local codepaths

• THOR swapper entrypoints
  packages/swapper/src/swappers/ThorchainSwapper/endpoints.ts

• THOR quote source labels / streaming labeling
  packages/swapper/src/swappers/ThorchainSwapper/constants.ts

• App quote fetching / request construction
  src/components/MultiHopTrade/hooks/useGetTradeQuotes/getTradeQuoteOrRateInput.ts
src/state/apis/swapper/swapperApi.ts
src/state/apis/swapper/helpers/swapperApiHelpers.ts

• Trade quote UX using isStreaming
src/components/MultiHopTrade/components/TradeInput/components/TradeQuotes/components/TradeQuoteBadges.tsx
src/components/MultiHopTrade/components/TradeInput/TradeInput.tsx
src/components/MultiHopTrade/components/TradeConfirm/hooks/useThorStreamingProgress.tsx
src/components/Layout/Header/ActionCenter/components/Details/StreamingSwapDetails.tsx

Acceptance Criteria

• Product reviews the THORChain rapid swaps context above
• Product decides the intended ShapeShift web behavior for THOR rapid swaps
• Product explicitly answers:
  • whether this should be transparent or user-facing
  • whether users should have any configurability over it
  • whether existing THOR streaming UX/copy is sufficient or needs product-defined copy
• Resulting product decision is documented on this issue for engineering follow-up

Need By Date

N/A

Screenshots/Mockups

N/A

Estimated effort

Half a day for product review / decisioning

[twblack88]

Sick writeup @gomesalexandre and good timing on filing this, since rapid swaps went live on mainnet today (thanks THORChain Discord).

Answering your questions directly — tl;dr

• Transparent or user-facing? Backend change only, no need to make user facing yet.
• User configurability? No new controls needed.
• Existing streaming UX/copy need changes? Not yet. Revisit if/when rapid diverges from standard and we can define its place relative to the existing options.

---

I dug into this, checked the other frontends, and vibed-up/ran a comparison script against ninerealms to validate quote behavior. Here's where things landed:

Research findings

• Rapid (streaming_interval=0) currently returns identical output to standard. Most likely explanation: AdvSwapQueueRapidSwapMax is still set to 1 on mainnet, so rapid iterations per block = 1 = functionally the same as standard at the quote level. Im not 100% sure of this and would love more robust quote spamming.
• Omitting params entirely now auto-streams with optimal parameters per the advanced queue. Our client-side pool-health interval logic (the 1/5/10 stuff) is now redundant (I believe you called this out). If I read their docs right it looks like the protocol handles this better than previously.

Assumptions to validate: I only tested against ninerealms. Would need to confirm SS-hosted endpoints behave the same and get a larger data set based on swap size to see any deltas.

Also worth noting: the advanced queue has that direction protection mechanic (skips same-direction market swaps on the same pool within a block) that means rapid isn't unconditionally better under high traffic. There is some data we need before we start exposing advanced options and management. Namely, are these rapid swaps performing well under load and do people still prefer the older style TWAPs (streams)? Only onchain will show us.

Decision

For now I advocate: silent backend improvement, no new user-facing option.

We could stop sending our computed streaming_interval values and let the advanced swap queue auto-optimize since the protocol is "smarter" now (allegedly/hopefully... so they say). Users keep the existing standard vs streaming tags in the quote cards that tradeoff is still real and worth preserving for large big boi swaps.

FWIW, I considered/mocked exposing rapid as a third option alongside standard and streaming, but it doesn't make sense yet. Rapid returns identical quotes to standard today (plus omitting params entirely make swaps already rapid under the hood).

But, just for the gits and shiggles:

Revisit when rapid becomes distinct.

If rapid starts returning meaningfully different expected_amount_out or performant slip, we need to understand where rapid actually sits on the speed-vs-price spectrum before deciding how to surface/control it. Basically: does it occupy a new spot (faster than streaming and better price than standard)? Or does it just replace one of the existing options?