> 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/fr/vaults/morpho-vaults/v2-vaults/risk-parameterization-and-controls.md). # Paramétrage des risques et contrôles V2 étend la boîte à outils que Gauntlet utilise pour gérer le risque des vaults bien au-delà des paramètres par marché de V1. Le résultat est une gestion de l'exposition plus précise, avec des contrôles de sécurité et opérationnels plus stricts, nécessaires pour des déploiements institutionnels et conformes. ### Identifiants de risque multidimensionnels Les paramètres de risque de V1 étaient appliqués au niveau du marché, avec un ensemble de plafonds par marché. V2 introduit les Risk IDs : des facteurs de risque partagés qui peuvent s'appliquer simultanément à plusieurs marchés et adaptateurs. Un Risk ID peut correspondre à : * Un marché spécifique (style V1) * Un actif de collatéral (par ex., plafonner l'exposition totale au wstETH sur tous les marchés qui l'utilisent) * Une source d'oracle (par ex., plafonner l'exposition totale à un flux de prix spécifique sur tous les marchés qui en dépendent) * Un protocole (par ex., plafonner l'exposition totale à un protocole de prêt spécifique via des adaptateurs) * Une configuration de marché spécifique (bande LLTV, IRM, etc.) Il s'agit d'un changement opérationnel significatif. Dans V1, si cinq marchés différents utilisaient le même oracle, les plafonds devaient être définis individuellement sur chaque marché et l'exposition agrégée du vaults à l'oracle était une somme suivie hors chaîne. Dans V2, un seul Risk ID peut plafonner l'exposition totale à l'oracle sur tous les marchés qui l'utilisent, avec des limites appliquées automatiquement on-chain. Chaque Risk ID prend en charge à la fois des plafonds absolus (un montant fixe dans l'actif sous-jacent du vaults) et des plafonds relatifs (un pourcentage des actifs totaux du vaults). ### Verrous temporels par fonction Les vaults V2 configurent les verrous temporels par fonction plutôt qu'avec un seul verrou temporel à l'échelle du vaults. Les actions à fort impact (comme l'activation de nouveaux adaptateurs, la modification des frais ou la suppression du Sentinel) peuvent avoir des verrous temporels plus longs que les actions à impact moindre, sans ralentir les opérations courantes. Les verrous temporels eux-mêmes ne peuvent pas être réduits sans passer par la durée actuelle du verrou temporel, ce qui empêche un Curator compromis de réduire rapidement la fenêtre de sécurité avant d'entreprendre d'autres actions. ### Pouvoir de veto du Sentinel Toute action du Curator soumise à un verrou temporel peut être révoquée par le Sentinel avant l'expiration de son verrou temporel. Cela s'associe aux capacités de sécurité plus larges du Sentinel (voir « Rôles dans les vaults V2 ») pour offrir un contrôle significatif sur l'activité du Curator. ### Abdication Le Curator peut abdiquer de façon permanente des sélecteurs de fonctions spécifiques soumis à un verrou temporel, rendant ces fonctions de configuration impossibles à appeler à l'avenir. Par exemple, un vault peut abdiquer les fonctions de définition de gate afin de préserver de manière permanente un accès sans permission, ou abdiquer les changements de registre d'adaptateurs pour restreindre les ajouts futurs d'adaptateurs. L'abdication est un primitive de renforcement de la confiance. Elle permet à un vault de s'engager de manière crédible auprès des fournisseurs sur le fait que certaines actions augmentant le risque ne pourront jamais être prises, quelle que soit la personne qui détienne le rôle de Curator à l'avenir. Cela est particulièrement pertinent pour les fournisseurs institutionnels qui exigent des règles fortes, imposées par le code, concernant l'enveloppe de risque d'un vaults. ### Autorisations on-chain : Gates et listes d'autorisation Les vaults V2 peuvent être déployés avec ou sans permissions. Les vaults avec permissions peuvent implémenter des contrôles d'accès via des contrats gate au niveau du vaults. Cela permet aux opérateurs de vaults de déployer une gamme plus large de modèles d'accès, y compris des produits privés ou à accès restreint, sans obliger les fournisseurs à interagir avec un front-end distinct ou un contrat enveloppe. --- # 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/fr/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.