Announced on June 12, 2023, two years after V3’s release, Uniswap V4 is Uniswap’s next major upgrade of the protocol. With a slew of new features, including a completely redesigned architecture that uses a single smart contract and hooks to enable LP and swap customizability, Uniswap is poised to further dominate the spot DEX landscape.

Upgrades

Singleton Contract

In Uniswap V3, a new smart contract is deployed each time a new liquidity pool is created. This includes any time a liquidity pool with a different fee tier for the same two tokens is created. As a result, the Uniswap V3 router directs swaps through multiple different contracts, which is a fairly gas-inefficient endeavor, especially for multi-hop swaps that transact through multiple liquidity pools.

With Uniswap V4, the protocol will now implement a “singleton” model, meaning that all pools will be managed within a single contract. One advantage of this design is that it reduces the gas costs associated with deploying a liquidity pool by 99%. The larger architectural change enabled by a singleton design is flash accounting. Regardless of the number of operations within a sequence of transactions on Uniswap, flash accounting allows the protocol to only calculate the end net state changes, vastly reducing the gas costs associated with multi-hop swaps. For example, in previous versions of Uniswap, if one were to make a USDC -> PEPE transaction with ETH as an intermediary asset, the protocol would have to swap USDC for ETH, send the ETH to the ETH <> PEPE pool, and then swap the ETH for PEPE. With a singleton architecture, all operations that occur between the first transaction and the last transaction will not incur additional gas costs as the protocol will automatically process all liquidity pool state changes within a single contract. Another example of flash accounting that demonstrates the benefits of a singleton contract is outlined below.

This functionality is enabled by EIP-1153, which is a transient storage opcode, slated to go live as part of the Ethereum Cancun upgrade in the second half of 2023. Transient storage, as the name suggests, is a new writable data location, where the data only exists for the duration of the transaction. As a result, full nodes don’t have to store the transient data and it does not contribute to state bloat. Two new opcodes, TLOAD and TSTORE, will allow contracts to store and load data values at the low cost of 100 gas and 1000 gas respectively.

The transient storage opcode will be used by the flash accounting module to store token balances within a transaction and will reduce not only the gas cost of trades that cross multiple pools but also more complex integrations and functionality such as those enabled by hooks, explained later in further detail. As an added benefit, the transient storage opcode will enable single transaction ERC-20 approvals, meaning a user can limit thier token approvals to one specific transaction.

ERC-1155

In Uniswap V1 and V2, where there was only full-range liquidity provision, LP positions were represented using ERC-20 tokens. In V3, due to the emergence of concentrated liquidity, every LP’s position could represent a different amount of liquidity in a different range, as such, LP positions were represented using the ERC-721 token standard  (NFTs). For Uniswap V4, with the implementation of a singleton contract, LP positions are represented using an ERC-1155 token.

The ERC-1155 token standard is a multi-token standard that is a hybrid between ERC-20 and ERC-721. Like ERC-721, it allows for multiple heterogeneous assets to be issued, however, unlike ERC-721, users hold a numerical balance of each asset, making it possible to have fungible tokens. The ERC-1155 token standard is best suited for scenarios where there are many different fungible & non-fungible assets. In Uniswap V4’s case, it allows one single contract to issue all LP positions across every single Uniswap pool.

One unique feature of ERC-1155 tokens is that instead of requiring token approvals, it has a TransferHook function. TransferHooks embed additional functionality into transfers, such as allowing a smart contract to reject the transfer of a token. In addition, ERC-1155 supports batch transfers, where one can send multiple tokens simultaneously without giving another contract full token approval. It is also a significant gas use improvement relative to ERC-721 tokens. With ERC-1155, users can now keep all tokens deposited in a liquidity pool within the singleton contract. This avoids ERC-20 transfers to and from the contract in a scenario where the liquidity provider wants to shift tokens into providing liquidity for some other liquidity pool.

Hooks

Uniswap V4 introduces the concept of a hook. Similar to a webhook, Uniswap hooks allow developers launching liquidity pools to customize certain behavior based on a set of triggers. Hooks are implemented through a contract that a liquidity pool points to, and the contract itself contains all the custom logic which the pool executes during a transaction.

There are currently eight hook callbacks that are supported.
- beforeInitialize/afterInitialize (when an LP position is initialized)
- beforeModifyPosition/affterModifyPosition (when an LP position is modified)
- beforeSwap/afterSwap (when a trader makes a swap)
- beforeDonate/afterDonate (when a donation is made to in-range liquidity providers)

Developers can create customized programmatic actions that occur in the scenario one or more of these hooks are triggered. Thus, hook callbacks can be used to customize how pools, swaps, fees, and LP positions are interacted with.

Examples

The possibilities of features enabled by hooks are fairly endless, and V4 greatly increases the granularity, expressivity, and customizability of liquidity pools and DEX mechanisms. MEV value capture is one problem that hooks may be able to solve. With hooks, some degree of MEV may be internalized. However, there are still limitations on MEV capture through hooks, as the hook can only be begin block aware but not end block aware, meaning that a liquidity pool cannot have full ordering preferences and maximize MEV internalization. This is unlike what is possible on certain Cosmos chains such as Osmosis using ABCI++ and its protocol revenue model in which MEV is internalized by baking in transaction preference logic at the chain level because the application is state-aware. A sample MEV capturing AMM that is possible with Uni V4 is diagrammed below.

Another change in dynamics is the introduction of a new entity competing for fees, hooks, or more accurately, the liquidity pool deployer. In Uniswap V3, the only two entities competing for fees are liquidity providers and the Uniswap DAO. As of today, the fee switch in Uniswap V3 still has not been turned on due to a wide range of concerns such as regulatory scrutiny and liquidity provider disincentives.

With Uniswap V4, a new entity, the deployer, will compete with Uniswap DAO and liquidity providers. This means that it is possible for both the Uniswap DAO and the deployer to turn on their own fee switch simultaneously, resulting in reduced trading fees to liquidity providers. In addition, deployers will be able to turn on a fee switch on LP position withdrawals, with the Uniswap DAO also being able to turn on the withdrawal fee switch, if and only if the deployer has turned his withdrawal fee switch on.

Theoretically, a pool should be able to encourage stickier liquidity with a withdrawal fee enabled, as only long term liquidity providers who have accrued significant fee revenue would be willing to pay the withdrawal fee. To further encourage stickier liquidity, a deployer could set a withdrawal fee that decreases as the length of time (number of blocks) one has provided liquidity for increases, penalizing short-term liquidity providers but not penalizing long-term liquidity providers. Importantly, this has implications for JIT liquidity, which is liquidity that is only provided for a single swap transaction by a sophisticated actor. If a deployer wanted to, they could charge a high withdrawal fee that would completely negate any profits made by a JIT liquidity provider.  

Below is a diagram outlining the process for an LP withdrawal fee + an enabled fee switch.

Uniswap V3 is generally unprofitable for LPs when measured with IL, LVR, and markout. The net result is that the average liquidity provider for a concentrated liquidity DEX loses an enormous amount of money to toxic flow that largely stems from CEX-DEX arbitrage.

There are a few possibilities in which hooks can improve LP profitability . One method is the internalization of MEV as mentioned above, especially for CEX-DEX arbitrage which often happens at the top of the block. Roughly 60% of arbitrage opportunities (by revenue) are due to CEX-DEX arbitrage, so this could potentially be a large boost in revenue for liquidity providers if internalized. In addition, liquidity pool deployers will be able to implement dynamic fees, such as those based on a volatility oracle, which would compensate liquidity providers by  mimicking the increased spread on a CLOB from market makers during periods of heightened volatility. Importantly, LVR scales linearly with the square of price volatility, and thus a dynamic fee based on price volatility will likely be very beneficial for liquidity providers. Lastly, the donate() function allows users, integrators, and hooks to directly pay in-range liquidity providers in either or both of the tokens of the pool, allowing deployers to incentivize a certain specific set of liquidity provision behavior. Below is a diagram outlining a dynamic fee.

Implications

Platform as a Service

With the introduction of hooks, Uniswap V4 has likely killed many new AMM-related projects by providing the benefits of a single liquidity hub and Uniswap’s existing liquidity moat along with its brand, while taking the best of many AMMs and packaging it into one product for developers with full customizability. For example, dynamic fees from Trader Joe, internalized MEV from Skip protocol, singleton contract from Crocswap and Balancer, custom orders from Dexible, and Balancer providing out-of-range liquidity into lending protocols are all features that one can now incorporate to some extent into their liquidity pools.

Uniswap has evolved from a spot DEX to a platform that enables other protocols to launch deeply customized liquidity pools, effectively becoming a spot DEX launchpad rather than a spot liquidity pool launchpad. Uniswap has taken the same path as much of web2, where everything eventually becomes a platform or a marketplace. That said, a new DEX that wants full customizability, especially with regards to MEV value capture through custom transaction ordering, or offering other types of traded products such as options or perps will still likely choose to launch their own protocol or appchain/rollapp.

An exciting area that one should look forward to is the combination of protocol-owned-liquidity (POL) and hooks, which should theoretically enable a protocol to have much more control over its onchain liquidity. For example, using withdrawal fees and the ability to donate to liquidity providers, a protocol could easily incentivize buy or sell walls for their native tokens or incentivize liquidity within a specific range e.g. donate more fees to liquidity providers within 5% of the current liquidity pool price.

Sophistication

During the transition from Uniswap V2 to Uniswap V3, one could see that liquidity provision became a significantly more sophisticated activity. Concentrated liquidity introduced new possibilities such as “limit orders” along with amplified impermanent loss. However, it also enabled a new class of products that build on top of Uniswap V3 concentrated liquidity, such as Infinity Pools offering “unlimited” leverage and Panoptic offering options.

With Uniswap V4, liquidity providers will likely become even more sophisticated, and professional liquidity provision will likely be the main method in which liquidity is provided. One example of this already being true is that in every single Uniswap V3 pool, <8% of wallet addresses provide >80% of liquidity. One further possibility of this is that there may be professional hook makers that make hooks tailored to passive LPs (normally retail) instead of active LPs (normally more sophisticated participants). By doing so, they’ll likely charge an extra fee for providing that service. Similarly, DEX aggregators that source liquidity from Uniswap will likely have to build a new routing engine that finds the best path across different Uniswap V4 pools, each with its own hooks and execution logic. This will likely be a significant headache for DEX aggregators, as it will be exponentially harder compared to Uniswap V3 to simulate the effect of hooks that interact with each other across multiple liquidity pools for a complex swap.

Final Thoughts

V4 is a significant upgrade for Uniswap, especially in a rapidly evolving crypto landscape where new exchanges, regardless of spot or derivatives, are launching as appchains/rollapps with much better expressivity for value capture. Throughout the past year, MEV has come to the forefront as an issue plaguing DeFi, especially for passive liquidity providers in AMMs who do not discriminate between toxic and uninformed flow. In addition, new spot DEX innovations such as Trader Joe’s volatility fee and Curve’s new iteration of tricrypto contracts, and its V2 AMM stand to threaten Uniswap’s market share. Ultimately, increased LP profitability has to come from someone given that it’s a zero-sum game, namely from swappers. But hooks will allow liquidity pool deployers to distinguish between arbitrageurs who are normally a source of toxic flow, and normal swappers who normally provided uninformed non-toxic flow. Overall, I would expect hooks to result in more fees for liquidity providers, but specifically weighted to fee generation from “toxic” participants.

Uniswap V4 should further bolster innovation within the protocol and allow it to compete with other DEXs by enabling features that were previously not possible. Importantly, with hooks acting as a tool for developers, Uniswap has smartly outsourced all the work in developing all these new features rather than relying on their own efforts. Developers will likely be eager to build creative solutions to tackle a wide range of issues relevant to spot DEXs across the EVM landscape. The space for hook design is a wide-open playing field, and I for one am extremely excited to see the innovative new mechanisms that developers create around hooks.