El hackeo de Binance por valor de 6.300 millones de dólares ha provocado un nuevo debate en la comunidad de Kaspa: ¿deberían las grandes billeteras de criptomonedas ser técnicamente incapaces de mover miles de millones de dólares en una secuencia de transacciones sin restricciones?
KaspaBots sostiene que el incidente pone de manifiesto el riesgo operativo de los sistemas tradicionales de billeteras calientes y afirma que la funcionalidad de covenants de Kaspa ofrece un enfoque diferente.
La idea es sencilla.
En lugar de depender únicamente de claves privadas y controles internos de los exchanges, las restricciones de gasto pueden vincularse directamente a las monedas y ser aplicadas por la propia blockchain.
«Diseñen sistemas en los que, por defecto, los movimientos de grandes cantidades estén sujetos a restricciones mediante covenants», escribió KaspaBots tras la brecha de seguridad de Binance.
Otro miembro de la comunidad de Kaspa, Eyal Yablonka, fue aún más lejos y sostuvo que Kaspa con covenants podría haber detenido el tipo de drenaje de 6.000 millones de dólares que sufrió Binance.
Esa afirmación requiere algunos matices, pero vale la pena examinar la tecnología subyacente.
Qué hacen realmente los covenants de Kaspa
La actualización Toccata de Kaspa se activó en la red principal el 30 de junio e incorporó a la red la programabilidad nativa de covenants en la capa 1.
Por lo general, un UTXO normal comprueba si la persona que intenta gastarlo tiene la autorización correcta.
Un covenant también puede imponer restricciones sobre lo que ocurre después de esa autorización.
La documentación de Kaspa describe los covenants como herramientas útiles para controles de tesorería, bóvedas, liberaciones programadas, sistemas de custodia y políticas de transferencia. Los outputs protegidos pueden definir cómo se permite mover los fondos y rechazar las transacciones que infrinjan esas reglas.
Binance es basura. No porque no haya incluido Kaspa, sino porque no *usó* Kaspa para proteger los fondos de sus usuarios. Kaspa con covenants habría detenido esta brecha de seguridad de 6.000 millones de dólares. Los covenants permiten asociar reglas de gasto personalizadas directamente a monedas individuales (UTXO), que se aplican de forma nativa a nivel de protocolo. En lugar de depender de una máquina virtual pesada basada en cuentas, como Ethereum (EVM), Kaspa aplica estas condiciones de forma nativa a nivel de protocolo.
— Eyal Yablon𐤊a (@fishtuna) 31 de octubre de 2026
Por ejemplo, un exchange podría crear teóricamente un monedero en el que:
solo se pueda retirar una cantidad limitada durante un periodo definido;
las transferencias más grandes deban enviarse a direcciones predefinidas;
los retiros por encima de un umbral requieran condiciones adicionales;
o los fondos solo puedan avanzar siguiendo una secuencia aprobada de outputs.
Esas restricciones se aplican a nivel de protocolo, en lugar de depender por completo de la seguridad del portátil de un empleado o de una aplicación interna.
Esa es la parte del argumento de la comunidad de Kaspa que merece atención.
Lea también: Predicción del precio de Kaspa (KAS) para noviembre: no se espera una recuperación importante
Por qué el hackeo de Binance hace que esto sea relevante
Binance afirma que los retiros no autorizados comenzaron alrededor de las 20:05 UTC del 29 de octubre y que, en última instancia, afectaron a activos por un valor aproximado de 6.300 millones de dólares.
La investigación inicial apuntó a un portátil de un empleado comprometido que permitió acceder a una infraestructura capaz de enviar retiros no autorizados. Desde entonces, Binance ha dicho que los investigadores encontraron otros puntos de entrada y que el ataque fue más complejo que el compromiso de un solo dispositivo. Hasta ahora, no ha encontrado indicios de que se filtraran las claves privadas de los monederos.
Esto plantea un interesante problema de seguridad.
Si el atacante no necesitó robar las propias claves privadas, protegerlas no era suficiente.
El sistema que controlaba lo que esas claves podían autorizar también necesitaba límites más estrictos.
Aquí es exactamente donde los diseños de bóvedas basados en covenants podrían resultar útiles.
Si los fondos estuvieran bloqueados en outputs que solo permitieran retiros bajo reglas estrictas, comprometer el software encargado de enviar las transacciones no daría automáticamente al atacante permiso para ignorar esas reglas.
El consenso rechazaría un gasto no válido.
Lea también: El precio de Kaspa podría caer aún más antes de la próxima recuperación alcista: ¿hasta dónde podría bajar KAS?
¿Kaspa habría detenido sin duda el hackeo de Binance?
Aquí es donde sería más cauteloso que algunas publicaciones de la comunidad.
Decir que «los covenants de Kaspa habrían detenido el hackeo de 6.300 millones de dólares» es demasiado categórico.
Binance no guardaba el portafolio robado en bóvedas con covenants de Kaspa, y la secuencia técnica completa del ataque aún está siendo investigada.
Que un sistema de covenants hubiera evitado la pérdida dependería por completo de cómo Binance hubiera diseñado esas restricciones de gasto.
Un covenant mal diseñado aún podría permitir acciones peligrosas. Las vías de recuperación también pueden crear formas de eludir las restricciones, y la infraestructura circundante sigue siendo vulnerable a errores de software, administradores comprometidos y procedimientos operativos deficientes.
Incluso la propia documentación de Kaspa señala que las herramientas para covenants aún están en una etapa relativamente temprana.
Una afirmación más precisa sería que las restricciones de gasto bien diseñadas podrían haber limitado lo que un sistema de monedero caliente comprometido era capaz de hacer.
Eso es distinto de decir que la propia blockchain hace imposibles los hackeos.
Suscríbete a nuestro canal de YouTube para recibir novedades diarias sobre criptomonedas, información sobre el mercado y análisis de expertos.
La publicación La comunidad de Kaspa afirma que los covenants podrían haber evitado un hackeo de 6.300 millones de dólares al estilo de Binance apareció primero en CaptainAltcoin.