INERTIAGitHub

What Actually Happens When Your Solana Swap Doesn't Land

A few months ago I got curious about a small, specific thing: what actually happens on Solana when a swap transaction doesn't land. Not "the network was down." Solana has gone well over a year without a major outage, through some of its most congested stretches. Something narrower and, I think, more interesting: your transaction leaves your wallet, the network is fine, blocks are being produced normally, and your specific transaction just... doesn't make it in.

I assumed this was rare. It isn't.

Over a recent 60-day stretch, Solana's network-wide transaction failure rate ranged from roughly 20% to 45.5%, averaging near 39% (Flipside data). A first systematic academic study of failed Solana transactions, published at ISSTA 2025 and based on 1.5 billion failed transactions across more than 72 million blocks, breaks down why: 47.99% of failures come down to "price or profit not met," another 19.19% are classified as invalid-status errors, and 17.72% are validity expirations. Together, the first two account for roughly two-thirds of everything that fails. During periods of memecoin mania specifically, up to 75% of non-vote transactions failed outright. And the failures aren't evenly distributed: Solana bots fail 58.43% of the time, against just 6.22% for human-submitted transactions. None of this is the network going down. It's the mechanics of Solana's design: each slot has a single leader, priority fees are set locally and reset every slot, and a transaction that loses that local auction, or expires before a leader gets to it, doesn't get queued for later. It just doesn't land.

For most transactions that's an inconvenience: you retry, you pay a bit more, you move on. For a swap, it's a different kind of problem, because a swap isn't just a transaction, it's a price you already committed to. Every slot it sits unconfirmed is a slot where the market can move against you. If it eventually lands late, you might get filled at a worse price than you approved. If you give up and resubmit and then the original also lands, you've got a duplicate execution and a support ticket shaped like a small crisis. Multiply a ~39% average failure rate by Solana's real transaction volume (something like 70 million transactions a day as of late 2025) and this isn't an edge case. It's a very large number of swaps, every single day, quietly not doing what the user expected.

What surprised me more, once I started looking, was how much good tooling already exists for the other half of this problem, and how little exists for this half. Priority fee estimators from Helius, Triton, and most RPC providers do a genuinely good job of recommending a fee likely to win the local market. Private RPC endpoints and Jito bundle submission route transactions away from the public mempool and meaningfully improve landing odds. Compute budget instructions stop you from wasting priority fee or under-requesting compute units. All of this is real, useful engineering, and none of it is what I'm describing.

Every one of those tools operates before a transaction is sent. That's the entire category. Once a transaction has actually left your wallet and failed to land, there is no existing on-chain mechanism, that I could find, that does anything about it at all. The industry has built an excellent set of tools for improving your odds, and essentially nothing for the case where the odds don't go your way, which, again, is not rare. It's closer to two-in-five on average, and it doesn't spare exactly the moments when price matters most: during memecoin mania, that number has run as high as three-in-four.

I kept expecting to find that someone had already solved this and I'd just missed it. I didn't find it. What I found instead were three weaker options, none of which anyone had fully committed to: build a centralized relayer that retries on the user's behalf (fast to build, but now you've reintroduced a trusted intermediary and a single point of failure into a system explicitly designed to avoid both); have the protocol just eat the cost of failed swaps as a subsidy (doesn't scale, and has no way to distinguish a swap worth rescuing from one that isn't); or just... accept it, and let users occasionally lose value to a structural quirk of how leader scheduling works, because that's apparently the status quo.

None of those sat right with me, so I started building something narrower: a way to escrow a small gas buffer and a revocable spending delegation, never custody, at the moment a swap is submitted, and let a permissionless network of keeper bots race to complete the swap if it stalls, in exchange for a bounty out of that buffer. If nobody does, the user gets everything back themselves after a short window. Nothing is ever locked up beyond what the user posted voluntarily, and nothing requires trusting me, or any specific keeper, or any specific piece of infrastructure staying online.

That's the part I actually want to write about another time: the mechanism, the mistakes I made building it, the vulnerability I found in my own first design and how I fixed it. This post is just about the problem, because I think the problem is the part people underrate. It's easy to assume "Solana is fast, it basically works" and move on, and mostly that's true. But "basically works" is doing a lot of quiet, uncounted work in that sentence. On average it fails something like one-in-five to two-in-five times, and during exactly the moments people care most about price, that number has run as high as three-in-four.

If you build anything that routes swaps on Solana, this is worth sitting with for a minute: what actually happens, on your platform, to the user whose transaction didn't land? If the honest answer is "nothing, they're on their own," that's the gap I think is worth closing.

Sources