Existe una forma de perder tus criptomonedas que no aparece en ninguna guía de seguridad: hacer todo bien y perderlas de todas formas. Eso es exactamente lo que le ocurrió a 374 carteras de Cardano, vaciadas no porque alguien robara una contraseña, sino porque el software que firmaba sus transacciones dejaba, sin saberlo, las claves privadas escritas en claro sobre la blockchain.
SecondFi, la cartera implicada, ha anunciado hoy su cierre definitivo. El caso merece entenderse a fondo, porque contiene la lección más incómoda sobre la autocustodia.
Qué pasó con SecondFi
SecondFi, la cartera Cardano que nació como sucesor del conocido Yoroi de EMURGO, ha comunicado que no reanudará sus operaciones normales y se dedicará exclusivamente a devolver los fondos. El ataque, detectado el 23 de junio, sustrajo aproximadamente 16,1 millones de ADA, equivalentes a unos 2,4 millones de dólares, de 374 direcciones, en tres oleadas distintas.
La respuesta de emergencia logró poner a salvo una cifra mucho mayor: cerca de 129 millones de ADA, casi 18,5 millones de dólares, transferidos a un custodio externo antes de que los atacantes pudieran alcanzarlos. La empresa de seguridad SlowMist estima que la exposición total, contando tokens y NFT en las carteras comprometidas, podría haber superado los 20 millones de dólares. Un punto debe quedar claro: la blockchain de Cardano no fue vulnerada; el problema residía íntegramente en el software de esa cartera concreta.
Los números del incidente
Fondos sustraídos, fondos rescatados y exposición estimada. Fuente: SecondFi, SlowMist, 2026
- Sustraídos por los atacantes16,1 M ADA
- Rescatados de emergencia129 M ADA
374 direcciones afectadas. La red Cardano no fue comprometida.
El mecanismo: cómo se pierde una clave privada sin entregarla a nadie
Concretamente, aquí la historia se vuelve técnica, y vale la pena explicarla porque es un principio que afecta a cualquier blockchain, no solo a Cardano. Cada vez que firmas una transacción, tu cartera utiliza la clave privada junto a un número de un solo uso, llamado en jerga nonce, cuya función es hacer que cada firma sea diferente de las demás. La regla de oro de la criptografía de curva elíptica es que ese número debe ser impredecible y nunca reutilizable.
Si ese valor se vuelve predecible o se repite, la firma deja de proteger el secreto y comienza a revelarlo: a partir de los datos de firma públicos, cualquiera puede reconstruir matemáticamente la clave privada. Es exactamente lo que ocurrió: el software de SecondFi generaba ese número de forma defectuosa, y las transacciones firmadas, todas públicas y legibles en la cadena por cualquier persona, contenían suficiente información para reconstruir las credenciales de la cartera. No es una vulnerabilidad nueva; es una de las trampas más conocidas y temidas de todo el sector, y por eso los desarrolladores serios jamás improvisan la parte criptográfica.
El detalle más duro: la frase secreta estaba quemada
Hay un aspecto de este caso que invierte todos los consejos habituales. Normalmente, cuando un servicio queda comprometido, la reacción instintiva es mover los fondos usando la propia frase de recuperación. Aquí eso no funcionaba.
El fallo actuaba a nivel de dirección y se activaba en el momento en que el usuario firmaba una transacción. Importar la misma frase secreta en otra cartera no ofrecía protección alguna: las claves ya eran derivables y seguían siéndolo dondequiera que se llevaran. Los usuarios afectados fueron advertidos explícitamente de que no restauraran esas frases en otras carteras. En la práctica, esas credenciales estaban quemadas para siempre.
Qué protegía y qué no
La lección práctica del incidente
- Protegió: el uso de una cartera hardware, cuyos usuarios no resultaron afectados.
- No protegió: mover la frase secreta a otra cartera, porque el defecto ya estaba en las claves.
- No protegió: guardar bien la frase, porque el problema no era el robo sino la generación.
Qué ocurre ahora con los afectados
El plan de recuperación está en marcha, aunque incompleto. SecondFi ha anunciado herramientas de exportación de carteras para principios de agosto y un portal de recuperación durante ese mismo mes, pero no se ha fijado una fecha concreta para la distribución de los fondos recuperados. Tampoco existe aún una auditoría independiente completa que explique en detalle la dinámica técnica, lo que deja a los usuarios sin un cuadro definitivo de los daños.
En el frente investigativo, la empresa de inteligencia blockchain encargada por EMURGO ha descrito al atacante principal como sofisticado y con amplia financiación. El fundador de Cardano, Charles Hoskinson, comentó lo ocurrido señalando que, aunque la cifra sea modesta comparada con otros robos del sector, eso no consuela en absoluto a quienes perdieron sus fondos.
La lección que queda
El mensaje de este caso resulta incómodo porque desmonta una simplificación muy extendida. Nos hemos acostumbrado a pensar que la autocustodia es una cuestión de disciplina personal: protege tu frase, no hagas clic en enlaces sospechosos, no confíes en nadie. Todo cierto, pero insuficiente. Porque bajo esas reglas existe una capa que no controlas: la calidad del código que genera tus claves y firma tus transacciones.
De aquí se desprenden dos indicaciones concretas. La primera es preferir, para cantidades que importan, una cartera hardware; en este caso marcó exactamente la diferencia entre quienes perdieron y quienes no. La segunda es apostar por software con una trayectoria larga, código abierto y revisiones independientes, desconfiando de las soluciones propietarias que reinventan la criptografía por su cuenta. En la autocustodia no basta con ser prudente: también hay que elegir bien a quién se confía la parte que uno no puede controlar. Quienes quieran profundizar en las bases pueden empezar por nuestra guía sobre cómo funciona una blockchain.
