Can an AI Agent Execute a Cross-Chain Trade?
Rift Research
Last updated
Yes. Several interfaces already exist and agents are calling them today. The question that matters is not whether an agent can execute a cross-chain trade but what it has to sign to do so. Most interfaces require the agent to approve a token allowance and then sign an arbitrary transaction payload. Both are places an autonomous caller can be exploited or simply get it wrong.
The short version
- Agent execution is live, not theoretical. LI.FI ships an official MCP server, a CLI, an OpenAPI spec and agent skill listings. Others are following.
- The differentiator is what the agent signs. A token approval plus arbitrary calldata is a fundamentally larger attack surface than a plain transfer to an address.
- Token approvals are the sharpest risk. An approval grants a contract ongoing spending rights. An agent that sets an unlimited allowance has created a standing liability.
- Recovery matters more for agents than for humans. If an agent stops mid-sequence, whether funds can be recovered without a fresh signature determines whether they are stuck.
- Nobody has solved discovery. An agent still has to be told which interface to use. Registry namespaces are unclaimed and already being occupied by third parties.
What does each interface require the agent to do?
| Interface | Steps | Wallet operations | Token approval | Signs calldata | If the agent stops mid-sequence |
|---|---|---|---|---|---|
| LI.FI MCP server | Seven: get-chains, get-token, get-quote, get-allowance, approve, sign and broadcast, get-status | Two | Yes, when allowance is below the amount | Yes. Signs the returned transactionRequest | Depends where it stopped. An approval granted and unused is a standing allowance |
| LI.FI CLI | Same flow, compact output designed to reduce token consumption | Two | Yes | Yes | Same as above |
| Third-party LI.FI MCP wrappers | Varies. Unofficial, requires the user to supply their own LI.FI API key | Two | Yes | Yes | Same, plus an unaudited intermediary |
| Direct aggregator API | Varies by provider. Rango is documented as quoting BTC-to-EVM with a single user signature | One to three | Usually | Usually | Provider-specific |
| Rift API1 | Three: quote, create order, send the asset to the returned address | One | No | No. A plain transfer of a native asset | Funds sit at the order address. A refund path is documented via the cancel endpoint |
Why is a token approval the riskiest step?
An approval is not a transfer. It grants a contract the right to move your tokens on an ongoing basis, and it persists after the trade completes.
For a human this is a known hazard with known hygiene: approve exact amounts, revoke stale approvals. For an agent it is worse in three specific ways.
The agent chooses the amount. An agent optimising for fewer future steps has an obvious incentive to set an unlimited allowance. That is the correct choice for efficiency and the wrong one for safety.
The agent does not revoke. Approval hygiene is a maintenance task with no immediate payoff. Nothing in a typical agent loop creates the pressure to do it.
The blast radius outlives the session. A stale unlimited approval remains exploitable long after the agent that granted it has finished. The 2024 Socket exploit was possible precisely because of stale unlimited approvals.
Why is signing arbitrary calldata a problem for an agent?
A transactionRequest is an opaque payload. Signing it means authorising whatever it encodes.
A human signing blind is already the standard failure mode in this industry. An agent signing blind is the same failure with no hesitation, at machine speed, and with no intuition that something looks wrong.
There is no general way for an agent to verify that a returned payload does what the quote said it does. It can decode it and compare against expectations, which requires the agent to have an ABI, a policy and a reason to bother. In practice most will sign what they are given.
A plain transfer of a native asset to an address has a much smaller surface. There is an amount and a destination. Both are checkable against the quote in one comparison.
What makes an interface agent-safe?
Five properties, in rough order of how much they matter. Use this as a checklist against any interface, including the ones below.
- No arbitrary calldata to sign. The agent should be able to verify the entire action from the quote.
- No token approvals. No standing rights granted to any contract.
- Idempotency. A retry after a timeout must not create a second order. Rift's order endpoints accept an
idempotencyKey1. Check whether the interface you are using has an equivalent, and test it rather than assuming it. - A recovery path that does not require a fresh signature. If the agent dies, the funds must be retrievable by some other means.
- Deterministic amounts. The agent must know exactly what to send. An ambiguous amount is an operational failure waiting to happen.
What happens if the agent dies mid-trade?
This is the question most agent tooling does not answer, and it is the one that decides whether an agent can run unattended.
On approve-and-sign flows, the outcome depends on where it stopped. Approval granted but not spent leaves a standing allowance. Signed and broadcast but not tracked leaves funds in flight with no watcher.
On deposit-address flows, funds sit at the order address until the order fills, expires, or is cancelled. Rift's published API documentation describes a cancel endpoint with two authorisation modes: a bearer refundToken returned at order creation, and an EVM signature with a deadline.1 Token mode is the one that matters for agents, because recovery would not depend on the agent still holding a key or being alive to sign.
[VERIFY BEFORE PUBLICATION: confirm that refundMode: token is fully supported in production and that an agent using it never needs to produce an EVM signature at any point in the lifecycle, including refunds. If a signature is required anywhere, this section and the comparison table both change.]
Where these interfaces beat Rift
Rift's agent surface is behind. This is a comparison of interfaces, not an argument that one is finished.
- LI.FI ships far more. An official MCP server, a CLI built for token efficiency, a published OpenAPI spec, an
ai-plugin.json, agent skill listings on three directories, and a documentation entry point written for agents. Rift currently has none of these. - Chain coverage. LI.FI covers 58 chains. Rango covers 85+. Rift covers four. An agent working outside Bitcoin, Ethereum, Arbitrum and Base cannot use Rift at all.
- Maturity. These interfaces are in production with real usage. Rift's agent surface is a plan.
- Discovery. LI.FI is listed across the major MCP registries and skill directories. An agent searching by capability will find it and will not find Rift.
What is still unsolved for everyone
Discovery. An agent has to be told which interface to use, or find it in a registry. LI.FI has not published to the official MCP registry; a third party is temporarily managing its record. A third-party wrapper is separately indexed under LI.FI's name on two registries. An agent searching by capability can load the wrong server.
Verification. No interface here lets an agent independently confirm that the returned quote is the best available. It has to trust the router or quote several and compare, which multiplies latency and cost.
Policy. None of these interfaces carries a native way to express a spending limit, a slippage ceiling or a per-session cap. That policy lives in the agent, where it is easy to omit.
Sources
- LI.FI agent integration paths and documented MCP flow — LI.FI docs: https://docs.li.fi/agents/overview
- LI.FI MCP server tool sequence — LI.FI docs: https://docs.li.fi/mcp-server/overview
- Rango single-signature BTC-to-EVM quoting — Eco, "Best Crypto Bridge Aggregator 2026": https://eco.com/support/en/articles/15291263-best-crypto-bridge-aggregator-2026
- Socket approval-related exploit and approval hygiene — Bungee guide: https://bungee-exchange-site.github.io/
- Third-party LI.FI MCP wrapper listings — Glama and Smithery MCP directories
- Rift order lifecycle, refund modes and idempotency — Rift API documentation: https://docs.rift.trade
Related: LI.FI Alternatives: 7 Cross-Chain Routers Compared compares the same providers on fees and coverage.