Risk Parameterization & Controls

V2 expands the toolkit Gauntlet uses to manage vault risk well beyond V1's per-market parameters. The result is more precise exposure management, with stronger safety and operational controls needed for institutional and compliant deployments.

Multidimensional Risk IDs

V1 risk parameters were applied at the market level, with one set of caps per market. V2 introduces Risk IDs: shared risk factors that can apply across multiple markets and adapters simultaneously.

A Risk ID can correspond to:

• A specific market (V1-style)

• A collateral asset (e.g., cap total wstETH exposure across every market that uses it)

• An oracle source (e.g., cap total exposure to a specific price feed across all markets that rely on it)

• A protocol (e.g., cap total exposure to a specific lending protocol via adapters)

• A specific market configuration (LLTV band, IRM, etc.)

This is a meaningful operational change. In V1, if five different markets used the same oracle, caps had to be set on each market individually and the vault's aggregate oracle exposure was a sum tracked off-chain. In V2, a single Risk ID can cap the total oracle exposure across every market that uses it, with limits enforced on-chain automatically.

Each Risk ID supports both absolute caps (a fixed amount in the vault's underlying asset) and relative caps (a percentage of total vault assets).

Per-Function Timelocks

V2 vaults configure timelocks on a per-function basis rather than a single vault-wide timelock. High-impact actions (such as enabling new adapters, changing fees, or removing the Sentinel) can carry longer timelocks than lower-impact actions, without slowing down routine operations.

Timelocks themselves cannot be decreased without going through the current timelock duration, which prevents a compromised Curator from rapidly shrinking the safety window before taking other actions.

Sentinel Veto Authority

Any timelocked Curator action can be revoked by the Sentinel before its timelock expires. This pairs with the Sentinel's broader safety capabilities (see "Roles in V2 Vaults") to provide a meaningful check on Curator activity.

Abdication

The Curator can permanently abdicate specific timelocked function selectors, making those configuration functions impossible to call in the future. For example, a vault can abdicate gate setter functions to permanently preserve permissionless access, or abdicate adapter-registry changes to constrain future adapter additions.

Abdication is a trust-hardening primitive. It allows a vault to credibly commit to suppliers that certain risk-expanding actions can never be taken, regardless of who holds the Curator role in the future. This is particularly relevant for institutional suppliers who require strong, code-enforced rules about a vault's risk envelope.

Onchain Permissions: Gates and Allowlists

V2 vaults can be deployed permissioned or non-permissioned. Permissioned vaults can implement access controls via gate contracts at the vault level. This enables vault operators to deploy a broader range of access models, including private or restricted-access products, without requiring suppliers to interact with a separate front-end or wrapper contract.