Reading the Solana Failure Paper: 2.9B Transactions, One Mirror

A Paper That Reads Like an Autopsy of My Own Bot

I find a paper on arXiv this week and it stops me cold. The title is "Why Does My Transaction Fail? A First Look at Failed Transactions on the Solana Blockchain," published as arXiv:2504.18055 and accepted to ISSTA 2025. Five researchers from Zhejiang University, Hangzhou High-Tech Zone Institute, and Singapore Management University sat down and did the thing I have been avoiding for months: they pulled a year of Solana history and asked, with academic rigor, why so many transactions die on the way to confirmation.

The headline number is brutal. Of roughly 2.9 billion non-vote transactions analyzed between August 2023 and July 2024, about half failed. More than 1.5 billion transactions paid fees, consumed compute, and produced nothing. I have been running an MEV bot long enough to know that I am part of this statistic — not a curious outsider studying it.

What hits hardest is the bot-versus-human breakdown. Per the arXiv preprint, bot accounts show a 58.43% failure rate while human accounts sit at 6.22%. That is not a small gap. That is the difference between a casual driver and someone who has been doing donuts in a Walmart parking lot for an hour straight. The peer-reviewed ISSTA 2025 version reports an even higher bot failure rate of 73.4%, which the authors attribute to refined classification on the final dataset. Either way the conclusion is the same: bots are the source of most of the noise on this chain, and I am running one of them.

Why I Read Academic Papers Now Instead of Twitter Threads

Before I started building a bot, my mental model of Solana came from short videos, conference clips, and the occasional thread from a builder I follow. That was fine for picking a chain. It is not fine for engineering one.

A paper like this one is different in three ways. First, it commits to a dataset and tells you exactly how big it is — 72,123,900 blocks covering one full year. Second, it tells you its confidence interval: 99.999% with a margin of error of about 0.06%. Third, it submits itself to peer review at a venue where reviewers care whether your classifier actually works, not whether your tweet trends.

I am not going to pretend I can replicate their methodology in my apartment. What I can do is read it as a practitioner, line by line, and ask: do the patterns they find match the patterns I see in my own logs? Almost every time, the answer is yes. That alignment is what makes this paper useful instead of merely interesting.

The Ten Buckets Where Transactions Go to Die

The authors classify failures into ten error themes using a combination of automated extraction and manual thematic coding. Two independent coders read top-frequency error messages and produced 45 codes that fold into 10 themes. That sounds dry until you read the numbers.

The top three categories alone account for roughly 85% of all failures. The single largest is "price or profit not met" at 47.99% of failures. "Invalid status" follows at 19.19%. "Validity expiration" — the blockhash-aging family of errors — comes in at 17.72%. Everything else combined is a rounding error by comparison.

For a bot operator, that distribution is a kind of confession. The largest category is not a bug, it is the natural shape of slippage-protected arbitrage running into competition. Half of all failures on Solana are essentially the chain telling bots "you got outbid on this opportunity, and your safety check saved you from completing a losing trade." That is a feature, not a defect. But it also means that the average bot — including mine, on its worst days — is shouting into the void roughly half the time it tries to act.

Where the Failures Cluster: Programs, Not Wallets

The paper publishes a top-10 programs table that I want to print out and tape above my desk. Together those ten programs account for nearly 78% of all failed transactions.

Raydium Liquidity Pool V4 is number one with about 327 million failed transactions and a 74.21% failure rate against its own traffic. Jupiter Aggregator V6 sits at number two with 252 million failures and a 79.74% rate. Chainlink Data Store, which I would have guessed sits comfortably above the fray, posts a 94.18% failure rate against 227 million transactions thanks to its "stale report" error pattern.

A few entries are signed by addresses the paper labels simply as "unknown," and these are the truly unsettling ones. One of them shows a 99.12% failure rate. Another shows 97.67%. Programs that fail nineteen out of twenty times do not exist by accident. Someone is paying fees to interact with them at scale, knowing full well most of the calls will revert. That is either a very specific niche strategy or somebody's bot left running long after the bug that broke it was forgotten.

The error fingerprints differ by program in ways that make engineering sense. Jupiter's V4 and V6 are dominated by "price or profit not met" because aggregators are where slippage shows up first. Raydium V4 is dominated by "invalid status," which the authors associate with sniper bots racing against stale pool state. Chainlink's failures are mostly validity expiration — the oracle moved between submission and execution, and the bot was holding a now-stale view.

The Fee and Compute Profile of a Failing Bot

This is the section of the paper that made me close my laptop and walk around the block. The authors run statistical tests on fees and compute usage and find three things, all significant at p < 0.001 per the arXiv full text:

1. Failed transactions pay higher fees than successful ones across every quantile.
2. Failed transactions consume fewer compute units than successful ones, especially below the 70th percentile.
3. Failed transactions therefore pay a higher fee per compute unit than successful ones.

In plain English: the bots that fail are bidding aggressively on priority while under-budgeting the actual work their transactions need to do. That is exactly the kind of misconfiguration you write when you are tuning for "get me into the block" without thinking carefully about "give my code enough room to actually execute." I know I have written that bug. I have probably written it three different ways.

The block-position numbers fit the same story. Failed transactions land at a median position of 592 in the block; successful ones at 529. They are reaching the block, just slightly later, and slightly hungrier for room they didn't reserve.

Bots Versus Humans: Different Worlds, Same Chain

The classification methodology deserves a paragraph because I was skeptical at first. The authors train a random forest classifier on 200 manually labeled accounts — 96 humans and 104 bots — using features like transaction frequency, volume, intervals, and program-interaction patterns. They report 96.91% accuracy on a validation set with a 95% confidence interval. The probability threshold for inclusion is 0.9, which is strict enough to avoid the obvious traps.

With that classifier they end up with 803,136 bot accounts and 1,359,772 human accounts. The error distributions between the two are revealing:

• Bots: price/profit (60.65%), invalid status (18.78%), invalid input account (17.80%).
• Humans: price/profit (63.95%), invalid status (19.77%), out of funds (8.14%).

Humans run out of money. Bots run out of accounts to point at — they ship transactions referencing accounts that no longer exist, or that the bot's own state model believed existed. That is not a difference of skill, it is a difference of scale. A human typing into a wallet UI cannot generate "invalid input account" errors at the volume a misconfigured arbitrage worker can.

The Mempool Question, Again

The paper is careful to compare Solana with other chains, and the cross-chain numbers bring out something I keep underestimating. On Ethereum, human-account failure rates sit at roughly 1–3%, and bot spamming at Solana's scale is economically prohibitive because of gas costs and sequential execution. On Solana, low fees and the lack of a public mempool turn the chain into a place where it is rational to fire transactions that you know will probably fail, because the cost of failing is trivially small.

I have to stop and underline that Solana lacks a public mempool — there is no pre-confirmation pool that anyone can read and front-run the way you can on Ethereum. There is a leader for each slot, and transactions either reach that leader in time or they don't. But this same architecture — combined with sub-cent fees — is what makes mass speculative submission cheap. It changes who can play and how loudly they can yell.

For context outside the paper, the PANews ecosystem report notes that a major MEV builder processed over 3 billion transaction bundles in one year and generated 3.75 million SOL in tips. Bundle volume peaked at 24.4 million bundles in a single day on December 21, 2024. Reverted transactions on Solana once peaked at 75.7% of all non-voting transactions in April 2024. The paper's snapshot is therefore conservative compared to the chain at its noisiest moments.

What This Means for an Operator Like Me

I run a small Solana MEV bot. I am not a fund. I am one person plus an AI assistant plus a paid RPC tier plus a stubborn refusal to stop, and the question I have been chewing on for weeks is: where is the next 10 percentage points of success rate going to come from?

Reading this paper reframes the question. The chain-wide bot failure rate is roughly 58% to 73% depending on which version of the paper you trust. If my bot is anywhere near average, the gap between "average" and "good" is large. The error distribution tells me where to look:

• If I am dying to "price or profit not met," I have a competition problem and a routing problem. My slippage protection is doing exactly what it should — keeping me from completing a bad trade — but my detection-to-execution loop is slow enough that the opportunity is gone by the time my transaction lands.
• If I am dying to "invalid status," my view of pool state is stale. The data I am acting on is older than I think it is, and I am picking races I cannot win.
• If I am dying to "validity expiration," I am submitting too late or holding transactions too long. The blockhash window is short on Solana, and bots that batch or queue too aggressively bleed expiration errors.
• If I am dying to "invalid input account," my account derivation logic has drift somewhere — maybe a Token-2022 mint where I assumed legacy, maybe an account that closed since my last refresh.

These are different bugs that produce different smells. The paper lets me look at my own failure logs and ask "which category am I in this hour?" instead of staring at raw transaction signatures hoping for a vibe.

What This Means for the Network

There is a public-goods angle too, and the paper does not shy away from it. If more than 1.5 billion failed transactions cross the chain in a year, that compute is not free even when individual fees are tiny. Validators run hardware that is sized for total load, not successful load. Block space that goes to bot retries is block space that does not go to human users sending a payment or minting an NFT. The authors note that after a validator update released on June 10, 2024, failure rates dropped meaningfully — suggesting that the largest single lever on bot waste was not a strategy change at the bot layer but an infrastructure fix at the validator layer.

That humbles me. I can spend weeks tuning my detection logic. The team behind the dominant validator client can ship one fix that does more for chain hygiene than every solo bot operator combined. I am inside this system, but I am not the loudest voice in it.

It also means I should not feel especially clever about getting my own success rate up. The chain is going to keep getting better at filtering low-quality bot traffic. "Beating the average failure rate" by riding a regression in validator behavior is not a moat. It is a bus I happen to be on.

A Note on What the Paper Cannot See

No dataset captures everything, and I want to mark the edges of this one before I lean on it too hard. The paper looks at non-vote transactions. It does not separately study block-engine bundles as auction units — those are addressed in adjacent work like the ACM Internet Measurement Conference 2025 study on sandwiching MEV on a major Solana MEV builder. It also covers a specific calendar window, August 2023 through July 2024, and the chain has changed since.

The Extropy cross-chain MEV analysis covering September 2023 through August 2024 reports roughly 90 million successful arbitrage trades and hundreds of millions of dollars in total arbitrage profits, with an average profit per trade of $1.58. That tiny average matters: when each successful arb is worth pocket change, the economics only work if you can run them at a volume and failure rate that the paper is now telling us is closer to half-shots than sure-things. Solo operators competing for $1.58 trades with a 58% failure rate are not playing the same game as well-capitalized teams with co-located infrastructure.

Reading Papers as a Discipline, Not a Habit

One reason I am writing this up is to convince myself to keep doing it. Reading academic papers about the chain I am trying to extract value from feels slow compared to skimming a feed, but every time I do it I find that some assumption I picked up from a podcast was wrong, or that some intuition I had about my own bot was confirmed in a way I could not have produced by myself.

The authors did the boring work. They pulled blocks 208,703,000 through 280,826,900. They sampled 10.4 million blocks across 53 days for parts of the analysis. They built a classifier, validated it, and then organized 2,311 unique error messages into 45 codes and 10 themes through manual thematic analysis. That is months of effort. I get to read it in an afternoon.

The trade is so obviously in my favor that the only honest response is to keep showing up for it. Pick a paper. Read it for what it says, not for what I want it to say. Map it back to my own logs. Update the things I believed that the data does not support.

What I Am Going to Do Differently This Week

No grand resolutions, just three concrete changes that fall directly out of this reading.

First, I am going to tag every failed transaction my bot emits with which of the ten error themes it falls into, so I can report my own breakdown back to myself daily. Right now I have failure counts. I want failure distributions.

Second, I am going to audit my compute-budget settings against my priority-fee settings. The paper's evidence that failed bots over-pay on fees while under-allocating compute is exactly the smell my own configurations have. I have probably written that bug. Time to find it.

Third, I am going to stop celebrating drops in raw failure count without checking whether they are correlated with drops in opportunity count. A bot that fails less because it tries less is not improving. It is hiding.

The paper does not tell me how to make money. It tells me how the chain actually behaves at billion-transaction scale, which is the prerequisite for any honest attempt at the first thing. I will take that trade every week of the year.

Key Takeaways

• An ISSTA 2025 paper analyzes roughly 2.9 billion Solana non-vote transactions across one year and finds that bot accounts fail at 58.43% (arXiv) or 73.4% (ISSTA final) while human accounts fail at only 6.22%.
• Three error themes — price/profit not met (47.99%), invalid status (19.19%), and validity expiration (17.72%) — account for roughly 85% of all failures and map cleanly to competition, stale state, and blockhash aging respectively.
• Just ten programs, led by Raydium V4, Jupiter V6, and Chainlink Data Store, are responsible for nearly 78% of all failed transactions, with several anonymous programs posting failure rates above 95%.
• Failed transactions pay more in fees per compute unit while requesting fewer compute units than successful ones, a fingerprint of bots that bid aggressively on priority but under-budget actual execution.
• The largest single improvement in chain-wide failure rates during the study window came not from bot operators getting smarter but from a validator client update in mid-June 2024 — a reminder of where the real leverage sits.