Request for AVS: Uniswap v4 Hooks

Occasionally, you hear an idea so exciting that you see the future with utter clarity. At Eigen Labs, we’re excited to work with exceptional builders and hear their special insights about the world on a daily basis. We want to share some of ours with you. We’re starting a new series called Request for AVS to showcase how trustless offchain compute and data can change the onchain economy. We hope you join us for v1 😄

Uniswap v4 is the Endgame

Uniswap v1 was a 0 to 1 innovation, bringing atomic swaps onchain.

Uniswap v2 extended v1’s functionalities, enabling us to trade ERC-20s in a single pool and enabling flash loans and oracles.

Uniswap v3 added concentrated liquidity, making LPing up to 4000x more capital efficient. 

But Uniswap v4 is more. Rather than extend the functionalities of prior versions in an opinionated manner, it transitions Uniswap from an AMM to a platform for AMMs. It empowers builders to create any onchain exchange, using hooks to highly customize the trader and liquidity provider experience.

Previously, if builders wanted to innovate on AMM design, they had to build their own exchange, either competing with Uniswap or building on a new chain. But liquidity inherently has network effects, and exchanges are, therefore, a winner-take-all, or at least a winner-take-most game. In the past 24 hours, Uniswap has done 35% of all DeFi spot volume per DeFi Llama. On Ethereum and major L2s, Uniswap’s dominance increases to 62%. 

Builders have to not just win on mechanism design, but attract enough liquidity to provide favorable prices to traders. This separation of liquidity and permissionless innovation has caused many exciting AMM designs to not take off. Uniswap v4 changes this, enabling anyone to tap into Uniswap’s liquidity with their mechanism.

Case Study: Solving Coincidence of Wants with Uniswap v4

To prove that Uniswap v4 is flexible enough to create any exchange, let’s use it to solve a classic problem: coincidence of wants. In a single block, some traders will swap USDC for ETH while others will swap ETH for USDC. With most onchain exchanges, both will trade against the liquidity pool, paying 0.3% in swap fees. Instead, they should swap with each other – saving both of them 0.3%. This is called the coincidence of wants.

We can design a hook to solve for coincidence of wants. Traders will send in orders to Uniswap v4. Rather than immediately getting matched against the pool, a hook can send orders to a matching engine to settle coincidences of wants against each other, which then settles to the overall pool. Traders then receive their desired asset, occasionally paying less in fees.

It’s important to ask: who runs this matching engine? Unfortunately, computing coincidence of wants expends too much gas onchain. We could send our orders to a centralized server. But that defeats the purpose of trading onchain altogether, leading to potential censorship and liveness issues. 

If only there were a way to access trustless offchain compute…

EigenLayer: A Platform for Trustless Offchain Compute and Data

Fortunately, EigenLayer enables trustless offchain compute (and data)! At a high level, EigenLayer is an infrastructure platform that gives you:

1. A decentralized network of node operators,
2. Willing to run your arbitrary node software and
3. Economically aligned to act honestly with your protocol

We call these decentralized networks Actively Validated Services (AVS)!

These operators can do a variety of tasks to boost the capabilities of Uniswap v4 hooks like:

• Run a matching engine (helping in our coincidence of wants example)
• Batch many transactions together 
• Run an auction
• Gain access to real-world information, like
  • Prices (like an oracle)
  • Volatility
  • Stablecoin depegs
  • Liquid staking yields
• (... and more)

By extending offchain compute and data to hooks, EigenLayer adds the missing piece for Uniswap v4 to recreate any onchain exchange.

Ideas to Build with Uniswap v4 Hooks and EigenLayer AVSs

The design space with v4 hooks and AVSs is endless! We will share 6 ideas briefly, but if you’re interested in building any, please reach out to us! We’d love to chat more :)

Idea: solve coincidence of wants to reduce taker fees

This is the example we talked about!

1. Taker flow will exist in both directions (buy/sell) for any given pool.
2. AVS operators can match these orders, enabling swappers to pay less fees and incur less price impact.

Idea: dynamic fees for periods of high volatility

1. Uniswap LPs fare worse during times of high volatility. 
2. To adjust, AVS operators can automatically increase fees during periods of high volatility. Operators can pull volatility data from a trusted external volatility source or calculate it themselves. 

Idea: automatically adjust LP positions for LST pools

1. Uniswap LPs face extra slippage from the natural yield-bearing nature of LSTs when LPing yield-bearing tokens (like stETH-ETH or rETH-USDC).
2. AVS operators could automatically read the yield from these liquid staking positions and move all LP positions up the curve by a constant amount.

Idea: dark pools

1. Dark pools enable people to trade large orders privately without affecting the broader market. In traditional finance, people can send a private order to an exchange that is matched against other takers at the mid-market price (halfway between best bid and ask).
2. Traders can send their orders to AVS operators, who would share and match market orders together at the price of the most liquid exchange, predefined for that pair.

Idea: run an auction to reduce Loss Versus Rebalancing (LVR)

1. LVR exists because of the price discrepancy between continuous offchain exchanges (Binance) and onchain exchanges (which only trade every block, 12 seconds for Ethereum mainnet). 
2. AVS operators can run an auction to determine who gets the first transaction in a block. 
3. The auction proceeds would go to LPs, instead of validators as they would with traditional MEV auctions. Proceeds can also go to swappers, to help with optimal price execution, thus driving more volume on chain

Idea: run a shared state across all chains

1. AMM pools can have different prices across chains. This leads to less efficient price discovery and more arbitrage on smaller chains.
2. Have operators maintain an aggregate state of capital. When traders send orders, they trade against this combined pool and receive less slippage. 

Conclusion

With the biggest decentralized exchange transitioning into a platform, there’s never been a better time to build onchain. Create any exchange with offchain compute and data as a Uniswap v4 hook AVS. If you’re interested in building any of these (or any other AVS), please dm on twitter @ishaan0x. Let’s chat :)