Solver Router: Fixing Latency and MEV in Intent-Based DEXs

Solver router symptoms and fixes

When an intent-based DEX swap fails or executes poorly, the solver router is rarely the root cause; it is usually a configuration mismatch between the router’s constraints and the current market state. High slippage, MEV extraction, and timeouts are the three most common failure modes. They point to specific, fixable parameters in the solver configuration.

Slippage and oracle freshness

High slippage occurs when the solver uses stale price data. If the oracle update interval exceeds the block time, the solver calculates routes based on prices that no longer exist. The router attempts to execute against a liquidity pool that has already adjusted, causing the swap to fail or fill at a worse rate.

Check the oracle freshness parameter. Ensure the solver is configured to reject quotes older than one block. For volatile assets, reduce this threshold to zero blocks, forcing the solver to request real-time data for every quote. This adds latency but prevents execution against outdated liquidity.

MEV extraction and mempool privacy

MEV bots scan the mempool for pending transactions. If the solver router broadcasts the intent publicly before finding a route, bots will front-run the transaction. The user sees the same slippage, but the cause is predatory extraction, not market movement.

Enable private mempool submission. The router should send the signed intent directly to the solver’s private endpoint or use a flashbots-style relay. This keeps the transaction invisible to public mempool monitors until it is included in a block. Verify that the solver API endpoint supports private submission and that the client is routing through it.

Timeouts and search limits

Timeouts happen when the solver takes too long to find a valid route. This is often a result of overly aggressive search limits or complex multi-hop paths. The router gives up before the transaction is ready, leading to failed swaps.

Review the time limit and solution limit settings. Increase the time limit slightly to allow the solver more iterations, but set a hard cap to prevent excessive latency. If the intent is simple (single-hop), reduce the search space to prevent the solver from wasting cycles on complex multi-hop paths that are unlikely to be optimal.

First solution strategy comparison

When a DEX aggregator receives a user intent, the solver must quickly generate an initial feasible route before refining it. The choice of first solution strategy dictates both the quality of that starting point and the time spent computing it. In high-latency environments, a slow initial search can cause timeouts or force the system to settle for suboptimal slippage.

The three primary strategies—Path Cheapest, Path Most Constraining, and Local Search—offer distinct tradeoffs between speed and initial solution quality. Path Cheapest greedily selects the lowest-cost edge at each step, providing rapid results but often creating fragmented routes that require heavy refinement. Path Most Constraining identifies the most difficult constraints first, ensuring critical bottlenecks are resolved early, which can lead to more stable initial paths at the cost of higher computational overhead. Local Search starts with a random or heuristic-based route and iteratively improves it, offering a balance but requiring more iterations to converge.

Source: Google OR-Tools Routing Options

Selecting the right strategy depends on your specific latency tolerance and the complexity of the DEX landscape. For most intent-based systems, a hybrid approach often yields the best results: use Path Most Constraining to anchor the route, then refine with Local Search techniques to minimize slippage.

Tune search limits and propagation control

When intent-based DEX solvers take too long to return a route, or when MEV bots front-run your transaction, the issue usually lies in how the solver balances exhaustive search against execution speed. The solver router must find a "good enough" path within a strict time window, rather than waiting for a mathematically perfect one that arrives after the market has moved. Tuning time_limit and solution_limit alongside propagation control allows you to prioritize transaction speed without sacrificing critical slippage protection.

Set a strict time limit

The time_limit parameter acts as the primary governor for solver latency. If this value is too high, the solver wastes cycles exploring low-probability paths, increasing the risk of MEV sandwich attacks. If it is too low, the solver may return a suboptimal route that fails to aggregate the best liquidity sources. For most high-frequency intent networks, a time limit between 50ms and 200ms provides a balance between depth of search and execution urgency.

Cap the number of solutions

The solution_limit parameter restricts how many candidate routes the solver evaluates before stopping. This works in tandem with time_limit to prevent infinite loops in complex multi-hop routing scenarios. By capping the search space, you ensure that the router returns the best available option within the defined constraints, rather than getting stuck trying to optimize negligible differences between two nearly identical paths.

Configure propagation control

Propagation control determines how aggressively the solver shares partial results with other nodes in the network. In congested networks, overly aggressive propagation can lead to redundant computations and increased latency. Conversely, too conservative a setting may isolate your intent, missing out on liquidity opportunities discovered by peers. Adjusting this parameter based on real-time network congestion helps maintain consistent transaction finality.

# Example configuration for low-latency trading
solver_config = {
    "time_limit": 100,          # 100ms hard limit
    "solution_limit": 50,       # Max 50 candidate routes
    "propagation_mode": "adaptive", # Dynamic sharing based on load
    "first_solution_strategy": "PATH_CHEAPEST_ARC" # Quick initial heuristic
}

Monitor and adjust based on latency

After applying these settings, monitor the solver's performance metrics. Look for patterns where transactions are consistently failing due to timeout or where slippage exceeds expectations. If latency spikes during peak hours, consider reducing the time_limit and relying more on heuristic strategies. If slippage is high, you may need to increase the solution_limit to allow for deeper liquidity aggregation, accepting the trade-off of slightly higher latency.

How solver context shapes settlement behavior

When a user submits an intent, the solver doesn’t just guess how to fill it. The user can attach arbitrary bytes—called solver context—to the adapter call. This data acts as a configuration layer that tells the solver exactly how to satisfy the request.

Without this context, solvers rely on default heuristics. These defaults often prioritize speed over security or cost, leaving users exposed to MEV (Maximal Extractable Value) attacks or inefficient routing. By injecting custom logic directly into the settlement payload, users regain control over the execution path.

Preventing MEV extraction

MEV bots scan the mempool for profitable trades. If a solver sees a standard swap, it can front-run or sandwich the transaction. Solver context changes this by allowing the user to specify private execution channels or specific slippage tolerances that bots cannot easily exploit.

For example, a user might include a context byte that forces the solver to use a specific, less congested liquidity pool or to execute the trade only during a specific block window. This restricts the solver’s freedom but significantly reduces the attack surface for MEV bots.

Custom intent satisfaction logic

Beyond security, context enables complex settlement rules. A user might want their intent to be satisfied only if the gas cost is below a certain threshold, or if the trade includes specific tokens as a side effect.

The solver reads these bytes and filters out solutions that don’t match the criteria. This turns the solver into a specialized executor rather than a general-purpose router. It ensures that the intent is not just satisfied, but satisfied in the way the user intended.

Troubleshooting context errors

If a transaction reverts or fails to find a solver, the issue is often malformed context data. Check the following:

1. Byte length: Ensure the context fits within the adapter’s expected buffer. Oversized data can cause reverts.
2. Syntax: Verify that the bytes follow the expected ABI encoding. Misaligned data leads to parsing errors.
3. Logic consistency: Ensure the context doesn’t contradict other intent parameters, such as slippage limits.

When context is correctly formatted, it becomes a powerful tool for optimizing settlement outcomes. It shifts the balance of power from the solver back to the user, allowing for more precise and secure intent execution.

FAQ about solver router settings

Quick checklist