Artículo de: Eric, Foresight News
Aproximadamente a las 10:21 hora de Pekín, Resolv Labs, que emitió la moneda estable USR mediante una estrategia de delta neutro, sufrió un ataque de hackers. La dirección que comienza con 0x04A2 acuñó 50 millones de USR en 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 este artículo se recuperó a alrededor de 0.8 dólares. El precio del token RESOLV también experimentó una caída máxima temporal de cerca del 10%.
Luego, el hacker repitió el mismo método para acuñar 30 millones de USR con 100,000 USDC. Con el fuerte desvinculamiento de USR, los operadores de arbitraje actuaron rápidamente; muchos mercados de préstamos en Morpho que admitían USR, wstUSR y otros como garantía casi se han vaciado, y Lista DAO en BNB Chain también ha suspendido nuevas solicitudes de préstamos.
No solo estos protocolos de préstamo se ven afectados. En el diseño del protocolo de Resolv Labs, los usuarios también pueden acuñar un token RLP con mayor volatilidad de precio y mayores rendimientos, pero que requiere que los poseedores asuman responsabilidad por pérdidas del protocolo. Actualmente, la oferta circulante del token RLP es de aproximadamente 30 millones de unidades, y el mayor titular, Stream Finance, posee más de 13 millones de RLP, con un riesgo neto expuesto de aproximadamente 17 millones de dólares.
Sí, Stream Finance, que anteriormente sufrió un colapso con xUSD, podría ser golpeada nuevamente.
Al momento de redactar este artículo, el hacker ha convertido USR en USDC y USDT, y ha continuado comprando Ethereum, adquiriendo ya más de 10,000 unidades. Con 200,000 USDC, ha extraído más de 20 millones de dólares en activos; durante el mercado bajista, el hacker encontró su "criptomoneda de cien veces".
Otra vez se aprovecharon de la «falta de rigor»
La caída del 11 de octubre del año pasado provocó pérdidas de garantía en muchas stablecoins emitidas con estrategias de delta neutro debido a ADL (desapalancamiento automático). Algunos proyectos que utilizaban altcoins como activos para ejecutar sus estrategias sufrieron pérdidas aún más graves e incluso desaparecieron directamente.
Resolv Labs, también atacada en esta ocasión, emitió USR utilizando un mecanismo similar. El proyecto anunció en abril de 2025 la finalización de 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ó el token RESOLV a finales de mayo y principios de junio.
Pero la razón por la que Resolv Labs fue atacado no fue el mercado extremo, sino que el diseño del mecanismo de acuñación de USR era «insuficientemente riguroso».
Actualmente, ninguna empresa de seguridad ni autoridad oficial ha analizado la causa de este incidente de hacking. La comunidad DeFi YAM, tras un análisis preliminar, concluyó que el ataque probablemente se debió a que el hacker controló el SERVICE_ROLE utilizado por el backend del protocolo para proporcionar parámetros al contrato de acuñación.
Según el análisis de Grok, cuando los usuarios acuñan USR, inician una solicitud en la cadena y llaman a la función requestMint del contrato, con los siguientes parámetros:
_depositTokenAddress: Dirección del token depositado;
_amount: cantidad depositada;
_minMintAmount: 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 con SERVICE_ROLE monitorea la solicitud, verifica el valor de los activos depositados mediante 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 _mintAmount proporcionado por SERVICE_ROLE, asumiendo que este número ha sido verificado fuera de la cadena por Pyth, por lo que no se estableció ningún límite superior ni se realizó ninguna verificación de oráculo en la cadena, y se ejecutó directamente mint(_mintAmount).
En consecuencia, YAM sospecha que el hacker controló el SERVICE_ROLE, que debería haber estado bajo el control del equipo del proyecto (posiblemente debido a una falla interna del oráculo, malversación o robo de claves), y estableció directamente _mintAmount en 50 millones durante la acuñación, llevando a cabo el ataque que permitió crear 50 millones de USR con solo 100.000 USDC.
En última instancia, Grok concluye que Resolv no consideró la posibilidad de que la dirección (o contrato) diseñada para recibir solicitudes de acuñación de usuarios fuera comprometida por hackers, no estableció un límite máximo de acuñación cuando las solicitudes de acuñación de USR se enviaron al contrato final que acuña USR, y tampoco utilizó un oráculo en cadena para una validación secundaria, confiando directamente en todos los parámetros proporcionados por SERVICE_ROLE.
La prevención tampoco es adecuada
Además de especular sobre las causas del hackeo, YAM también señaló la falta de preparación del equipo del proyecto para hacer frente a la crisis.
YAM indicó en X que Resolv Labs suspendió el protocolo tres horas después de que se completara el primer ataque, con aproximadamente una hora de retraso debido a la recopilación de las cuatro firmas necesarias para las transacciones de multifactores. 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 miembros del equipo o operadores externos confiables, para aumentar la atención a anomalías en la cadena, mejorar la posibilidad de una suspensión rápida y cubrir mejor diferentes zonas horarias.
Aunque la sugerencia de que solo se requiera una firma para pausar el protocolo es algo radical, requerir múltiples firmas de personas en diferentes zonas horarias para pausar el protocolo puede retrasar críticamente la respuesta en caso de emergencia. Introducir un tercero confiable que monitoree continuamente el comportamiento en la cadena, o utilizar herramientas de monitoreo con permiso para pausar el protocolo en emergencias, son lecciones aprendidas de este evento.
Los ataques de hackers a los protocolos DeFi ya no se limitan a vulnerabilidades en contratos; el incidente de Resolv Labs sirve como advertencia a los equipos de proyectos: se debe asumir que ninguna parte del protocolo es confiable, y todos los componentes relacionados con parámetros deben someterse al menos a una verificación secundaria, incluso si el backend es operado por el propio proyecto.