Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to 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 checks that the contract is coded to be a hook target. Depending on the use case, isHookTarget() can be further strengthened by checking whether the calling address is a proxy deployed by a 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
  • Implementing KYB or entity-level eligibility requirements
  • Enforcing allowlists for permissioned or RWA-backed vaults
  • Creating permissioned vaults for institutional users

Access-control hooks are commonly used when eligibility is determined offchain and then published onchain through roles, allowlists, credential registries, or a custom policy contract. The hook should check the EVC-authenticated account appended to calldata, not only msg.sender, because vault operations may be routed through EVC batches, operators, or integration contracts.

Circuit breakers

Hooks can be used as vault-level circuit breakers for selected operations. A circuit-breaker hook can revert when a configured condition is active, such as:

  • Pausing new deposits or borrows during oracle, liquidity, or asset incidents
  • Blocking transfers of vault shares during an issuer or transfer-agent event
  • Disabling flash loans or other high-risk actions during an exploit response
  • Enforcing utilization, exposure, or concentration ceilings during status checks
  • Allowing de-risking actions such as repay or withdraw while blocking actions that increase exposure

Design circuit breakers narrowly. Broad pauses can protect against some incidents, but they can also interrupt normal operations, integrations, liquidations, or user exits if they are applied to the wrong operation set.

Compliance and RWA controls

For tokenized asset and RWA markets, hooks can encode operation-level rules that match the vault's eligibility and transfer assumptions. Common examples include:

  • Requiring KYC/KYB approval before deposit, mint, borrow, or transfer
  • Checking jurisdiction, sanctions, accreditation, investor-type, or entity-status registries
  • Enforcing per-account exposure limits or minimum position sizes
  • Restricting vault-share transfers to approved recipients
  • Blocking new exposure when the underlying asset, issuer, custodian, oracle, or redemption process is paused

Hooks gate only selected hooked EVK operations using configured onchain conditions. They do not by themselves perform legal review, identity verification, KYC/KYB, sanctions screening, issuer administration, transfer-agent processing, determine legal eligibility, or make a vault or market compliant. Those outcomes depend on external data and processes, governance, and the exact operations covered. Document policy sources, stale-data and provider failures, upgrades, bypasses, privileged roles, revocation, and emergency behavior before launching a permissioned or RWA-related vault.

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
    • Block 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
    • Set debt floors so liquidations are more likely to be economically viable
    • 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
    • Hooks do not cover operations outside the configured bitfield, and some operations may not be hookable
    • A reverting, unavailable, or gas-intensive hook can deny service to covered operations, including de-risking or liquidation paths if configured carelessly
  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