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

Artículo: 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 un hacker. 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, USR cayó a alrededor de 0.25 dólares, y al momento de redactar, se había recuperado a alrededor de 0.8 dólares. El precio del token RESOLV también experimentó una caída cercana al 10% en su máximo temporal.

Luego, el hacker utilizó el mismo método para acuñar otros 30 millones de USR con 100,000 USDC. Con la gran desvinculación de USR, los traders de arbitraje actuaron rápidamente, y muchos mercados de préstamos que soportan USR, wstUSR, y otros como colateral en Morpho, fueron prácticamente vaciados, y Lista DAO en BNB Chain también suspendió nuevas solicitudes de préstamo.

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 tiene una mayor volatilidad de precios y mayores rendimientos, pero que requiere asumir responsabilidad por pérdidas en el protocolo. Actualmente, la circulación de tokens RLP es de casi 30 millones, siendo el mayor poseedor Stream Finance, que posee más de 13 millones de RLP, con un riesgo neto de aproximadamente 17 millones de dólares.

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

Al momento de redactar, el hacker ya había convertido USR a USDC y USDT, y continuaba comprando Ethereum, habiendo adquirido más de 10,000 hasta ahora. Con 200,000 USDC, extrajo más de 20 millones de dólares en activos, encontrando durante el mercado bajista su “moneda de cien veces”.

Otra vez vulnerado por la “falta de rigor”

La caída del 11 de octubre del año pasado provocó pérdidas de colateral en muchas stablecoins emitidas con estrategias Delta neutrales debido al ADL (reducción automática de apalancamiento). Algunos proyectos que utilizaban altcoins como activos para ejecutar estrategias sufrieron pérdidas aún más severas e incluso se retiraron directamente.

Resolv Labs, que fue atacado esta vez, también utilizó un mecanismo similar para emitir USR. Este proyecto había anunciado en abril de 2025 la finalización de una ronda de financiamiento de semillas de 10 millones de dólares liderada por Cyber.Fund y Maven11, con participación de Coinbase Ventures, y puso en marcha 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 el “diseño del mecanismo de acuñación de USR que no fue lo suficientemente riguroso”.

Hasta ahora, ninguna empresa de seguridad o entidad oficial ha analizado las razones detrás del ataque. La comunidad DeFi YAM, a través de un análisis, llegó a la conclusión preliminar de que el ataque probablemente fue causado por el control del hacker sobre el SERVICE_ROLE en el backend del protocolo, que se utiliza para proporcionar parámetros al contrato de acuñación.

Según el análisis de Grok, cuando un usuario acuña USR, inicia una solicitud en la cadena y llama 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 que se espera recibir (para evitar deslizamientos).

Luego, el usuario deposita USDC o USDT en el contrato, y el SERVICE_ROLE en el backend del proyecto monitorea la solicitud, utiliza el oráculo Pyth para verificar el valor de los activos depositados y luego llama a las funciones completeMint o completeSwap, decidiendo 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 ese número fue verificado por Pyth fuera de la cadena, por lo que no se establecieron límites y no se realizó una verificación del oráculo en la cadena, ejecutando directamente mint(_mintAmount).

Por lo tanto, YAM sospecha que el hacker controló el SERVICE_ROLE que debía ser controlado por el proyecto (posiblemente debido a un descontrol en el oráculo interno, 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 última instancia, 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 pudiera ser controlada por un hacker, y al enviar la solicitud de acuñación de USR al contrato que finalmente acuñaba USR, no se estableció un límite máximo de acuñación, ni se permitió que el contrato de acuñación realizara una verificación secundaria con un oráculo en la cadena, confiando directamente en todos los parámetros proporcionados por el SERVICE_ROLE.

La prevención también fue deficiente

Además de especular sobre las razones del ataque, YAM también señaló que el proyecto no estaba adecuadamente preparado para enfrentar la crisis.

YAM comentó en X que Resolv Labs solo suspendió el protocolo tres horas después de que se completara el primer ataque del hacker, de las cuales aproximadamente una hora de retraso se debió a la necesidad de recopilar las cuatro firmas requeridas para la transacción de múltiples firmas. YAM cree que la suspensión de emergencia debería requerir solo una firma y que los permisos deberían distribuirse tanto como fuera posible entre los miembros del equipo o operadores externos de confianza, lo que aumentaría la atención sobre situaciones anormales en la cadena, mejorando la posibilidad de una suspensión rápida y cubriendo mejor las diferentes zonas horarias.

Aunque la sugerencia de que se puede suspender el protocolo con una sola firma es algo radical, la necesidad de múltiples firmas a través de diferentes zonas horarias para suspender el protocolo puede efectivamente retrasar acciones importantes en situaciones de emergencia. Introducir a terceros confiables que monitoreen continuamente el comportamiento en la cadena, o utilizar herramientas de monitoreo con permisos de suspensión de emergencia, son lecciones que se derivan de este evento.

Los ataques de hackers a los protocolos DeFi ya no se limitan a vulnerabilidades de contratos, y el evento de Resolv Labs recuerda a los proyectos que en términos de seguridad del protocolo, no se debe confiar en ninguna parte del proceso; todos los aspectos que involucran parámetros deben ser al menos verificados dos veces, incluso el backend operado por el propio proyecto no debe ser una excepción.