Pool Coverage: Why More Pools Don't Mean More Arbitrage

The Temptation to Register Everything

It is a tempting metric to chase. The bot supports four DEX protocols. The candidate universe on Solana is enormous — Raydium alone holds nearly half a million pools with non-zero liquidity, per an on-chain analysis. If the bot only watches a few thousand of them, then surely the missing ninety-something percent is leaving money on the table.

That intuition is exactly what I keep running into while reviewing the current pool coverage. The instinct says: more pools, more price observations, more chances to spot a mispriced route. The same intuition that tells a Walmart shopper a bigger store has better deals, or that a fund holding more tickers is more diversified. It feels obviously true.

It is not true, and the reason it is not true is a graph-theory problem hiding inside the bot.

What An Arbitrage Cycle Actually Requires

The formal model is well-established. A peer-reviewed paper on DEX arbitrage detection, "An Improved Algorithm to Identify More Arbitrage Opportunities on Decentralized Exchanges", describes the standard setup: tokens are nodes, pools are edges, and the edge weight encodes the exchange rate after fees. An arbitrage opportunity is a negative-weight cycle in that graph — a closed loop where the product of exchange rates, after fees, exceeds one.

The paper is precise about which nodes are even candidates for cycle membership. Its filtering pipeline applies, in order:

1. Pools with TVL above $20,000 are retained; everything else is dropped.
2. Pools must be active on the date being analyzed.
3. Tokens with degree one are eliminated.

That third rule is the one that matters here. A degree-one token is a token that appears in exactly one pool. In graph terms, it is a leaf — there is only one edge attached to it. A leaf cannot be part of any cycle, because a cycle requires entering and exiting the node by different edges. There is no second edge to exit on.

This is not a heuristic. It is structural. Bellman-Ford, the standard algorithm for negative-cycle detection on weighted directed graphs, has no way to route through a leaf. The leaf gets pruned in the first reduction pass because nothing useful can happen there. A practitioner write-up on CoinMonks walks through the same logic in the context of triangular arbitrage: take the natural log of each exchange rate, flip the sign, and look for a negative loop. Whether the implementation uses Bellman-Ford or a brute-force traversal — an open-source Solana arbitrage bot explicitly chooses brute force because "it can find all opportunities" faster — the underlying structure is identical. No second edge, no path back, no opportunity.

The Shape of the Solana Pool Universe

Now apply this to the actual data. The on-chain measurement of Raydium's pool universe is the cleanest snapshot I have seen of the problem:

• Raydium pools with non-zero liquidity: 493,203
• Unique token addresses across those pools: 474,161

Divide one by the other and you get approximately 1.04 pools per token. The average Raydium-listed token has just barely more than one pool. The median is almost certainly exactly one. In graph terms, the overwhelming majority of those 474,161 tokens are leaves. They contribute an edge to the graph and then dead-end.

Most of these are pump.fun-style meme tokens that launch with a single SOL or USDC pair and never acquire a second one. Data from pump.fun on-chain activity, corroborated by a parallel analysis, puts the picture in stark relief:

• Daily token deployments on the platform: around 20,000
• Tokens that graduate to Raydium each day: roughly 100 to 200
• Total tokens deployed historically: about 1.8 million
• Tokens that ever exceeded a $10M market cap: 18
• Overall graduation rate: 1.4%

The lottery odds are roughly one in a hundred thousand for a pump.fun token to clear a $10M cap. Yet every one of those failed launches still contributes a pool to the on-chain ledger. Most of them are leaves in the token graph, contributing nothing to cycle space.

A Pool Is Not Liquidity

Even the multi-pool tail does not save the picture, because the depth of these pools is trivial. Launch data on Solana tokens reports that 90% of Solana token launches put fewer than 10 SOL into their initial pool, with the most common amount being 6 to 7 SOL — somewhere in the neighborhood of a dinner-for-two at a decent restaurant. The pool is a few rocks tossed into a creek bed; calling it liquidity is a category error.

It gets worse when you look at the composition of those pools. A write-up titled "Types of Quantitative Trading on Solana" documents what its author calls phantom liquidity: a pool that displays $1M of TVL on a dashboard while actually holding about $2,000 of redeemable counter-asset. The remaining "million" is the meme token itself, against which there is essentially no external market. Whatever number the front-end shows, the real arbitrageable depth is the smaller side of the pair. Trying to drain the meme side back into SOL just moves price into a wall.

And then the rug-pulls and abandonment kick in. The same on-chain analysis notes that in a recent 30-day window, "nearly two-thirds of tokens were slaughtered within the initial 24 hours, with over 90% of available liquidity evaporating." Even when a meme token does acquire a second pool — a brief moment of degree-two existence — it usually does not survive long enough for an arbitrage bot to depend on the route.

The Operational Quote That Sealed It

The argument is not just academic. The performance-tuning documentation for a paid Solana MEV bot service makes the point in plain operational language:

"having more pools do not always mean having better performance."

And more concretely:

"if a mint has 3 pools with 200 SOL, 100 SOL, 2 SOL in the liquidity, excluding the one with 2 SOL will help you get better profits."

The 2 SOL pool is small enough that a single retail trade moves it dramatically off the price of the larger pools. From a naive perspective, that looks like a giant arbitrage opportunity: huge price divergence, easy capture. From the perspective of a bot that has to construct and submit a transaction, it is a trap. The profit captured by any cycle that touches the 2 SOL pool is bounded by the 2 SOL pool's depth — a few hundred dollars of throughput, maybe less. Meanwhile the bot has spent compute units evaluating the route, eaten priority fees, paid a Jito tip that takes 50–60% of expected profit per an analysis on Medium, and competed against every other bot that also saw the divergence. The economics are upside down.

The Compute Budget Is Finite

This is where the cost of registering useless pools stops being theoretical. Every pool the bot tracks costs something to evaluate, and Solana hands every transaction a hard ceiling on what it can compute. The maximum compute unit allocation per transaction is 1,400,000 CU. The same service's docs recommend setting the per-transaction CU limit between 250,000 and 800,000 in practice, noting that "large arbitrage opportunities can consume up to 600k to 800k CU sometimes depending on the pools."

That budget is consumed whether the route ends up profitable or not. Each additional pool registered into the route-search expands the candidate set. If half of those pools are degree-one leaves that cannot contribute to any cycle, the bot still pays the discovery cost — pulling state, deserializing accounts, considering routes that mathematics has already ruled out.

The latency picture is just as constrained. The same Medium analysis puts the target route-detection budget at under 50 milliseconds, with transaction construction under 10 milliseconds, and notes that a bot reading from a public RPC sits roughly 200 milliseconds behind colocated competitors. Within a 50ms window, every microsecond spent evaluating impossible cycles is a microsecond not spent evaluating real ones. The competition is fast enough — a source reports a 76.8% non-vote transaction failure rate on Solana driven largely by MEV spam — that there is no slack to give up.

So the cost of pool bloat is not theoretical. It is: fewer real opportunities evaluated per block, more compute paid per evaluation, more reverts when the bot picks a stale route, and a worse position in the auction relative to a leaner competitor.

Where the Real Edges Live

Look at the structure of a working production bot and the answer becomes obvious. An open-source reference implementation shows the actual token graph for a working arbitrage strategy: USDC connecting to four major tokens (degree 4), AART connecting to three (degree 3), SOL connecting to two (degree 2), BTC sitting at degree 1. The cycles all run through the high-degree nodes. USDC, SOL, USDT, the bridge tokens — these are the anchors. They are the few intersections in the city where every road meets, and every arbitrage cycle worth chasing has to pass through one of them.

This is also why the major-DEX volume numbers concentrate where they do. A May 2025 DEX ranking puts Raydium at $35.6B in 30-day volume, Orca at $22.8B, Meteora at $14B, with their top pools dominated by SOL/USDC, USDS/USDC, and TRUMP/USDC pairs ranging from $31M to $369M in pool size. These are not the tokens with the largest count of pools — these are the tokens with the largest pool depth, and they are the only ones where cycles actually carry meaningful dollar throughput.

The authoritative setup guides are blunt about it. A 2026 guide recommends starting with "2–3 DEX pairs on high-liquidity tokens (SOL/USDC, SOL/USDT). Prove the logic works, then expand." Another guide says the same thing in different words: "Start narrow. One pair, two venues, prove the loop runs in budget. Expanding coverage is cheap once the latency profile is healthy." Both pieces are written by infrastructure vendors who have a commercial incentive to encourage bigger bots that consume more resources. They still recommend starting small. That is informative.

The Conditional Case For Long-Tail Pools

There is a documented argument for the other direction, and it deserves to be stated fairly. A sniper-bot piece acknowledges that on the most contested pairs — the SOL/USDC majors — the competition is brutal, and a bot without colocation, custom infrastructure, and a serious latency profile is unlikely to win there. The realistic edge for a smaller operator, the article suggests, sits in "thinner liquidity — fresh launchpad pools, niche memecoin pairs on PumpSwap and Meteora DLMM, three-leg routes through unpopular intermediates," where "competition is two orders of magnitude lighter."

This is true, and it does not contradict the cycle-formation argument. It refines it. Note the operative phrase: three-leg routes through unpopular intermediates. The strategy is not to register a million isolated MEME/SOL pools. The strategy is to find the rare cases where a meme token has acquired a second or third pool — most often because a market maker has stood it up on Meteora's DLMM, or because the token has graduated and now exists on both PumpSwap and Raydium — and route through those. The token needs degree at least two for the cycle to exist at all, and the second pool needs enough depth for the profit to exceed the Jito tip and the priority fee.

That is a quality filter masquerading as a quantity expansion. It is not "register more pools." It is "register the small number of long-tail pools where the second edge actually exists and the depth is non-trivial." Different operation, different conclusion.

What I'm Actually Going To Do About Coverage

The practical implication is that the right way to think about pool coverage is not as a list to maximize. It is as a filter to harden. The questions that matter:

For each token in the bot's universe, does it have at least two pools that both clear a real liquidity threshold? The academic paper uses $20K TVL as the cutoff; the sniper-bot guidance uses $10K as a practical on-chain validation floor. Either way, sub-threshold pools get dropped, not because they are uninteresting, but because their depth cannot support a profitable cycle after fees and tips.

For each candidate route, is the profit bounded by the smallest pool depth? If yes — and it always is, because every leg of a cycle constrains the maximum trade size — then the route is only as valuable as its weakest pool. A 200 SOL / 100 SOL / 2 SOL triangle is not a three-pool opportunity; it is a 2 SOL opportunity with two large pools attached to it. Drop the 2 SOL pool. The remaining two-pool combination may or may not be a cycle on its own, depending on whether the tokens it connects have alternative paths.

For each marginal pool added, what is the cost in compute units per block, and what is the realistic upper bound on the profit it can contribute? If the compute cost is constant per evaluation and the profit ceiling is a few dollars, the math is hostile. The slot of compute would be better spent re-evaluating a high-degree route through SOL/USDC where the depth supports a meaningful trade.

For each meme token registered, has it survived the 24-hour graveyard window? Two-thirds do not. Registering them while they are still in their first day is a coin flip with a heavily weighted coin.

The filtering questions are different from the coverage questions, and answering them well does more for profitability than tripling the pool count ever would.

What This Means For The Bot Today

At the current stage of development, the bot is not latency-competitive against the colocated leaders. The infrastructure profile is what it is — paid RPC, regional latency, no custom hot path that can win against a serious validator-adjacent operator on a SOL/USDC sandwich. That sets the boundaries of what "good pool coverage" even means for this bot.

It means: prioritize coverage where the cycle math is favorable and the competition is survivable. The high-degree bridge tokens (SOL, USDC, USDT) are not optional — every meaningful cycle passes through them. The mid-tier tokens with three or four well-funded pools are the next priority — these are where realistic three-leg cycles live, and where the competition is meaningful but not impossible. The long tail of pump.fun-era pools, single-edge meme tokens with sub-10-SOL liquidity, is mostly noise from the perspective of cycle formation. Some small fraction of that long tail develops a genuine second pool with usable depth, and that fraction is worth detecting — but it is a quality filter against a stream, not a coverage expansion to be celebrated.

The pool universe on Solana is not 493,000 opportunities the bot is missing. It is roughly a few hundred to a few thousand high-quality nodes embedded in a sea of leaves. The work is in the filter, not in the count.

Key Takeaways

• An arbitrage cycle requires every token in the cycle to have degree ≥ 2 in the token-pool graph. Single-pool tokens are leaves and cannot participate, by definition.
• Roughly 1.04 pools per token across Raydium's 474,161 listed tokens means the vast majority are leaves, contributing nothing to cycle space regardless of how many of them the bot watches.
• Profit on any cycle is bounded by the depth of its smallest pool. A high-divergence 2 SOL pool inside a 200/100/2 SOL triangle is not an opportunity; it is a compute drain.
• Compute units and the sub-50ms route-detection budget are finite. Every leaf pool evaluated is real arbitrage capacity not evaluated elsewhere.
• Long-tail meme coverage is a conditional strategy, not a default. It pays off only on multi-pool tokens with non-trivial counter-asset depth — a filter problem, not a coverage problem.