El guardarropa de una boda en la que trabajé usaba boletos de papel numerados — arranca una mitad, conserva la otra, un abrigo por número. Sencillo, mientras la máquina solo imprima cada número una vez.
Se atascó a la mitad de la noche y empezó a reimprimir números que ya se habían entregado. Dos personas se presentaron con el boleto #114. Solo había un abrigo colgado alguna vez bajo ese número.
La palabra que encaja, hasta donde puedo decir: el boleto extra — una reclamación emitida más de una vez, porque quien imprime las reclamaciones no comprueba qué hay realmente colgado al fondo. Los tokens de liquid-staking de Bitcoin tienen la misma exposición: se acuña un recibo contra un depósito, solo tan honesto como el código que lo acuña.
En marzo, la bóveda BRO de Solv Protocol dejó que un depósito de 1 BTC acuñara más SolvBTC de lo que debería. Un bug de reentrancy permitió que un solo depósito de NFT desencadenara un callback que emitió un segundo lote de tokens antes de que terminara la primera acuñación — el equipo de seguridad Halborn lo rastreó hasta esa ruta de doble acuñación, por unos $2.7M. Los usuarios fueron reembolsados, pero durante un tiempo el token de recibo se adelantó al Bitcoin que lo respaldaba.
La integración de staking de Babylon evita el paso del token de recibo por exactamente esta razón. Una bóveda de BTC en staking lleva tres condiciones de gasto prefirmadas en el momento de la creación — deshacer staking, liquidar y slashing — aplicadas directamente por el script de Bitcoin, no por un contrato inteligente que minta una reclamación sobre el depósito. No hay un segundo token que pueda emitirse dos veces, porque no hay ningún token.
Lo que me queda claro: Solv podría corregir su contrato después del exploit y reembolsar a los usuarios. Una bóveda prefirmada no se puede parchear — las condiciones que se firman al crearse son las condiciones de la vida de esa bóveda. Cambiar un bug que puedes arreglar por un error que no puedes es un tipo de riesgo en sí mismo.
El boleto #114 es el número que aún recuerdo, más que el abrigo en sí.
Mi propia solicitud de retiro desde la red de pruebas todavía está en su período de desafío — informaré cuando realmente llegue a la billetera, no solo al panel.
@BabylonLabs_io $BABY #baby
Se atascó a la mitad de la noche y empezó a reimprimir números que ya se habían entregado. Dos personas se presentaron con el boleto #114. Solo había un abrigo colgado alguna vez bajo ese número.
La palabra que encaja, hasta donde puedo decir: el boleto extra — una reclamación emitida más de una vez, porque quien imprime las reclamaciones no comprueba qué hay realmente colgado al fondo. Los tokens de liquid-staking de Bitcoin tienen la misma exposición: se acuña un recibo contra un depósito, solo tan honesto como el código que lo acuña.
En marzo, la bóveda BRO de Solv Protocol dejó que un depósito de 1 BTC acuñara más SolvBTC de lo que debería. Un bug de reentrancy permitió que un solo depósito de NFT desencadenara un callback que emitió un segundo lote de tokens antes de que terminara la primera acuñación — el equipo de seguridad Halborn lo rastreó hasta esa ruta de doble acuñación, por unos $2.7M. Los usuarios fueron reembolsados, pero durante un tiempo el token de recibo se adelantó al Bitcoin que lo respaldaba.
La integración de staking de Babylon evita el paso del token de recibo por exactamente esta razón. Una bóveda de BTC en staking lleva tres condiciones de gasto prefirmadas en el momento de la creación — deshacer staking, liquidar y slashing — aplicadas directamente por el script de Bitcoin, no por un contrato inteligente que minta una reclamación sobre el depósito. No hay un segundo token que pueda emitirse dos veces, porque no hay ningún token.
Lo que me queda claro: Solv podría corregir su contrato después del exploit y reembolsar a los usuarios. Una bóveda prefirmada no se puede parchear — las condiciones que se firman al crearse son las condiciones de la vida de esa bóveda. Cambiar un bug que puedes arreglar por un error que no puedes es un tipo de riesgo en sí mismo.
El boleto #114 es el número que aún recuerdo, más que el abrigo en sí.
Mi propia solicitud de retiro desde la red de pruebas todavía está en su período de desafío — informaré cuando realmente llegue a la billetera, no solo al panel.
@BabylonLabs_io $BABY #baby