Resolv Labs Sufrió un Ataque, Los Proyectos DeFi Fueron Explotados Nuevamente

Resolv Labs, la entidad emisora de la stablecoin USR que utiliza una estrategia Delta neutral, ha sido atacada. Una dirección que comienza con 0x04A2 creó 50 millones de USR desde el protocolo Resolv Labs con 100,000 USDC.
Después de que se revelara el incidente, el precio de USR cayó inmediatamente a aproximadamente 0,25 dólares, antes de recuperarse a unos 0,80 dólares en el momento de escribir este artículo. El precio del token RESOLV también cayó casi un 10% en poco tiempo.

Luego, los hackers usaron un método similar para crear 30 millones de USR con 100,000 USDC. Cuando USR perdió valor significativamente, los especuladores aprovecharon rápidamente, y muchos mercados de préstamo en Morpho que soportan USR, wstUSR y otros activos colaterales quedaron casi agotados. La lista DAO en la cadena BNB también suspendió las nuevas solicitudes de préstamo.

Estos protocolos de préstamo no son los únicos afectados. El protocolo Resolv Labs también permite a los usuarios crear tokens RLP, lo que genera mayor volatilidad de precios y mayores ganancias, pero también los hace responsables legalmente por las pérdidas derivadas del protocolo. Actualmente, hay cerca de 30 millones de tokens RLP en circulación, de los cuales Stream Finance posee más de 13 millones, representando un riesgo neto de aproximadamente 17 millones de dólares.
Así es, Stream Finance, la compañía que sufrió grandes pérdidas por xUSD, podría estar a punto de enfrentar otro golpe.
Hasta el momento de escribir, los hackers han convertido USR en USDC y USDT y continúan comprando Ethereum, habiendo adquirido más de 10,000 ETH. Con 200,000 USDC, los hackers han recuperado más de 20 millones de dólares en activos, encontrando su “moneda rentable 100 veces” en el mercado bajista.
Una vez más, una vulnerabilidad fue explotada debido a una “falta de rigor”.

La fuerte caída del 11 de octubre pasado provocó que muchos stablecoins emitidos con estrategia Delta-neutral sufrieran pérdidas en sus colaterales por ADL (reducción automática de apalancamiento). Algunos proyectos que usan altcoins como activos enfrentaron pérdidas aún mayores, e incluso algunos desaparecieron por completo.

Resolv Labs, el proyecto atacado esta vez, también utiliza un mecanismo similar para emitir USR. En abril de 2025, el proyecto anunció que había completado 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.

Sin embargo, la razón del ataque a Resolv Labs no fue un mercado hostil, sino que el mecanismo para crear USR “no era lo suficientemente riguroso”.
Hasta ahora, ninguna empresa de seguridad ni autoridad oficial ha analizado las causas de este ciberataque. Un análisis preliminar del miembro de la comunidad DeFi YAM sugiere que el ataque probablemente se debió a que los hackers tomaron control del rol SERVICE_ROLE, utilizado en la parte auxiliar del protocolo para proporcionar parámetros al contrato de creación de dinero digital.

Según Grok, cuando un usuario crea USR, inicia una solicitud en la cadena y llama a la función requestMint del contrato, con parámetros que incluyen:
_depositTokenAddress: La dirección donde se envía el token;
_amount: La cantidad a almacenar;
_minMintAmount: La cantidad mínima de USR que se espera recibir (punto de protección contra deslizamiento).

Luego, el usuario envía USDC o USDT al contrato. La parte auxiliar SERVICE_ROLE del proyecto supervisa la solicitud, usando el oracle Pyth para verificar el valor del activo enviado, y luego llama a las funciones completeMint o completeSwap para determinar la cantidad real de USR creada.

El problema radica en que el contrato de acuñación confía completamente en el valor de mintAmount proporcionado por SERVICE_ROLE, asumiendo que este valor ha sido verificado por Pyth fuera de la cadena. Por lo tanto, no establece límites superiores ni verifica con un oracle en la cadena, sino que simplemente ejecuta mint(_mintAmount).

Basándose en esto, YAM sospecha que los hackers tomaron control del rol SERVICE_ROLE, que debería estar bajo control del equipo del proyecto (posiblemente por una falla en el sistema oracle interno, robo interno o robo de claves), y establecieron directamente _mintAmount en 50 millones durante la creación de dinero falso, logrando así crear 50 millones de USR con 100,000 USDC.

Finalmente, Grok concluye que Resolv no consideró la posibilidad de que la dirección (o contrato) que recibe las solicitudes de creación de USR pudiera estar bajo control de hackers al diseñar el protocolo. Cuando la solicitud de creación de USR llega al contrato que finalmente genera USR, no se establece ningún límite máximo de cantidad y el contrato no usa un oracle en la cadena para verificar de forma secundaria. En cambio, confía directamente en todos los parámetros proporcionados por SERVICE_ROLE.

Las medidas preventivas también son insuficientes.

Además de especular sobre las causas del ataque, YAM señala la falta de preparación del equipo del proyecto para gestionar una crisis.
YAM declaró en X que Resolv Labs solo suspendió el protocolo durante tres horas tras el ataque inicial, de las cuales aproximadamente una hora fue para recopilar las cuatro firmas necesarias para las transacciones multisig. YAM opina que la suspensión de emergencia debería requerir solo una firma, y que este poder debería ser otorgado a miembros del equipo o a operadores externos confiables siempre que sea posible. Esto aumentaría la conciencia sobre anomalías en la cadena, mejoraría la capacidad de detener rápidamente y cubrir diferentes zonas horarias.

Aunque la propuesta de suspender un protocolo con una sola firma puede parecer extrema, exigir múltiples firmas desde diferentes zonas horarias para detener un protocolo en una emergencia puede causar retrasos significativos. La introducción de un tercero confiable que supervise continuamente el comportamiento en la cadena, o el uso de herramientas de monitoreo con capacidad de detener en emergencias, son lecciones aprendidas de este incidente.

Los ataques de hackers a protocolos DeFi han sido tradicionalmente limitados a vulnerabilidades en los contratos. El incidente de Resolv Labs es una advertencia para los equipos de proyectos: la seguridad del protocolo no debe confiar en ninguna parte del mismo, y todos los enlaces relacionados con parámetros deben pasar por al menos dos verificaciones, incluso en los servidores operados por el propio equipo.