> For the complete documentation index, see [llms.txt](https://vaultbook.gauntlet.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://vaultbook.gauntlet.xyz/vaults/morpho-vaults/v2-vaults/risk-parameterization-and-controls.md). # 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://vaultbook.gauntlet.xyz/vaults/morpho-vaults/v2-vaults/risk-parameterization-and-controls.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.