¿Qué ocurrió?
Según el reportaje de Cointelegraph, el exchange descentralizado (DEX, es decir, un protocolo para el intercambio de tokens sin intermediario central) DYORSWAP se convirtió en víctima de una estafa en la que los atacantes utilizaron una red falsa que se hacía pasar por la blockchain GIWA. El resultado fue una pérdida de ETH por un valor aproximado de 2 millones de dólares.
El núcleo del problema es simple: existía una versión falsa de la red GIWA que los estafadores presentaban como la auténtica. Al parecer, DYORSWAP la trató como un entorno legítimo, lo que permitió a los atacantes drenar los fondos.
¿Qué es GIWA y por qué importa?
GIWA es un proyecto vinculado a la empresa Dunamu, operadora del exchange de criptomonedas surcoreano Upbit. Un detalle clave que enmarca todo el caso lo indica el propio Cointelegraph: según Dunamu, GIWA aún no había lanzado su mainnet en el momento del incidente, es decir, la red real y plenamente funcional.
Esto es fundamental. Si la red oficial aún no estaba en funcionamiento, entonces cualquier "red GIWA" con la que se estuviera trabajando en ese momento no podía ser la auténtica. Precisamente esta brecha entre la expectativa (un nombre conocido asociado a Upbit) y la realidad (ningún mainnet activo) fue la que aprovechó la estafa.
¿Cuánto pagó DYORSWAP?
Según Cointelegraph, DYORSWAP indicó que pagó más de 200 ETH en compensaciones. La pérdida total mencionada ronda los 2 millones de dólares en ETH.
| Dato | Valor (según Cointelegraph) |
|---|---|
| Pérdida estimada | ~2 millones USD en ETH |
| Compensación pagada | más de 200 ETH |
| Estado del mainnet de GIWA | según Dunamu, aún no lanzado |
¿Qué no está confirmado todavía?
Aquí es necesaria la cautela. De la fuente disponible no se desprende el mecanismo técnico exacto del ataque, es decir, si se trató de contratos inteligentes falsificados, RPC o documentación falsa, ingeniería social, o una combinación. Tampoco está confirmado por esta fuente quién está exactamente detrás del ataque, si los fondos fueron rastreados o congelados, ni cómo se calculó y distribuyó exactamente la compensación entre los usuarios afectados.
No queremos deducir la causa allí donde la fuente no la indica. Nos ceñimos a lo que ha sido documentado.
En qué fijarse en este tipo de incidentes
Esto no es un consejo sobre qué hacer con el dinero, sino una lista de patrones que se repiten en casos similares y que se pueden verificar:
- Identidad verificada de la red. Antes de integrar una nueva red, ayuda confirmar el anuncio oficial del propio operador. En este caso, el operador (Dunamu) comunicó explícitamente que el mainnet aún no estaba en funcionamiento.
- Diferencia entre testnet y mainnet. Un nombre conocido de un proyecto no significa que la red concreta con la que se trabaja sea la auténtica y real.
- Chain ID y contratos oficiales. En las integraciones se verifica si los identificadores de la red y las direcciones corresponden a las fuentes oficiales, y no solo al nombre.
Charliedesk no hace más predicciones sobre este caso. Registramos lo que ocurrió de forma demostrable y lo que queda abierto. Si aparece información verificada sobre el mecanismo del ataque o sobre el destino de los fondos robados, volveremos sobre ello.