Je rassemble la page de sécurité, l’audit du dépôt et les explications sur les permissions associées à @TermMax , et je constate que « audité » n’est finalement qu’une couche très externe. Ce qui détermine réellement comment le système réagit au moment où il faut que quelque chose tourne mal, ce sont quels contrats peuvent être modifiés, qui peut faire une pause et comment les autorisations clés sont contrôlées conjointement.#TermMax
Le dépôt public répertorie actuellement des rapports par étapes d’ABDK, des rapports TMX et des rapports du concours Cantina, et Immunefi mentionne aussi des primes pour des vulnérabilités encore en cours. La documentation indique également une surveillance on-chain 24h/24 et un mécanisme de pause automatique. Ces informations montrent que le projet a mis en place une défense multicouche, mais elles traitent surtout de la détection des problèmes et de la réduction du temps de réponse — sans pour autant garantir que les contrats ne rencontreront plus jamais de problème.
En creusant davantage au niveau des permissions, TermMax confie les actions de gestion critiques à un multisig 4-sur-6, isole les différents marchés entre eux, et les paramètres du Vault comportent un équilibrage via timelock et Guardian. En parallèle, l’officiel précise aussi conserver la capacité d’arrêt d’urgence, et certains composants disposent d’une architecture prévue pour être upgradeable. En d’autres termes, ce système ne garantit pas la sécurité en misant sur « personne ne peut jamais rien contrôler », mais en limitant le risque de point unique grâce à l’isolation, la latence, l’autorisation conjointe à plusieurs et des actions d’urgence.
Sur l’isolation des marchés, je le noterai séparément. Le fait qu’un marché soit déployé de manière indépendante ne signifie pas que des pertes ne surviendront pas ; cela exprime plutôt l’objectif de contenir au maximum la frontière de panne pour qu’elle ne se propage pas aux autres marchés. La conception de la sécurité ne consiste souvent pas à éliminer le risque, mais à réduire d’abord la portée qu’une erreur unique pourrait affecter.
Au contraire, je trouve que c’est plus intéressant que la formule « le code fait loi ». Dans la vraie vie, quand DeFi rencontre une anomalie, il faut toujours répondre à deux questions concrètes : les permissions sont-elles suffisamment rapides, et les frontières sont-elles suffisamment étroites ? Trop lent, et on n’a peut-être pas le temps de stopper et de limiter les dégâts ; trop large, et on risque de transformer le gouvernement (la gouvernance) lui-même en source de risque.
Donc, par la suite, je continuerai à surveiller s’il y a des changements parmi les membres du multisig, la portée des composants upgradeables, les événements de pause et les traces de correctifs après l’audit. Les rapports d’audit prouvent qu’il y a eu une vraie recherche de problèmes ; ce sont les trajectoires de permissions qui me diront comment le système gère concrètement ces problèmes dans la réalité.
Le dépôt public répertorie actuellement des rapports par étapes d’ABDK, des rapports TMX et des rapports du concours Cantina, et Immunefi mentionne aussi des primes pour des vulnérabilités encore en cours. La documentation indique également une surveillance on-chain 24h/24 et un mécanisme de pause automatique. Ces informations montrent que le projet a mis en place une défense multicouche, mais elles traitent surtout de la détection des problèmes et de la réduction du temps de réponse — sans pour autant garantir que les contrats ne rencontreront plus jamais de problème.
En creusant davantage au niveau des permissions, TermMax confie les actions de gestion critiques à un multisig 4-sur-6, isole les différents marchés entre eux, et les paramètres du Vault comportent un équilibrage via timelock et Guardian. En parallèle, l’officiel précise aussi conserver la capacité d’arrêt d’urgence, et certains composants disposent d’une architecture prévue pour être upgradeable. En d’autres termes, ce système ne garantit pas la sécurité en misant sur « personne ne peut jamais rien contrôler », mais en limitant le risque de point unique grâce à l’isolation, la latence, l’autorisation conjointe à plusieurs et des actions d’urgence.
Sur l’isolation des marchés, je le noterai séparément. Le fait qu’un marché soit déployé de manière indépendante ne signifie pas que des pertes ne surviendront pas ; cela exprime plutôt l’objectif de contenir au maximum la frontière de panne pour qu’elle ne se propage pas aux autres marchés. La conception de la sécurité ne consiste souvent pas à éliminer le risque, mais à réduire d’abord la portée qu’une erreur unique pourrait affecter.
Au contraire, je trouve que c’est plus intéressant que la formule « le code fait loi ». Dans la vraie vie, quand DeFi rencontre une anomalie, il faut toujours répondre à deux questions concrètes : les permissions sont-elles suffisamment rapides, et les frontières sont-elles suffisamment étroites ? Trop lent, et on n’a peut-être pas le temps de stopper et de limiter les dégâts ; trop large, et on risque de transformer le gouvernement (la gouvernance) lui-même en source de risque.
Donc, par la suite, je continuerai à surveiller s’il y a des changements parmi les membres du multisig, la portée des composants upgradeables, les événements de pause et les traces de correctifs après l’audit. Les rapports d’audit prouvent qu’il y a eu une vraie recherche de problèmes ; ce sont les trajectoires de permissions qui me diront comment le système gère concrètement ces problèmes dans la réalité.