Con 200,000 intercambios por casi 100 millones, los stablecoins de DeFi vuelven a ser atacados

Escrito por: Eric, Foresight News

Aproximadamente a las 10:21 hora de Beijing, Resolv Labs, que emite la stablecoin USR utilizando una estrategia Delta neutral, fue atacado por hackers. Una dirección que comienza con 0x04A2 acuñó 50 millones de USR desde el protocolo de Resolv Labs utilizando 100,000 USDC.

Con la exposición del evento, el USR cayó a alrededor de 0.25 dólares, y al momento de escribir, se había recuperado a cerca de 0.8 dólares. El precio del token RESOLV también experimentó una caída temporal de cerca del 10%.

Luego, el hacker repitió la estrategia y acuñó 30 millones de USR utilizando nuevamente 100,000 USDC. Con el gran desanclaje del USR, los comerciantes de arbitraje también actuaron rápidamente, y muchos mercados de préstamos en Morpho que admiten USR, wstUSR y otros como colaterales fueron casi vaciados; también, Lista DAO en la cadena BNB suspendió las nuevas solicitudes de préstamos.

Los protocolos de préstamo afectados no se limitan a estos. En el diseño del protocolo de Resolv Labs, los usuarios también pueden acuñar un token RLP que presenta una mayor volatilidad de precios y mayores rendimientos, pero que requiere asumir responsabilidad de compensación si el protocolo incurre en pérdidas. Actualmente, la circulación del token RLP es de cerca de 30 millones, y el mayor poseedor, Stream Finance, tiene más de 13 millones de RLP, con una exposición al riesgo neto de aproximadamente 17 millones de dólares.

Así es, Stream Finance, que ya fue golpeada una vez por el colapso de xUSD, podría estar enfrentando otro golpe.

Al momento de escribir, el hacker ha convertido USR a USDC y USDT, y continúa comprando Ethereum, habiendo ya adquirido más de 10,000. Con 200,000 USDC, ha extraído más de 20 millones de dólares en activos, y el hacker ha encontrado su “token de cien veces” en este mercado bajista.

Otra vez víctima de la “falta de rigor”

La caída del 11 de octubre del año pasado provocó que muchas stablecoins emitidas utilizando estrategias Delta neutrales sufrieran pérdidas de colateral debido a ADL (reducción automática de apalancamiento). Algunos proyectos de activos que utilizan altcoins como estrategia de ejecución enfrentaron pérdidas aún más severas e incluso se retiraron del mercado.

Resolv Labs, que fue atacado esta vez, también utilizó un mecanismo similar para emitir USR. El proyecto había anunciado en abril de 2025 que completó una ronda de financiación de semillas de 10 millones de dólares liderada por Cyber.Fund y Maven11, con la participación de Coinbase Ventures, y lanzó el token RESOLV a finales de mayo y principios de junio.

Sin embargo, la razón del ataque a Resolv Labs no fue una situación de mercado extrema, sino que el diseño del mecanismo para acuñar USR era “demasiado laxo”.

Hasta ahora, no hay ninguna empresa de seguridad ni oficial que haya analizado las causas de este incidente de hacker. La comunidad DeFi YAM, a través de un análisis, ha llegado a la conclusión preliminar de que el ataque probablemente se debió a que el SERVICE_ROLE utilizado por el backend del protocolo para proporcionar parámetros al contrato de acuñación fue controlado por el hacker.

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

_depositTokenAddress: dirección del token depositado;

_amount: cantidad depositada;

_minMintAmount: cantidad mínima de USR esperada (para evitar deslizamientos).

Después, los usuarios depositan USDC o USDT en el contrato, y el SERVICE_ROLE del backend del proyecto supervisa la solicitud, utiliza el oráculo Pyth para verificar el valor de los activos depositados, y luego 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 el _mintAmount proporcionado por el SERVICE_ROLE, asumiendo que este número ha sido verificado por Pyth fuera de la cadena, por lo que no se establecieron límites de cantidad ni se realizó una verificación adicional mediante un oráculo en la cadena, y simplemente ejecutó mint(_mintAmount).

Por lo tanto, YAM sospecha que el hacker controló el SERVICE_ROLE que debería haber sido controlado por el equipo del proyecto (posiblemente debido a un mal funcionamiento interno del oráculo, malversación o robo de claves), y al acuñar, estableció directamente _mintAmount en 50 millones, logrando así el ataque de acuñar 50 millones de USR con 100,000 USDC.

En resumen, la conclusión de Grok es que Resolv no consideró en el diseño del protocolo la posibilidad de que la dirección (o contrato) que recibe las solicitudes de acuñación de los usuarios fuera controlada por hackers, y al enviar la solicitud de acuñación de USR al contrato final que acuña USR, no se estableció un monto máximo de acuñación, ni se permitió que el contrato de acuñación utilizara un oráculo en la cadena para una verificación secundaria, confiando directamente en todos los parámetros proporcionados por el SERVICE_ROLE.

La prevención también fue inadecuada

Además de especular sobre las causas del hackeo, YAM también señaló la falta de preparación del equipo del proyecto para enfrentar la crisis.

YAM expresó en X que Resolv Labs solo suspendió el protocolo 3 horas después de que se completara el primer ataque del hacker, de las cuales aproximadamente 1 hora de retraso se debió a la necesidad de recopilar las 4 firmas requeridas para la transacción de múltiples firmas. YAM considera que la suspensión de emergencia debería requerir solo una firma, y que los permisos deberían distribuirse lo más posible entre los miembros del equipo o personal operativo externo confiable, lo que aumentaría la atención a situaciones anormales en la cadena, mejorando la posibilidad de una rápida suspensión y cubriendo mejor diferentes zonas horarias.

Aunque la sugerencia de que se necesita solo una firma para suspender el protocolo es un poco radical, la necesidad de múltiples firmas que cruzan diferentes zonas horarias para suspender el protocolo podría efectivamente retrasar asuntos importantes en situaciones de emergencia. La introducción de terceros confiables que monitoreen continuamente el comportamiento en la cadena, o el uso de herramientas de monitoreo que tengan permisos para suspender el protocolo de emergencia, son lecciones que este evento ha dejado para el futuro.

Los ataques de hackers a los protocolos DeFi ya no se limitan a las vulnerabilidades de los contratos; el incidente de Resolv Labs advierte a los equipos del proyecto que no se debe confiar en ninguna parte de la seguridad del protocolo, y que todos los pasos que involucran parámetros deben ser al menos verificados dos veces, incluso el backend operado por el equipo del proyecto no es una excepción.