Anoche, al revisar los documentos de seguridad de TermMax, descubrí que los parámetros clave que se modifican no entran en vigor de inmediato. La configuración de Vault de TermMax consta de tres pasos: Submit → Wait → Accept. En primer lugar, CURATOR envía los cambios; durante el período de espera, GUARDIAN puede revisarlos o revocarlos; y el Owner del Vault conserva el derecho de supervisión. De forma predeterminada, la espera es de 1 día y se puede configurar dentro de un rango de 1 a 30 días.
Yo lo veo como una orden de cambio para una institución de trading: la propuesta se sella, la supervisión de riesgo en guardia la revalida, y solo al terminar el conteo se permite el registro en la bóveda. Los cambios en la fuente del oráculo solo los puede enviar y aceptar DEFAULT_ADMIN_ROLE, y se actualizan por activo; cuando la fuente principal falla, se puede cambiar inmediatamente a la fuente de respaldo. Este diseño amplía la ventana de observación y también hace que la distribución de las tres clases de permisos entre en controles de seguridad.
El time lock solo retrasa la configuración o el cambio de fuentes de datos; no puede probar que el precio actual sea preciso ni sustituir el monitoreo on-chain. Mi orden de verificación es: primero mirar la cola de ejecución y el tiempo restante, luego revisar los registros de revocación y las direcciones de roles, y al final comparar la desviación entre la fuente principal y la de respaldo, así como el estado del cambio. Si GUARDIAN no revisa durante mucho tiempo y las claves de gestión están concentradas, esperar un día solo hace que el riesgo se materialice un día más tarde. La arquitectura pone el freno, pero quién está vigilando el panel sigue teniendo que responder con el registro operativo.@TermMax
#termmax
Yo lo veo como una orden de cambio para una institución de trading: la propuesta se sella, la supervisión de riesgo en guardia la revalida, y solo al terminar el conteo se permite el registro en la bóveda. Los cambios en la fuente del oráculo solo los puede enviar y aceptar DEFAULT_ADMIN_ROLE, y se actualizan por activo; cuando la fuente principal falla, se puede cambiar inmediatamente a la fuente de respaldo. Este diseño amplía la ventana de observación y también hace que la distribución de las tres clases de permisos entre en controles de seguridad.
El time lock solo retrasa la configuración o el cambio de fuentes de datos; no puede probar que el precio actual sea preciso ni sustituir el monitoreo on-chain. Mi orden de verificación es: primero mirar la cola de ejecución y el tiempo restante, luego revisar los registros de revocación y las direcciones de roles, y al final comparar la desviación entre la fuente principal y la de respaldo, así como el estado del cambio. Si GUARDIAN no revisa durante mucho tiempo y las claves de gestión están concentradas, esperar un día solo hace que el riesgo se materialice un día más tarde. La arquitectura pone el freno, pero quién está vigilando el panel sigue teniendo que responder con el registro operativo.@TermMax
#termmax