Intercambia 200 mil por casi 100 millones, las stablecoins de DeFi vuelven a ser atacadas

Artículo por: Eric, Foresight News

Alrededor de las 10:21 hora de Beijing de hoy, Resolv Labs, que utiliza una estrategia neutral de Delta para emitir stablecoins USR, fue hackeada. La dirección que comienza con 0x04A2 usó 100,000 USDC para acuñar 50 millones de USR desde el protocolo Resolv Labs.

Tras la exposición del incidente, el precio de USR cayó a cerca de 0.25 dólares y, al momento de redactar este artículo, se recuperó a aproximadamente 0.8 dólares. El precio del token RESOLV también sufrió una caída máxima cercana al 10% en un corto período.

Luego, los hackers repitieron el proceso usando otros 100,000 USDC para acuñar 30 millones de USR. Con la gran desconexión de USR, los traders de arbitraje actuaron rápidamente. Muchos mercados de préstamos en Morpho que soportan USR, wstUSR y otros como colaterales quedaron casi vacíos, y Lista DAO en BNB Chain también suspendió nuevas solicitudes de préstamo.

No solo las plataformas de préstamo se vieron afectadas. En el diseño del protocolo Resolv Labs, los usuarios también pueden acuñar un token llamado RLP, que tiene una mayor volatilidad de precio y mayores rendimientos, pero requiere que los usuarios asuman la responsabilidad de compensar pérdidas si el protocolo sufre daños. Actualmente, hay cerca de 30 millones de RLP en circulación, con Stream Finance como el mayor poseedor, con más de 13 millones de RLP, exponiéndose a un riesgo neto de aproximadamente 17 millones de dólares.

Exactamente, Stream Finance, que ya sufrió un colapso por xUSD, podría verse afectada nuevamente.

Hasta el momento, los hackers han convertido USR en USDC y USDT, y continúan comprando Ethereum, habiendo adquirido ya más de 10,000 ETH. Con 200,000 USDC, han obtenido activos por más de 20 millones de dólares. Durante el mercado bajista, los hackers encontraron en TA una “criptomoneda de 100 veces”.

Otra vez, por una “falta de rigor” que permitió la explotación

El 11 de octubre del año pasado, una caída significativa provocó pérdidas en muchas stablecoins emitidas con estrategias neutrales de Delta debido a la reducción automática de apalancamiento (ADL). Algunos proyectos que usaban altcoins como colateral sufrieron pérdidas severas e incluso huyeron.

En esta ocasión, Resolv Labs también utilizó un mecanismo similar para emitir USR. El proyecto anunció en abril de 2025 que había completado una ronda de financiación semilla de 10 millones de dólares, liderada por Cyber.Fund y Maven11, con participación de Coinbase Ventures, y lanzó su token RESOLV a finales de mayo y principios de junio.

Pero la causa del ataque no fue un mercado extremo, sino que el mecanismo de acuñación de USR no fue lo suficientemente riguroso.

Hasta ahora, no hay análisis oficial o de empresas de seguridad sobre las causas del incidente. La comunidad DeFi, a través de YAM, concluyó preliminarmente que el ataque probablemente se debió a que el rol de servicio (SERVICE_ROLE) en el backend del protocolo, que proporciona parámetros para la acuñación, fue controlado por los hackers.

Según Grok, cuando los usuarios acuñan USR, envían una solicitud en la cadena y llaman a la función requestMint del contrato, con parámetros como:

_depositTokenAddress：dirección del token depositado;

_amount：cantidad depositada;

_minMintAmount：cantidad mínima de USR esperada (slippage).

Luego, los usuarios depositan USDC o USDT en el contrato, el backend del proyecto, con el rol SERVICE_ROLE, monitorea la solicitud, usa el oráculo Pyth para verificar el valor de los activos depositados, y posteriormente llama a las funciones completeMint o completeSwap para decidir la cantidad real de USR a acuñar.

El problema radica en que el contrato de acuñación confía completamente en _mintAmount proporcionado por SERVICE_ROLE, asumiendo que ese número ha sido verificado fuera de la cadena por Pyth, por lo que no establece límites máximos ni realiza una segunda verificación con un oráculo en la cadena, y ejecuta directamente mint(_mintAmount).

Por ello, YAM sospecha que los hackers controlaron el ROLE de servicio (posiblemente por un fallo en el oráculo interno, robo de claves o autohackeo), y durante la acuñación establecieron _mintAmount en 50 millones, logrando así el ataque de usar 100,000 USDC para acuñar 50 millones de USR.

En definitiva, Grok concluye que Resolv no consideró en el diseño del protocolo que la dirección (o contrato) que recibe las solicitudes de acuñación podría ser controlada por hackers. Cuando la solicitud de acuñación de USR se envía al contrato final, no se estableció un límite máximo, ni se realizó una segunda verificación con un oráculo en la cadena, confiando ciegamente en todos los parámetros proporcionados por SERVICE_ROLE.

La prevención también fue insuficiente

Además de especular sobre las causas del hackeo, YAM señaló que el equipo no estuvo suficientemente preparado para responder a la crisis.

En X, YAM afirmó que Resolv Labs solo pausó el protocolo tres horas después del primer ataque, y que aproximadamente una hora de ese retraso se debió a la necesidad de recopilar las firmas de cuatro signatarios para las transacciones multisig. YAM opina que una pausa de emergencia debería requerir solo una firma, y que los permisos deberían estar distribuidos entre los miembros del equipo o operadores externos confiables, para aumentar la vigilancia sobre comportamientos anómalos en la cadena y facilitar una pausa rápida, además de cubrir diferentes zonas horarias.

Aunque la sugerencia de que solo se necesita una firma para pausar el protocolo puede parecer algo radical, en situaciones de emergencia, la necesidad de múltiples firmas en diferentes zonas horarias puede retrasar decisiones cruciales. La introducción de terceros confiables que monitoreen continuamente la actividad en la cadena, o el uso de herramientas de monitoreo con permisos de pausa de emergencia, son lecciones que deja este incidente.

Los ataques a protocolos DeFi no se limitan solo a vulnerabilidades en los contratos. El incidente de Resolv Labs advierte a los proyectos que en la seguridad del protocolo no se puede confiar en ninguna parte, y que todos los procesos relacionados con parámetros deben al menos someterse a una segunda verificación, incluso en los sistemas operados por el propio equipo del proyecto.