En consultant hier soir la documentation de sécurité TermMax, j’ai seulement alors remarqué que les paramètres clés modifiés ne prennent pas effet immédiatement. Les réglages du Vault de TermMax suivent un enchaînement en trois étapes : Submit → Wait → Accept. CURATOR soumet les changements, GUARDIAN peut les examiner ou les annuler pendant la période d’attente, et le Vault Owner conserve le droit de surveillance. L’attente par défaut est de 1 jour, configurable entre 1 et 30 jours.
Je le vois comme un bon de modification de transaction : proposition mise en archive, contrôle de la sécurité effectué pendant la garde, et seulement à l’issue du chronomètre l’enregistrement est autorisé. Les changements provenant de la source d’un oracle ne peuvent être soumis et acceptés que par DEFAULT_ADMIN_ROLE, et sont mis à jour séparément par actif ; lorsque la source principale devient invalide, il est possible de basculer immédiatement vers la source de secours. Cette conception ajoute une fenêtre d’observation et fait aussi entrer la répartition des trois types de privilèges dans les vérifications de sécurité.
Le time-lock ne fait que retarder la configuration ou le remplacement de la source de données : il ne peut pas prouver que le prix actuel est exact, ni remplacer une surveillance on-chain. Mon ordre de vérification est : d’abord examiner la file d’exécution et le temps restant, puis vérifier les journaux d’annulation et les adresses des rôles, enfin comparer l’écart entre les sources principales et de secours ainsi que l’état du basculement. Si GUARDIAN n’examine pas sur le long terme et que les clés de gestion se concentrent, attendre un jour ne fait que repousser d’un jour la concrétisation du risque. L’architecture fournit un frein : celui qui observe le tableau de bord doit aussi répondre par les enregistrements d’exécution.@TermMax
#termmax
Je le vois comme un bon de modification de transaction : proposition mise en archive, contrôle de la sécurité effectué pendant la garde, et seulement à l’issue du chronomètre l’enregistrement est autorisé. Les changements provenant de la source d’un oracle ne peuvent être soumis et acceptés que par DEFAULT_ADMIN_ROLE, et sont mis à jour séparément par actif ; lorsque la source principale devient invalide, il est possible de basculer immédiatement vers la source de secours. Cette conception ajoute une fenêtre d’observation et fait aussi entrer la répartition des trois types de privilèges dans les vérifications de sécurité.
Le time-lock ne fait que retarder la configuration ou le remplacement de la source de données : il ne peut pas prouver que le prix actuel est exact, ni remplacer une surveillance on-chain. Mon ordre de vérification est : d’abord examiner la file d’exécution et le temps restant, puis vérifier les journaux d’annulation et les adresses des rôles, enfin comparer l’écart entre les sources principales et de secours ainsi que l’état du basculement. Si GUARDIAN n’examine pas sur le long terme et que les clés de gestion se concentrent, attendre un jour ne fait que repousser d’un jour la concrétisation du risque. L’architecture fournit un frein : celui qui observe le tableau de bord doit aussi répondre par les enregistrements d’exécution.@TermMax
#termmax