Skip to main content

​
Chains

RAVN spans EVM chains, Solana, and native Bitcoin. One integration covers all of them. Use the chain ID in every request.
Building a chain or token picker? Read GET /chains and GET /tokens instead of hardcoding these tables, they’re the same data, live.

​
EVM

​
Non-EVM

Native coin on an EVM chain uses the sentinel address 0xEeeeeEeeeEeEeeEeEeEeeEEEeeeeEeeeeeeeEEeE (not on Tempo or Arc, see below). Amounts are always strings in the token’s smallest unit (wei, lamports, satoshis).
Tempo’s native currency is literally USD (18 decimals): a non-transferable unit of account, not a market-priced asset, so no venue lists it as swappable, only its ERC-20 tokens (USDC.e, pathUSD, USDT0, PRIME) route. Its explorer also has a dedicated payment receipt view at https://explore.tempo.xyz/receipt/{txHash}, alongside the usual /tx/{txHash} transaction page. And Tempo’s PRIME is Hastra’s liquid-staking receipt for Figure’s tokenized HELOC pool, not Echelon Prime / Parallel’s governance token of the same ticker.
Arc (Circle’s chain) pays gas in USDC, and its native coin and the USDC token at 0x3600000000000000000000000000000000000000 are one balance. RAVN lists USDC once, as that token (6 decimals): quote Arc USDC by that address, not the native sentinel, which Arc has no swappable entry for. Gas comes out of the same USDC, so a swap that sells a wallet’s whole USDC balance reverts once gas is charged: leave a few cents of USDC for gas (about 0.04 covers it). Arc’s tokens on RAVN: USDC, EURC, cirBTC (Circle’s wrapped BTC) and WETH, plus any token by address.
Not every venue serves every chain. The router automatically selects venues that can serve a given route, and it returns NO_LIQUIDITY if none can.

​
Venues

RAVN aggregates the venues below. On every quote, the venues eligible for that specific route, never all of them at once, are queried in parallel and the best real output wins: Most venues return one fixed execution type; a few return different types depending on the source chain or execution mode, noted per row below. The id column is the value you’ll see in venue.id on a quote and /health, and what excludeVenues and onlyVenues take. Exclude and identify venues by id, not name: RAVN’s own multi-step routes are all named RAVN (venue.id compose, or relay for Relay with a DEX on arrival). Both lists also cover the venues in a route’s hops: see POST /quote.
Every venue delivers the asset the user asked for, never a wrapped copy. The one wrap in the list, Layerswap, exists only for pairs where WBTC itself is the requested output. RAVN runs no bridge of its own. NEAR Intents moves coins in and out through its own bridge, so on its routes the deposit is held as a matching token on NEAR for the minutes the swap takes. RFQ and gasless venues let the user swap with zero native gas, because they sign an off-chain message and a solver covers the gas.
THORChain with BTC as the source requires THORChain’s memoless feature, which THORChain can disable network-wide with its HALTMEMOLESS flag, and currently has. RAVN checks that flag on every quote and simply leaves THORChain out of the race while it is set, so you never receive a quote that cannot execute. Even with the flag clear, RAVN races it only once its own switch for it is on, and only from 0.1 BTC.This changes nothing you need to handle: selling BTC still works, because Chainflip, Relay and NEAR Intents all serve it and keep competing. THORChain sending funds to native BTC is unaffected either way: that path uses an ordinary memo with no registration.
Rift enforces no minimum output. It picks its route and rate when the deposit lands, so the user can receive more or less than quoted. Its quotes carry slippage.noMinimum: true: show that to the user before they send. RAVN ranks a Rift quote under its figure, by slippage.expectedShortfallBps (5 to 100 bps, by swap size and token type), and every quote carries the result as expectedOutputAmount. alternatives already arrive in RAVN’s order; if you order routes yourself, sort on expectedOutputAmount, not the raw output, and skip any with pickable: false. Rift races when you leave slippageBps out (Auto). A request with its own slippage limit gets a Rift quote only with allowNoMinimum: true, see /quote.

​
Private swaps

Set confidential: true on /quote and the race narrows to the venues with a private settlement path: NEAR Intents (Confidential Intents), Houdini Swap and Hinkal. Each hides the direct on-chain link between the deposit and the payout; how strongly depends on the venue. You get NO_LIQUIDITY rather than a public fill if none can quote. Houdini Swap and Hinkal only ever race on these requests.
  • NEAR Intents costs the least: about 0.3 bps more than a public swap EVM to EVM, 5 to 8 bps more when Bitcoin or Solana is a leg.
  • Houdini Swap settles through two of its partner exchanges in turn, which hold the funds for the minutes to an hour the swap takes, and prices about 3% below spot, so it usually wins only where NEAR Intents can’t quote. See confidential on /quote for its compliance rules.
  • Hinkal pays out of a shared pool, usually seconds after the deposit. It delivers about 0.3 to 0.45% less than NEAR Intents and more than Houdini Swap, so it too mostly wins where NEAR can’t quote. It is opt-in and works differently from every other venue: see Hinkal below.
Your integrator fee applies to private swaps too, paid beside the swap: NEAR Intents from an EVM chain, Bitcoin or Solana, Houdini Swap from an EVM chain or Solana, Hinkal from the EVM chains it serves.

​
Hinkal

Hinkal runs a shared pool on each EVM chain it serves. Your user pays into the pool, and Hinkal pays the recipient out of it from a fresh temporary wallet, through LI.FI (a bridge-and-swap service), so the payout can arrive in another token, on another chain, or both. A chain explorer shows “wallet A paid Hinkal” and “Hinkal paid wallet B”, with no direct line from A to B. The payout usually comes 5 to 30 seconds after the deposit confirms, plus the bridge’s own time. What it costs comes out of the quoted output: LI.FI’s 0.25%, and Hinkal’s 0.10% plus a small flat fee. The deposit’s gas comes on top, paid by the paying wallet in the chain’s coin and reported in the quote’s gas, not taken from the output. It is heavy: about 450k to 670k gas, which is cents on Base or Arbitrum and a few dollars on Ethereum.
  • Opt in. Before Hinkal’s swap can be built, the paying wallet signs twice, and /execute asks for each signature with an AUTHORIZE answer. So RAVN races Hinkal only on a quote sent with authorizeSteps: true (typed from SDK 0.4.1, whose executeAndTrack answers the steps) or with onlyVenues naming hinkal. Without either, a private race simply leaves Hinkal out, and an integration that can’t collect the signatures never gets a Hinkal quote. See AUTHORIZE steps.
  • Limits. From EVM chains only: Ethereum, Base, Arbitrum, Polygon, BNB Chain, Robinhood Chain, paying out on any of those or Solana. Up to $10,000 a swap. destinationAddress set on the quote: Hinkal fixes the payout when it prices, and doesn’t quote without one. No refundAddress other than userAddress: a failed swap can only go back to the wallet that paid. Up to 12 Hinkal swaps started an hour per IP, or 120 per API key: calls without a key share their server’s IP, so send your key. Never through the MCP server or x402: neither can collect the signatures.
  • Send the deposit within 10 minutes of receiving the second AUTHORIZE. Hinkal prices its route then, and a deposit sent later is likely to fail at the bridge.
  • A failed swap isn’t refunded on its own. If the payout fails, the funds wait at Hinkal on the source chain. /status reports the swap failed, never refunded, and the paying wallet gets the funds back by signing their recovery through POST /recover. They go back to that wallet only, and RAVN can do this for 7 days.
  • How private it is. Thinner than NEAR Intents. Hinkal has few users, so a deposit has few others to hide among, and the payout follows the deposit by seconds for about the same amount: someone lining up time and amount can often still link the two wallets. Hinkal sees both sides and screens depositors (Chainalysis); per Hinkal’s compliance documentation, a flagged depositor’s funds can only go back out publicly, to the wallet that paid. RAVN sees both sides too: it keeps the order (paying wallet, receiving wallet, amounts) encrypted for 7 days, to track the swap and recover funds, with the wallet’s read-only Hinkal session, which can read that wallet’s Hinkal balance but never move it. And a recovery is an ordinary on-chain payment back to the paying wallet, which can link it to the wallet it was paying. Tell your users it hides the direct link, never that it is untraceable.
  • Territory. Hinkal’s terms bar Cuba, Iran, North Korea, Syria, and Crimea, Sevastopol, Donetsk and Luhansk. RAVN leaves Hinkal out when your request comes from one, and you are responsible for your end users’ eligibility: pass excludeVenues: ["hinkal"] where you can’t meet that.

​
Settlement models

RFQ market makers

Professional market makers quote a firm, signed price. The user signs and a solver settles. Zero slippage, zero gas.

Intent networks

The user expresses an intent, or deposits the origin asset, and solvers compete to fill and deliver on the destination.

Solver and relayer networks

Relayers fill on the destination chain and deliver the canonical asset. This gives fast cross-chain execution without bridging.

Validator-vault networks

A decentralized, threshold-signed validator network custodies a deposit channel and swaps against its own AMM or vault liquidity. No single custodian ever holds the funds.

On-chain DEX aggregators

One transaction the user signs and broadcasts, routed across on-chain pools by the aggregator’s own router. Same-chain only. The transaction hash is the swap’s settlement proof, so you report it to /status yourself.
Coverage grows over time. The /health endpoint always reports the current live venue set.