This article is a personal engineering / educational essay on on-chain arbitrage strategy on Solana. It is for informational and educational purposes only and does not constitute investment, legal, or financial advice, nor a recommendation to engage in arbitrage, MEV extraction, or any specific trading strategy on any blockchain. Tokens (SOL, USDC, BONK, WIF, JUP, etc.), pools, and protocols (Raydium, Orca, Meteora, Phoenix, etc.) are named only as technical illustrations of how cyclic arbitrage works; their inclusion is not an endorsement, valuation, or recommendation. The publisher holds no positions in and has received no compensation from any project named herein. Conduct your own research and consult a licensed advisor before making any decisions.

Cyclic Arbitrage — SOL→USDC→Token→SOL

I can compute exact swap outputs now. I can take a pool's reserves, plug in an input amount, and get back the precise number of tokens I'll receive — down to the last decimal. The AMM math is no longer a black box. But knowing how a single swap works is like knowing how to drive a single leg of a road trip. It doesn't tell me where to go, which highways to chain together, or how to get back home with more gas in the tank than I started with.

Today I'm tackling the core strategy that makes on-chain arbitrage bots work: cyclic arbitrage. The idea is deceptively simple. Start with SOL. Swap through a series of tokens across different pools. End up back at SOL. If the final amount is greater than the starting amount, pocket the difference. If the math doesn't work out, the transaction reverts and nothing happens. Rinse, repeat, tens of thousands of times per minute.

This is where the AMM math I just learned becomes a weapon instead of a textbook exercise.

The Airport Currency Exchange Problem

Here's a scenario every American traveler knows. You're at JFK, about to fly to London with a layover in Frankfurt. You've got US dollars. At the currency exchange counter near Gate B37, you check the rates:

• USD to EUR: 1 USD = 0.92 EUR
• EUR to GBP: 1 EUR = 0.86 GBP
• GBP to USD: 1 GBP = 1.27 USD

You think: what if I convert my dollars to euros, then euros to pounds, then pounds back to dollars? Let's trace $1,000 through:

1. $1,000 → 920 EUR
2. 920 EUR → 791.20 GBP
3. 791.20 GBP → $1,004.82 USD

You started with $1,000 and ended with $1,004.82. You made $4.82 doing absolutely nothing productive — just shuffling money through three different exchange rates. That's triangular arbitrage: a three-legged currency loop that exploits the mathematical inconsistency between three exchange rates.

In traditional foreign exchange, this is one of the oldest strategies in the book. The math is straightforward: multiply the three exchange rates together. If the product is greater than 1, the loop is profitable. In the example above: 0.92 × 0.86 × 1.27 = 1.0048. Greater than 1. Profit exists.

The catch in traditional FX is that these discrepancies are vanishingly small — often a single basis point — and they disappear in seconds. Major banks and HFT firms have teams of PhDs and data centers co-located at exchange matching engines, fighting over fractions of a penny. A regular person with a laptop has no seat at that table.

But on a blockchain? The table looks completely different.

From Airport Counters to Liquidity Pools

On Solana, there are no currency exchange counters. There are liquidity pools — smart contracts that hold reserves of two tokens and let anyone swap between them according to a mathematical formula. I covered how these work in the AMM math deep-dive. What matters now is that there are hundreds of these pools, operated by different protocols — Raydium, Orca, Meteora, Whirlpool, Phoenix, and more — each with their own reserves, their own pricing, and their own fee structures.

And here's the key insight: the same token pair can have wildly different prices across different pools.

Think of it like gas stations. In a well-connected city, gas prices within a few blocks of each other tend to converge — competition keeps them aligned. But imagine a city where gas stations can't see each other's signs, where customers don't always comparison-shop, and where the price at each station is set purely by a formula based on how much gas is in its tanks right now. That's what the Solana DEX landscape looks like. Every pool is an independent pricing engine. There's no central authority synchronizing prices. Alignment happens only through arbitrage itself.

SOL might be priced at 149.50 USDC on a Raydium pool, 150.20 USDC on an Orca pool, and 149.80 USDC on a Meteora pool — all at the same instant. These differences are tiny in percentage terms, but they represent real money to someone who can move fast enough.

The Cyclic Path: SOL → USDC → BONK → SOL

Let me walk through a concrete example. Suppose I'm looking at three pools:

• Pool A (Orca): SOL/USDC — I can swap SOL for USDC here
• Pool B (Raydium): USDC/BONK — I can swap USDC for BONK here
• Pool C (Meteora): BONK/SOL — I can swap BONK back to SOL here

My cycle is SOL → USDC → BONK → SOL. Three swaps, three pools, three different protocols. Let me trace 1 SOL through the loop:

1. Swap 1: 1 SOL → Pool A → 150.20 USDC (Orca's current price)
2. Swap 2: 150.20 USDC → Pool B → 7,350,000 BONK (Raydium's current price)
3. Swap 3: 7,350,000 BONK → Pool C → 1.0038 SOL (Meteora's current price)

I started with 1 SOL. I ended with 1.0038 SOL. Gross profit: 0.0038 SOL. Before costs.

Now, that 0.0038 SOL — roughly $0.57 at current prices — doesn't sound like much. And it isn't, for a single trade. But remember: this is a bot that can evaluate and execute these cycles continuously, every few hundred milliseconds. And the trade sizes can be larger than 1 SOL. The margin per trade is thin, but the volume is relentless.

This is a 3-hop cycle — three swaps, three pools, forming a complete loop back to the starting token. The starting and ending token is the same: SOL. That's important, because it means I never need to hold an inventory of random tokens. I start with SOL, I end with SOL. No directional bet on BONK. No exposure to whether USDC holds its peg. Just a mathematical loop.

Extending the Loop: 4-Hop Cycles

Three hops is the simplest cycle. But there's no reason to stop there. Consider a 4-hop cycle:

SOL → USDC → BONK → WIF → SOL

Now I'm chaining four swaps across four pools:

1. SOL → USDC (Pool A)
2. USDC → BONK (Pool B)
3. BONK → WIF (Pool C)
4. WIF → SOL (Pool D)

Same principle. If the final SOL amount is greater than the starting SOL amount (after all fees and costs), the cycle is profitable. Four hops means four different opportunities for pricing inconsistency to create a gap, but it also means four sets of swap fees eating into the margin, and more computational complexity to evaluate.

In theory, you could have 5-hop, 6-hop, even longer cycles. In practice, each additional hop adds fees, increases transaction size, and makes it harder for the final output to exceed the initial input. Three and four hops are the sweet spot — long enough to exploit complex pricing relationships, short enough that fees don't eat the entire margin.

It's like planning a delivery route. A FedEx driver delivering packages in a loop through three neighborhoods is efficient. Five neighborhoods, still manageable. But a route that hits fifteen neighborhoods in a single loop? The gas costs alone kill the economics, even if there's technically a faster path through all of them.

Why Do Price Imbalances Exist?

This is the question that nags at me. If arbitrage is "free money," why don't prices instantly equalize across all pools? Why does any opportunity exist at all?

The answer has several layers, and understanding them is critical to understanding why this strategy works at all.

Different liquidity depths. Every pool has different amounts of reserves. A Raydium SOL/USDC pool with $10 million in liquidity will react differently to a $50,000 trade than an Orca pool with $500,000 in liquidity. The deep pool absorbs the trade with minimal price impact. The shallow pool's price moves dramatically. After the trade, the two pools are pricing SOL at different rates — even though nothing about SOL's fundamental value has changed.

This is like the difference between tossing a boulder into the Pacific Ocean versus tossing it into a swimming pool. Same boulder. Very different splash.

Information propagation delay. When a big trade hits one pool — say, someone dumps a large amount of SOL on Raydium — the price on that specific pool adjusts instantly (it's a mathematical formula, it has to). But the price on Orca doesn't change. The price on Meteora doesn't change. Those pools haven't been touched. Their reserves are the same as they were a second ago, so their formula produces the same price as a second ago.

In traditional finance, news travels across markets in microseconds via direct data feeds and market makers. On Solana, there's no such feed. Each pool is an isolated calculation. The only mechanism that synchronizes prices across pools is... arbitrageurs. People like me, building bots like mine, running cycles that buy where it's cheap and sell where it's expensive until the gap closes. We are the price synchronization mechanism. Arbitrage isn't a parasitic activity — it's the immune system that keeps DeFi pricing healthy.

Variable fee structures. Different protocols charge different swap fees. Raydium might take 0.25% per swap. Orca might take 0.30%. Meteora might take 0.04% on some concentrated liquidity pools. Phoenix, as an order book, has its own fee schedule entirely. These fee differences mean that the "true" price — what a trader actually receives after fees — varies across protocols even when the raw reserve ratios are identical. Fee asymmetry creates arbitrage gaps that wouldn't exist in a uniform-fee world.

Trading volume asymmetry. Some pools see heavy one-directional flow. Maybe a popular token is trending on social media, and retail traders are all piling into the same Raydium pool to buy it. That pool's price gets pushed up by the concentrated buying pressure, while other pools for the same token sit relatively untouched. The price gap widens with every lopsided trade, and it stays wide until someone runs an arbitrage cycle that pulls it back into alignment.

New pool creation. Solana's permissionless nature means anyone can create a new liquidity pool at any time. When a new BONK/SOL pool launches on a smaller protocol, its initial pricing may not match the established pools. Until arbitrage bots find it and start running cycles through it, that pool's prices drift freely from the market consensus.

The bottom line: price imbalances aren't a bug. They're an inherent feature of a decentralized system with hundreds of independent pricing engines operating without a central coordinator. And they'll continue to exist for as long as DEXes exist, because the forces that create them — varying liquidity, uneven trading volume, different fee structures, information asymmetry — are structural. They're not going away.

Atomic Execution: The Safety Net

Here's what makes all of this practical instead of theoretical: atomic execution.

In traditional triangular FX arbitrage, execution risk is the elephant in the room. You execute leg 1 (USD → EUR) and now you're holding euros. You execute leg 2 (EUR → GBP) and now you're holding pounds. If, between leg 2 and leg 3, the GBP/USD rate moves against you... you're stuck holding pounds at a loss. You've completed two-thirds of a three-legged trade and the third leg is now unprofitable. Your "risk-free" arbitrage just became a losing position. This happens. This is why traditional triangular arb requires enormous capital buffers and sophisticated risk management.

On Solana, all three swaps happen in a single transaction. One atomic unit. Either all three succeed, or all three revert. There is no state where I've completed two legs but not the third. It's physically impossible within the execution model. The blockchain processes my transaction as a single indivisible operation.

Think of it like a multi-stop airline ticket versus separate one-way flights. If you book a round trip — New York to Chicago to Dallas to New York — and your Chicago-to-Dallas leg gets canceled, the airline rebooks or refunds the whole thing. You don't get stranded in Chicago holding a useless Dallas-to-New York ticket. That's what atomicity does. It's a package deal. All or nothing.

This means the risk profile of on-chain cyclic arbitrage is fundamentally different from its traditional finance counterpart:

• No execution risk. The transaction either profits or reverts. I never hold an unwanted intermediate token.
• No inventory risk. I start with SOL, I end with SOL (or nothing changes). I don't need to maintain reserves of dozens of tokens "just in case."
• No counterparty risk. There's no other party who might fail to deliver. The smart contracts are the counterparty, and they execute deterministically according to their code.
• No settlement delay. The transaction finalizes in under a second. There's no T+1 waiting period, no clearing house, no overnight exposure.

The costs I do pay are transaction fees (gas), priority fees for faster inclusion, and MEV tips if I'm using a block builder service. But these are known quantities — I can calculate them before submitting the transaction and include them in my profitability check. If the cycle doesn't clear more than the total cost, I simply don't submit it.

The Profit Condition

Let me formalize what "profitable" actually means, because it's more nuanced than "end up with more SOL than I started with."

Given a cycle SOL → Token A → Token B → SOL, here's the actual profitability equation:

Net Profit = Final SOL − Starting SOL − Transaction Fee − Priority Fee − Tip

Each of those cost components:

• Transaction Fee: Solana's base fee per transaction. Small but nonzero.
• Priority Fee: Additional fee paid to incentivize validators to include my transaction sooner. In competitive MEV situations, this can be significant.
• Tip: Payment to block builders for preferential ordering within a block. This is a tip efficiency competition — I'm competing for inclusion based on how much I pay relative to the compute resources I consume.

The swap fees are already baked into the swap outputs. When I compute the output of each leg using the AMM math, the protocol's fee is subtracted before I receive my tokens. So the "Final SOL" figure already accounts for swap fees at each hop.

The profitability condition is simple in theory:

Final SOL > Starting SOL + Transaction Fee + Priority Fee + Tip

In practice, this means the pricing inconsistency across the three (or four) pools needs to be large enough to overcome all these costs combined. And "large enough" is a moving target — it depends on current gas prices, current tip competition, and how many other bots are fighting for the same opportunity.

This is why I think of it like a cross-country road trip where you're buying gas at different prices along the way. You can map out a route where you buy cheap gas in Missouri and use it to drive through expensive Colorado, but the savings need to exceed your tolls, your wear and tear, and the opportunity cost of not taking the direct route. The margin has to survive the friction.

The Scale of the Search Space

Here's where the problem gets genuinely hard. And genuinely interesting.

Imagine the Solana DEX ecosystem as a map. Every token is a city. Every liquidity pool is a road connecting two cities. SOL, USDC, USDT, BONK, WIF, JUP, and hundreds of other tokens — those are all cities on the map. And for each pair of tokens, there might be multiple roads — a Raydium pool, an Orca pool, a Meteora pool, sometimes more.

Now I need to find every loop — every route that starts in one city, travels through two or more other cities, and returns to the starting point — where the total "toll" (swap fees and costs) is less than the "earnings" (pricing inconsistencies along the way). And I need to find these loops fast, because they open and close in fractions of a second.

How many possible cycles are there? The number is staggering. With hundreds of tokens and thousands of pools, the possible 3-hop and 4-hop cycles number in the tens of thousands. And each one needs to be evaluated — compute the exact output at each hop using the current pool reserves, subtract all costs, check if the result is positive. Then re-evaluate constantly as pool states change with every trade.

This is not a problem you solve by hand. This is not even a problem you solve with a spreadsheet. This is a graph problem.

Thinking in Graphs

This is where computer science shows up and saves the day.

The Solana DEX ecosystem maps naturally onto a directed weighted graph:

• Nodes = tokens (SOL, USDC, BONK, WIF, JUP, etc.)
• Edges = pools (each pool connecting two tokens, with the "weight" being the exchange rate after fees)

A 3-hop arbitrage cycle is literally a cycle in the graph — a path that starts at a node, traverses three edges, and returns to the starting node. A 4-hop cycle traverses four edges. The problem of "find all profitable arbitrage opportunities" translates directly to "find all cycles in this graph where the product of edge weights exceeds 1."

And here's the elegant part. If I take the negative logarithm of each edge weight, the product condition becomes a sum condition:

• Product of rates > 1
• Sum of log(rates) > 0
• Sum of -log(rates) < 0

A cycle where the product of exchange rates exceeds 1 becomes a negative-weight cycle in the log-transformed graph. And finding negative-weight cycles in a graph? That's a well-studied problem in computer science. Algorithms like Bellman-Ford were designed for exactly this.

It's like discovering that the delivery routing problem you've been staring at for weeks is actually a textbook problem that has a name, a Wikipedia page, and battle-tested algorithms dating back to the 1950s. The math isn't new. The application is.

This graph-theoretic framing transforms cyclic arbitrage from "check every possible loop by brute force" into something far more tractable. Instead of evaluating every possible combination of three or four pools (which would be computationally explosive), I can use graph algorithms to efficiently identify the cycles most likely to be profitable, then do the precise AMM math only on those candidates.

The graph also makes it clear why market efficiency is a dynamic process, not a static state. Every trade changes the reserves of a pool, which changes the weight of an edge in the graph. A cycle that was unprofitable a millisecond ago might become profitable after a large trade hits one of its pools. And a cycle that was profitable when I started evaluating it might become unprofitable by the time my transaction lands on-chain, because another bot ran the same cycle first and closed the gap.

The graph is alive. It's constantly shifting. Every block, every transaction, every trade reshuffles the edge weights. My bot needs to continuously re-scan the graph, re-evaluate cycles, and act the instant a profitable one appears.

The Detection Problem

Finding cycles in a graph is one thing. Finding profitable cycles in a graph that changes every few hundred milliseconds is another thing entirely.

The naive approach — enumerate every possible 3-hop and 4-hop cycle, compute exact outputs for each, compare to costs — would work if I had unlimited time. But I don't. I'm competing against other bots who are running the same analysis. The opportunity might exist for less than a second. If my detection takes 500 milliseconds and a competitor's takes 100 milliseconds, the competitor captures the trade and I get nothing. Not a smaller profit. Nothing. The opportunity is gone.

So the detection process has to be layered. Think of it like how a baseball scout evaluates prospects. You don't give every high school pitcher a full biomechanical analysis and a multi-day tryout. You filter. You start with basic stats — velocity, win record, height. That eliminates 90% of candidates. The remaining 10% get a closer look — game film, in-person scouting. The top 1% get invited to a showcase. Only the finalists get the full workup.

Arbitrage detection works the same way. First, a fast scan across all known cycles using approximate exchange rates — quick division, no precision, just a rough signal. If a cycle looks unprofitable at the approximate level, skip it. If it looks interesting, run the full AMM math — exact reserves, exact fees, exact output at each hop. If the full calculation still shows profit, subtract the estimated costs. If it's still positive, it's a candidate for execution.

This tiered approach means I'm spending most of my compute on the fast, cheap filter — and only burning cycles on expensive, precise calculation for the small fraction of paths that have a chance of being profitable.

Why This Matters: The Role of Arbitrageurs

There's a philosophical question lurking behind all the math: is this useful? Am I building something that contributes value, or am I just extracting rent from other traders?

The answer is more nuanced than I expected. Arbitrageurs serve a critical function in decentralized markets: price discovery and alignment.

When a large trade pushes the price of SOL on one pool to 148 USDC while other pools still show 150 USDC, the market is temporarily wrong. Not wrong in a subjective, opinion-based way — wrong in a mathematical, measurable way. Two pools claiming to price the same asset are disagreeing by more than 1%. Someone trading on the cheap pool is getting a worse deal than they should, and someone trading on the expensive pool is paying more than they should.

An arbitrage bot that cycles SOL through the cheap pool and back through the expensive pool pushes both prices toward each other. The cheap pool's SOL reserves decrease (pushing the price up) and the expensive pool's SOL reserves increase (pushing the price down). After the arbitrage, the two pools are closer to consensus.

In traditional finance, this function is performed by market makers — designated entities with special privileges and obligations. On-chain, it's performed by anyone with a bot and some SOL. The function is the same. The access is democratized. And the market is better for it.

This doesn't mean arbitrage is always benign — there are predatory forms of MEV like sandwich attacks that genuinely harm regular users. But cyclic arbitrage, specifically, is what economists call a positive externality. The arbitrageur profits, yes. But the market also benefits through tighter pricing consistency across pools. It's a rare case where self-interest and public good are genuinely aligned.

The Practical Reality

Here's what I know, sitting in front of my screen right now. I have the AMM math. I understand the concept of cyclic paths. I can see, intellectually, how tokens as graph nodes and pools as graph edges create a detection problem that maps onto well-known algorithms. I can trace through a concrete example — SOL to USDC to BONK to SOL — and calculate whether the loop is profitable.

What I don't have yet is the machinery. The pool data feeds. The cycle enumeration engine. The evaluation pipeline that can process tens of thousands of candidate cycles and identify the profitable ones before the opportunity window closes. The transaction builder that can pack three or four swaps into a single atomic transaction. The cost estimator that accounts for gas, priority fees, and competitive tips.

The gap between "I understand this" and "I can do this" is enormous. It's the gap between understanding how an internal combustion engine works and actually building a car that drives. The physics is the easy part. The engineering is where things get hard.

But the math is clear. The strategy is sound. The infrastructure exists. I just need to build the machine that connects all the pieces.

I start with SOL. I end with SOL. Everything in between is math.