Why Paraswap integration breaks under peak load
The aggregator does not reduce everything to a single source of liquidity: it queries dozens of pools, assembles a multi-step route, and returns a ready transaction for signing.
While the quote is being calculated and reaches the wallet, the state of the pools changes — and it is under peak load that this gap becomes critical.
The first type of failure is quote desynchronization: the price comes from a state that is already outdated, and the swap executes under conditions that no longer exist on the market.
The second is route failure: if even one pool is drained from the chain, the entire transaction reverts, although the remaining steps were still valid.
Separately, there are stuck transactions — during a gas spike, a signed operation hangs in the queue, its deadline expires, and funds are locked until manual cancellation.
The share of failed swaps during active hours grows severalfold: the user pays only the network fee, the swap itself does not go through, but the interface keeps showing a successful result until the very end.
This is what a typical swap failure looks like, because of which the Paraswap integration in production stops maintaining the promised reliability.
We analyze how this is addressed: where to place route freshness validation, which slippage and deadline thresholds work at peak, and how to return a clear status instead of a stuck transaction.
What well-tuned swap routing provides
Swap routing is the calculation of how to execute a trade, not the selection of a single venue: the aggregator compares pool depth across many decentralized exchanges, splits the amount into parts, and assembles a path so that price impact and pool fees are minimal.
Paraswap keeps this logic on its side, so the product does not need to know exactly where the swap will be executed.
This yields measurable effects.
The share of successful swaps grows because the route is recalculated right before the transaction is sent, rather than taken from a saved calculation: a quote that became outdated during volatility no longer leads to a revert due to slippage exceeded.
Route preparation response time remains in tenths of a second even during request spikes — the calculation runs in parallel across venues.
Load resilience rests on route redundancy. If an individual venue is unavailable or responds slowly, the route is built from the remaining ones, and the operation is retried with an updated quote instead of failing.
The share of swaps requiring manual intervention drops to isolated cases: the operator no longer has to manually select a pool or raise the slippage threshold.
What this changes in operations: the class of failures 'trade did not go through due to price' stops being noticeable in support requests, and service behavior under peak load becomes predictable.
Routing performance is visible in metrics — share of successful swaps, average and tail response time, and slippage distribution across trades.
Options for connecting to liquidity sources
Liquidity sources differ not only in depth, but also in how quickly the price you showed the user leaves them.
When the route uses a single pool, a large nearby trade moves the quote, and the swap executes worse than expected; when there are dozens of routes, the question is who iterates through them and with what latency.
We build at least two independent channels into the architecture: the primary one through a swap aggregator and a backup direct connection to vetted pools. This defines system behavior when an external service is unavailable or returns a route with slippage above the limit.
| Option | When it fits | Limitations |
|---|---|---|
| Direct connection to a single venue | Narrow set of assets, predictable volumes, need full control over contract calls | No price choice: if liquidity in that pool drops, the trade either fails or executes at a bad rate |
| In-house router | Own set of pools, non-standard swap logic, readiness to maintain indexing and route recalculation | Expensive to develop and maintain; it is hard to compete on price with ready-made aggregators |
| External swap aggregator, e.g. Paraswap | Need the best available price across a broad set of venues without your own infrastructure | Dependence on an external service: latency, request limits, changes in rules and network list |
| Hybrid scheme with a backup route | Production environment with availability requirements and slippage control | Testing is more complex: both paths and the switching rules between them must be covered |
The hybrid scheme provides predictability: as long as the aggregator responds within the price and time limits, the swap goes through it; if it deviates, the backup route kicks in, and the user is not left with an unexecuted order.
This option is most often what we make the foundation, while the others — as stepping stones while load or control requirements have not yet grown.
How Paraswap integration proceeds: work stages
Aggregator integration is not connecting a single call, but embedding into the existing swap scheme: the route is assembled from several liquidity sources, and the final output depends on request parameters, slippage limits, and failure handling.
Below is the sequence of Paraswap integration stages that we follow on projects — from auditing current swaps to handing over the system with maintenance procedures.
- Swap scheme audit. We collect current pairs, volumes, and shares of failed transactions. The output is a map showing where the aggregator provides an output gain and where direct swap is more profitable.
- Route setup. We define liquidity source priorities, slippage limits, minimum output amount, and behavior when liquidity is insufficient. The backup source is fixed in advance.
- Connection and configuration. We integrate calls, keys, and limits, and describe error and retry handling so that a single failure does not stop swaps.
- Correctness validation. We run scenarios on historical data and in a test environment: compare estimated output with actual, check boundary amounts and failure of one of the sources.
- Observability and traffic rollout. We set up metrics for the share of successful swaps and deviation of actual output from estimated. We enable traffic gradually — starting with a small share.
- System handover. We deliver route schemes, configurations, maintenance procedures, and the procedure for failures, and train your team.
Delivery artifacts: schemes, policies, procedures
Integration does not end with working code, but with a set of artifacts that allow the system to be developed and maintained on your own. Below is what exactly remains with the customer after handover.
- Route configurations — supported networks and token pairs, slippage thresholds, liquidity source priorities, and fallback rules when the best route is unavailable.
- Access policies — separation of signing and read keys, operator roles, rotation procedure, and decommissioning of credentials.
- Flow schemes — the path from quote request to trade confirmation: where limits are checked, where the result is recorded, and what happens on timeout.
- Limits and safeguards — per-transaction and daily volume thresholds, pair restrictions, automatic halt on abnormal price drop.
- Maintenance procedures — response times for quote degradation, procedure for connecting new sources, scheduled checks of failure scenarios.
- Integration documentation — methods, request and response formats, error codes, typical recovery and rollback scenarios.
We hand over the set together with an owner on the customer side: engineers walk through the schemes and procedures with the team so that the documents do not remain unused.
Further changes to routes or limits are made according to the described procedures, without rebuilding the integration.
Case study: swaps stopped failing during peak loads
Situation before
Token-to-token swaps went through a single route: when liquidity on the venue dropped or the trade reverted due to slippage, the user got an error and went off to try again.
During peak loads, the share of failed swaps reached every sixth request, and the on-call engineer manually raised the allowed price deviation and switched the source — triage took up to half an hour, and swaps did not go through all that time.
What was changed
We connected the Paraswap aggregator as a routing layer: it compares available liquidity sources and splits a large trade into parts so as not to crash the price on a single pool.
Around it, we placed control of allowed price deviation, pre-signature quote validation before signing the transaction, and automatic retry with route reassembly if a source returned an error.
We separately configured failover to a backup source when the primary venue is unavailable — already without on-call involvement.
What the result was
The share of failed swaps dropped to single-digit percentages: the result comes on the first or second attempt, not on the fourth try. Recovery time after a venue failure decreased from tens of minutes of manual work to seconds — the route rebuilds itself.
Manual triage became about ten times less frequent: the on-call engineer no longer sits on a stream of failed swaps and instead works on development tasks. Swap stability during peaks no longer depends on who is on shift today.
How does an aggregator differ from a direct connection to an exchange?
A direct connection to a single exchange is one liquidity pool and one route: the price is determined by the depth of that pool, and on a large volume slippage grows.
An aggregator assembles a route from several venues, splits the order between pools, and rearranges steps according to the current state of the book. The difference is not in the 'average price', but in who makes the routing decision.
With Paraswap integration, route control remains with the aggregator: you set the boundaries — allowed slippage, minimum execution price, list of networks and tokens — while its calculation layer computes the trade split.
Price predictability is higher: several routes compete, and the trade executes at the best of those found, rather than the only available one.
| Criterion | Direct connection to DEX | Aggregator |
|---|---|---|
| Route control | Full, but only one route | Your boundaries, the aggregator computes the split |
| Price predictability | Depends on the depth of one pool | Route competition, order splitting |
| Venue dependency | A pool halt breaks the swap | One venue failure only narrows the routes |
| Maintenance | Your own code for each network | You only monitor the boundaries |
The direct scheme depends more on the venue: a pause on contracts or liquidity withdrawal — and the swap function stops working entirely.
Hence the choice of swap scheme: the aggregator covers user swaps and the long tail of tokens, while a direct connection covers proprietary strategies where precise execution control is needed.
In practice, they are combined: the aggregator as the primary path, the direct connection as backup.
Technical questions and routing limitations
Routing in Paraswap is the only part of the integration that depends on external venues.
If a pool rebalances liquidity or a source halts trading, the trade split changes at the moment of signing, and without explicit failure handling the user gets a stuck operation instead of a clear error. Below is what the technical team most often checks before implementation.
What happens if a venue is unavailable?
The aggregator excludes it from the route and rebuilds the path using the remaining liquidity sources. If no available pools remain, or the best route gives a price worse than the threshold set at submission, the swap is not executed — the transaction is not sent to the network.
Can the aggregator be replaced without rewriting the service?
Yes. The routing layer is moved behind a unified interface: quote retrieval, response format, and failure handling are described in a single integration module.
Switching to another provider is an edit of this module and the route selection logic; the rest of the code and transaction accounting are not affected.
What are the volume limits and where is the drawdown boundary?
The limit is set not by the aggregator but by pool depth: a large trade passes through several price levels, and the final rate differs from the displayed quote.
We calculate the drawdown before signing, set an upper volume limit per trade and an allowed price deviation; if they are exceeded, the operation is rejected or split into several parts over time.
Let's discuss your task: estimate and work plan
The work estimate relies on facts, not assumptions, so to start we need a snapshot of the current swap scheme and its requirements. Some of the items below are covered by a description, some by access to a test environment or an export of configurations. Below is what to send so that we come back with an integration plan, not clarifying questions.
- Current swap scheme: which contract or service executes the swap today, where amounts are calculated, which steps are done manually, and whether an external aggregator such as Paraswap is used.
- List of venues and networks: where liquidity is needed, which venues must remain in the swap route, and which can be excluded without losing execution.
- Swap requirements: allowed slippage, minimum and maximum trade amount, behavior on partial fill, and maximum order execution time.
- Expected load: how many swaps per hour on average and at peak, how many wallets and users operate in parallel, and whether there are seasonal spikes.
- Access roles and key perimeter: who initiates and who signs the operation, where keys are stored, and whether there are limits per transaction and per daily turnover.
- Environments: which test network is used and how it differs from the production environment in available liquidity and settings.
- Reporting and control: what transaction log is needed, how the discrepancy between the order and actual execution is tracked, and where error events go.
If there are no answers for some items yet, that is also a workable option: we will record them as open in the task statement and close them during the analysis stage.
After that, we will come back with an integration plan — work order, rollback points, acceptance criteria — and start with the test environment.