Redactado por: Eric, Foresight News
Hoy, alrededor de las 10:21 hora de Beijing, Resolv Labs, que emitió el stablecoin USR utilizando una estrategia Delta neutral, fue atacado por hackers. La dirección que comienza con 0x04A2 acuñó 50 millones de USR utilizando 100,000 USDC del protocolo de Resolv Labs.
Con la exposición del evento, el USR cayó a alrededor de 0.25 dólares, y al momento de redactar, se había recuperado a cerca de 0.8 dólares. El precio del token RESOLV también experimentó una caída máxima cercana al 10%.
Después, los hackers repitieron el mismo método, utilizando 100,000 USDC para acuñar 30 millones de USR. A medida que el USR se desacopló drásticamente, los comerciantes de arbitraje también actuaron rápidamente, y muchos mercados de préstamos en Morpho que soportaban USR, wstUSR, etc., como colateral, fueron prácticamente vaciados; Lista DAO en la cadena BNB también suspendió nuevas solicitudes de préstamo.
No solo estos protocolos de préstamo se vieron afectados. 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 la responsabilidad de compensación en caso de que el protocolo sufra pérdidas. Actualmente, el suministro circulante de tokens RLP es de casi 30 millones, siendo Stream Finance el mayor tenedor con más de 13 millones de RLP, teniendo una exposición al riesgo neto de aproximadamente 17 millones de dólares.
Ciertamente, Stream Finance, que ya sufrió una crisis con xUSD, podría ser golpeado nuevamente.
Al momento de redactar, los hackers ya habían convertido USR a USDC y USDT, y continuaron comprando Ethereum, habiendo adquirido más de 10,000 hasta el momento. Con 200,000 USDC, extrajeron más de 20 millones de dólares en activos, y los hackers encontraron su "moneda de cien veces" durante el mercado bajista.
Una vez más, se aprovechó la "falta de rigor".
La caída del 11 de octubre del año pasado llevó a que muchos stablecoins emitidos con estrategias Delta neutrales sufrieran pérdidas colaterales debido a ADL (reducción automática de apalancamiento). Algunos proyectos que ejecutaron estrategias con altcoins sufrieron pérdidas aún más severas e incluso desaparecieron por completo.
Esta vez, Resolv Labs, que fue atacado, también emitió USR utilizando un mecanismo similar. El proyecto anunció en abril de 2025 que había completado una ronda de financiación inicial 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 condición de mercado extrema, sino que el diseño del mecanismo para acuñar USR era "demasiado poco riguroso".
Actualmente, no hay ninguna empresa de seguridad o autoridad que haya analizado las razones detrás de este ataque. La comunidad DeFi YAM llegó a la conclusión preliminar a través de un análisis: el ataque probablemente fue causado por el CONTROL de SERVICE_ROLE que se utiliza en el backend del protocolo para proporcionar parámetros al contrato de acuñación, que fue tomado por los hackers.
Según el análisis de Grok, cuando los usuarios acuñan USR, generan 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 que se espera recibir (punto de deslizamiento).
Luego, los usuarios depositan USDC o USDT en el contrato, el SERVICE_ROLE del backend del equipo del proyecto monitorea la solicitud, utiliza el oráculo de 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 ese número ha sido verificado fuera de la cadena por Pyth, por lo que no se estableció un límite superior ni se realizó una verificación con un oráculo en la cadena, simplemente ejecutó mint(_mintAmount).
En consecuencia, YAM sospecha que los hackers controlaron el SERVICE_ROLE que debería estar bajo el control del equipo del proyecto (posiblemente debido a un oráculo interno fuera de control, robo de confianza o pérdida de claves), configurando directamente el _mintAmount en 50 millones durante el proceso de acuñación, logrando así el evento de ataque que permitió 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) encargada de recibir las solicitudes de acuñación de los usuarios fuera controlada por hackers. Al enviar la solicitud para acuñar USR al contrato final que acuñaría 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 adicional 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 insuficiente.
Además de especular sobre las razones del hackeo, YAM también destacó la insuficiente preparación del equipo del proyecto para enfrentar la crisis.
YAM comentó en X que Resolv Labs solo suspendió el protocolo tres horas después de completar el primer ataque de los hackers, y que alrededor de una hora de retraso se debió a la necesidad de recopilar las cuatro firmas requeridas para la transacción multifirma. YAM considera que la suspensión de emergencia debería requerir solo una firma, y que los permisos deben ser asignados en la medida de lo posible a los miembros del equipo, o a operadores externos de confianza, lo que puede aumentar la atención a las anomalías en la cadena y mejorar las posibilidades de una rápida suspensión, además de cubrir mejor las diferentes zonas horarias.
Aunque la sugerencia de que una sola firma puede suspender el protocolo parece algo radical, la necesidad de múltiples firmas en diferentes zonas horarias para suspender el protocolo puede, de hecho, retrasar la acción en situaciones de emergencia. Introducir un tercero de confianza que monitoree continuamente el comportamiento en la cadena, o utilizar herramientas de monitoreo con permisos para suspender el protocolo de emergencia, son lecciones que deja este evento.
Los ataques de hackers a protocolos DeFi ya no se limitan a vulnerabilidades en contratos. El evento de Resolv Labs advierte a los equipos de proyecto que no deben confiar en ninguna parte de la seguridad del protocolo; todos los aspectos que involucran parámetros deben ser verificados al menos dos veces, incluso el backend operado por el equipo del proyecto no es una excepción.