For the complete documentation index, see llms.txt. This page is also available as Markdown.

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.

Mis à jour

Ce contenu vous a-t-il été utile ?