Why Your Agent Can't Hold Bitcoin
Your agent can already sign an EVM transaction or a Solana instruction. Ask it to hold real Bitcoin and most stacks have nothing. The gap is not the agent. It is the wallet underneath it.
Quick answer
Agent wallet infrastructure, whatever is generating and managing the keys underneath your agent, is almost universally built around account-based signing: one key, one signature, authorizes a transaction against a balance. That model maps cleanly onto EVM chains and Solana. It does not map onto Bitcoin. Bitcoin is a UTXO ledger: spending means selecting specific unspent outputs and constructing a transaction (or a PSBT) against them, a different construction step most agent tooling never had a reason to build. So the agent is not incapable. The wallet layer it was handed simply never learned Bitcoin's shape.
Two wallet models, one gap
| Account-based (EVM, Solana) | UTXO (Bitcoin) | |
|---|---|---|
| Spending unit | Balance at an address | Specific unspent outputs (UTXOs) |
| Send a payment | Sign one transaction against the balance | Select UTXOs, build a transaction, set fee and change, then sign |
| What agent SDKs ship | First-class: sign and send | Rarely first-class: coin selection and PSBT construction usually is not part of the abstraction |
| Result for an agent | Works out of the box | Agent can quote and even receive a Bitcoin deposit address, then has no code path to spend from it |
Neither model is wrong. They solve the same problem, own a private key, authorize a spend, differently. The gap only shows up when a stack built for the first model meets an asset that only speaks the second.
Where this actually breaks
An agent asks for a quote, the route resolves to native BTC, and the execution type comes back as DEPOSIT: send BTC to this address, this amount. That part works. The break comes next. Turning "send BTC to this address" into an actual broadcastable transaction means:
- Looking up which UTXOs the sending address actually controls
- Selecting enough of them to cover the amount plus a fee
- Building the transaction (or a PSBT) with correct inputs, outputs, and change
- Signing it with a key that understands Bitcoin script, not just an EVM signature scheme
None of that is exotic. It is standard Bitcoin engineering. But it is also code most agent-wallet stacks never had a reason to write, because the vast majority of on-chain agent activity to date has been EVM and Solana. The result is a real product, quoting and even routing into native BTC, that stops one step short of usable for an agent that has to act on its own.
How RAVN closes it
RAVN's MCP server ships a tool built specifically for this seam: ravn_btc_prepare_send. It takes the deposit address and amount from a DEPOSIT execution result and returns an unsigned PSBT (Partially Signed Bitcoin Transaction, BIP-174), the standard format for handing off a built-but-unsigned transaction. The UTXO lookup and transaction construction run entirely against mempool.space's public API, no RAVN server call needed for that step, and RAVN never sees or holds a private key at any point. The tool ends where signing begins. What the agent does with that PSBT is a decision made once, not per swap:
- Local keySign directly in the agent's own environment.
- Human reviewHand the PSBT to a person or wallet app to review and sign before anything broadcasts.
- Custody / TEERoute it to a service that signs without exposing the key to the agent process.
Either way, the agent receives and can act on the canonical asset, real Bitcoin on the Bitcoin network, not a wrapped stand-in. See native BTC swaps without wrapping for why that distinction matters on the swap side too.
Three doors, same gap closed behind all of them
This is not tied to one integration path. RAVN's agent access, the free MCP server, pay-per-call x402, and the plain REST API, all sit on the same quote and execute logic, so ravn_btc_prepare_send is available regardless of which door an agent walks through. Full breakdown: AI agents on RAVN.
Give your agent a Bitcoin wallet, not just a Bitcoin quote
Point an MCP client at the server and try ravn_quote and ravn_btc_prepare_send end to end.
The honest tradeoffs
- Signing is still the agent's problem. RAVN builds the transaction. It never signs one. Key management is a decision the integrator makes, not something this tool abstracts away.
- Confirmation time has a floor. Bitcoin block times set the pace regardless of how fast the quote or the PSBT construction was.
- Coverage is real venues, not every venue. Native BTC routes race Garden Finance, Relay, and NEAR Intents when a pair supports it, ranked by net execution rather than headline rate.
FAQ
Why can't AI agents hold real Bitcoin?
Most agent wallet infrastructure is built around EVM and Solana account keys. Bitcoin uses a UTXO model that requires selecting unspent outputs and constructing a transaction or PSBT, a different code path most agent tooling never implemented.
What is a PSBT?
A Partially Signed Bitcoin Transaction (BIP-174), the standard format for a built-but-unsigned Bitcoin transaction. ravn_btc_prepare_send builds one from a deposit address and amount.
Does RAVN custody or sign the agent's Bitcoin?
No. The PSBT is built from mempool.space's public API. RAVN never holds a private key and never signs on the agent's behalf.
How does an agent receive native BTC through RAVN?
A DEPOSIT execution result feeds into ravn_btc_prepare_send, which returns an unsigned PSBT ready to sign. No RAVN server call is needed for that step.
Which venues does RAVN race for native BTC?
Garden Finance (HTLC), Relay, and NEAR Intents, when the pair supports it, ranked by net execution.
