-
Investigadores definieron cinco tipos de fallas semánticas en eventos de contratos.
-
De 6.617 contratos analizados, cerca del 99% presentó al menos una inconsistencia.
Un equipo de universidades de Singapur, China y Hong Kong publicó en septiembre de 2026 un estudio sobre un supuesto que casi nadie cuestiona en el ecosistema de contratos inteligentes: que los eventos que emite un contrato reflejan fielmente lo que ocurrió en su estado interno.
Confiar en una wallet suele significar confiar en que muestra lo que realmente pasó en la cadena. Esa fórmula da por sentado algo que rara vez se pone en duda: que los eventos que consulta una aplicación reflejan con exactitud el estado interno del contrato que los emitió.
Un evento es, en esencia, un registro que el contrato decide emitir de forma voluntaria durante la ejecución de una transacción. La máquina virtual de Ethereum lo anota en el recibo correspondiente, pero no comprueba en ningún momento si ese registro corresponde a lo que realmente cambió en el estado del contrato.
Esa ausencia de validación no es un detalle menor del protocolo. Es el punto ciego exacto que este estudio decidió mapear, clasificar y, sobre todo, medir a una escala que ningún trabajo anterior había intentado.
Cinco formas de mentir sin romper ninguna regla
Los investigadores revisaron 1.294 hallazgos de auditoría y 11 incidentes de seguridad documentados para construir una clasificación de fallas. El resultado permitió identificar cinco categorías:
- Colisión de eventos
- Discrepancia entre estado y evento
- Emisión no autorizada
- Discrepancia de emisión
- Discrepancia de parámetros.
La más común, presente en el 98,44% de los contratos inteligentes analizados, ocurre cuando el contrato emite un evento equivocado, omite uno esperado o lo duplica. La segunda más frecuente, presente en 62,85% de los casos, sucede cuando un evento anuncia un cambio que el estado del contrato nunca llegó a registrar.
Ninguna de estas fallas requiere que el contrato viole una regla explícita de Ethereum. El código puede ejecutarse exactamente como fue programado y, aun así, dejar un registro que no corresponde a la realidad de sus propios números internos.
Este hallazgo conecta con algo que CriptoNoticias ya había documentado sobre las auditorías de código: una revisión de seguridad reduce el riesgo, pero no garantiza que el contrato revisado se comporte como sus propios registros afirman.
Cuando el engaño sale del contrato y llega a la wallet
La parte más reveladora del estudio no está en el contrato, sino en lo que ocurre después: qué hacen los sistemas externos con esos eventos.
Los investigadores identifican dos vectores de ataque que explotan exactamente esta confianza ciega. El primero ocurre cuando un sistema externo acepta eventos de un emisor que no es el contrato legítimo, algo que ya causó el robo de unos USD 13.000.000 en el ataque a pNetwork.
El segundo sucede cuando una aplicación infiere que algo pasó basándose solo en el evento, sin verificar el estado real del contrato. Este vector recuerda al problema reportado cuando Binance retiró 30 colecciones de NFT falsificadas de su mercado.
En ambos casos, la apariencia de legitimidad en la cadena no garantizaba que la propiedad o el origen del activo fueran reales.
| Vector de ataque | Mecanismo | Caso documentado |
|---|---|---|
| Confusión de origen | El sistema acepta eventos de un emisor no autorizado | pNetwork, USD 13.000.000 |
| Desincronización estado-evento | El sistema confía en el evento sin validar el estado | Sleepminting en NFT |
Los propios investigadores reprodujeron ambos ataques contra sistemas reales en producción. Así consiguieron que cinco exploradores de bloques, incluido BscScan, mostraran una transferencia de tokens que jamás ocurrió en el estado del contrato.
El costo recae sobre quien menos puede evaluarlo
Al auditar seis wallets de criptomonedas en uso activo, el equipo de universidades de Singapur confirmó cuatro fallas reales de este tipo, una de ellas con una recompensa de USD 600 por parte del proyecto afectado. Dos reportes seguían pendientes de respuesta al cierre del estudio.
Todo esto traslada el riesgo a un terreno incómodo: el usuario final no tiene forma de saber si el saldo o la transacción que ve en su wallet corresponde a una verificación real del estado del contrato, o a la simple lectura de un evento que nadie contrastó.
Programas de recompensas documentó por CriptoNoticias en proyectos como Decred muestran que la industria confía en hackers éticos para cerrar este tipo de brechas, pero ese modelo depende de que alguien decida buscar la falla antes de que un atacante lo haga.
Vale reconocer un límite del propio estudio: la mayoría de estos hallazgos son defectos detectados por la herramienta, no vulnerabilidades explotadas de forma confirmada en cada uno de los 6.617 contratos. La cifra de 98,44% mide presencia de inconsistencias según la definición del detector, aunque no necesariamente indica daño financiero directo en cada caso.
Leer bien la cadena no es lo mismo que leer la verdad
El hallazgo de fondo conecta con un problema que atraviesa buena parte de la infraestructura de Ethereum: las aplicaciones que rodean a los contratos —wallets, exploradores, puentes entre cadenas— fueron diseñadas para ser rápidas, no para desconfiar. Validar cada evento contra el estado real cuesta tiempo de cómputo que la mayoría prefiere ahorrarse.
Esa decisión de diseño funciona bien mientras los contratos se comporten como se espera. Pero deja de funcionar en el momento exacto en que alguien construye, de forma deliberada, un evento que dice una cosa mientras el estado del contrato dice otra.
Una wallet puede ejecutar cada consulta a la perfección, procesar cada bloque sin errores y aun así construir, para el usuario, una versión de los hechos que el contrato nunca vivió. La confianza en la cadena de bloques no elimina la necesidad de verificar; solo la traslada a una capa que casi nadie revisa.
