Escrito por: Eric, Foresight News
Aproximadamente a las 10:21 hora de Beijing de hoy, Resolv Labs, que emite la stablecoin USR utilizando una estrategia delta neutral, fue atacado por hackers. Una dirección que comienza con 0x04A2 utilizó 100,000 USDC para acuñar 50 millones de USR desde el protocolo de Resolv Labs.
Tras la exposición del incidente, el USR cayó a alrededor de 0.25 dólares, y en el momento de redactar este artículo se había recuperado a aproximadamente 0.8 dólares. El precio del token RESOLV también cayó casi un 10% en su punto más bajo.
Posteriormente, el hacker repitió el método y utilizó otros 100,000 USDC para acuñar 30 millones de USR. Con la fuerte desvinculación del USR, los arbitrajistas actuaron rápidamente. Muchos mercados de préstamos en Morpho que admiten USR, wstUSR, etc., como garantía están casi vacíos, y Lista DAO en BNB Chain también ha suspendido nuevas solicitudes de préstamo.
Los protocolos afectados no se limitan a estos mercados de préstamos. En el diseño del protocolo de Resolv Labs, los usuarios también pueden acuñar un token RLP, que tiene una volatilidad de precio mayor y un rendimiento más alto, pero que requiere asumir responsabilidad de compensación cuando el protocolo sufre pérdidas. Actualmente, la circulación del token RLP es de casi 30 millones, y el mayor tenedor, Stream Finance, posee más de 13 millones de RLP, con una exposición neta al riesgo de aproximadamente 17 millones de dólares.
Sí, Stream Finance, que ya fue afectado una vez por el colapso de xUSD, podría recibir otro golpe.
En el momento de redactar este artículo, el hacker ya había convertido el USR en USDC y USDT, y continuaba comprando Ethereum, habiendo adquirido ya más de 10,000 ETH. Con 200,000 USDC, extrajo activos por valor de más de 20 millones de dólares. El hacker encontró su "token de 100x" durante el mercado bajista.
Otra vez se aprovecharon de la "falta de rigor"
La fuerte caída del 11 de octubre del año pasado provocó que muchas stablecoins emitidas utilizando estrategias delta neutral sufrieran pérdidas de garantía debido al ADL (desapalancamiento automático). Algunos proyectos que utilizaban altcoins como activos para ejecutar la estrategia sufrieron pérdidas aún más graves o incluso cerraron directamente.
Resolv Labs, atacado esta vez, también utiliza 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 la participación de Coinbase Ventures, y lanzó el token RESOLV a finales de mayo y principios de junio.
Pero la razón del ataque a Resolv Labs no fue una situación extrema del mercado, sino un diseño "poco riguroso" del mecanismo de acuñación de USR.
Todavía no hay análisis de empresas de seguridad o oficiales sobre la causa de este incidente de hacking. La comunidad DeFi YAM llegó preliminarmente a una conclusión tras su análisis: es probable que el ataque se deba a que el SERVICE_ROLE, utilizado en 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 un usuario acuña USR, inicia una solicitud en la cadena y llama a la función requestMint del contrato. Los parámetros incluyen:
_depositTokenAddress: la dirección del token depositado;
_amount: la cantidad depositada;
_minMintAmount: la cantidad mínima esperada de USR a recibir (protección contra deslizamiento).
Luego, el usuario deposita USDC o USDT en el contrato. El backend del proyecto, SERVICE_ROLE, monitorea la solicitud, verifica el valor del activo depositado utilizando el oráculo Pyth, y luego llama a las funciones completeMint o completeSwap para determinar 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 SERVICE_ROLE, asumiendo que este número fue verificado fuera de la cadena por Pyth. Por lo tanto, no estableció un límite máximo ni realizó una verificación del oráculo en la cadena, y simplemente ejecutó mint(_mintAmount).
En base a esto, YAM sospecha que el hacker controló el SERVICE_ROLE, que debería haber sido controlado por el equipo del proyecto (posiblemente debido a un oráculo interno fuera de control, malversación interna o robo de claves), y estableció directamente _mintAmount en 50 millones durante la acuñación, logrando el ataque de acuñar 50 millones de USR con 100,000 USDC.
En resumen, la conclusión de Grok es que Resolv, al diseñar el protocolo, no consideró la posibilidad de que la dirección (o contrato) utilizada para recibir las solicitudes de acuñación de los usuarios pudiera ser controlada por un hacker. Al enviar la solicitud de acuñación de USR al contrato final que acuña USR, no estableció una cantidad máxima de acuñación, ni hizo que el contrato de acuñación realizara una verificación secundaria con un oráculo en cadena, sino que confió directamente en todos los parámetros proporcionados por SERVICE_ROLE.
La prevención tampoco fue adecuada
Además de especular sobre la causa del hackeo, YAM también señaló la preparación insuficiente del equipo del proyecto para enfrentar la crisis.
YAM declaró en X que Resolv Labs suspendió el protocolo 3 horas después de que el hacker completara el primer ataque, y que aproximadamente 1 hora de este retraso se debió a la recolección de las 4 firmas necesarias para la transacción multisig. YAM cree que la suspensión de emergencia debería requerir solo una firma, y el permiso debería asignarse preferentemente a miembros del equipo o a operadores externos de confianza, para aumentar la atención sobre el comportamiento anómalo en la cadena, mejorar la posibilidad de una suspensión rápida y cubrir mejor las diferentes zonas horarias.
Aunque la sugerencia de requerir solo una firma para suspender el protocolo es algo radical, el hecho de necesitar múltiples firmas en diferentes zonas horarias para pausar el protocolo ciertamente puede causar grandes problemas cuando ocurre una emergencia. Introducir terceros de confianza que monitoreen continuamente el comportamiento en cadena, o utilizar herramientas de monitoreo con permisos para suspender el protocolo en emergencias, son lecciones aprendidas de este incidente.
Los ataques de hackers a protocolos DeFi ya no se limitan a vulnerabilidades de contratos. El incidente de Resolv Labs advierte a los equipos de proyectos que la suposición en la seguridad del protocolo debería ser no confiar en ningún eslabón individual. Todos los eslabones que involucren parámetros deben ser verificados al menos dos veces, incluso el backend operado por el propio equipo del proyecto.
