How we integrated 8 swap providers in one backend
DEX aggregator
A crypto startup offers crosschain swaps across thousands of tokens with minimum execution fees
001
ClientA European DEX aggregator startup.
002
ChallengeIntroduce onchain and crosschain swaps with minimal execution fees.
003
SolutionOne backend to aggregate 8 swap providers, ready for future integrations.
Liquidity is spreading across more and more chains
Back in 2020, Uniswap dominated DEX trading. Today, the market is spread across a wider mix of protocols. Even Uniswap and PancakeSwap together now account for only about a third of DEX volume.
It means the execution is getting much harder. A swap provider can only build routes across the liquidity it has access to. When DEX liquidity aggregation is spread across more protocols and chains, one provider is less likely to find the most efficient path. That is why aggregators need multiple providers behind one system: not to add complexity, but to avoid missing better execution.
Why one swap provider is not enough:
the role of multi-chain liquidity aggregation
001
Better pricing
for every user
The client needed to stay competitive on swap pricing. But the cost of a trade is more than platform fees. Execution quality changed with the route, the available liquidity, and the price impact during execution, so one provider could perform well in one case and worse in another.
With multiple swap sources, the product has a better chance to offer better pricing for the users.
002
Broader liquidity access
Small swaps are easier to route well. Larger trades are not. When too much volume goes through one route, available liquidity can thin out quickly. If the transaction is large enough, it will move the price.
To get the best possible rates for large orders, it’s always good to split the transaction.
003
More trading pairs across chains
No single swap provider offers equally strong coverage across all token pairs. Each swap API has strengths and weaknesses. Some work great with specific chains, others have better cross-chain support.
More providers means better coverage.
Our goal
Build one backend for many swap sources
How to build dex aggregator
The client saw where the market was going. Liquidity was spreading across more protocols every year, and the aggregator would have to support more sources in the future.
That made the backend a strategic problem. We had to build with scaling in mind. Yes, we unified eight swap sources. But more importantly, we made it much easier to add new sources later.
Here’s what we did
Unified swap data
Each provider returns the same swap in a different format. There are different quote fields and fee logic. The response structures are also inconsistent. Left as-is, every new provider would add one more integration model to the product layer.
We solved that at the backend level. The system translated provider-specific responses into one common structure. The client has one format to work with, no matter where the route came from.
The DEX market is only getting more fragmented. Thanks to the unified DEX aggregator layer, the client can add more providers – and they don’t have to change the system for every new integration.
Token layer
Good routing is only part of a DEX aggregator. Users also need reliable token lists, metadata, prices, logos, and filtering logic that stay consistent across the app. Because token data came from multiple sources and in different formats, it’s hard to present one clean asset layer.
We built a token data layer that parsed assets across networks, enriched metadata, and formed token lists for downstream products.
That gave the client a cleaner asset experience today and a much easier way to expand token coverage later.
Swap engine
The client needed one swap flow that could support cross-chain trading. That was harder than it sounds, because providers handled routing and execution differently. Some were strong inside a single ecosystem. Others added cross-chain support, but with their own rules and response models.
We built a shared backend flow for requesting quotes and preparing transaction-ready data across both same-chain and cross-chain swaps.
For the client, that meant broader swap coverage without tying every application to the strengths and limits of a single provider.
Reliable data flow
A large part of the backend challenge was not routing itself, but the shape of the underlying data. RPC responses came in raw formats like hex values, base58 addresses that first had to be converted correctly before they could be matched to database logic and product rules.
We handled this through staged and deferred processing. The backend could ingest the data first, normalize it in the right sequence, and only then persist it in a controlled way.
The system is now very stable with large token volumes.
Live updates
Swap and token data could not be loaded once and left alone. It always has to be fresh. But update logic can easily create broken states when one part of the system refreshes faster than another, especially when several downstream products rely on the same backend.
We designed coordinated refresh flows that kept updates inside the backend. Client applications could keep working with one stable interface while the data behind it was being refreshed.
The client's services could keep consuming current token and swap data through one interface.
Results
"The goal was not to stack integrations. We built a decentralized exchange aggregator to make multiple swap providers work as one system. Once that was in place, we could improve coverage and pricing without rewriting the product each time."
