The Reality of DEX Integration — N Protocols, N Different Interfaces

After the first DEX, I think I have this figured out. I've built the math, parsed the accounts, constructed the instructions, and watched a swap execute on-chain. One DEX down. Five to go. How hard can the rest be?

The second one changes my mind completely.

It's not that the second DEX is harder in some absolute sense. It's that it's different in every possible way. Different instruction names. Different account structures. Different fee models. Different assumptions about how a token swap should work. The swap itself — "give me token A, I'll give you token B" — is identical in purpose. Everything else is different.

I'm now on the sixth DEX integration, and I can confirm: every single one feels like starting from scratch.

No Standard Exists

In the traditional software world, there are standards for almost everything. Credit card processing has the ISO 8583 message format. Emails follow SMTP. Web APIs use REST or GraphQL. When you integrate with one payment processor, the next one might have different endpoints and different authentication, but the underlying data model is recognizable. The shape of the thing is the same.

Ethereum has something analogous in the token world. The ERC-20 standard defines exactly how a token contract should behave — what functions it exposes, what events it emits, what inputs and outputs each function expects. If you know how to interact with one ERC-20 token, you know how to interact with all of them. It's like how every gas station in America accepts the same credit card swipe, the same pump handle, the same nozzle fitting. The brand on the sign doesn't matter. The interface is standardized.

Solana has no equivalent standard for swaps.

There's no "SRC-swap" specification that says "a swap instruction must accept these accounts in this order, charge fees according to this structure, and return output according to this formula." Every DEX designs its own swap interface from the ground up. The instruction name is whatever the team felt like calling it. The account list is whatever the program needs internally. The fee model reflects whatever economic design the team chose.

Imagine if every fast food chain in America had a completely different ordering system. Not just different menus — different systems. McDonald's uses a touchscreen. Burger King requires you to fill out a paper form. Wendy's takes orders exclusively through a mobile app, but only on Tuesdays. Chick-fil-A has you speak your order into a microphone in a specific syntax, and if you get the syntax wrong, you get nothing and no error message explaining what went wrong.

That's what integrating multiple Solana DEXs feels like.

Six DEXs, Five Architectures

I'm integrating six DEX instances across five fundamentally different architectures. Each one represents a different philosophy about how decentralized trading should work.

Raydium AMM V4 is the classic constant-product automated market maker. It's the oldest architecture in my set, and in some ways the most straightforward. Two token reserves, a simple x * y = k formula, and a swap that shifts tokens between the reserves. If you've read any introduction to DeFi, this is the model they describe. It's the Honda Civic of DEX designs — nothing fancy, widely understood, gets the job done.

Raydium CPMM is Raydium's newer pool type. Same team, same protocol name, but a meaningfully different on-chain program with its own instruction set and account structure. It's like how Ford makes both the F-150 and the Mustang. Same company, same dealer network, but you don't service them identically. The engine is in a different place. The parts don't interchange.

Orca Whirlpool introduces concentrated liquidity using a tick-based system. Instead of spreading liquidity evenly across all possible prices (like a constant-product AMM), Whirlpool lets liquidity providers concentrate their funds within specific price ranges, defined by discrete price points called ticks. The math is substantially more complex — instead of a single multiplication, I'm dealing with square root price calculations and tick traversals. The account structure reflects this complexity. Where AMM V4 needs the pool state and the two token vaults, Whirlpool needs additional tick array accounts that describe the liquidity distribution at different price levels.

Meteora DLMM also does concentrated liquidity, but through a completely different mechanism — bins instead of ticks. Think of it this way: Whirlpool divides the price axis into a continuous series of tick marks, like a ruler. Meteora divides it into discrete containers, like a set of buckets. The mathematical result is similar — liquidity concentrated in specific ranges — but the data structures, the account layouts, and the swap logic are entirely different. It's the difference between measuring distance with a tape measure versus counting floor tiles. You can get to the same answer, but the tools and process look nothing alike.

Phoenix breaks away from the AMM model entirely. It's an on-chain order book — a limit order book where makers post bids and asks at specific prices, and takers match against them. This is how traditional stock exchanges work, and it's fundamentally different from the pooled-liquidity model. Instead of calculating output from a mathematical formula applied to reserves, Phoenix matches against existing orders. The account structure reflects a completely different world: market state, seat accounts, order trees. Integrating Phoenix after working with AMMs is like switching from driving an automatic to a manual transmission. The destination is the same, but the controls operate on entirely different principles.

PumpSwap is purpose-built for the meme token ecosystem. It uses a constant-product formula similar to AMM V4, but with its own program, its own account structure, and its own peculiarities. One significant difference: many tokens created through the PumpSwap ecosystem use Solana's Token-2022 program instead of the original SPL Token program. This distinction — which token program a mint belongs to — matters enormously at the instruction level, and I'll get to why shortly.

Six DEX instances. Five different architectures. One bot that needs to interact with all of them through a single, coherent codebase.

What Differs: The Devil in Every Detail

Let me get specific about what "different" means in practice, because the word doesn't capture the depth of the problem.

Instruction Names

The first thing you encounter when integrating a new DEX is: what do I actually call this instruction? On Solana, every program defines its own instruction set with its own names and discriminators. One DEX calls its swap function swap. Another calls it swap_v2. Another uses a completely different name. The instruction discriminator — the 8-byte identifier that tells the on-chain program which function you're invoking — is derived from the instruction name, so getting this wrong means the program doesn't even recognize what you're asking it to do.

This is like calling different government agencies. The IRS calls it "filing a return." The DMV calls it "submitting an application." The passport office calls it "a petition." You're doing essentially the same thing — giving a government agency information and asking them to process it — but the terminology, forms, and procedures are completely different at each one. And if you walk into the DMV and say "I'd like to file a return," they look at you blankly.

Required Accounts

Every Solana instruction takes a list of accounts. These are the on-chain data that the program needs to read from or write to in order to execute the instruction. This is where the differences between DEXs become truly overwhelming.

A simple constant-product swap might need around 10 accounts: the pool state, the two token vaults, the user's token accounts, the token program, an authority account, and a few others. A concentrated liquidity swap might need 15 or more, because it also needs tick array or bin array accounts that describe the liquidity distribution. An order book swap needs market state, order trees, and potentially seat accounts.

The specific accounts required are dictated by the program's internal architecture. There's no way to guess them. You have to read the program's IDL (Interface Definition Language) or source code, identify every account, understand whether each one is a signer, writable, or read-only, and construct the account list exactly as specified.

It's like doing your taxes in multiple states. Every state has its own tax form, its own list of required documents, its own deductions and credits, its own definition of taxable income. The underlying action is the same — report income, calculate tax — but the forms and requirements share almost nothing. And each state government designed their forms independently, with no consultation with any other state.

Account Ordering

This one is subtle and vicious. It's not enough to include the right accounts — you have to include them in exactly the right order. Solana programs reference accounts by index position. If the program expects the pool state at position 0 and the token vault at position 1, and you swap them, the program reads the token vault's data as if it were pool state data. The result is either a cryptic error or — in the worst case — the program interprets garbage data and does something entirely wrong.

There's no runtime check that says "hey, you passed the token vault where I expected the pool state." The program trusts that the accounts are in the correct order. It's like filling out a Scantron test — if your answers are correct but shifted down by one row, every answer is wrong, and the machine doesn't tell you that your problem is alignment. It just tells you that you failed.

Fee Structures

Every DEX charges fees differently. Some charge a single LP fee — a percentage of each swap that goes to liquidity providers. Some add a protocol fee on top — a cut that goes to the DEX's treasury. Some have dynamic fees that change based on market conditions or volatility. Some embed fees in the output amount; others deduct them from the input.

For an arbitrage bot, accurate fee calculation is existential. An opportunity that looks profitable before fees might be a loss after fees. And since different DEXs charge fees differently, I can't use a single fee formula. Each DEX needs its own fee calculation logic that matches exactly what the on-chain program does.

The differences are not just in the percentage. They're in the mechanics. One DEX applies the fee before calculating the output. Another calculates the output first and deducts the fee from that. The difference in calculation order means the same fee percentage produces different results. Getting this wrong by even a fraction of a basis point can mean the difference between a profitable trade and a loss.

Price Models

The mathematical model for calculating swap output — "if I input X of token A, how much of token B do I get?" — varies fundamentally across architectures.

A constant-product AMM uses the formula output = (reserve_out * input) / (reserve_in + input), adjusted for fees. It's a single calculation once you know the reserves.

A concentrated liquidity DEX requires traversing price ranges. The output depends on where the current price falls within the liquidity distribution, how much liquidity is available at each level, and whether the swap crosses into a new tick or bin. It's not one formula — it's a loop that walks through the liquidity structure, consuming available liquidity at each level until the input amount is fully utilized.

An order book requires matching against existing orders, consuming the best available price first and moving to the next level when a price level is exhausted. The logic resembles a stock exchange's matching engine more than a mathematical formula.

Each model needs its own implementation. The abstraction layer I build on top can present a unified interface — "calculate output for this input" — but underneath, three completely different algorithms are running.

Token Programs

Here's a detail that wouldn't matter in most blockchain ecosystems but matters enormously on Solana: which token program does each token use?

Solana originally had one token program — SPL Token. Then Token-2022 (also called Token Extensions) was introduced, offering additional features like transfer fees, interest-bearing tokens, and confidential transfers. The two programs are separate on-chain programs with different program IDs.

When I construct a swap instruction, I need to specify which token program to use for each token involved. If a pool pairs a standard SPL Token with a Token-2022 token, I need to pass two different token program IDs in the same instruction. Get this wrong, and the transaction fails.

This means I can't hardcode the token program. For every swap, I need to check each token's mint account to determine which program owns it, then pass the correct program ID. Some DEXs handle this internally. Others require the caller to figure it out and pass the right accounts.

It's like discovering that some gas stations only accept Visa and others only accept Mastercard, and there's no sign on the pump — you have to check each time, and if you guess wrong, the payment silently fails.

The Abstraction Layer Problem

With six DEXs that share nothing beyond the concept of "swap token A for token B," I need an abstraction layer. A common interface that the rest of the bot can call without knowing which DEX it's talking to.

The interface is conceptually simple:

Input: source token, destination token, amount. Output: swap instruction ready to submit.

But implementing this interface means solving the same problem six different ways — one for each protocol. Each DEX has its own instruction name, its own account structure, its own ordering rules, its own fee model, and its own token program requirements. A generic "swap these tokens" request needs to be translated into the specific format each on-chain program expects.

Imagine building a universal remote that controls every TV ever manufactured. The interface is simple — power, volume, channel. But behind the scenes, you need a different infrared code set for every manufacturer, every model, every year. The universal remote is a thin shell wrapped around hundreds of device-specific implementations. Integrating multiple DEXs feels exactly like that.

The challenge isn't writing one builder. Any single DEX builder is manageable, if tedious. The challenge is that I need six of them, each with its own subtleties, and they all need to work correctly in production where a single wrong account index means a failed transaction and a missed opportunity.

The Account List Problem

The most labor-intensive part of each integration is assembling the correct list of accounts, in the correct order, with the correct read/write permissions. Every DEX demands a different set.

A constant-product AMM might need around 10-12 accounts. A concentrated liquidity DEX might need more, because the relevant price range data changes dynamically as prices move — what you need for one swap might be different from the next, even on the same pool. An order book DEX needs an entirely different category of accounts that has no conceptual overlap with AMM-style accounts at all.

The challenge isn't the count. It's that each protocol's documentation (if it exists) describes the accounts differently, orders them differently, and fails differently when you get it wrong.

Each builder is its own project within the project. And each one requires deep reading of the DEX's documentation, IDL, and often source code, because documentation rarely covers every edge case.

The Problems I Hit

Theory is one thing. Actually integrating these DEXs is another. Here's what goes wrong in practice.

Missing Accounts

The single most common failure mode is a missing account. I construct what I think is a complete account list, submit the transaction, and get back an error. The error message tells me the transaction failed, but it doesn't tell me which account is missing or what account should be there.

On Solana, when a program expects an account at a certain index and that index is out of bounds (because the list is too short), the error is generic. It's like getting a form rejected with the stamp "INCOMPLETE" but no indication of which field is missing. I'm left comparing my account list against the IDL, line by line, trying to spot the gap.

Sometimes the missing account is obvious — I forgot the token program. Sometimes it's subtle — a specific DEX version requires an additional configuration account that the previous version didn't need, and the documentation hasn't been updated to reflect this.

Instruction Version Changes

DEXs evolve. They release new versions of their swap instructions. swap becomes swap_v2. The new version might add accounts, remove accounts, or change the order of existing accounts. The old version might still work, or it might be deprecated, or it might work for some pools but not others.

When a DEX upgrades from swap to swap_v2, it's not just the instruction name that changes. The account list changes too. An account that was at index 5 might move to index 7, with new accounts inserted before it. If I update the instruction name but not the account list, the transaction fails in confusing ways — the program receives accounts, but they're the wrong accounts at the wrong positions.

This is like when your bank redesigns its online banking interface. The same features exist, but every button is in a different place. The transfer function now requires two additional confirmation steps. The account number that used to auto-fill now has to be entered manually in a different format. You know how to bank, but you have to re-learn the specific interface.

Same DEX, Different Pool Types

This one caught me off guard initially. Raydium isn't one integration — it's two. AMM V4 and CPMM are separate programs with separate instruction sets. Being able to swap on AMM V4 pools tells me nothing about how to swap on CPMM pools.

This is true across the ecosystem. A single brand name might encompass multiple pool types, each with its own on-chain program. Integrating "Raydium" means integrating two separate programs. The brand is the same. The code is not.

Token-2022 Detection

When I first build my DEX integrations, I hardcode the SPL Token program ID everywhere. It works for most pools because most tokens use the original SPL Token program. Then I encounter a pool where one token uses Token-2022, and the transaction fails with an opaque error.

The fix requires dynamic detection: for each token in a swap, determine at runtime whether it uses SPL Token or Token-2022, then pass the correct program ID in the instruction. This check needs to happen at runtime because the same DEX, the same pool type, can pair tokens from different programs.

This isn't a hard problem in isolation. But it's a problem I have to solve per DEX, because each DEX handles token programs differently in its account list. Some DEXs have a single token program account; others have two (one per token); others derive it internally. The detection logic is the same, but where and how I pass the result varies by DEX.

Why Not Just Use Jupiter?

If this sounds like a lot of work — it is. And there's an obvious question: why not use Jupiter?

Jupiter is Solana's dominant DEX aggregator. It integrates with all major DEXs, finds the optimal route for any swap, splits trades across multiple pools when beneficial, and exposes a clean API. For a regular user or even a trading bot with relaxed timing requirements, Jupiter is the right answer. It abstracts away everything I've described in this article.

For an MEV bot, Jupiter is the wrong answer, for one reason: latency.

When I use Jupiter's API, my swap goes through several steps: my bot sends a request to Jupiter's API server, Jupiter calculates the optimal route, Jupiter returns a transaction for me to sign and submit. This round trip adds tens of milliseconds — maybe more, depending on API server load and network conditions.

In MEV, tens of milliseconds is an eternity. The opportunities I'm targeting exist for fractions of a second. By the time Jupiter's API responds, the opportunity might already be gone, captured by another bot that built its transaction locally and submitted it faster.

Direct integration through CPI (Cross-Program Invocation) — where my on-chain program calls the DEX program directly — eliminates the API round trip entirely. My program constructs the swap instruction locally, embeds it in a transaction, and submits it. No external API. No network round trip to a third-party server. No dependency on someone else's infrastructure being fast enough.

The trade-off is stark: Jupiter gives me simplicity at the cost of speed. Direct integration gives me speed at the cost of building and maintaining six separate DEX integrations, each with its own instruction builder, account builder, fee calculator, and output estimator.

For a regular application, the choice is obvious — use Jupiter. For an MEV bot competing at the millisecond level, the choice is equally obvious — pay the integration cost and go direct.

This is the same trade-off that exists in other speed-sensitive domains. A casual investor uses a brokerage app. A high-frequency trading firm builds custom connectivity to exchange matching engines, bypassing every intermediary. The casual investor optimizes for convenience. The HFT firm optimizes for microseconds. Same market, completely different infrastructure decisions.

The Pattern That Emerges

After six integrations, a pattern has emerged. Not in the DEX interfaces themselves — those remain stubbornly unique. The pattern is in the integration process.

Every new DEX follows the same steps:

1. Find and read the program's IDL or source code.
2. Identify the swap instruction name and discriminator.
3. Map out every required account, its type, and its read/write permission.
4. Determine the account ordering.
5. Understand the fee structure and implement matching math.
6. Handle token program detection for Token-2022 compatibility.
7. Build the instruction builder.
8. Test against live pools.
9. Debug the inevitable failures from missing accounts, wrong ordering, or edge cases.
10. Integrate into the abstraction layer.

This process takes days per DEX. Not because any single step is intellectually hard, but because the information gathering is labor-intensive and the debugging cycle for on-chain transactions is slow. Submit, fail, read error, adjust, submit again. Each iteration requires building and submitting a transaction, waiting for confirmation, and parsing the result.

The process also never gets easier in the way you'd hope. DEX number six doesn't go faster than DEX number three, because the knowledge from integrating one DEX doesn't transfer to another. Knowing Orca Whirlpool's account structure tells me nothing about Phoenix's account structure. The process is the same; the content is entirely new each time.

The Hidden Cost

There's a cost that isn't obvious until you're maintaining six integrations in production: ongoing maintenance. DEXs upgrade their programs. They change fee structures. They add new pool types. They deprecate old instruction versions.

Every upgrade potentially breaks my integration. And since I'm not using an aggregator like Jupiter — which maintains these integrations as its core business — I'm responsible for tracking every update, reading every changelog, and adjusting my code accordingly. It's like maintaining six different cars, each from a different manufacturer, each requiring different parts, different tools, and different service schedules. The driving experience is similar; the maintenance burden is six times what it would be with one car.

This is the ongoing tax for choosing speed over convenience. Jupiter's team handles DEX updates for their thousands of users. I handle them myself, for my one bot.

The Question That Keeps Coming Back

Every time I start integrating a new DEX, I ask myself the same question: is this worth it?

Six integrations means six instruction builders, six account builders, six fee calculators, six sets of edge cases, six ongoing maintenance burdens. Each new DEX adds coverage — more pools, more potential arbitrage cycles — but also adds complexity and maintenance cost.

There's no clear answer. More DEX coverage means more opportunities. But each additional DEX has diminishing returns — the highest-volume pools are on the first three or four DEXs. The sixth DEX might add coverage for pools that rarely have profitable opportunities.

And somewhere out there, right now, another team is launching another DEX with another completely unique interface. If I want to integrate it, I know exactly what awaits: reading their IDL, mapping their accounts, building their instruction builder, debugging their edge cases. The whole process, from the top, with no shortcuts.

The question isn't whether I can integrate the next DEX. The process is known. The question is whether the marginal opportunities it unlocks justify the marginal complexity it adds — and at what point the maintenance cost of N integrations outweighs the revenue from the Nth DEX's pools.

I don't have an answer yet. But I'm fairly certain of one thing: whatever the next DEX looks like, it won't look like any of the ones I've already integrated.