Skip to main content
RAVN quotes and executes swaps across 16 chains, including native Bitcoin, not wrapped BTC, as a source or destination asset. Everything below sits on top of the same Integrator API (/api/v1/quote, /api/v1/execute, /api/v1/status): same fields, same fees (0% on every route), same DTOs. Pick whichever access pattern fits your agent.

​
Three ways in

All three hit the same underlying swap logic. There’s no “agent tier” with worse pricing or routing than the human-facing app: an agent calling the MCP server for free gets exactly the same quote a retail user gets on ravn.exchange.

​
Which one should I use?

  • Building on Claude, Cursor, or another MCP-native agent? Use the MCP server: point your client at one URL, and you’re done. No API key needed.
  • Your agent already speaks x402 (e.g. wraps fetch with an x402 client) and would rather pay per call than manage a key? Use x402 payments.
  • Writing your own HTTP client, or need endpoints x402/MCP don’t cover? Use the REST API directly.

​
Signing: who holds the wallet?

execute can return TRANSACTION or SIGNATURE — both require a signature RAVN never produces for you (see Execution Types). For a human-facing dapp that’s a wallet popup; for an autonomous agent, it’s a design decision you make once, not per swap:
  • Local key in the agent’s own environment. Simplest: the agent process holds a private key (env var, secrets manager) and signs directly with a library like viem or web3.js. Fine for a sandboxed or self-custodied agent; the key is a standing secret like any server-side key.
  • Human-in-the-loop approval. The agent calls quote/execute, then hands the returned transaction or typedData to a human (or a wallet app like MetaMask/Phantom) to review and sign before anything broadcasts. Slower, but nothing moves without a person confirming it.
  • TEE or custody-agent signing. The private key never enters the agent’s own process; it lives in a secure enclave or a custody service (e.g. a CDP-managed wallet, Turnkey, Privy) that the agent calls out to for a signature. Keeps the agent stateless with respect to funds.
DEPOSIT-type results (the common case for Bitcoin-source swaps) sidestep this: there’s no typed data to sign, just a plain transfer to an address, and RAVN’s own ravn_btc_prepare_send tool builds that transaction for you.

​
Receiving real Bitcoin

If your agent’s swap resolves to a Bitcoin deposit (executionType: "DEPOSIT" from ravn_execute), it still needs to actually send that payment. See ravn_btc_prepare_send, which turns the deposit address and amount into a ready-to-sign transaction, so your agent doesn’t need to write its own Bitcoin coin-selection logic. RAVN never sees or holds a private key at any point.