Los esfuerzos de Solana por modernizar la verificación de firmas de transacciones se han topado con un contratiempo inesperado, y provino de una fuente inusual: un agente de investigación autónomo con IA que opera bajo el alias @hackhackai en la blockchain de Solana. El agente identificó una posible vulnerabilidad en SIMD-0376, la propuesta diseñada para reformar la forma en que la red gestiona la verificación de firmas de transacciones.

Según los hallazgos del agente, la falla, de no ser corregida, podría permitir firmar en la dirección cero, un escenario que debería ser imposible bajo las reglas actuales, poniendo en riesgo 433 cuentas de metadatos.

Qué propone SIMD-0376

Solana actualmente verifica las firmas Ed25519 utilizando la biblioteca ed25519-dalek. SIMD-0376 las reemplazaría por el estándar de verificación EdDSA cofactorizado ZIP-215, una implementación diferente de la misma curva criptográfica subyacente, un estándar que se originó como una propuesta de mejora de Zcash.

La verificación de firmas se ejecuta en cada transacción que procesa la red, razón por la cual las mejoras de eficiencia en esta capa se multiplican a lo largo de todo el rendimiento de Solana. La ventaja práctica del cambio es tangible: la propuesta busca habilitar el procesamiento de firmas por lotes, lo que podría reducir los costos computacionales de los validadores en aproximadamente un 40% al manejar grandes volúmenes de firmas.

David Rubin de Syndica presentó la propuesta el 6 de octubre de 2025. Tras refinamientos posteriores, fue fusionada en el repositorio de Solana Improvement Documents el 28 de enero de 2026.

El problema de la dirección cero

La vulnerabilidad se centra en un caso límite específico introducido por el estándar ZIP-215: la posibilidad de firmar con, o para, la dirección cero. Bajo las reglas normales de Ed25519, una firma de este tipo sería rechazada de plano. Bajo la lógica de verificación más permisiva de ZIP-215, podría no serlo.

La dirección cero no es un caso límite cualquiera. Funciona como una identidad nula, una dirección compuesta únicamente por ceros para la cual no existe clave privada en la práctica, razón por la cual las reglas actuales tratan cualquier firma contra ella como inválida por definición, y por la cual una firma verificable en la dirección cero socavaría un supuesto básico de los sistemas basados en cuentas como el de Solana.

Esa permisividad es intencional. ZIP-215 fue diseñado para aceptar un rango más amplio de representaciones de firmas válidas, lo que hace más sencillo el procesamiento por lotes. La contrapartida es que también relaja ciertas verificaciones de límites que antes servían como salvaguardas de seguridad implícitas.

El resultado, según los hallaz de @hackhackai, es que 433 cuentas de metadatos vinculadas al ecosistema de Solana podrían quedar expuestas a operaciones de firma que nunca deberían ser posibles. Hackhackai se describe a sí mismo como un agente de investigación enfocado en IA creado específicamente para aislar vulnerabilidades en protocolos de Solana.

Por qué importa el momento

La propuesta fue presentada en octubre de 2025 y fusionada en enero de 2026, pero la vulnerabilidad de la dirección cero salió a la luz sin una cobertura significativa de los medios de noticias cripto convencionales en los meses posteriores. Esa brecha también es una radiografía de cómo se desarrolla hoy la investigación de protocolos: un agente autónomo que opera en cadena puede detectar un problema a nivel de propuesta mucho antes que la cobertura convencional o las respuestas oficiales.

Las cuentas de metadatos señaladas en los hallazgos no son billeteras genéricas de usuarios. En la arquitectura de Solana, las cuentas de metadatos suelen almacenar datos a nivel de programa, configuraciones de tokens o atributos de NFT. En el peor de los casos, una anomalía de firma que afecte a estas cuentas podría permitir modificaciones no autorizadas al estado de programas o a los registros de propiedad de activos, dependiendo de cómo cada programa gestione las instrucciones firmadas entrantes.

Para los desarrolladores que construyen sobre Solana, en particular aquellos cuyos programas interactúan con cuentas de metadatos, la pregunta práctica es si su lógica de validación de instrucciones asume el comportamiento actual de rechazo de Ed25519 o verifica explícitamente las entradas de dirección cero. Los programas escritos antes de que se propusiera SIMD-0376 no tendrían motivo para incluir la última verificación, ya que nunca fue necesaria.

Al momento de escribir este artículo, ni los autores de la propuesta ni la Solana Foundation habían comentado públicamente sobre la falla. Cualquier revisión al texto del SIMD, una respuesta formal de sus autores o de los ingenieros principales de Solana, o nuevas directrices para los programas que interactúan con cuentas de metadatos serían las próximas señales concretas de cómo se resolverá esta disyuntiva entre la eficiencia por lotes y la verificación estricta.