Uniswap v4 Hook DualPool Technical Breakdown: LP Funds Can Still Earn Returns Even When Idle

Source: Uniswap; Compiled by: Jinse Finance Claw

Uniswap DualPool is now live — an open-source Uniswap v4 Hook co-designed by Spark and developed by Uniswap Labs. It allows market makers to earn lending returns while their assets are idle, only putting funds to use when trades happen. From the outside, DualPool looks like a standard v4 pool: traders, aggregators, and solvers execute trades through the PoolManager. Internally, however, the pool’s funds are held in an ERC-4626 yield vault; when a trade needs to be executed, the funds are pulled into concentrated liquidity positions.

The idle capital problem

On-chain liquidity is on standby 24/7. Assets submitted into an AMM pool can be traded at any time, but during the gaps between trades, those assets generate no returns. For professional market makers, this forces them to make a trade-off between where to store capital:

• Put funds into the pool: earn trading fees, but give up lending returns;

• Put funds into the lending market: earn returns, but cannot participate in trading flow.

For stablecoin pairs, fees are thin and competition is fierce; lending returns may match fees or even exceed them. As a result, market makers sometimes choose yield instead, and that liquidity therefore doesn’t show up on the AMM.

DualPool eliminates this trade-off by providing liquidity instantly: between trades, funds are stored in the yield vault; when a trade arrives, the pool calls on the needed funds on demand within the trade itself.

How DualPool works

Between two trades, the liquidity actually held in the PoolManager by DualPool is nearly zero. Its funds are stored in an ERC-4626 vault selected by the pool operator, continuously earning lending returns. When a trade arrives, the Hook atomically executes a four-step loop within the trade transaction:

1. Take out only what’s needed: the Hook calculates the quantities of various tokens required for its configured range based on the current price, and extracts only the difference from the vault.

2. Deploy concentrated liquidity: according to the operator’s allocation plan, publish the funds as one or multiple positions.

3. Execute the trade normally: the PoolManager runs standard swap math for these positions, charging the pool’s fixed fees, no different from other pools.

4. Re-deposit remaining funds into the vault: the Hook removes all the positions it added, settles with the PoolManager, and re-deposits the remaining funds back into the vault.

For traders, this is just a regular Uniswap trade. The operator’s funds leave the vault only during the lifespan of the trade, and are immediately returned once the trade completes. Because the trade itself handles liquidity withdrawal and re-deposit, the system can run autonomously without any Keeper infrastructure.

Who DualPool is for

• Operators are professional market makers. Operators deploy the pool, set fees, choose a yield vault, design the liquidity distribution, and inject initial capital. In return, they receive both trading fees and yield generated by idle funds.

• Liquidity providers (LPs) can join the pool when operators allow external deposits. LPs receive proportional claims on the pool’s assets, while earning fees and vault yield, without needing active management.

• Swappers trade with DualPool just like any other Uniswap pool, using the existing interfaces, aggregators, and routers they already use. The entire process does not expose the fact that the liquidity was just stored in a lending vault.

Routers and aggregators run DualPool trades through existing v4 execution paths with no changes required. The only (optional) additional work is quoting (detailed below).

Liquidity shape

DualPool does not deploy funds into a single price range. Each pool comes with an operator-configured distribution: a set of weighted tick ranges, deployed together each time a trade occurs. Ranges can overlap, be distributed asymmetrically on either side of the current price, or be fully skewed to one side. This is enough to encode a market-making strategy, not just a simple swing. Typical distribution patterns operators may run include:

• Stablecoin order book: concentrate most weight into a narrow band around the anchored price, with shallower coverage around the edges, so that the vast majority of depth is placed where nearly all trading volume occurs.

• Barbell: keep the center tight, while retaining one-sided depth farther away, so large one-sided flow can be traded without diluting liquidity onto ticks that are rarely touched.

• Anchored defense ladder: stepwise stack deeper support on the fragile side of the anchored price; suitable for operators with defensive obligations.

Operators can replace the distribution plan at any time between trades, so the shape can flexibly adapt to different volatility environments: narrow and aggressive when markets are calm, wider and more defensive when markets are tense. The capital allocation algorithm is conservative by design; before computing liquidity, the Hook assigns each range the exact share of the pool’s balance. Therefore, overlapping ranges never double-count capital.

Unchangeable characteristics

The following three attributes are fixed when the pool is created:

• Fees: each DualPool has static fees; after that, no code path can change them. If you want to re-price the same trading pair, the operator needs to deploy a new pool.

• Vault: the binding between the pool currency and its yield vault is set once at creation. After that, there is no administrator path to redirect the pool’s funds to a different vault.

• Trading logic: each trade runs PoolManager’s standard v4 math for any liquidity deployed by the Hook.

These invariants make DualPool predictable to the aggregators and solvers routing to it: operators cannot change the core trading logic, and there is no admin function to steal funds deposited by LPs. Operator-controlled power (pausing and resuming the pool, re-adjusting the liquidity distribution, restricting external deposits, and cutting off vault access in emergencies) is completely outside these three invariants.

Quoting pools with zero liquidity

A pool with no standing liquidity breaks a long-standing convention of routers and aggregators: estimating depth by reading pool state. If you check the on-chain DualPool between two trades, you’ll see a price, but liquidity is nearly zero—even if the pool can still execute trades worth millions of dollars. Therefore, DualPool exposes a dedicated quoting interface. Using Hook’s native quoting process is entirely optional, but doing so can significantly improve routing effectiveness:

• Indicative quote view: quote an expected trade based on the liquidity (including fees) that the Hook will deploy. A zero quote indicates the pool cannot trade and should be routed elsewhere.

• Paired reserve view: distinguish a pool’s total assets from effective liquidity — the amount the vault can currently return immediately. When the vault has a cap or is limited by utilization, effective liquidity equals the cap; the Hook configures the fund size according to that cap, and routers should control trade size accordingly.

• Paused pools return a clear error rather than silently returning empty fill, so routers can skip them.

There is no change at the execution level, because a DualPool trade is a standard v4 trade with the same execution and slippage constraints as other pools. The only difference is cost: this loop adds vault withdrawal and deposit operations within the trade, so Gas overhead may be several times higher than a regular v4 trade. At current Gas prices, it’s only a few cents extra, but it still factors into the net execution price.

Security model

DualPool’s security model is enforced mostly by code, independent of vault selection:

• Isolation: the Hook maintains a separate ledger for each pool and each currency’s assets. The total token balance is never used as an accounting input, and assets recorded by one pool cannot be redeemed by another pool.

• Share safety: LP shares are internal and non-transferable. Share calculations include virtual offsets to defend against inflation attacks; rounding is always toward the direction beneficial to existing LPs, and a configurable minimum holding period is enforced to prevent fee sniping via deposits and withdrawals within the same block.

• Reentrancy protection: user-facing entry points have standard protections; the trade loop is protected by a transient lock that rejects reentrant calls for the same pool and freezes all deposit and withdrawal operations anywhere on the Hook during any loop.

The core trust assumption is the underlying yield vault. The pool vault holds its idle funds, and the Hook has standing approvals for it, so operators must choose vault governance and upgrade risks that are acceptable. Vault selection is the core of operator risk management. If a vault’s risk becomes unacceptable, the fallback is a single emergency action: pause the pool, disable deposits, revoke vault approvals, and attempt to withdraw all pool assets. If the vault has a cap or insufficient liquidity, the system degrades gracefully: quoting and deployment size shrink to effective liquidity, LP claims on total assets are not affected; a vault that cannot accept deposits will never block trades.

OpenZeppelin has audited DualPool and found no serious or high-risk vulnerabilities; all issues reported were resolved. The audit report is provided alongside the DualPool Hook code.

Building with DualPool

If you want your capital to keep earning returns between two swaps, DualPool is now live. To deploy your own DualPool, use this deployment guide: it walks you through deploying an audited Hook from the official factory. The guide covers the full process, including configuration and verification.

For a deeper understanding of how DualPool works, check the GitHub repository and developer documentation, which include integration guides for routers and aggregators.