Hooks
Hooks are optional policy checks attached to an EVK vault. They let a vault apply additional rules to selected operations—such as deposit, withdraw, transfer, borrow, repay, or liquidation—without changing the vault's core accounting logic. Common uses include access control, emergency pauses, exposure limits, and other market-specific invariants.
A vault's hook configuration contains a hook target contract and a bitfield identifying the hooked operations. When a selected operation runs, the vault calls the hook target with the operation's calldata and caller context. If the hook returns successfully, the vault continues; if it reverts, the entire operation reverts. Operations not selected in the bitfield bypass the hook. A separate vault-status hook can check post-transaction conditions when the EVC completes a batch.
The hook target becomes part of the vault's security and availability boundary. Users and integrators should review which operations are hooked, the target's code and privileged roles, whether it can be upgraded or paused, and whether a failure could block repayments, withdrawals, or liquidations.
Common patterns
Restrict selected actions to approved users, institutions, market makers, or borrowers with an assigned credit line.
A hook can enforce an onchain allowlist or credential state, but it does not itself verify identity or establish legal eligibility.
Block risky operations during an oracle incident, liquidity stress event, exploit response, or asset-specific disruption.
Design pauses narrowly when possible so de-risking actions, such as repay, can remain available.
Run a post-condition check at vault status time to prevent utilization, exposure, or concentration from moving beyond a configured bound.
Useful for utilization ceilings, per-account limits, issuer exposure, or collateral-count limits.
Reject transactions that would create positions too small to monitor, repay, or liquidate economically.
Avoid broad rules that accidentally block repayments, liquidations, or account cleanup flows.
For tokenized asset markets, hooks can enforce specified onchain conditions supplied by an allowlist, credential contract, issuer, or other system.
Whether the condition source satisfies KYC, KYB, sanctions, accreditation, jurisdiction, issuer, or transfer-agent requirements depends on the offchain process and responsible parties. A hook does not itself establish legal or regulatory compliance.
Designing hook policies
Hook policies should be specific about which operation they control and what happens when the policy fails. Common patterns include:
- Deposit-only restrictions: allow anyone to withdraw or repay, but restrict new deposits or borrows to approved accounts.
- Borrow restrictions: allow public supply while limiting debt creation to approved borrowers or configured credit lines.
- Transfer restrictions: restrict vault-share transfers when the share token represents exposure to a permissioned or RWA-backed product.
- Status-check restrictions: enforce post-transaction invariants such as utilization ceilings, exposure limits, or per-account concentration limits.
- Emergency restrictions: temporarily block risky actions while allowing de-risking actions such as repay or withdraw where appropriate.
Operators should test hooks against normal user flows, liquidations, EVC batches, sub-accounts, and integrator assumptions. A hook that is too broad can accidentally block required actions or make a vault behave differently from a standard ERC-4626 integration.
Implementation details
When a hooked operation runs, the vault calls the hook target with the same msg.data and trailing caller context. Ordinary operation hooks receive the EVC-authenticated caller; the final vault-status hook receives address(evc) and therefore carries no authenticated-account identity in that trailer. The hook target must satisfy IHookTarget.isHookTarget(); it can handle selected selectors in explicit functions or a fallback and return successfully or revert. It does not need to implement the full vault interface.
For more detailed information about the implementation and examples, please refer to the EVK Periphery repository.