LLM trading agents fail onchain for two different reasons: the model makes a poor decision, or a sound decision turns into a bad transaction. Research benchmarks mostly measure the first. CryptoBench, an expert-curated benchmark that adds 50 questions per month, found that leading models retrieve crypto data well but show a pronounced weakness on predictive analysis (CryptoBench, arXiv 2512.00417). The second kind of failure, where execution goes wrong after the decision, gets far less attention: stale quotes, slippage, a balance that changed, the wrong chain. This page covers both and the guards that address each.
Last reviewed: Nov 2026. Benchmark findings are summarized from the papers' abstracts; read the papers before relying on specific results.
Decision Failures vs Execution Failures
A decision failure is a wrong call: buying the wrong token, at the wrong time, for the wrong reason. An execution failure is a right call that lands badly: the trade fills at a worse price than expected, partly fails, or runs against a balance that no longer exists. They need different fixes, because better models reduce the first and do nothing for the second.
Failure | Layer | Example | Main guard | Sources |
Weak prediction | Decision | Agent appears grounded but forecasts poorly | Evaluation, position limits | |
Framework behavior | Decision | Same model, very different risk-taking by architecture | Test the agent, not just the model | |
Price moves before inclusion | Execution | Swap fills below expected output | Minimum-output condition in the transaction | |
Stale state | Execution | Balance or position changed after simulation | Balance check at execution time | |
Irreversible error | Both | Hallucinated input triggers a trade | Spending limits, approval |
What the Benchmarks Measure
The two most cited benchmarks for crypto trading agents both measure decision quality. CryptoBench tests retrieval and prediction tasks designed by crypto professionals. Agent Market Arena runs agents in live crypto and stock markets and compares architectures and models. Neither isolates what happens between a decision and a confirmed transaction.
CryptoBench sorts its monthly questions into four quadrants, Simple Retrieval, Complex Retrieval, Simple Prediction and Complex Prediction, and evaluated ten LLMs directly and inside an agentic framework. Its authors call the main failure mode a retrieval-prediction imbalance and warn of agents that appear factually grounded while lacking the analysis to synthesize information (CryptoBench). The paper was first submitted on November 29, 2025 and revised through May 15, 2026.
The CryptoBench authors explain why crypto is harder than general agent benchmarks: extreme time-sensitivity, a highly adversarial information environment, and the need to combine specialized sources such as onchain intelligence platforms and real-time DeFi dashboards (CryptoBench). Each of those conditions also affects execution. Time-sensitive data goes stale between the decision and the block, and adversarial inputs are the same channel prompt injection uses, which Eco's guide to prompt injection attacks on agents that hold funds covers in detail. Agent Market Arena addresses data quality from the other side by integrating verified trading data and expert-checked news (When Agents Trade).
Agent Market Arena, introduced in "When Agents Trade" on October 13, 2025, is a lifelong, real-time benchmark that runs four agent designs, InvestorAgent, TradeAgent, HedgeFundAgent and DeepFundAgent, across GPT-4o, GPT-4.1, Claude-3.5-haiku, Claude-sonnet-4 and Gemini-2.0-flash. Its abstract reports that agent frameworks display markedly distinct behavior, from aggressive risk-taking to conservative decisions, while model backbones contribute less to outcome variation (When Agents Trade, arXiv 2510.11695). For builders, that finding shifts attention from picking a model to designing the agent around it. Eco's agentic trading guide covers how agents place trades in general.
Why Do Onchain Trades Fail After the Decision?
Onchain trades fail after the decision because the chain state the agent reasoned about is not the state the transaction meets. Prices move, other transactions land first, balances change, and quotes expire. An agent that builds a transaction from a snapshot and sends it later is betting the snapshot still holds.
Simulation narrows the gap but does not close it. Eco's Sauce documentation describes simulation as running the transaction against chain state without signing or sending it, and states directly that state can change before the transaction is sent (Eco docs: Sauce introduction). The same holds for any simulator; see Eco's simulation tools comparison.
Multi-step strategies compound the problem. A rebalance that withdraws from one venue, swaps, and deposits elsewhere can fail at any step. If each step is a separate transaction, a failure halfway leaves funds in an intermediate position the agent never planned for. Chainlink notes that because smart contract transactions are irreversible, an AI error can lead to permanent loss of funds (Chainlink: What Is DeFAI).
Inputs add another path. Agents increasingly buy market data per call: Turnkey's analysis of Coinbase's x402 Bazaar found crypto market data and trading signals accounted for 48,853 calls, 23.4% of the top 100 listings over a 30-day window ending September 13, 2026, and noted that most of those feeds served a handful of payer addresses (Turnkey). A wrong or manipulated feed becomes a wrong trade unless something checks the outcome.
The Minimum-Output Guard
The most direct guard against execution failure is a condition checked inside the transaction: if the swap returns less than a stated minimum, or a balance falls short, the whole transaction reverts and nothing moves. The agent can still be wrong about what to trade, but it cannot complete a trade at a state it never accepted.
Sauce, Eco's onchain harness for agents, is built around this pattern. A Sauce program combines several onchain actions and the conditions they must satisfy into one transaction; if a failure is not handled by the program, the transaction reverts and its transfers are undone. The docs list enforcing a minimum output, comparing pools, and trying a second pool when the first fails as common swap patterns, and lending actions that check the resulting position (Eco docs). Because the program reads balances and prices at execution time, the check runs against the state the transaction actually meets.
agent decides: swap 1,000 USDC for token X, expect at least N
|
v
program (one transaction):
require(pot.USDC >= 1000 USDC) -- balance still there?
out = best_of(poolA.quote, poolB.quote)
swap on chosen pool
require(out >= N) -- price still acceptable?
|
all checks hold -> transfers execute
any check fails -> whole transaction reverts, funds stay putThe Sauce MCP server lets coding agents compile, simulate and build these programs, and its transaction-building tools return unsigned transactions for a wallet to sign (Eco docs: Sauce for AI agents). Execution is atomic within one chain; the docs note that a program runs on one chain. See programmable transactions vs smart contracts for the broader model.
A Checklist for Builders
A trading agent that holds funds needs controls at both layers. At the decision layer: evaluate the whole agent rather than the model alone, cap position sizes, and require approval above a threshold. At the execution layer: simulate, put minimum-output and balance conditions inside each transaction, and keep keys outside the agent.
Evaluate the agent. Agent Market Arena found framework design mattered more than the model (When Agents Trade).
Cap exposure. See AI agent spend controls.
Approve large trades. See human approval for AI agent transactions.
Guard execution. Minimum output and balance checks inside the transaction (Eco docs).
Keep a stop. See the AI agent kill switch guide.
Where This Falls Short
Execution guards solve a narrow problem well and leave the rest. They stop a trade from completing at an unacceptable state, but they cannot judge whether the trade made sense, they only check what the program states, and they work within one chain per transaction. Decision quality remains an open research problem.
Bad goals pass. A valid swap the agent should never have made still executes.
Thresholds need care. A minimum set too loose protects nothing; too tight and most trades revert.
Benchmarks are young. Both papers describe evolving benchmarks; results will move as models and agents change.
Frequently Asked Questions
These are the common questions about why LLM trading agents fail and how to guard against it.
Are LLM trading agents profitable?
The benchmarks here measure capability and behavior rather than settle that question. CryptoBench reports weak predictive performance across leading models (CryptoBench).
Does a better model fix execution failures?
No. Price movement and stale state happen after the decision. Conditions inside the transaction address them (Eco docs).
Is simulation enough?
No. State can change between simulation and sending (Eco docs).
What is a minimum-output check?
A condition that reverts a swap if it returns less than a stated amount, evaluated during execution.
Related Reading
Sources and Methodology
Benchmark descriptions come from the arXiv abstracts and Sauce behavior from Eco's documentation, fetched on November 12, 2026. No trading agent was run for this page.

