An agent can plan the move, price it, and build the transaction, but on almost every tool available today, it cannot sign it, and the two largest agent-facing bridge servers do not carry Bitcoin at all. The limit is not routing. Routing is solved. The limit is that moving Bitcoin requires a key, and handing a key to an autonomous process is a decision nobody has found a safe default for.

This piece covers why the key is the constraint, what breaks on Bitcoin specifically, the working pattern people actually use, and the three providers whose tools an agent can call today.

Why can’t an AI agent just hold Bitcoin?

An agent has no way to hold Bitcoin that is meaningfully different from a script holding a private key, and that is the whole problem. A wallet is a keypair. Whatever holds the key controls the coins. There is no permission layer inside Bitcoin that lets you grant an agent the right to move 0.01 BTC on Tuesdays and nothing else.

Compare that with what an agent gets on an EVM chain. There, a token approval is a bounded grant — a spending cap on one contract for one token, revocable. Account abstraction goes further: session keys, spending limits, allowlisted destinations, a co-signer. None of that exists on Bitcoin. The key signs everything or it signs nothing.

So “agent holds Bitcoin” collapses into “some process on a machine has the seed.” That is a custody decision dressed up as an architecture decision, and it is why the serious tools decline to make it for you.

What breaks when an agent tries to move Bitcoin specifically?

Four things break, and they are all properties of Bitcoin rather than shortcomings of the agent.

There is no contract to approve against. Bitcoin Script can check a signature, enforce a timelock, and verify a hash preimage. It cannot hold the persistent state an allowance needs. The entire approve-then-spend pattern that agent tooling is built around has no Bitcoin equivalent.

Balances are UTXOs, not numbers. Spending requires selecting inputs, calculating change, and building a transaction. Send 0.05 BTC from a 0.4 BTC input, and the remainder comes back as change to an address you must control. Get that wrong, and the difference goes to miners.

Blocks are ten minutes. An agent loop expects a result in seconds. A Bitcoin confirmation is minutes, and most destinations want several. Anything holding a quote across that window is exposed to the price moving.

There is no native dollar. The reason to move Bitcoin at all is usually to reach something priced in dollars — a lending market, a perp venue, a payment. Bitcoin has no stablecoin, so the move and the conversion are the same action.

So what does the working pattern actually look like?

One supervised conversion, then the agent operates on the other side. Rather than giving an agent Bitcoin, you move the Bitcoin once — with a human signing — into an asset on a chain where bounded permissions exist. USDC on Base, USDC on Arbitrum, a wrapped BTC token if you want to keep the price exposure. From that point, the agent works inside an approval you set and can revoke.

This is a narrower claim than “agentic Bitcoin,” and it is the one that survives contact with the tooling. The agent’s job is research, routing, quoting, monitoring and execution on the destination side. The Bitcoin leg stays manual, once, at the start.

It is also where the demand is. Spark’s BTCFi research, published 29 May 2026, put Bitcoin’s entire DeFi footprint at 91,332 BTC — about 0.46% of circulating supply. The gap is a plumbing problem, and the plumbing is exactly what an agent is good at, right up to the signature.

Which providers let an AI agent move Bitcoin?

Three are worth knowing. Two of them are bigger than the third and neither touches native Bitcoin.

LI.FI - the widest coverage, explicitly read-only

LI.FI’s MCP server is the broadest route surface an agent can query, and it is deliberately incapable of moving anything. It exposes around fifteen tools across token and chain metadata, quotes, routing, gas, allowances, and transaction status, covering 58 chains, 27-plus bridges and 31-plus DEXes, and works with Claude, Cursor, Windsurf and VS Code Copilot.

The docs are blunt about the boundary: the server “provides read-only tools” and “does not sign or broadcast transactions.” A quote comes back with an unsigned transactionRequest that you sign and submit with your own wallet. Rate limits are 200 requests per two hours without an API key, 200 per minute with one.

The honest part: Bitcoin is not in the chain list. LI.FI is an EVM-and-Solana aggregator, and for an agent that already holds tokens on those chains it is the best research tool of the three. It is not a Bitcoin tool.

deBridge - execution-shaped, with the signature handed back to you

deBridge shipped its MCP server in February 2026 and designed it around handing the final step to a browser. The Block covered the launch on 16 February 2026. The server exposes six tools — get_instructions, search_tokens, get_supported_chains, create_tx, estimate_same_chain_swap and get_trade_dapp_url — across 24 to 28 networks and more than 40,000 tokens, with a hosted endpoint at agents.debridge.com so an agent can connect without installing anything.

The last tool is the interesting one. The agent produces a shareable deBridge App link, and the documentation describes the boundary plainly: the server “never touches private keys or signs transactions. The user always completes the swap themselves: open the generated link, connect their wallet, review, and sign.”

The honest part: same gap. Bitcoin is not a supported native chain — the coverage is EVM plus Solana. deBridge is the better of the two if you want an agent that gets you to a one-click confirmation, and it still starts from tokens you already hold off Bitcoin.

Garden - the one with the Bitcoin chain in it

Garden Finance is a Bitcoin-first cross-chain protocol, which makes it the only one of the three whose route set starts where Bitcoin actually is. Its catalogue on 8 September 2026 listed 26 assets across 15 chains, including Lightning, Solana, Starknet and Hyperliquid, 13 of those entries a form of Bitcoin across seven tickers. Settlement is by atomic swap: the swap completes on both sides or refunds on both, so there is no pooled balance for an agent to be wrong about.

It reaches agents through two formats, and the difference decides where the tool is reachable rather than what it can do. MCP is portable. The protocol is spoken by Claude Code, Cursor, Codex, Windsurf and VS Code alike, so one server covers every environment an agent might run in. A skill file is not. A .md skill is native to Claude and does nothing in Cursor or Copilot. Garden ships both: an MCP server for swaps, a Claude skill that drives the same flow conversationally, and a second Claude skill for developers embedding Garden into their own application.

Underneath either one the API is the same, and it is already agent-shaped: quote, create order, execute HTLC action, instant refund hash, available liquidity. A refund that is a script condition rather than a support ticket matters more when a machine is driving, and quotes are whole — Garden states it charges no fee of its own and that the quoted figure includes network costs, so an agent does not have to model fee layers separately to know what it will receive. In a nine-swap cost snapshot on 20 August 2026, Garden quoted lowest on all nine against Chainflip and Relay, the gap widest on $100 swaps.

How do the three compare?

Who actually signs, and why does every tool stop there?

All three stop at the signature, and they stop at the same place for the same reason: an agent that can sign is an agent that can lose everything on a bad inference. A hallucinated address, a decimal misread, a prompt-injected instruction inside a token name or a web page the agent read on the way — each of those is survivable when a human confirms and unrecoverable when nothing does.

This is not a Bitcoin-specific caution. Base shipped its MCP in May 2026 behind OAuth with user approval on every transaction. Bybit and BitGo both shipped agent servers in 2026 with the same shape. The pattern across the whole category is identical: agents propose, humans dispose.

On Bitcoin, the stakes of crossing that line are higher, because there is no revoke. An EVM approval can be pulled after the fact. A Bitcoin transaction cannot.

What should you check before letting an agent near your Bitcoin?

Keep the key out of the agent’s context. A key pasted into a chat is in the transcript, the logs and possibly a provider’s retention window. Anything holding a key should read it from an OS keystore at the moment of use.

Confirm the destination address out of band. The single highest-value target for prompt injection against a swap agent is the destination field.

Have gas on the destination chain. Arriving with a Bitcoin-denominated token and no ETH, SOL or STRK is the most common way a first attempt stalls, agent or not.

Size to the route, not to your balance. Caps exist on every route, and inside them the far side’s depth sets your slippage.

Assume the conversion is taxable. In most jurisdictions giving up BTC for a token is a disposal, and coming back is a second one. An agent running conversions on a schedule generates a lot of those.

FAQ

Can AI agents hold crypto?
They can hold a key, which is not the same as being trusted with one. On EVM chains bounded permissions exist — token approvals, session keys, spending caps — so an agent can be given limited authority. Bitcoin has no equivalent, so authority there is all or nothing.

Can Claude execute a crypto swap?
Claude can call an MCP server to search tokens, price a route and build an unsigned transaction. On LI.FI and deBridge the signature is handed back to a wallet you control. That handoff is deliberate, not a missing feature.

Does deBridge support Bitcoin?
Not as a native chain. Its MCP covers EVM networks and Solana. You can move a wrapped Bitcoin token across those chains; you cannot start from BTC on the Bitcoin chain.

Does LI.FI support Bitcoin?
Bitcoin is not in its 58-chain list either. LI.FI aggregates across EVM chains and Solana.

What is the safest way to give an agent access to funds?
Move a fixed amount to a dedicated wallet, on a chain where approvals are bounded and revocable, and grant nothing from your main holdings. Treat it as a float rather than an account.

Can an agent move Bitcoin without any human step at all?
Only if something in the loop holds the key and signs unattended, which every provider named here declines to do. If a tool offers it, that is the question to ask about it first.

Is a bridge cheaper than an exchange for this?
Often not, for common pairs. An exchange usually wins on BTC to USDC. Bridges win when the destination is a rollup that exchanges do not support as a withdrawal network, which is most of them.

Can an AI Agent Actually Move Bitcoin? was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.

On August 18, 2026, an attacker chained six bugs in MAYAChain’s trade account and outbound-handling logic to drain the Asgard reserve. No key was stolen, and this wasn’t a flash-loan drain: a single batched deposit triggered a false theft alert, and an uncapped slash subsidy turned that into 48.87M forged CACAO in one thin pool. The attacker cashed out through it, extracting roughly $1.7M.

Protocol Background

MAYAChain settles cross-chain swaps through its Asgard vaults, with every observed transaction tracked against a shared ObservedTxVoter record. A single MsgDeposit can batch multiple actions together, including trade-account swaps and a DONATE action, all reported against that same voter. When an outbound transaction appears to go missing, the chain treats it as theft and slashes a subsidy into the affected pool to make it whole, a safety mechanism this exploit turned into the attack itself.

Hack Analysis

MAYAChain’s protection against a receipt being processed twice lives in a shared ObservedTxVoter record, one per native transaction ID. Inside the handler for a batched MsgDeposit, every message in the batch creates its own fresh voter and overwrites whatever was there before via SetObservedTxInVoter(). A transaction with enough messages can let its last message quietly erase what every earlier message had recorded.

The attacker used exactly that. A single MsgDeposit carrying 23 messages ran 20 trade-account swaps into ARB.ETH, two more into ARB.LINK, and closed with a one-unit DONATE:ARB.LINK message. That final message overwrote the voter the earlier trade withdrawals had set, resetting OutboundHeight to 0 and marking the whole transaction done.

Check here in rwa data: 516BA14D6976EC7B8A3087E1C52B195433EF0F9D85F4B9520675BC4FEB99E9B7

With OutboundHeight zeroed, the outbound matcher fell back to FinalisedHeight and scanned forward in fixed increments, but it never checked the one block where the LINK outbounds had actually landed. Finding no record there, the chain concluded the outbound had gone missing and triggered its theft-detection slash.

That slash path converts the supposedly stolen amount into CACAO at the pool’s own exchange rate, with nothing capping the result against how much asset the pool actually holds. The ARB.LINK pool had only about 0.11 LINK in it, so running the stolen amount through that rate produced a number completely detached from reality: roughly 49.45 million CACAO, booked straight into the pool.

The code writes that inflated pool balance to state before it actually tries to fund it from the reserve. The reserve only held about 168,000 CACAO, so the funding transfer failed, but the pool’s new balance had already been saved. The handler that caught the failure just logged it and marked the transaction done anyway, with no rollback, leaving the inflated pool sitting in state as if it were real.

With a pool now showing tens of millions of CACAO against almost no LINK, the attacker added a small amount of liquidity to it. The pool-unit math treated the deposit as founding a fresh pool, handing over 99.93% ownership, and an immediate withdrawal at 9,900 basis points paid out 48.87 million CACAO from the Asgard module. The attacker moved straight into swapping it for BTC, ETH, RUNE, and stablecoins across every Maya pool.

Root Cause

It was six separate weaknesses lining up in one transaction. The root failure is that a shared observed-transaction voter could be silently overwritten by a later message in the same batched deposit, and everything downstream, theft detection, the slash subsidy, and the funding transfer, trusted that voter’s state without re-checking or bounding it against reality.

Once the final DONATE message reset the voter, the outbound matcher's fallback logic never checked the right block, the slash subsidy calculation never capped itself against the pool's real balance, and the code that wrote the inflated pool to state ran before the code meant to fund it, with the resulting failure just logged and swallowed instead of rolled back. Any one of those checks alone would have stopped the drain, bind the voter to something a later message can't clobber, cap the subsidy to what the pool can actually hold, or roll back state when a downstream transfer fails.

How QuillAudits Infrastructure Review Could Have Prevented This

Voter integrity across batched messages. Any check whose entire security model rests on a shared record needs a guarantee that record can’t be overwritten by an unrelated message later in the same batch. A review tracing every writer of ObservedTxVoter would have caught SetObservedTxInVoter clobbering per-message state in handler_deposit.go.

Bound every subsidy calculation to the pool’s actual balance. The AssetValueInRune call behind the slash subsidy had no ceiling tied to pool.BalanceAsset, so a thin pool could be told it held tens of millions of CACAO it never had. Any function that credits a balance from a computed value needs an explicit sanity cap against the resource it's crediting.

Never commit state ahead of the transfer meant to back it. SetPool ran before SendFromModuleToModule in helpers.go, so when the transfer failed, the inflated state had already been saved. Persisted state should follow a successful funding transfer, not precede it, and a failed downstream call should roll back what came before it rather than just log and continue.

Funds Flow After Attack

The attacker immediately began swapping the drained CACAO into BTC, ETH, RUNE, and stablecoins across every Maya pool.

20.82 BTC, worth about $1,343,367, moved to bc1q0hsgwunccczelq05ucpmfz268eyy5jr2y5l646. As of now they are still in attacker wallet

Meanwhile on ethereum attacker has deposited some eth in tornado cash.

Post-Attack Mitigation

Maya founder posts an initial public message calling it sad news and saying it will work to fix the issue and recover in full.

Maya confirms the exploit to its community, roughly 20 BTC and $300k in other assets, says it has done a global halt to contain the damage, and shares the attacker’s Bitcoin address in case they’re open to a bug bounty.

Maya commits $200,000 of the team’s own funds into the pools as a first step in the recovery process.

Maya says it will accelerate the launch of its Aztec Chain platform and direct a share of the funds it raises back into the pools to help recover from the exploit.

Maya sends the attacker a message through a Bitcoin OP_RETURN transaction, asking them to return the funds and offering a bug bounty in exchange.

Relevant Addresses and Transactions

Attacker Wallet

• Maya trade-account attacker, executed the exploit transaction, still holds 8,874,269.11 CACAO: maya1dl3yrfpedyr5jfr0r86s2apjltnjqgszmwsv8x
• bc1q0hsgwunccczelq05ucpmfz268eyy5jr2y5l646
• 0xa2f246f82995CBcCA8eD0d9F251383881A5E423e

Affected Pool

• ARB.LINK: 0XF97F4DF75117A78C1A5A0DBB814AF92458539FB4

Key Transactions

• Exploit transaction: 516BA14D6976EC7B8A3087E1C52B195433EF0F9D85F4B9520675BC4FEB99E9B7
• Add & Remove Liquidity Tx: 888AF3EBE9A9A0DBA0F64FE4FD77793E69872466691387A786C9FE19E2693519
• Bug Bounty Offer: aa209b30d84cd63474ba873cfb1c72e5da8e7765b818a0750842e870c1d5b367

Conclusion

No key was stolen, and no single bug did this on its own. A shared voter that a later message could silently overwrite was trusted by every check downstream of it, theft detection, the slash subsidy, and the transfer that was supposed to back it, and none of them verified what the others had already gotten wrong. A pool with barely any liquidity ended up crediting tens of millions of CACAO to itself, and the attacker just had to show up and withdraw it. Six checks failed in sequence; one working boundary anywhere in that chain would have stopped it.

Original Posted at QuillAuidts

MAYAChain $1.7M Slash Subsidy Pool Inflation Exploit (Explained) was originally published in Coinmonks on Medium, where people are continuing the conversation by highlighting and responding to this story.