Optimal Multi-Hop Routing Across Uniswap V2, V3, V4

introduction

MULTI-POOL GRAPH TRAVERSAL

The Cross-Version Routing Problem

The algorithmic challenge of finding the most capital-efficient path for a single swap when liquidity is fragmented across Uniswap V2, V3, and V4 pools.

Optimal multi-hop routing across Uniswap versions is a complex graph-traversal problem. A router must split a user's swap across a heterogeneous set of pools—constant-product V2 pairs, concentrated-liquidity V3 pools with discrete fee tiers, and the singleton V4 architecture with custom hooks. Each pool type has a distinct cost function for price impact and a different gas profile. The router's objective is to find the path that maximizes the output token amount net of gas costs, a calculation that becomes exponentially harder as the number of potential intermediate tokens and pool versions grows.

The introduction of the V4 singleton contract fundamentally changes the gas-cost model for this problem. In V2 and V3, a multi-hop swap requires a separate external call to each pool contract, incurring a fixed gas overhead per hop. In V4, the singleton allows multiple pool swaps to be executed atomically within a single contract call, dramatically reducing the marginal gas cost of an additional hop. An optimal routing algorithm must therefore model a mixed graph where some edges (V4 pools) have a lower gas weight than others (V2/V3 pools), potentially making a path with more V4 hops cheaper than a direct V3 route, even if the direct route offers a slightly better spot price.

For swap aggregators, wallet developers, and solver networks, the cross-version routing problem is the core logic determining execution quality. An incorrect gas model leads to suboptimal routes that leak value to arbitrageurs. A failure to account for V4 hook-imposed fees or liquidity constraints results in reverted transactions. Chainscore Labs can advise on routing algorithm design, gas estimation models that accurately weight mixed-version paths, and the integration of V4's singleton execution into existing solver architectures to ensure routers remain competitive as Uniswap's liquidity landscape fragments further.

MULTI-VERSION ROUTING OPERATIONS

Routing Architecture Quick Facts

Operational impact of splitting a single swap across V2, V3, and V4 pools for routers, aggregators, and fillers.

Area	What changes	Who is affected	Action
Atomic execution model	V4 singleton allows multi-hop routes that include V4 pools to execute atomically. V2 and V3 pools require separate external calls per pool.	Aggregators, solver networks, filler bots	Model gas costs for mixed-version routes. A route including a V2 pool breaks V4 atomicity and adds transfer overhead.
Gas accounting	V4 introduces a native ETH credit/debit system and a per-pool lock. V2 and V3 use ERC-20 transfers. Mixed routes incur both cost models.	Routing algorithm designers, gas estimators	Update gas models to account for V4's transient storage and hook gas. Do not apply V3 transfer cost assumptions to V4 legs.
Pool graph construction	Routers must now traverse a single V4 singleton containing many pools, plus separate V2 and V3 factory contracts. The graph topology changes.	Off-chain routing engines, quote APIs	Index V4 pools by PoolId within the singleton. Treat the singleton as a single node with internal edges, not as separate contracts.
Hook interference risk	A V4 pool with a custom hook can revert a swap based on arbitrary logic. A route that appears valid statically may fail at execution time.	Solver networks, aggregator frontends	Simulate routes against the latest chain state before submission. Monitor hook behavior for pools included in frequently used routes.
Fee tier fragmentation	V4 allows unlimited fee tiers. V3 has a fixed set. V2 has a single 30 bps fee. The search space for optimal routes expands significantly.	Routing algorithm developers, liquidity analysts	Implement heuristic or ML-based route pruning. Exhaustive search across all V4 fee tiers will become computationally infeasible.
Native ETH handling	V4 natively supports ETH pairs. V2 and V3 require WETH wrapping. A route mixing native ETH and WETH legs introduces wrap/unwrap steps.	Wallets, aggregator contracts	Account for WETH deposit and withdraw gas in mixed routes. Prefer native ETH legs in V4 to reduce user friction.
Contract approval model	V4 uses Permit2 for all swaps. V2 and V3 use direct token approvals. A mixed route requires the user to have both Permit2 authorization and legacy approvals set.	Wallet developers, frontend integrators	Ensure UI flow handles both approval types. A missing Permit2 authorization will cause the V4 leg of a mixed route to fail.

technical-context

MULTI-VERSION ROUTING ARCHITECTURE

Unified Liquidity Graph and Cost Model

A canonical model for off-chain routers to represent the entire Uniswap ecosystem as a single, traversable graph with version-specific cost functions, enabling optimal pathfinding across V2, V3, and V4 pools.

Optimal multi-hop routing across Uniswap V2, V3, and V4 requires a unified liquidity graph where each pool is a node edge with a dynamic weight derived from its version-specific execution cost. The core challenge is not just finding a path that maximizes output, but doing so while accurately modeling the gas overhead of crossing version boundaries. A route that splits a swap across a V2 pair and a V3 pool, for instance, incurs the cost of two separate external calls and data loads, whereas a route that stays entirely within the V4 singleton can execute multiple hops atomically with significantly lower overhead. The routing algorithm must therefore treat the V4 singleton as a subgraph where internal edges have a near-zero gas multiplier, while edges that exit or enter the singleton carry a fixed cross-contract call penalty.

The cost model must account for three distinct execution environments. V2 pools involve a simple swap() call on a standalone pair contract with a flat gas cost. V3 pools add the complexity of tick crossing and initialized tick bitmap access, making the gas cost of a swap path-dependent based on the liquidity distribution. V4 pools, operating within the singleton, amortize the base transaction cost across all hops and introduce hook-specific gas costs that are unknown until the hook contract is called. A robust routing model pre-calculates a gas coefficient for each pool based on its version and, for V4, a hook complexity flag. The pathfinding algorithm then optimizes for net_output = gross_output - (gas_cost * gas_price_in_asset), ensuring that a path with a slightly worse price but drastically lower gas consumption is correctly identified as optimal.

For integrators, the operational impact is that a static routing table is insufficient. The unified graph must be continuously rebuilt from on-chain state: V2 reserves, V3 liquidity net values at each tick, and V4 pool states with their registered hooks. The router must simulate each candidate path's swap outcome using the exact pool math to calculate the gross output, then add the version-specific gas estimate. This simulation is compute-intensive and is the primary reason high-frequency routers run their own indexing infrastructure. Chainscore can assist teams in designing this gas estimation model, auditing the correctness of the path-simulation logic, and ensuring that the routing algorithm correctly handles edge cases such as empty tick ranges in V3 or reverting hooks in V4 that could invalidate an otherwise optimal path.

IMPACT ANALYSIS

Affected Systems and Teams

Aggregators & Routers

Swap aggregators and meta-aggregators are the primary actors affected by multi-hop routing across Uniswap versions. The core challenge is modeling a unified liquidity graph where nodes represent pools across V2, V3, and V4, and edges represent direct swaps or intermediate tokens.

Key Impact Areas:

Graph Construction: Must ingest and continuously update pool state from three distinct contract architectures (V2 pairs, V3 pools, V4 singleton pools).
Gas Accounting: V4's singleton model and hooks introduce variable gas costs that differ fundamentally from V2 and V3. Routing algorithms must accurately estimate gas for mixed-version paths to find the true optimal route.
Atomic Execution: Routers must construct calldata for the Universal Router or a custom proxy that can atomically execute a path touching V2, V3, and V4 pools, handling token transfers and callbacks correctly.

Action: Audit your routing algorithm's gas model for V4 pools, especially those with hooks. Verify that your split logic does not inadvertently fragment a swap across versions in a way that increases net gas cost beyond a single-version route.

implementation-impact

ROUTING ARCHITECTURE

Implementation Impact Areas

Multi-hop routing across V2, V3, and V4 pools introduces distinct engineering challenges that affect gas accounting, atomic execution guarantees, and off-chain solver design.

Mixed-Version Gas Modeling

Routers must accurately model gas costs for hops that traverse different Uniswap versions. V2 uses a simple constant-product model with fixed gas overhead, V3 introduces tick-crossing costs that vary with liquidity density, and V4's singleton architecture amortizes warm-storage access across hops but adds hook-specific gas overhead. An incorrect gas model leads to failed transactions or suboptimal route selection. Integrators should build version-aware gas estimators that account for cold vs. warm pool access, hook invocation costs, and the V4 singleton's multi-hop discount. Chainscore can review gas estimation models for accuracy against live chain behavior.

Atomic Execution Across Versions

A single swap split across V2, V3, and V4 pools must execute atomically to prevent partial fills and MEV exposure. The Universal Router achieves this by batching commands into a single transaction, but integrators building custom routers must handle the fact that V2 and V3 use separate router contracts while V4 uses the singleton's swap entry point. Any revert in a later hop must unwind state changes from earlier hops. Teams should use the Universal Router's command pattern or implement equivalent re-entrancy-safe batching logic. Chainscore can audit custom multi-version routing contracts for atomicity violations and re-entrancy vulnerabilities.

V4 Singleton Warm-Storage Optimization

The V4 singleton contract keeps all pool state in a single contract, meaning the second and subsequent V4 hops in a multi-hop path access warm storage. This fundamentally changes the cost calculus for routes that include multiple V4 pools versus routes that mix versions. Routers should prioritize V4-heavy paths when gas efficiency is critical, but must also account for hook gas costs that can negate the warm-storage advantage. Off-chain solvers need updated cost models that treat V4 pool access as progressively cheaper within a single transaction. Chainscore can help teams benchmark and model the effective gas savings of V4 multi-hop paths.

Hook-Induced Routing Failures

V4 hooks can revert transactions based on custom logic in beforeSwap or afterSwap callbacks. A route that appears valid based on pool liquidity and price may fail at execution time if a hook enforces a fee cap, volatility check, or access control that the router did not simulate. Off-chain routing engines must either simulate hook behavior during path finding or implement fallback route selection to handle hook-induced reverts gracefully. This adds a new failure mode that does not exist in V2 or V3 routing. Chainscore can assess routing engine resilience to hook-induced failures and recommend simulation strategies.

Cross-Version Price Impact Aggregation

Splitting a large swap across multiple pools and versions requires accurate aggregation of price impact to quote the user a reliable expected output. V2 uses the x*y=k formula, V3 uses concentrated liquidity math with tick transitions, and V4 inherits V3's math but may have hooks that modify fees dynamically. The router must compute the marginal price after each hop and feed it into the next hop's calculation. Errors in this chain accumulate and can produce misleading quotes. Integrators should validate their price-impact aggregation against on-chain results during testing. Chainscore can review quote accuracy and price-impact calculation logic.

Solver Competition in Multi-Version Environments

In intent-based systems like UniswapX, fillers compete to execute user orders across any combination of Uniswap versions. A filler with a superior multi-version routing engine can outbid competitors by finding paths that others miss—such as routing through a V4 pool with a favorable dynamic fee or combining V2 and V3 pools to access deeper combined liquidity. This creates an arms race in routing algorithm sophistication. Teams operating filler infrastructure should continuously benchmark their routing against competitors and monitor for new pool deployments across all versions. Chainscore can advise on filler routing strategy and competitive benchmarking.

MULTI-HOP EXECUTION ACROSS UNISWAP VERSIONS

Routing Risk Matrix

Evaluates the operational risks, gas cost variables, and execution atomicity concerns when splitting a single swap path across V2, V3, and V4 pools within a single transaction.

Area	What changes	Who is affected	Action
Execution Atomicity	V4 singleton allows multi-hop within one pool manager; V2/V3 require external router contracts to sequence hops atomically. Partial fill or revert logic differs across versions.	Aggregators, Solvers, MEV Searchers	Audit router contract logic to ensure atomic execution across mixed-version paths. Verify that a revert in one hop correctly unwinds state for prior hops.
Gas Accounting	V4 introduces native ETH support and a dynamic fee model; V2 and V3 have fixed gas overhead per hop. Cross-version paths incur heterogeneous gas costs.	Aggregators, Trading Bots, Wallets	Update gas estimation models to account for V4's singleton overhead vs. V2/V3's per-pool overhead. Simulate mixed paths to avoid out-of-gas failures.
Pool Liquidity Depth	V4 allows infinite fee tiers, potentially fragmenting liquidity. V3 has established fee tiers. V2 has a single fee tier. Routing across versions may require traversing shallow pools.	Traders, Liquidity Providers, Aggregators	Implement slippage checks that account for the cumulative price impact across fragmented V4 pools. Monitor depth per fee tier before including in routes.
Hook-Induced Reverts	V4 pools can have hooks that revert swaps based on custom logic (e.g., volatility checks, allowlists). A hook revert in a multi-hop path fails the entire transaction.	Aggregators, Solvers, Fillers	Simulate or dry-run swap paths that include V4 pools to detect hook reverts before submission. Maintain a registry of known hook behaviors.
TWAP Oracle Consistency	V2 uses arithmetic mean, V3 uses geometric mean. V4 hooks can introduce custom oracles. Aggregating prices across versions requires mathematical conversion.	Lending Protocols, Derivatives, Data Teams	Do not mix raw V2 and V3 oracle values without conversion. Verify that V4 hook-based oracles are manipulation-resistant before including in aggregated feeds.
Permit2 and Approval Scope	Universal Router uses Permit2 for gasless approvals. A multi-hop path may require approvals for tokens across V2 and V3 pools, while V4 uses the singleton's native transfer logic.	Wallets, Frontends, Aggregators	Ensure Permit2 signatures cover all tokens in the path. Validate nonce and expiration management to prevent replay across mixed-version routes.
L2 Sequencer Downtime	On L2s, sequencer downtime can delay or reorder transactions. Multi-hop paths that span V2, V3, and V4 pools on an L2 are all subject to the same sequencer liveness risk.	L2 Deployments, Wallets, Aggregators	Check L1 rollup state for sequencer downtime before submitting time-sensitive multi-hop transactions. Include grace periods in oracle lookback windows.

MULTI-VERSION ROUTING READINESS

Router Implementation Checklist

A practical checklist for teams building or upgrading an off-chain router that splits swaps across Uniswap V2, V3, and V4 pools. Each item identifies a critical integration point, explains why it matters for execution quality and gas efficiency, and specifies the artifact or signal that confirms readiness.

What to check: The router's graph model correctly represents V2 pairs, V3 pools, and V4 pools as distinct edge types with version-specific cost and constraint functions.

Why it matters: V2 uses a constant product curve with a single reserve ratio, V3 uses concentrated liquidity with tick-based分段 pricing, and V4 introduces dynamic fee hooks that can alter the swap invariant mid-execution. Treating all pools as identical edges leads to incorrect quotes, failed splits, or suboptimal path selection.

Readiness signal: The graph model includes a version discriminator on each edge. V4 edges reference a hooks address and a beforeSwap gas overhead estimate. The path-finding algorithm can compare a V2 → V3 → V4 route against a V3 → V3 → V3 route and correctly rank them by net output after gas.

resource-links

UNISWAP ROUTING REFERENCES

Canonical Resources

These resources are the primary starting points for teams implementing or auditing optimal multi-hop routing across Uniswap V2, V3, and V4 pools. Use them to separate off-chain path discovery from on-chain execution, verify contract surfaces, and model version-specific gas and liquidity behavior.

Smart Order Router Reference Implementation

The Uniswap Smart Order Router repository is the most relevant canonical reference for off-chain route search, split routing, and quote construction across Uniswap liquidity sources. Teams building aggregators should study how candidate paths are generated, how pool liquidity is sampled, and how gas-adjusted output is compared before execution. Treat it as a reference model rather than a drop-in answer: production routers still need chain-specific indexing, stale-liquidity protections, token filtering, L2 gas modeling, and fallback behavior when RPC or subgraph data diverges from current pool state.

EXPLORE

Universal Router Execution Surface

The Universal Router repository documents the command-based execution layer used for complex swaps, including multi-hop and multi-protocol flows. For mixed V2/V3/V4 routing, the key implementation task is translating an off-chain optimal route into a safe command sequence with correct token custody, minimum-output checks, Permit2 usage, and refund handling. Integrators should review command encoding, failure semantics, and supported module behavior before routing user funds through custom abstractions. Any custom router should be tested against partial fills, reverts, fee-on-transfer tokens, and native ETH wrapping paths.

EXPLORE

Uniswap V4 Core and Singleton Architecture

The V4 core repository is the canonical source for the singleton, pool manager, lock model, hooks, and accounting behavior that affect route execution. Routing engines must account for V4 differently from V2 pair contracts and V3 pool contracts: pools are represented inside the singleton, hooks can modify swap behavior, and atomic multi-hop execution interacts with the PoolManager’s locking and settlement flow. Before including V4 pools in a routing graph, teams should classify hook permissions, simulate hook-side gas and revert conditions, and avoid assuming that all V4 pools behave like plain constant-product or concentrated-liquidity venues.

EXPLORE

V3 Multi-Hop Swap Documentation

Uniswap’s V3 multi-hop swap guide is the practical reference for path encoding, fee-tier selection, and exact-input versus exact-output swap flows. It is especially useful when building graph edges for V3 because each token pair can have multiple fee-tier pools with different liquidity depth, tick spacing, and price impact. Routers should model each fee tier as a distinct edge, estimate tick crossing costs, and avoid selecting a superficially better quote that becomes worse after gas and slippage constraints. Use this guide to validate path construction before combining V3 legs with V2 or V4 execution.

EXPLORE

V2 Router02 Contract Reference

The V2 Router02 documentation remains important for mixed-version routers because V2 pools still appear in long-tail liquidity paths and stable routing fallbacks. V2 pathing is simpler than V3 or V4, but execution has different assumptions: pair-level reserves, deterministic pair addresses, support for fee-on-transfer token variants, and no fee-tier dimension. When routing across V2 and newer versions, teams should normalize reserve freshness, reserve-based price impact, and gas costs against V3 tick traversal and V4 singleton settlement. Do not treat V2 quotes as interchangeable with V3/V4 quotes without version-aware slippage and token-behavior checks.

EXPLORE

Chains We Build On

Looking to build on a specific blockchain?

We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.

Learn More

EVM ecosystems

Ethereum
Arbitrum
Optimism
Polygon
Avalanche
Cronos

Non-EVM ecosystems

Solana
Sui
Aptos
Hedera
Stellar
NEAR

Additional ecosystems

Polkadot
Cosmos
TON
Cardano
Algorand
Tempo

Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.

ROUTING OPTIMIZATION FAQ

Frequently Asked Questions

Common questions from protocol architects and routing engineers building or integrating multi-hop swap systems that span Uniswap V2, V3, and V4 pools.

Each Uniswap version imposes different constraints on the routing graph. V2 pools use a constant-product curve with a single reserve pair per pool. V3 pools introduce concentrated liquidity with tick-based liquidity distribution, making the exchange rate path-dependent on the swap size. V4 pools share a singleton architecture where multiple pools can be traversed atomically without intermediate token transfers, but hooks attached to each pool can introduce arbitrary state transitions and fee dynamics. A router must model V2 edges as simple reserves, V3 edges as piecewise functions across tick ranges, and V4 edges as potentially stateful transitions. Treating them as uniform edges produces suboptimal execution and can cause failed transactions when a V4 hook reverts on an unexpected state change.

Trusted by Industry Leaders

Delivering blockchain solutions for 5+ years.

We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.

Selected Partners & Clients

“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”

Lee Erswell

CEO, Telos Foundation

how to get started

How to get started?

If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.

Exploration & Strategy

Define your product goals and choose the right blockchain architecture for your use case.

Architecture & Design

Design the smart contracts, tokenomics, and security parameters of your system.

Development & Integration

Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.

Security & Launch

Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.

Learn More

Explore More Solutions

Discover our
blockchain development services.

We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.

Book a Call

DeFi Protocol Development

End-to-end development of custom DeFi protocols including core smart contracts and system architecture.

DEX & Exchange Development

Building high-performance decentralized exchanges with optimized liquidity and advanced trading logic.

Lending & Borrowing Platforms

Scalable credit markets and money protocols built for production-grade liquidity and security.

Optimal Multi-Hop Routing Across V2, V3, and V4 Pools

The Cross-Version Routing Problem

Routing Architecture Quick Facts

Unified Liquidity Graph and Cost Model

Affected Systems and Teams

Aggregators & Routers