Dentro del exploit de $11,5 millones del puente Verus‑Ethereum

Posteriormente, estos activos fueron intercambiados y consolidados en unos 5.402 ETH, probablemente para simplificar su movimiento posterior o el proceso de lavado de fondos.

Por qué las pruebas criptográficas parecían válidas

A primera vista el ataque resultó confuso, porque el sistema de verificación criptográfica del puente aparentemente funcionaba correctamente.

El puente utilizaba raíces de estado notarizadas y pruebas de Merkle para confirmar que una transacción había ocurrido en la cadena de origen antes de permitir un retiro en Ethereum. Estas pruebas demuestran que cierta información está incluida en el estado de la blockchain.

El problema es que una prueba de Merkle solo confirma que un dato existe dentro de un bloque o árbol de estado, pero no garantiza que ese dato sea económicamente válido o que esté respaldado por activos bloqueados.

Según los investigadores, el contrato:

• verificaba correctamente las raíces de estado notarizadas
• verificaba correctamente las pruebas de inclusión de Merkle
• pero no comprobaba que el monto reclamado estuviera realmente respaldado por fondos bloqueados en la cadena de origen.

Esto permitió que un atacante construyera datos de transferencia que pasaban la verificación criptográfica, pero que autorizaban retiros mayores que el colateral real.

En términos simples: la prueba confirmaba el mensaje, pero el contrato nunca comprobó si ese mensaje autorizaba realmente el pago que estaba ejecutando.

La verificación que faltaba

Los analistas de seguridad describen el problema como una clásica falla de validación en la lógica del negocio.

El contrato en Ethereum debía haber comprobado que varios elementos coincidieran con la transferencia real en la cadena de origen, por ejemplo:

• tipo de token
• cantidad transferida
• dirección del destinatario
• estado contable de las reservas del puente

Al faltar esa verificación, el contrato permitió retiros que no estaban respaldados por depósitos reales. De acuerdo con los investigadores, el atacante habría gastado apenas unos $10 en comisiones VRSC para activar retiros por valor de millones en Ethereum.

Como el problema no fue criptográfico sino de lógica del contrato, los desarrolladores prepararon un parche en Solidity para cerrar la vulnerabilidad una vez identificada.

Comparación con los hacks de Wormhole y Nomad

El exploit de Verus encaja en un patrón que ya se ha visto en otros grandes fallos de puentes entre cadenas.

Wormhole (2022)

En febrero de 2022, el puente Wormhole sufrió un ataque que permitió a un hacker acuñar 120.000 wrapped ETH (wETH) —valorados en más de $320 millones— tras evadir el proceso de verificación de firmas del sistema.

En la práctica, el atacante logró convencer al puente de que había colateral depositado cuando en realidad no existía.

Nomad (2022)

El puente Nomad fue explotado en agosto de 2022, provocando pérdidas cercanas a $190 millones. Un error de configuración hizo que los mensajes fueran tratados automáticamente como válidos, permitiendo copiar y reutilizar transacciones para liberar fondos del contrato.

Dónde encaja el caso Verus

El incidente de Verus se parece más al de Nomad que al de Wormhole. En ambos casos:

• el sistema aceptaba mensajes o pruebas como válidos
• pero la lógica que determinaba qué autorizaban esos mensajes era defectuosa.

El resultado final fue el mismo: retiros de fondos sin respaldo desde los pools de liquidez del puente.

Por qué los puentes cross‑chain siguen siendo un objetivo frecuente

Los puentes son uno de los componentes más atacados del ecosistema DeFi porque combinan varios sistemas complejos en una sola arquitectura:

• verificación de pruebas criptográficas
• mensajería entre blockchains
• contabilidad de contratos inteligentes
• custodia de grandes reservas de activos

Si falla cualquier parte del proceso de validación —incluso un chequeo pequeño— el sistema puede autorizar retiros que exceden el colateral real.

El caso Verus refuerza una lección clave para el diseño de estos sistemas: “prueba verificada” no significa automáticamente “transferencia válida”. Los contratos deben aplicar reglas contables estrictas sobre montos, activos, destinatarios y protección contra replays.

Qué podría ocurrir ahora: recuperación y seguros

Cuando comenzaron a circular los primeros reportes, todavía había pocos detalles públicos sobre planes de recuperación o compensación para los usuarios afectados. Algunas coberturas señalaban que las confirmaciones oficiales aún estaban emergiendo en ese momento.

Si los fondos robados no se recuperan, una posible compensación podría depender de varios factores, entre ellos:

• reservas del tesoro del proyecto
• decisiones de gobernanza dentro del protocolo
• negociaciones con el atacante
• cobertura de seguros DeFi de terceros

El incidente también reaviva un debate dentro de la industria: si los fallos de puentes deben considerarse principalmente errores de contratos inteligentes, fallas de infraestructura o riesgos de diseño operativo, algo que afecta directamente cómo las aseguradoras DeFi evalúan la cobertura.

La lección más importante para DeFi

El exploit del puente Verus‑Ethereum demuestra que las vulnerabilidades más peligrosas no siempre son fallos criptográficos, sino errores pequeños en la lógica de validación del contrato.

Un puente puede verificar firmas, pruebas y raíces de estado perfectamente… y aun así ser vulnerable si el contrato no confirma que los datos probados autorizan exactamente la transferencia que se ejecuta.

Esa diferencia aparentemente sutil ya ha costado miles de millones al ecosistema DeFi en múltiples incidentes de puentes. El caso Verus es otro recordatorio de que, en los sistemas cross‑chain, la seguridad depende tanto de la contabilidad correcta como de la criptografía.