Skip to main content
In the Aera V3 protocol, a guardian is the entity responsible for executing strategy operations on behalf of a vault. Gauntlet operates as the guardian for its vaults, submitting batches of operations — swaps, protocol deposits, withdrawals, fee reports — that are validated against on-chain constraints before execution. The guardian model is designed so that guardians have enough flexibility to execute complex DeFi strategies while being tightly constrained by the protocol to prevent unauthorized actions. This page explains how the guardian model works at the protocol level. For how Gauntlet uses the guardian role to curate and manage vaults, see Curation. For operational details on running a guardian, see the Guardian Guides.

​
Guardian Role

Every Aera V3 vault has an owner and one or more guardians. The owner configures the vault — setting guardian permissions, hook configurations, and pause controls — while the guardian executes the day-to-day strategy operations. The separation is deliberate: the owner defines what actions are possible, and the guardian executes within those bounds. A vault can have multiple guardians, each with its own independent Merkle root defining a distinct set of allowed operations. This enables separation of concerns — for example, one guardian handles yield strategy execution while another handles risk monitoring and can only pause or rebalance. Each guardian’s permissions are scoped independently; compromising one guardian does not grant access to another’s operation set. Guardians interact with vaults primarily through the submit function, which accepts a batch of operations to execute atomically. Each operation in the batch specifies a target contract, calldata, and optional parameters for chaining and callbacks. The protocol validates every operation against the guardian’s Merkle tree before execution. The guardian can also call pause to halt all guardian operations on a vault — an important safety mechanism that allows the guardian to immediately stop activity if a security concern arises. Any guardian on a vault can pause within a single block, without waiting for governance or multisig approval. Only the vault owner (or designated roles) can call unpause to resume operations.

​
Operation Submission

Guardian operations flow through a structured validation pipeline before any on-chain state changes occur. When a guardian calls submit, the following sequence executes:
  1. Submit hooks fire. If the vault has beforeSubmit hooks configured, they run first. These can perform batch-level validation or accounting before any operations execute.
  2. Per-operation validation. For each operation in the batch, the protocol checks the operation against the guardian’s Merkle tree. The Merkle tree encodes which target contracts are allowed, which function selectors can be called, and what calldata constraints apply. Each operation includes a Merkle proof that the vault verifies on-chain.
  3. Operation hooks. Individual operations can trigger pre-hooks (before execution) and post-hooks (after execution). Pre-hooks typically validate calldata parameters — for example, enforcing slippage bounds on a swap by checking prices against the OracleRegistry. Post-hooks verify post-conditions like ensuring no residual token approvals remain.
  4. Execution. The vault executes the validated call against the target DeFi protocol.
  5. Post-submit hooks. After all operations complete, afterSubmit hooks run for batch-level post-processing — fee accounting, position tracking, or state snapshots.
Operations also support chaining, where the output of one operation feeds into the next. This enables multi-step DeFi interactions (approve then swap, deposit then stake) in a single atomic submission. Advanced operations can include native token transfers and register callback listeners for operations that trigger asynchronous responses.

​
On-Chain Constraint Enforcement

All guardian constraints are enforced on-chain at the protocol level — not by off-chain monitoring, governance votes, or advisory frameworks. A guardian operation that violates any constraint reverts in the same transaction, within the same block. There is no window between detection and enforcement. The protocol enforces the following constraints on guardian actions: Merkle tree whitelisting. Every guardian is associated with a Merkle root that encodes the complete set of allowed operations. The vault owner sets this root via setGuardianRoot. A guardian cannot execute any operation that falls outside its Merkle tree — there is no fallback or override. This means the set of contracts a guardian can interact with, the functions it can call, and the parameter ranges it can use are all cryptographically committed to on-chain. Changing the Merkle tree requires a new root to be set by the owner. Hook-enforced invariants. Pre-operation and post-operation hooks validate constraints in real time during execution. Hooks can enforce slippage bounds by checking prices against the OracleRegistry, enforce position concentration limits, validate that portfolio exposures remain within defined ranges, and reject operations that would move the vault outside its risk parameters. Because hooks execute within the same transaction as the guardian’s operations, violations are caught and reverted before any state change takes effect. Zero-approval enforcement. Guardians cannot leave outgoing nonzero ERC-20 token approvals after an operation batch completes. This prevents a compromised guardian from pre-approving tokens for later extraction. Post-operation hooks enforce this constraint. Whitelist validation. Guardians must be registered on the vault’s whitelist contract. Anyone can call checkGuardianWhitelist to verify whether a guardian is still authorized, and the protocol removes guardians that fail the whitelist check. Pause capability. Both the vault owner and any guardian can pause operations within a single block. This dual-pause model means a guardian can immediately halt activity if it detects anomalous conditions, without waiting for governance, multisig coordination, or timelock expiry. Only the owner can unpause. Fee constraints. For vaults using FeeVault, fee accrual is calculated by a dedicated fee calculator contract (DelayedFeeCalculator for single-depositor, PriceAndFeeCalculator for multi-depositor). The guardian or fee recipient can claim accrued fees, but cannot manipulate the fee calculation itself.

​
Callbacks

The Aera V3 protocol supports a callback mechanism that allows guardians to respond to on-chain events during operation execution. When an operation triggers an asynchronous response — for example, a DeFi protocol that executes part of a request in a later transaction — the guardian can register a callback listener as part of the operation submission. Callbacks enable complex multi-step interactions where the guardian needs to react to protocol-specific events. For example, a cross-chain bridge operation might require the guardian to finalize a transfer after a message relay confirms delivery on the destination chain. The callback system is part of the operation chaining infrastructure: when submitting an operation batch, the guardian can specify which operations should listen for callbacks and how the vault should handle the response. This keeps the guardian’s interaction pattern flexible without requiring separate transactions for each step.
Callback handling is an advanced topic relevant to guardian operators. For implementation details, see the Guardian Guides.