Una cosa que me resulta interesante sobre el concurso de seguridad de febrero de 2025 de TermMax es el tamaño del alcance revisado: 5.816 líneas de código (LOC).
Para TermMax, un protocolo descentralizado de préstamo y préstamo con tasa fija, esa cantidad de código es un volumen significativo para poner bajo revisión. Pero, solo con el número, se sabe más sobre cuánto código se incluyó que sobre dónde se concentró realmente el peso de la seguridad dentro de ese alcance.
Esas 5.816 LOC cubrieron lógicas muy distintas, incluyendo funcionalidades de mercado, órdenes, router y bóveda. Contar líneas trata a todas por igual. Económicamente, no necesariamente tienen un peso equivalente.
Un pequeño fragmento de código puede controlar el movimiento de fondos, los permisos, el precio o la contabilidad. Un componente mucho más grande puede influir mucho menos de forma directa en el estado económico.
Lo que aún no sé es cuánta de la verdadera superficie de seguridad de TermMax se concentró en una parte relativamente pequeña de ese alcance revisado.
La evidencia más sólida sería un mapeo claro entre la revisión y las transiciones de estado de mayor consecuencia de TermMax: los lugares donde un pequeño error de implementación podría producir un gran resultado económico.
Eso cambia la forma en que interpretaría el alcance.
La pregunta más útil no es cuántas líneas había dentro del límite de la auditoría, sino cuánta autoridad económica controlaban esas líneas revisadas.
Una revisión de 5.816 LOC puede ser amplia en volumen de código sin decirme si esa misma amplitud existía en las partes de TermMax donde las fallas importan más.
La cuestión es si la revisión de TermMax fue amplia solo por conteo de código, o también amplia en las partes del sistema capaces de cambiar el estado económico.
Estoy observando cómo TermMax mapea la cobertura de seguridad en el movimiento crítico de fondos, permisos, precios, contabilidad y las invariantes que los protegen.
@TermMax #TermMax
$PIEVERSE
Para TermMax, un protocolo descentralizado de préstamo y préstamo con tasa fija, esa cantidad de código es un volumen significativo para poner bajo revisión. Pero, solo con el número, se sabe más sobre cuánto código se incluyó que sobre dónde se concentró realmente el peso de la seguridad dentro de ese alcance.
Esas 5.816 LOC cubrieron lógicas muy distintas, incluyendo funcionalidades de mercado, órdenes, router y bóveda. Contar líneas trata a todas por igual. Económicamente, no necesariamente tienen un peso equivalente.
Un pequeño fragmento de código puede controlar el movimiento de fondos, los permisos, el precio o la contabilidad. Un componente mucho más grande puede influir mucho menos de forma directa en el estado económico.
Lo que aún no sé es cuánta de la verdadera superficie de seguridad de TermMax se concentró en una parte relativamente pequeña de ese alcance revisado.
La evidencia más sólida sería un mapeo claro entre la revisión y las transiciones de estado de mayor consecuencia de TermMax: los lugares donde un pequeño error de implementación podría producir un gran resultado económico.
Eso cambia la forma en que interpretaría el alcance.
La pregunta más útil no es cuántas líneas había dentro del límite de la auditoría, sino cuánta autoridad económica controlaban esas líneas revisadas.
Una revisión de 5.816 LOC puede ser amplia en volumen de código sin decirme si esa misma amplitud existía en las partes de TermMax donde las fallas importan más.
La cuestión es si la revisión de TermMax fue amplia solo por conteo de código, o también amplia en las partes del sistema capaces de cambiar el estado económico.
Estoy observando cómo TermMax mapea la cobertura de seguridad en el movimiento crítico de fondos, permisos, precios, contabilidad y las invariantes que los protegen.
@TermMax #TermMax
$PIEVERSE