Which Solana DEX fails least

A failure is a cost, not an error

The framing that makes this measurement worth doing is that a rejected transaction is not a technical annoyance. It is a purchase that did not arrive.

When a swap fails, the base fee and any priority fee are charged because the validator did the work of processing it. No tokens move, no volume is recorded, and the money is gone. A campaign that sends a thousand transactions into a venue rejecting a third of them has paid for a thousand attempts and received roughly six hundred and seventy swaps.

Almost nobody quotes this number. Fee schedules are published, network costs are discussed endlessly, and the share of transactions a venue actually accepts is treated as an implementation detail. On any campaign of a meaningful size it is a larger variable than most of the things that are quoted.

How we measure it

The method is deliberately simple, because a simple method is one somebody else can reproduce.

1. Ask a Solana RPC node for the current finalized slot.
2. Pull a set of blocks spaced several hundred slots apart, so the sample covers a window rather than a single instant.
3. Read every transaction in those blocks. Record whether the metadata carries an execution error, what fee was charged, and which known DEX program addresses appear in the account list.
4. Count. Failures divided by transactions, per venue and overall, computed over raw values rather than over bucketed averages.
5. Publish the block range and sample size alongside the result, so any figure can be traced to where it came from.

The current numbers, updated weekly, are on the measured data page, and the raw snapshot is downloadable as JSON so the arithmetic can be checked rather than believed.

What the spread looks like

Deliberately no fixed figures on this page, because they change and a stale number quoted confidently is worse than none. What is stable is the shape of the result, and it has been consistent across every sample so far.

The gap between the top and bottom rows has consistently been an order of magnitude rather than a few percentage points, which is the finding that makes the exercise worth repeating.

Why curves fail most

The mechanism explains the number completely, and it is not a criticism of any particular platform.

A bonding curve is one piece of state. Every buyer moves it. When several participants submit transactions against the same curve inside the same slot, each of them quoted a price from a state the others are simultaneously changing. Only the transactions that land first receive what they quoted; the rest exceed their slippage tolerance and revert.

Tolerances on curves have to be tight, because curve pricing moves in fine increments, which makes the problem worse rather than better. The result is a structurally high rejection rate during any period of interest, and interest is precisely when people want to be trading.

An AMM pool with real depth behaves differently for a structural reason: your swap is small relative to the reserves, so other traffic in the same block moves the price by less than your tolerance allows. The venue is not better engineered; it is less contested per unit of depth.

What it means for routing

Three practical consequences follow, and all of them are decisions made before a campaign starts rather than settings tuned during one.

Failure rate is chosen by routing. A campaign concentrated on a contested venue will reject a large share of what it sends regardless of configuration. The same budget spread across pools with depth converts far more of itself into confirmed swaps.

Curve-era results understate pool-era results. A team that ran a campaign while their token was still on a curve, and calibrated expectations from it, will find the same budget performs considerably better after migration. That is a pleasant direction to be wrong in and still worth planning around.

Swap size is the other lever. Smaller swaps relative to depth fail less, because your own order moves the price less and therefore stays inside tolerance more often. That is the same conclusion nearly every execution question in this category arrives at, and the failure guide covers how to identify which specific error you are hitting.

There is a fourth consequence that only becomes visible once you have the numbers, and it changes how a campaign should be judged rather than configured. If a venue rejects a known share of what it receives, then the gap between attempted and confirmed swaps is predictable rather than mysterious. A campaign reporting fewer confirmed swaps than transactions sent is not necessarily misconfigured; it may be performing exactly as the venue's measured rate implies. Knowing that figure in advance turns an alarming result into an expected one, and it is the difference between diagnosing a problem and inventing one.

What the measurement does not claim

Being precise about the limits is what makes the figures usable.

It is a sample, not a census. A set of blocks across a window, not every transaction ever sent. A sample taken during unusual conditions reads differently from one taken on a quiet afternoon, which is why the block range is published alongside the result.

Venue attribution counts transactions that touch a program, rather than decoding instruction data to determine intent. A transaction routing through two venues is counted for both. That is the correct reading for execution purposes and it is not the same as counting swaps.

It says nothing about why any individual transaction failed. The aggregate tells you where failures concentrate; the specific cause of one failure is in its own transaction log.

It is republished rather than smoothed. An unusual week looks unusual here, because averaging it away would hide exactly the variation the measurement exists to show. Our measurement policy lists the other figures we decline to estimate and why.