Skip to main content
Hooks are extension points in the Aera V3 protocol that allow custom logic to run at specific moments during vault operations — without modifying the core vault contracts. When a guardian submits operations, deposits occur, or tokens transfer, hooks can intercept these events to enforce constraints, calculate fees, validate parameters, or perform any other custom logic. This is how Gauntlet vaults enforce slippage limits, position boundaries, and transfer restrictions while keeping the underlying vault contracts generic and reusable. Hooks are configured by the vault owner and execute automatically as part of the vault’s normal operation flow. The guardian does not choose which hooks run — the hooks are part of the vault’s on-chain configuration and apply uniformly to all operations.

​
Hook Types

Aera V3 defines several hook interfaces that cover different vault lifecycle points: Submit hooks run before and after an entire guardian submission batch. The vault owner configures these via setSubmitHooks, specifying a beforeSubmit and afterSubmit hook contract. Submit hooks operate on the full batch of operations and are useful for batch-level accounting, aggregate position checks, or state snapshots. Operation hooks run during individual operations within a submission batch. These are encoded in the guardian’s Merkle tree alongside the operation itself:
  • Pre-hooks execute before the operation’s target call. They typically validate calldata parameters — for example, a Uniswap swap pre-hook might consult the OracleRegistry to enforce on-chain slippage bounds, ensuring the swap’s minimum output is within an acceptable range of the oracle price.
  • Post-hooks execute after the operation completes. They verify post-conditions like ensuring no residual token approvals remain or confirming that expected token balances changed as intended.
Transfer hooks (IBeforeTransferHook) run before token transfers within multi-depositor vaults. These can enforce transfer restrictions, blocklists, or compliance requirements on vault unit transfers between addresses.

​
Execution Flow

When a guardian submits a batch of operations to a Gauntlet vault, hooks execute at multiple points in the pipeline: The execution order is deterministic:
  1. beforeSubmit hook fires once for the entire batch
  2. For each operation: pre-hook, Merkle verification, execution, post-hook
  3. afterSubmit hook fires once after all operations complete
If any hook reverts, the entire submission transaction reverts. This ensures that hooks act as hard constraints — a vault cannot bypass a failing hook check.

​
Hook Composition

Hooks in Aera V3 can be composed and chained together. A hook contract can internally delegate to other hook contracts, building a pipeline of validation and transformation logic. This composition pattern allows Gauntlet to layer multiple independent concerns into a single hook configuration:
  • A submit hook might first check aggregate position limits, then update a fee accounting snapshot, then emit events for off-chain monitoring — each implemented as a separate internal hook in a composed pipeline.
  • An operation pre-hook might chain an oracle price check with a calldata parameter extraction step, where the first hook fetches the current price and the second validates that the operation’s parameters are within bounds.
The vault owner can also use configurable hooks — hook contracts that accept configuration parameters (stored in the Merkle tree leaves) rather than having behavior hardcoded. This means the same hook contract can enforce different slippage bounds for different operations or different position limits for different assets, configured per-guardian through the Merkle tree.

​
Common Use Cases

Hooks enable a range of vault behaviors without requiring changes to the core Aera V3 contracts: Slippage enforcement. Pre-hooks on swap operations consult the OracleRegistry for current asset prices and verify that the swap’s minimum output falls within acceptable bounds. This protects vault assets from sandwich attacks and excessive slippage during guardian-submitted trades. Position limits. Submit hooks or post-hooks can check that the vault’s exposure to any single protocol, asset, or chain stays within defined limits after an operation batch completes. Transfer restrictions. Transfer hooks on multi-depositor vaults can enforce compliance rules, blocklists, or lock-up periods on vault unit transfers between addresses. Fee calculation. Post-submit hooks can snapshot vault state for fee calculation, ensuring that fee accrual reflects actual operations rather than being manipulated through timing. Approval cleanup. Post-hooks verify that no ERC-20 token approvals remain after operations complete, enforcing the zero-approval invariant that protects vault assets between guardian submissions.