Build secure Uniswap V4 Hooks in AVS

Uniswap V4 introduced a novel "hook" mechanism, allowing custom functionality to be injected into the exchange process, while EigenLayer's AVS offers a groundbreaking way to extend Ethereum's validator set to secure new services.

Before delving into the article, special thanks to @ishaan0x (EigenLayer) and @0xTechDean (Othentic) for their review and feedback.

Uniswap V4 hooks x AVS examples

The combination of Uniswap V4 hooks with EigenLayer's Actively Validated Services (AVS) is sparking new possibilities in the Ethereum ecosystem. By leveraging EigenLayer’s decentralized node operators, complex off-chain computations can be performed to enhance Uniswap hooks’ functionality.

Here are some ideas on how the two technologies could work together based on these articles (1, 2) by EigenLayer’s team:

• Coincidence of Wants Matching: AVS can run a matching engine that facilitates direct trade matches between buyers and sellers, reducing fees and minimizing gas usage by settling only necessary transactions on-chain.
• Dark Pool Trades: AVS could enable private, large-scale trades in "dark pools" by matching orders off-chain, reducing market impact and slippage for significant orders.
• Dynamic Fee Adjustments: AVS could pull real-time market data to adjust Uniswap LP fees dynamically during periods of high volatility, protecting liquidity providers from significant losses.
• Automated LP Management for Liquid Staking Tokens: AVS operators could automate liquidity management for pools containing yield-bearing tokens, adjusting LP positions automatically based on yield changes.
• Auctions for Loss Versus Rebalancing (LVR): AVS could run auctions to determine who gets the first transaction in a block, helping LPs mitigate losses due to price discrepancies between off-chain and on-chain markets.
• Cross-Chain Price Aggregation: Leverage AVS for aggregating prices from multiple chains, enhancing accuracy and reducing arbitrage opportunities.

MEV Protection using hook and AVS - Angstrom by Sorella

Above are only some of the examples of how Uniswap V4 hooks and AVSs may coexist and cooperate. Let’s have a look at an existing example - Angstrom by Sorella Labs.

Angstrom, a Uniswap V4 hook, protects liquidity providers from arbitrage by enabling decentralized auctions for transaction sequencing using Application-Specific Sequencing (ASS), a concept introduced by Sorella. Through this setup, Uniswap pools use an AVS to reach consensus on the auction order for swaps, particularly for the first transaction.

Here is the flow:

1. Users send their signed limit orders to a private pool.
2. Arbitrageurs bid to be the first transaction. The highest bid wins and its amount is subsequently distributed, pro rata, to the underlying LPs in the range of the swap.
3. A network of nodes runs a parallel consensus to Ethereum, determining which arbitrageur wins and what transactions to execute - here comes the Actively Validated Service (AVS).
4. Valid limit orders are then bundled with the AMM liquidity at a uniform clearing price. This bundle is sent to Ethereum's mempool, where it is included in blocks after covering the base fee.

By doing so, Angstrom enhances the precision and fairness of the transaction process, reducing the impact of Maximal Extractable Value (MEV) and allowing users to have greater control and transparency over their transactions.

What are the most common security threats coming from the Hooks?

Based on our research for Uniswap Foundation on the security threats for Uniswap V4 hooks we have enumerated a bunch of threats that Hook builders must take into account when building one. When integrating Uniswap V4 hooks with Actively Validated Services (AVSs), several security threats must be considered to ensure robust functionality.

Here are some key threats and scenarios that could lead to them:

• Funds Theft: Hooks could be exploited to manipulate or drain liquidity pools. This could be achieved with:
  • Using the wrong sender. Using the sender parameter of hook functions to determine the owner of tokens.
  • Sender impersonation. Impersonating the victim to execute operations in the pool on their behalf.
  • Unauthorized access to hook functions. Lack of protection from calling the hook functions directly by any contract.
  • Unauthorized access to callback. Lack of protection from calling the Pool Operator’s callback function directly by any contract.
• Denial of Service (DoS): A hook could be used to intentionally or unintentionally revert transactions, causing service disruptions. This could be achieved with:
  • Invalid dynamic fee. The calculation of dynamic fee underflows, overflows or the value is over 100%.
  • Hook reinitialization. The reinitialization of the hook through a different pool to break the current state of the hook.
• Bypassing limits: Hooks could be exploited to bypass the business limits arising from the specific use case (e.g. maximum holder’s balance). This could be achieved with:
  • Using the wrong sender. Using the sender parameter of hook functions to determine the address to apply the business limits to.
• Ownership and Access Control Issues: If hooks retain owner permissions, malicious owners could alter hook behavior post-deployment, such as upgrading the hook to redirect funds or modify operational parameters.
• Invalid External Data: Hooks integrated with AVS often rely on external data sources, such as oracles. Manipulated or unreliable data can lead to incorrect pricing or fee calculations, resulting in financial loss or unfair trading conditions. This is specifically a threat coming from AVS which is covered below.

What Are the Most Common Security Threats Associated with Actively Validated Services (AVS)?

Based on our latest security reviews of Actively Validated Services (AVS) and their corresponding frameworks, we have identified several prevalent threats that can compromise the integrity and security of AVS systems:

• Improper Validation of Task Results: Tasks are a critical component of AVSes, executed and validated by operators, with their results often consumed by other parts of the system. If the validation mechanism is flawed, malicious actors can submit invalid tasks, potentially compromising the entire AVS.
• Unauthorized Attesters: Attesters are operators who validate tasks and confirm their correctness. Their votes are crucial for reaching consensus on task validity. If the AVS permits anyone to act as an attester without meeting specific requirements (e.g., staking), the voting system can be manipulated, resulting in the acceptance of invalid tasks.
• Task Replay Attacks: Without mechanisms to prevent the same task from being accepted multiple times, malicious users could submit duplicate tasks and collect rewards repeatedly, depleting the reward pool. A safeguard against such attacks could include penalizing repeated task submissions or simply reverting on the same task data.
• Lack of Attestation Verification: If tasks are accepted without attestations from operators with active assets at stake, anyone could submit tasks that are improperly accepted, undermining the trust and reliability of the system.
• Attestation Power Manipulation: Voting power is generally tied to the assets an attester has at stake, ensuring they have "skin in the game." However, if the synchronization between an operator's stake and their voting power is delayed (e.g., after a stake withdrawal), an operator might retain their voting influence without having assets at risk. This creates a security loophole where votes could be cast without sufficient financial risk.
• Low AVS Stake Levels: AVSes share similar risks with Ethereum’s Proof of Stake (PoS) model or liquidity pools. When the assets staked in an AVS are low, it becomes easier for an attacker to amass the majority of the attestation power (e.g. 66% in case of Othentic), gaining undue control over the system. The risk becomes worthwhile when the potential gains outweigh the amount of funds the attacker risks.
• Lack of Incentives or High Costs: Ensuring scalability and incentivizing operators to participate in an AVS is a key challenge. If the reward mechanisms are unfair, overly risky, or unprofitable, operators may abandon the system, leading to centralization or operational failure.
• Sybil Attacks: Malicious actors could create multiple fake identities to increase their influence within the AVS, skewing task validation results or reaching consensus through fraudulent means.
• Collusion Among Attesters: Groups of attesters may collude to manipulate the voting process, leading to fraudulent task approvals and undermining the decentralized validation mechanism.
• Denial of Service (DoS) Attacks: Overloading the AVS with an excessive number of tasks or requests could disrupt its operation, making it difficult for legitimate tasks to be processed and validated efficiently.
• Smart Contract Vulnerabilities: As many AVSes operate through smart contracts, flaws or bugs in the contract’s code can be exploited, allowing attackers to bypass validation mechanisms, steal funds, or alter task outcomes.
• Oracle Manipulation: If an AVS relies on external data (oracles) to validate tasks, attackers could target and manipulate the oracles, leading to incorrect validations and compromised results.

By addressing these threats, AVS developers and operators can build more robust, secure, and resilient systems, ensuring the continued decentralization and integrity of their services.

How to be safe?

First, prepare a threat model of your project that includes threats coming from both sides, the hook and AVS. If you do not know how to do it, find a security partner. Second, address the threats, both from this article and your threat model.

Consider using existing frameworks that have already implemented the main AVS functionalities and build on top of that. A good example is the Othentic stack that brings a lot of ready to use components implementing AVS functionalities.

Go through our checklist shared below and make sure all is covered.

Last, but not least, don’t forget to audit your hook and AVS.

Checklist for Uniswap V4 Hooks

Checklist for Actively Validated Services

Want to increase the security of your project?

Composable Security 🛡️⛓️ is an elite team of 2 experienced Security Researchers who specialize in (re)staking, AVS and UniswapV4 projects.

Uniswap Foundation grant recipient. Creators of the Smart Contract Security Verification Standard and the first Security Guide for DApps CTOs, Lead Developers, and Security Enthusiasts.

• Ready to increase your security? Let us help you!

Have peace of mind like: Braintrust, Enjin, Tellor, Volmex Finance and many more.