2,959 of 13,527 non-vote transactions failed across 39 mainnet blocks spread over 0.8 hours, read at 12:36 UTC on 2026-09-24.
◆Base layer, measured
Solana failed transactions
About one in four non-vote transactions on Solana executes and fails, and pays for it. The numbers, from a public dashboard and from blocks this site read itself, and why it happens.
A Solana transaction can end three ways: it lands and succeeds, it lands and fails, or it never lands. The middle case is the one nobody prices in. On a typical day a quarter to a third of the non-vote transactions the network executes fail — the program they call returns an error — and every one of them pays its fee. This page puts the number in front of you from two sources that do not share a pipeline, breaks a sample of it open, and says why it happens.
01The rate
How many Solana transactions fail
Two sources that do not share a pipeline. The dashboard counts every day since 2023; the sample is this site reading recent blocks straight from a public RPC node. Both exclude validator vote transactions unless they say otherwise.
34.7%
Non-vote transactions that fail
Daily figure for 2026-07-19 from the public dashboard, whose query was last run on 2026-07-21 — read on 2026-09-15.
Source: Dune · scarn_eth ↗
26.5%
Measured by this site
4,100 of 15,459 non-vote transactions failed across 39 mainnet blocks spread over about an hour, read on 2026-09-15 (UTC).
Source: Solana mainnet public RPC, block by block · committed snapshot
0.3%
Vote transactions that fail
Consensus votes are 56.2% of all transactions and almost never fail. Counting them makes the overall rate 15.4% — the number most often quoted, and the one that hides the user-facing figure.
Source: Dune, same day
02Inside the sample
What the failures were
A failed transaction on Solana is one the leader included and executed, and whose program then returned an error. It is not a dropped transaction — those never reach a block and no public dataset counts them. Every failure below still paid its fee.
By error kind
- Program returned its own error (slippage, price moved, checks failed)
- 3,865 · 94.3% of failures
- Instruction data the program could not parse
- 153 · 3.7% of failures
- Account data not what the program expected
- 38 · 0.9% of failures
- Program aborted
- 15 · 0.4% of failures
- Could not cover rent
- 12 · 0.3% of failures
- Signed by the wrong authority
- 7 · 0.2% of failures
- Transaction loaded more account data than its limit allows
- 4 · 0.1% of failures
- Instruction given fewer accounts than it needs
- 3 · 0.1% of failures
- Insufficient funds
- 2 · 0.0% of failures
- Instruction aimed at the wrong program
- 1 · 0.0% of failures
What the failures cost
- Fees paid on failed transactions
- 0.0948 SOL in 39 blocks
- Fees paid on successful ones
- 0.5083 SOL
- Share of all fees that bought nothing
- 15.7%
- Vote transactions in the same blocks
- 26,091 · excluded from every rate above
By program touched
| Program | Transactions | Failed | Failure rate |
|---|---|---|---|
| System program 11111111… | 10,152 | 3,227 | 31.8% |
| SPL Token Tokenkeg… | 8,706 | 2,729 | 31.3% |
| Associated Token Account ATokenGP… | 7,019 | 1,950 | 27.8% |
| SPL Token-2022 TokenzQd… | 6,619 | 2,520 | 38.1% |
| Unlabeled program pfeeUxB6… | 6,014 | 2,070 | 34.4% |
| Pump.fun AMM pAMMBay6… | 5,018 | 1,324 | 26.4% |
| Memo MemoSq4g… | 2,389 | 1,013 | 42.4% |
| Unlabeled program LBUZKhRx… | 1,835 | 746 | 40.7% |
| Pump.fun (bonding curve) 6EF8rrec… | 1,087 | 758 | 69.7% |
| Jupiter v6 JUP6LkbZ… | 922 | 635 | 68.9% |
| Unlabeled program 9H6tua7j… | 790 | 279 | 35.3% |
| Unlabeled program EtrnLzgb… | 757 | 140 | 18.5% |
A transaction counts once for every program it touches, so the rows overlap. Compute-budget instructions are not counted as a program. Labels are for well-known program ids; unlabeled rows show the id.
03Why
Why they fail
Almost all of the failures in the sample are one kind: the program ran and said no. That is not the network breaking. It is what happens when many parties send transactions that can only succeed for one of them, and the rest execute anyway.
- 01
Bots race for the same opportunity
An arbitrage, a liquidation, a token launch: when one of them appears, every bot watching it sends a transaction. One wins. The others still execute, hit the program's checks — the price already moved, the position is already closed, the pool already changed — and fail. Of the busiest programs in the sample, the two that fail most do so about seven times in ten: Pump.fun's bonding curve, a token-launch venue where the racing is the whole business, and Jupiter v6, a swap aggregator.
- 02
Slippage limits do their job
A swap carries a worst-acceptable price. If the pool moved between signing and execution, the program refuses the trade. That is the protection working, but it counts as a failed transaction and the fee is spent.
- 03
The state changed under the transaction
A transaction is built against a snapshot of the accounts it touches. Hundreds of milliseconds later, at execution, an account may have a different balance, a different owner, or may no longer exist. The program sees the new state and rejects.
- 04
Compute and data limits
A transaction that asks for less compute than it needs, or hands a program bytes it cannot parse, fails after doing the work. In the sample they are 3.9% of the failures, against 94.3% for programs returning their own error.
- 05
Every failure is paid for
Solana charges the fee whether the program succeeds or not, because free failures would be free spam. For a bot that is the cost of doing business; for a person it is a surprise. In the sample, 15.7% of all fees paid in the hour bought nothing — a share that swings with priority fees from hour to hour far more than the failure rate does.
- 06
Failed is not dropped
None of these numbers include transactions that never reached a block — the leader was overloaded, the route was congested, the blockhash expired. Those are invisible to every dataset built from blocks, and at peak they are the larger problem. The Why Layer 2 page is about that case.
04What changes
What a separate execution lane changes
A rollup does not make a bad trade good. What it changes is who you compete with, what you know before you pay, and what you learn when it fails.
Contention is scoped to the workload
On the base layer a swap competes with every bot and every launch on the chain at once. On a dedicated lane it competes only with the traffic on that lane, and the operator can size the lane for it.
Ordering is explicit
Solieum's sequencer takes transactions in the order it receives them and issues a signed receipt for the position. Racing for a slot is replaced by a queue you can see, with an equivocation any receipt holder can prove.
A refusal is an answer, not a silence
A transaction the node will not take is answered at submission with the program's own error and its logs. Nothing is left for a poller to discover, and the record of anything that does get dropped — a forced entry that could not run — is in the published data, so it survives a restart.
The fee rule is the chain's to set
Solana keeps the fee on a failure for a good reason: it cannot know the outcome in advance, so the fee is what makes spamming expensive. Solieum can know, so it refuses instead and charges nothing — see the section below. The rule is the chain's to choose; the base layer cannot choose one per application.
Forced inclusion for the censorship case
A transaction the sequencer will not take can be posted on Solana and must be included within a deadline. That covers the dropped-not-failed case a base layer has no answer for.
What it does not change
Slippage still expires, races still have one winner, and a program that says no still says no. The failures that come from competition move; the ones that come from the trade itself do not.
05On Solieum
How Solieum gets to zero
The failure rate on this page is not a defect in Solana; it is the necessary consequence of an open fee market. You build a transaction against the state you can see, an unknown leader runs it hundreds of milliseconds later against the state that exists then, after an unknown set of other transactions in an order nobody committed to in advance. Solieum removes the gap rather than narrowing it: it executes your transaction when you submit it, against the exact position it will occupy, and refuses the ones that would fail before they cost anything.
Why this chain can know the answer in advance and the base layer cannot
- One executor. The process that answers your submission is the process that produces the block. Nothing is handed to an unknown party.
- The position is fixed first. Ordering issues a signed receipt for a dense, irrevocable position before execution, so a transaction's predecessors are known when it arrives and cannot change.
- Nothing is ever inserted in front. Every path that adds a transaction, forced inclusion and deposits included, appends. What is queued ahead of you stays ahead of you.
- The block's clock is stamped when the block opens, not when it seals, so the run at submission and the run at seal see identical inputs — including the deadline a program branches on.
Together those mean the state your transaction will execute against is already determined when you press send. Running it then is not a prediction, which is why the answer is exact rather than advisory.
So a submission ends one of two ways
Admitted
It executes against the projected block, succeeds, takes its position, and will succeed at seal. A gated transaction that failed at seal would be a determinism defect in the node, and it is reported in those words rather than counted as a drop.
Refused
It is refused there and then, with the program's own error and logs handed back. No fee, no position, no receipt, no published bytes. Being told no costs nothing and takes milliseconds instead of a block.
The sample on this page is what made the case: of its 4,100 failures, 4,100 — 100.0% — fall into classes that are each a deterministic function of the code and the state it runs against, which is exactly what an execution at admission holds. The largest, at 94.3%, is a program returning its own error, and that is the class a static pre-check would miss entirely.
What this does not mean
It does not mean a trade always works
A slippage limit still refuses, a race still has one winner, and a program that says no still says no. What changed is the price and the latency of being told.
It is not finality, and moves no clock
Succeeding is not settling, and this changes the settlement schedule by nothing at all. The ladder is exactly as it was: the sequencer's receipt is a soft confirmation in milliseconds and is revocable; the block's root reaches Solana under bond within seconds; and the root is final only once it has survived the challenge window — 48 hours (ADR-0016), then a 24-hour air gap, about three days in total — which is the moment a withdrawal against it can complete. “Every transaction in a block succeeded” describes what executed, not what has settled. Read beside a latency figure it would sound like instant finality, which is the one misreading on this page that could cost somebody money.
Forced-inclusion entries are not gated
An entry posted on Solana to defeat censorship is executed and marked included even if it is junk, unsigned or unpayable — otherwise anyone could wedge the chain for the price of one L1 fee. Forced inclusion promises a slot, not a successful transaction, and that promise outranks the statistic. So the on-chain failure rate is zero by construction with forced entries excepted, not zero unconditionally.
It moves a cost onto the operator
Every admitted transaction executes twice and each gate run copies the projected state, so spam that used to be priced by the sender's fee is now paid for in the operator's CPU. A per-sender admission rate limit and a per-transaction compute ceiling are the guards for that and are not built yet; a public endpoint wants a rate limit in front of it until they are.
And it is devnet today
The gate is built, tested and running on the devnet chain, where nothing of value is at stake and there is no public endpoint. It is a property of the node you can read and run, not a measurement of a live network under load.
06Method
How these numbers were made
- The dashboard. Counts every transaction per day from the Solana blocks Dune ingests, splits votes from non-votes, and calls a transaction failed when its execution returned an error. Its author notes that leader overload and dropped transactions are not included, which is the same boundary this page draws.
- The sample. This site read 39 finalized mainnet blocks through the public RPC, spaced roughly 300 slots apart across one hour, taking each block at account-level detail — enough for the account keys, the error and the fee, without pulling whole transaction bodies to count them. A transaction touching the Vote program is a vote; a transaction whose meta carries an error is a failure; the fee is the fee the block recorded. Programs are counted once per transaction they appear in, so the program rows overlap; a key counts as a program when its account is executable on chain, checked in the same sitting.
- Why two sources. The dashboard has the history and the sample has the receipt. They are read through different software from different data, and they land in the same range — a quarter to a third of non-vote transactions — which is the point of having both.
- What is not here. No dropped transactions, no estimate of them, and no bot-versus-human split: the dashboard's own attempt at that split had timed out when it was read, and this site has no better classifier than an arbitrary threshold. Numbers this page cannot stand behind are not on it.
Live series and the query behind the dashboard figures: dune.com/scarn_eth/solana-tx-fail-rate ↗. The sample is re-taken every hour by a scheduled job on the machine serving this page, and the reading on screen says when it was taken; when there is no fresh reading, the page shows the last committed snapshot, dated.
Building something the base layer can't hold?
Tell us the workload. If Solieum is the wrong answer for it, we would rather say so early than have you find out at launch.