Skip to main content

Hooks and Custom Logic

The Euler Vault Kit (EVK) provides a flexible hooking system that allows vault governors to extend vault functionality or restrict certain operations. This guide explains how hooks work and provides examples of common use cases.

Hook System Overview

Hooks are implemented through a hook configuration that consists of two parameters:

  • The hook target: The address of a contract that implements the hook logic
  • The hooked operations: A bitfield that specifies which operations should trigger the hook

When a hooked operation is invoked, the vault will:

  1. Check if the operation is enabled in the hooked ops bitfield
  2. Call the hook target with the same msg.data that was provided to the vault
  3. Append the EVC-authenticated caller as trailing calldata
  4. Revert the operation if the hook call fails

Hook Target Implementation​

Every hook target contract must implement the isHookTarget() function, which returns a special function selector (magic value). This function serves as a security check to ensure that only contracts specifically coded to be hook target can become one. Depending on a use case, isHookTarget() can be further strenghtened by checking whether the calling address is a proxy deployed the recognized EVault factory. Example implementation can be as follows:

function isHookTarget() external view returns (bytes4) {
    if (eVaultFactory.isProxy(msg.sender)) return this.isHookTarget.selector;
    else return 0;
}

Example Use Cases

Access Control​

The HookTargetAccessControl contract demonstrates how to implement role-based access control for vault operations. This is useful for:

  • Restricting deposits to whitelisted addresses
  • Limiting borrowing to specific users
  • Implementing KYC/AML requirements
  • Creating permissioned vaults for institutional users

Stake Delegation​

The HookTargetStakeDelegator contract was developed specifically for Berachain vaults participating in Proof of Liquidity (POL). It automatically stakes vault shares into Berachain Reward Vaults, enabling:

  • Automatic staking of vault shares into Berachain Reward Vaults
  • Seamless participation in Berachain's POL mechanism
  • Optimization of staking rewards through automated delegation
  • Integration with Berachain's staking infrastructure

Other Use Cases​

  1. Flash Loan Fees

    • Enforce a percentage fee on flash loans
    • Collect fees in any token
    • Scale fees with gas costs

  2. Utilization Caps

    • Prevent vault utilization from exceeding a threshold
    • Implement dynamic caps based on market conditions
    • Protect against high utilization risks

  3. Minimum Debt Sizes

    • Prevent creation of dust positions
    • Ensure positions are profitable to liquidate
    • Reduce gas costs for liquidators

  4. Custom Collateral Restrictions

    • Limit the number of collateral assets
    • Implement custom collateral validation
    • Add additional risk checks

Limitations

  1. ERC-4626 Compliance

    • Some hook configurations may cause the vault to not be fully ERC-4626 compliant
    • The max* functions may be inaccurate with hooks installed

  2. Operation Scope

    • Hooks can only affect operations specified in the hooked ops bitfield
    • Core accounting invariants cannot be broken
    • Some operations may not be hookable

  3. Gas Costs

    • Each hooked operation requires an additional external call
    • Complex hook logic can significantly increase gas costs
    • Consider the impact on user experience