Inside RAVN’s Native $BTC Aggregator and Its THORChain Integration

THORChain x RAVN Podcast #232 ft. 0xMuninn, KentonC137 & patriotsounds | September 5, 2026 | Watch the full episode on YouTube

By Raynalytics

TL;DR

• RAVN is live in public beta with an aggregator that compares native-asset routes across THORChain and other execution venues, then ranks results by expected net output after applicable costs.
• 0xMuninn says RAVN does not custody funds or deploy contracts that hold them. Its retail app is intended to remain zero-fee, while its API is designed for wallets and other integrators.
• RAVN’s MCP interface aims to let AI agents quote and execute the same native-asset routes, including a path from a $BTC treasury to $USDC settlement for x402 payments.
• $RUNE support, more EVM destination routes through Router v6, and possible $XMR support remain future work. None was presented as live or dated.

Introduction

RAVN is an execution aggregator built around a simple question: if someone holds native $BTC and wants an asset on another network, why should the route require wrapped assets, a bridge, or several disconnected interfaces?

0xMuninn said the product grew out of that friction. After working in Web3 infrastructure, he wanted an interface that could compare execution venues while leaving the user with the canonical destination asset. The result is a consumer-facing app in public beta, plus an API for wallets and other products that want to offer cross-chain execution without building the underlying routing themselves.

The podcast focused on where THORChain Swap fits in that model, why RAVN is building for both people and agents, and which parts of the integration are still not ready.

1. One Request, Competing Native Routes

RAVN is not itself a liquidity venue. It sends a requested swap to multiple execution sources, then compares what comes back. During the show, 0xMuninn named THORChain, Chainflip, NEAR Intents and Relay among the integrations, and said the product had more than 13 execution venues in its routing set.

The relevant comparison is not only the displayed exchange rate. RAVN says it ranks routes on the amount expected to reach the user after applicable transaction costs, and can favor speed, gasless RFQ routes or zero-slippage RFQs when they genuinely provide the better result.

"We never touch any fund." (0xMuninn)

That model gives a wallet or user one request instead of a separate search through every venue. It does not mean every route is identical. Each provider has its own asset coverage, execution model and operational status, so the selected route remains dependent on the live quotes available at that moment.

0xMuninn repeatedly drew a line around custody. He said RAVN does not hold user funds, route funds through its own contracts or write contracts that receive them. It is building the routing and execution layer around independent venues, not a new bridge or a synthetic-asset system.

2. The Consumer App Is Only One Surface

RAVN’s public app is the visible entry point, but 0xMuninn described the API as the larger business path. An integrator can check venue health, request a quote and then execute when it chooses. The API accommodates three transaction patterns: an on-chain transaction, a deposit flow and a signature transaction for RFQ or gasless routes.

"We are baking all of these 13 venues into one single API and providing it to other integrators." (0xMuninn)

For a wallet, the proposed value is implementation scope. Instead of building Bitcoin transaction handling and maintaining a separate relationship with each execution venue, it could call RAVN’s API and expose a native $BTC route. 0xMuninn estimated that a basic integration could take 20 to 30 minutes, but that is his estimate, not a guarantee for every wallet.

The consumer app currently supports EVM and Solana wallet connections. For a $BTC-originating swap, RAVN intentionally uses a deposit-address flow rather than asking someone to connect a Bitcoin wallet to the site. 0xMuninn framed that as a trust and simplicity choice, especially for holders with meaningful balances in one wallet.

RAVN is live in public beta, not a finished launch. The team is inviting feedback while it fixes issues and refines the product. Its stated retail policy is a zero RAVN fee, with monetization intended to come from B2B and agent-facing products.

3. Agentic Finance Needs Execution and Key Boundaries

The most forward-looking part of the conversation was RAVN’s MCP server. The idea is not to create a separate, worse route for bots. An agent should be able to ask for a quote, execute a selected route and check its status through the same routing engine that serves a person.

"Hold the keys yourself." (0xMuninn)

0xMuninn’s example was an agent with $BTC, $ETH or $SOL in treasury that needs to settle an x402 payment in $USDC on Base or Solana. RAVN could provide the conversion path to the settlement asset, while x402 handles the machine-to-machine payment. The protocol does not change the agent’s permission model: RAVN says it never controls the keys.

That distinction matters. An agent can be permitted to execute, advised to prepare a transaction, or kept entirely away from signing authority. 0xMuninn’s recommendation was to keep keys with the user and let an agent advise or act only within the authority the user deliberately grants.

The product thesis is that permissionless native-asset execution reduces friction for agents that otherwise need to navigate exchange accounts, KYC and several different APIs. It is still early infrastructure, not evidence that autonomous trading is safe by default. Denny pointed to a recent case where a user’s own cloud agent mishandled a $30,000 swap, underscoring why route selection and key control need to remain separate decisions.

4. THORChain Integration Is Live, but the Next Routes Are Conditional

RAVN already uses THORChain for the native $BTC routes it can support today. The next requests are broader than that. 0xMuninn said $RUNE was not yet available in RAVN, and that current THORChain capabilities and temporarily unavailable memoless flows limited some of the paths he had expected to offer.

The recent memoless recap explains why those flows were paused while the protocol reviews their defenses. RAVN’s experience also surfaced an implementation detail: a memoless $BTC swap can require a unique inbound amount so the protocol can match the transaction without a memo. 0xMuninn initially found that unexpected, then said the documented design made sense once he understood it.

"I’m waiting for Router v6." (0xMuninn)

Router v6 could make more EVM destination addresses available, which is the immediate expansion 0xMuninn emphasized. Kenton and Denny described the work as close or largely complete, but gave no reliable activation date. The honest status is work in progress, not a launch promise.

$XMR is another potential addition, not a committed route. 0xMuninn wants to study the technical dependencies and user demand after THORChain’s Monero integration is established. He also declined to add custody-based privacy hops to RAVN simply to offer a privacy feature, arguing that a route can obscure activity without providing the same properties as an on-chain privacy asset.

What to Watch

• RAVN beta feedback: whether public testing changes the app’s available routes, wallet support or execution experience.
• B2B integrations: whether a wallet or application adopts the API for native $BTC execution, beyond RAVN’s own interface.
• Agent permissions: how RAVN’s MCP users set signing authority and transaction constraints as agentic flows mature.
• Router v6: whether THORChain activates the expanded destination capability RAVN wants, and which routes it enables in practice.
• $RUNE and $XMR: whether RAVN adds these assets after its technical and product reviews. Neither was live at the time of the podcast.

More THORChain data, check out raynalytics.net

Follow Raynalytics for more Weekly Analytics and Podcast recaps.