Hoy revisé el rango de recompensas de fallos de Babylon que se actualizó justo el 27 de julio y, después de leerlo, me quedé aún más inquieto.
La recompensa máxima es de 500.000 USD, y 16 tipos de activos entran en el alcance. A simple vista, parece que la inversión en seguridad no es baja. Pero al bajar más, hay varios tipos de riesgos que realmente podrían arrastrar el sistema a un gran incidente y que, sin embargo, quedan explícitamente excluidos: riesgo de centralización, el relé entre Bitcoin y Babylon temporalmente inactivo, más de un tercio de los Finality Provider maliciosos, que el Comité de Covenants alcance una mayoría maliciosa o no pueda reunir firmas, y parámetros de configuración como la profundidad de confirmación demasiado bajos.
Lo que también es especialmente digno de notar es que las reglas de recompensas prohíben probar oráculos de terceros y contratos inteligentes de terceros.
Esto entra en una contradicción muy clara con la dirección que recientemente impulsó @BabylonLabs_io . Babylon ya ha anunciado que conectará Trustless Bitcoin Vaults a Aave V4 y Aegis, con la idea de lanzar en el cuarto trimestre préstamos nativos con BTC como colateral a tasa fija.
La cadena de producto se vuelve: Babylon gestiona la infraestructura de colateralización con BTC, Aave gestiona el mercado de préstamos, Aegis gestiona el producto de tasa fija; y por fuera posiblemente haya que conectar también billeteras, frontends, oráculos y mecanismos de liquidación.
Lo que ven los usuarios es “BTC nativo, autocustodia, sin necesidad de puentes”; lo que ve el atacante, en cambio, son las juntas y rendijas de responsabilidad entre varios sistemas.
Los problemas de seguridad de Babylon divulgados este año por OpenZeppelin se concentran precisamente en este tipo de juntas: el colateral caducado aún conserva derecho de voto, Finality Provider elude la confinación, anomalías en las cuentas de Co-Staking causan congelamiento de fondos, e incluso se llega a provocar la caída de validadores. La respuesta oficial sí fue de reparación oportuna, pero esto, en realidad, subraya que el problema de los límites no es un riesgo meramente teórico.
No cuestiono si Babylon tiene auditorías; lo que cuestiono es, cuando el negocio va acumulando componentes de terceros, ¿quién se responsabiliza de los incidentes “entre componentes”?
La seguridad no puede limitarse a ver si en un repositorio individual hay vulnerabilidades. Cuando realmente ocurre algo grave, a menudo cada parte puede demostrar que su propio código no tiene fallos, pero al final nadie puede garantizar que el dinero del usuario esté a salvo.
#baby $BABY @BabylonLabs_io
La recompensa máxima es de 500.000 USD, y 16 tipos de activos entran en el alcance. A simple vista, parece que la inversión en seguridad no es baja. Pero al bajar más, hay varios tipos de riesgos que realmente podrían arrastrar el sistema a un gran incidente y que, sin embargo, quedan explícitamente excluidos: riesgo de centralización, el relé entre Bitcoin y Babylon temporalmente inactivo, más de un tercio de los Finality Provider maliciosos, que el Comité de Covenants alcance una mayoría maliciosa o no pueda reunir firmas, y parámetros de configuración como la profundidad de confirmación demasiado bajos.
Lo que también es especialmente digno de notar es que las reglas de recompensas prohíben probar oráculos de terceros y contratos inteligentes de terceros.
Esto entra en una contradicción muy clara con la dirección que recientemente impulsó @BabylonLabs_io . Babylon ya ha anunciado que conectará Trustless Bitcoin Vaults a Aave V4 y Aegis, con la idea de lanzar en el cuarto trimestre préstamos nativos con BTC como colateral a tasa fija.
La cadena de producto se vuelve: Babylon gestiona la infraestructura de colateralización con BTC, Aave gestiona el mercado de préstamos, Aegis gestiona el producto de tasa fija; y por fuera posiblemente haya que conectar también billeteras, frontends, oráculos y mecanismos de liquidación.
Lo que ven los usuarios es “BTC nativo, autocustodia, sin necesidad de puentes”; lo que ve el atacante, en cambio, son las juntas y rendijas de responsabilidad entre varios sistemas.
Los problemas de seguridad de Babylon divulgados este año por OpenZeppelin se concentran precisamente en este tipo de juntas: el colateral caducado aún conserva derecho de voto, Finality Provider elude la confinación, anomalías en las cuentas de Co-Staking causan congelamiento de fondos, e incluso se llega a provocar la caída de validadores. La respuesta oficial sí fue de reparación oportuna, pero esto, en realidad, subraya que el problema de los límites no es un riesgo meramente teórico.
No cuestiono si Babylon tiene auditorías; lo que cuestiono es, cuando el negocio va acumulando componentes de terceros, ¿quién se responsabiliza de los incidentes “entre componentes”?
La seguridad no puede limitarse a ver si en un repositorio individual hay vulnerabilidades. Cuando realmente ocurre algo grave, a menudo cada parte puede demostrar que su propio código no tiene fallos, pero al final nadie puede garantizar que el dinero del usuario esté a salvo.
#baby $BABY @BabylonLabs_io