Charles Hoskinson: Aplicación SecondFi comprometida, protocolo de Cardano no afectado

Charles Hoskinson emitió una nueva actualización en vivo el 24 de junio de 2026, después de revisar TypeScript minimizado de la aplicación SecondFi y de realizar un análisis forense independiente del incidente de la billetera. La actualización se centró en cómo parece que ocurrió el ataque, por qué el caso apunta al código de la aplicación de SecondFi y por qué la evidencia disponible no indica una falla en el protocolo de Cardano, los nodos centrales, las bibliotecas de billeteras de código abierto ni la criptografía fundamental.

Seguridad del protocolo de Cardano separada del incidente de SecondFi

La revisión de Hoskinson examinó si el incidente de SecondFi se limitaba a una sola aplicación o estaba conectado a un problema más amplio en la cadena de suministro criptográfica de Cardano. Su evaluación no encontró indicios de que las bibliotecas criptográficas de Cardano de código abierto utilizadas por la mayoría de las billeteras del ecosistema hubieran sido comprometidas.

La revisión técnica abarcó la derivación de claves, la construcción de firmas, la generación de palabras de recuperación, la mecánica de las billeteras HD y la selección de UTXO. Se describió que esos componentes eran coherentes con la infraestructura de código abierto utilizada en todas las billeteras de Cardano antes del incidente.

Las transacciones anómalas vinculadas a SecondFi estaban en cambio ligadas a la base de código de fuente cerrada de la aplicación, que había sido modificada respecto de los estándares de código abierto. La distinción es central en la actualización, la red de Cardano, los nodos, la criptografía a nivel de protocolo y la infraestructura de billeteras de código abierto quedaron separadas de la presunta falla dentro de una aplicación de billetera específica.

El código de SecondFi y los estándares de auditoría de billeteras pasan al centro de atención

La siguiente etapa del caso ahora depende de una auditoría independiente. Se espera que ese proceso explique cómo ocurrió el incidente, quién fue responsable y qué plan de remediación se ofrecerá a los usuarios afectados.

Hoskinson evitó publicar la ruta técnica específica del ataque antes de una divulgación adicional por parte de Emurgo o del equipo de SecondFi. En cambio, la actualización situó la verificación formal, la disciplina de auditoría y la responsabilidad a nivel de aplicación en el centro de la investigación.

El incidente también reabrió la cuestión más amplia de los estándares de billeteras en el ecosistema de Cardano. Lace y Daedalus se mencionaron como ejemplos de software de billetera desarrollado con visibilidad de código abierto y revisión externa. La posición más amplia presentada en la actualización fue que el código de las billeteras que gestionan fondos de usuarios debe ser de código abierto, auditarse con regularidad y mantenerse con escrutinio compartido cuando los componentes criptográficos afectan al ecosistema más amplio.

La preocupación no era solo la existencia de una vulnerabilidad. El problema más profundo es la modificación de código criptográfico sensible fuera del escrutinio público. Para los desarrolladores de billeteras, el caso de SecondFi ahora sitúa el diseño de la aplicación, la implementación criptográfica, el historial de auditorías y la transparencia de código abierto directamente dentro de la discusión de seguridad.

Seguridad del usuario, alegaciones de white hat y plan de remediación

La actualización también abordó afirmaciones iniciales de que algunos fondos podrían haber sido movidos por un actor white hat en lugar del atacante. Esa afirmación aún requiere confirmación a través del proceso de auditoría o de un plan oficial de remediación, dejando sin resolver los procedimientos de recuperación y devolución de fondos.

Hoskinson también abordó la cuestión de si las 24 palabras de recuperación de la billetera fueron comprometidas. Con base en el código que revisó, las propias palabras de recuperación no parecían estar comprometidas en esa etapa. La actualización también señaló que esto es difícil de verificar sin acceso completo al proceso de derivación de claves, especialmente cuando las billeteras pueden haber sido generadas en Yoroi y luego importadas a SecondFi, o generadas directamente dentro de SecondFi.

Hasta que se completen la auditoría y el proceso de remediación, la aplicación SecondFi debe tratarse como comprometida. El enfoque más seguro descrito en la actualización es dejar las claves en reposo y evitar transaccionar mediante cualquier billetera de SecondFi.

La actualización también aclaró los límites del papel de Input Output. La empresa no tiene autoridad especial para congelar, revertir o recuperar fondos a nivel de protocolo. Cardano no incluye mecanismos de intervención de ese tipo, alineando la red con un modelo global de criptomonedas en el que ninguna empresa o individuo controla los saldos de los usuarios.

La investigación ahora se centra en tres entregables concretos, una auditoría independiente, una explicación técnica de los equipos responsables de SecondFi y un plan de remediación para usuarios. Para el ecosistema más amplio de Cardano, la actualización en vivo reduce el caso al código de la aplicación, los cambios de billetera de código cerrado y la responsabilidad de auditoría, manteniendo al mismo tiempo la capa de protocolo, las bibliotecas de billeteras de código abierto y la infraestructura criptográfica central fuera de la falla reportada.