Back to Blog

Análisis en profundidad y reflexiones sobre el incidente de ataque al protocolo Resupply

Phalcon Security
6 de julio de 2025
12 min read

El 26 de junio de 2025, el protocolo de stablecoin Resupply desplegado en la red principal de Ethereum fue atacado, lo que resultó en la pérdida de aproximadamente $10 millones en activos. Debido a un problema en la implementación del oráculo de precios del contrato relevante, para los Markets recién creados con baja liquidez, el atacante pudo manipular el precio relativo (es decir, la tasa de cambio entre el activo prestado y el activo colateral) del activo prestado (reUSD emitido por Resupply) mediante un ataque de donación, llevándolo a 0. Esto permitió al atacante eludir la verificación de salud del activo y tomar prestado una gran cantidad de reUSD para obtener ganancias.

Después de que BlockSec fuera el primero en la red en emitir públicamente una alerta temprana y proporcionar un análisis preliminar (Tweet1, Tweet2), Resupply también publicó posteriormente un anuncio oficial, pero no profundizó en muchos detalles técnicos. Este artículo proporcionará un análisis más detallado. Por otro lado, tras el ataque, también hubo una intensa controversia comunitaria entre las partes del proyecto y sus interesados. Este artículo profundizará y discutirá las complejas relaciones ecológicas detrás del protocolo, para referencia de los lectores.


1. Antecedentes

1.1 Sobre el protocolo Resupply

Resupply es un protocolo de stablecoin descentralizado que pertenece al ecosistema de Curve. La stablecoin emitida por Resupply se llama reUSD. Se trata de una stablecoin descentralizada respaldada por posiciones de deuda colateralizadas (CDPs), respaldadas por otras stablecoins — incluyendo crvUSD y frxUSD — que generan intereses en los mercados de préstamo de plataformas externas. Los usuarios pueden aportar crvUSD y frxUSD para tomar prestado reUSD, logrando así la refinanciación de activos en stablecoins.

Específicamente, los usuarios pueden realizar operaciones relacionadas con préstamos en un Market de Resupply desplegado en la cadena. La creación y el comportamiento de los Markets se gestionan a través del DAO. Cada Market especifica una Vault ERC-4626 como activo colateral (collateral) y utiliza el activo correspondiente a esa Vault como el subyacente (underlying). Los usuarios depositan colateral (la Vault o el activo de la Vault) en el Market para tomar prestado reUSD.

Tomando como ejemplo el Market 0x6e90 y la Vault 0x0114 involucrados en este ataque, los activos (tokens) relevantes son los siguientes:

  • Market 0x6e90

    • underlying: crvUSD
    • collateral: cvcrvUSD (es decir, Vault 0x0114)
    • borrowed: reUSD
  • Vault 0x0114

    • asset: crvUSD (almacenado en realidad en el Controller de Curve LlamaLend, que también es un Market)
    • collateral: wstUSR
    • borrowed: crvUSD
    • share: cvcrvUSD (el token ERC-4626 emitido por la Vault)

En otras palabras, los usuarios pueden empeñar cierta cantidad de cvcrvUSD (o crvUSD, que en la práctica se convertirá en cvcrvUSD mediante la Vault) en este Market para tomar prestado reUSD.


1.2 ¿Cómo determina el sistema si un usuario es elegible para tomar prestado un activo?

Similar a los protocolos de préstamo en general, el Market de Resupply también realiza una verificación de salud del activo sobre la posición de un usuario (a través del modificador isSolvent).

isSolvent finalmente llama a la función _isSolvent, que verifica el LTV (relación préstamo-valor), exigiendo que la proporción entre el activo prestado y el activo colateral no exceda el valor máximo establecido por el sistema (_ltv <= maxLTV).

Se puede observar que el cálculo del LTV depende de la tasa de cambio (_exchangeRate), es decir, del precio (relación de intercambio) del activo prestado respecto al activo colateral.


2. Análisis del ataque

2.1 Análisis de la causa raíz

Desde la perspectiva del código del contrato, la causa clave del ataque fue que la implementación del oráculo de precios del Market de Resupply tenía un problema. Para los Markets recién creados con baja liquidez, el atacante podía manipular la tasa de cambio mediante un ataque de donación, eludiendo así la verificación de salud y tomando prestado una gran cantidad de reUSD para obtener ganancias.

¿Cómo se calcula la tasa de cambio?

La fórmula es la siguiente:

Obviamente, si getPrices devuelve un precio mayor que 1e36, el redondeo hacia abajo de la división entera dará como resultado _exchangeRate = 0.

¿Cómo manipular el precio?

Según el código, el precio se puede calcular de la siguiente manera:

Dado que el código establece precision = 1, DEAD_SHARES = 1000, y shares = 1e18.

Finalmente, tras sustituir las variables, la fórmula de cálculo del precio es la siguiente:

Se puede observar que para amplificar el valor de price, la clave está en ampliar la brecha entre total_assets y totalSupply, haciendo que total_assets sea extremadamente grande mientras que totalSupply permanece muy pequeño. En la implementación real del protocolo Resupply, total_assets en la fórmula depende del underlying (crvUSD), y totalSupply depende de las shares (cvcrvUSD) correspondientes a la liquidez total en el Market. Este es precisamente el escenario clásico de un ataque de donación.

2.2 Análisis de la transacción del ataque

Según la transacción de ataque [4], se puede analizar que el atacante realizó los siguientes pasos principales:

  1. Tomó prestados 4,000 USDC mediante un préstamo flash y los intercambió por 3,999 crvUSD.

  2. Donó 2,000 crvUSD al Controller 0x8970. Antes de la donación, el Controller 0x8970 tenía 0 crvUSD. Después de la donación, la cantidad registrada de crvUSD pasó a ser 2000000000000000000000 (con 18 decimales).

  3. Depositó aproximadamente 2 crvUSD en la Vault 0x0114 y recibió 1 share (cvcrvUSD). En este punto, la cantidad registrada de crvUSD era 2002000000000000000001 (con 18 decimales).

  4. Añadió 1 unidad (es decir, 1 share de la Vault 0x0114) de colateral al Market 0x6e90.

  5. Tomó prestados 10,000,000 de reUSD del Market 0x6e90. En este punto, _exchangeRate = 0, lo que resultó en _ltv = 0, por lo que la verificación _isSolvent fue aprobada.

¿Por qué _exchangeRate era igual a 0? Porque a través de los pasos anteriores, el atacante manipuló el contrato para llegar al siguiente estado:

Recordando el método de cálculo de la tasa de cambio:

Dado que price > 1e36, _exchangeRate = 0.

  1. Intercambió el reUSD tomado prestado para obtener ganancias.

3. Lecciones aprendidas

El Market atacado en Resupply utilizaba una implementación de oráculo de precios similar al contrato de plantilla de Curve.

Sin embargo, la documentación oficial de Curve ya había indicado el ámbito de aplicación de esta implementación — desafortunadamente, Resupply no pareció tener en cuenta esta advertencia de aplicabilidad en su despliegue.

4. Relaciones y controversia comunitaria

4.1 Red de relaciones compleja de cinco proyectos principales en el ecosistema de Curve

Para comprender el impacto más profundo del incidente de Resupply, primero debemos observar las complejas relaciones entre los cinco protocolos centrales dentro del ecosistema de Curve.

Curve Finance es el núcleo de todo el ecosistema, proporcionando pools de liquidez, crvUSD y el protocolo LlamaLend, que sustentan las operaciones de Resupply, Prisma, Convex y Yearn. Convex optimiza el rendimiento de Curve mediante staking y gobernanza, y proporciona mecanismos de recompensa adicionales para Prisma y Resupply. Prisma depende de los tokens LP de Curve y de las funciones de mejora de rendimiento de Convex, mientras que Resupply se basa directamente en LlamaLend de Curve para emitir reUSD y fue desarrollado conjuntamente por Convex y Yearn. Yearn no solo optimiza los rendimientos de los pools de Curve, sino que también impulsó el desarrollo de Resupply mediante la colaboración con Convex.

Curve Finance: Como plataforma central, los pools de liquidez de Curve (como el pool de crvUSD) y el protocolo LlamaLend son utilizados directamente por Resupply para emitir reUSD, por Prisma para hacer staking de tokens LP, por Yearn para la optimización de rendimientos, y por Convex para votaciones de gobernanza.

Convex: Convex es el protocolo de mejora de rendimiento de Curve. Los usuarios pueden hacer staking de tokens LP de Curve para obtener mayores recompensas en CRV, así como tokens CVX de Convex. Convex controla casi el 50% del poder de voto de gobernanza de Curve y proporciona mecanismos de mejora de rendimiento para Prisma y Resupply.

Prisma: Prisma hace staking de los tokens LP de Curve, y los usuarios obtienen recompensas mejoradas (cvxPRISMA) a través de Convex. Prisma depende de la liquidez de Curve y de los mecanismos de rendimiento de Convex.

Yearn: Yearn es un agregador de rendimiento que ofrece a los usuarios altos retornos optimizando los rendimientos de los tokens LP de Curve (mejorados a través de Convex). Yearn colaboró con Convex para desarrollar Resupply y utiliza extensamente los pools de Curve en sus estrategias de rendimiento.

Resupply: Desarrollado conjuntamente por Convex y Yearn, permite a los usuarios tomar prestado reUSD empeñando stablecoins como crvUSD y automáticamente hace staking de tokens en Convex para obtener recompensas en CRV y CVX, formando un bucle de optimización de rendimiento.

4.2 Controversia e impacto

Sin embargo, cuando Resupply fue atacado, esta compleja red de relaciones se convirtió inmediatamente en el foco de la controversia. El fundador de Curve, Michael Egorov, rápidamente se distanció de Resupply, enfatizando:

“No hay ni una sola persona de Curve trabajando en ese proyecto… por favor no generalicen hacia Curve.”

Esta declaración de desvinculación reflejó cómo las intrincadas relaciones de cooperación dentro del ecosistema DeFi pueden ser frágiles en tiempos de crisis.

Estos proyectos interrelacionados forman juntos un ecosistema altamente acoplado — en un sistema así, cualquier problema en un eslabón puede desencadenar una reacción en cadena. Por lo tanto, no es sorprendente que el incidente de ataque a Resupply haya generado un amplio debate en la comunidad sobre la interdependencia y la seguridad de los protocolos.


5. Reflexiones adicionales

5.1 Cronología

  • 17 de mayo de 2025: La dirección oficial de Resupply 0x1f84 desplegó un nuevo Market de LlamaLend a través de la Curve's OneWay Lending Factory.

    • El Market utilizaba crvUSD como activo de préstamo y wstUSR como token de colateral.
    • El contrato de la Vault ERC-4626 era 0x0114, y el Controller correspondiente era 0x8970.
  • 31 de mayo de 2025: Se publicó una nueva propuesta wstUSR-long LlamaLend Market en la página de gobernanza de Resupply. Esta propuesta tenía como objetivo permitir a los usuarios acuñar reUSD a través del Market de LlamaLend.

  • 11 de junio de 2025: La propuesta se publicó en la cadena.

  • 26 de junio de 2025, 00:18:47 (UTC): La propuesta fue aprobada, y la dirección oficial de Resupply 0x0417 desplegó un nuevo ResupplyPair (es decir, el Market crvUSD/wstUSR de Resupply) 0x6e90, vinculando la Vault 0x0114 y el Controller 0x8970.

    • Vinculó la Vault 0x0114 y el Controller 0x8970.
    • Utilizó la posición de deuda colateralizada de la Vault (es decir, cvcrvUSD, con crvUSD como underlying) como colateral.
  • 26 de junio de 2025, 01:53:59 (UTC): Aproximadamente 1.5 horas después del despliegue del Market 0x6e90, el atacante ejecutó con éxito el exploit. Al mismo tiempo, BlockSec detectó el ataque e intentó contactar al equipo del proyecto.

  • 26 de junio de 2025, 02:26 (UTC): Después de no poder contactar al equipo y confirmar que no había más pérdidas, BlockSec emitió una advertencia pública.

  • 26 de junio de 2025, 02:53:23 (UTC): El equipo del proyecto pausó el protocolo.

5.2 Si hubiera existido Phalcon Security, la tragedia podría haberse evitado

BlockSec Phalcon Security representa el último avance en protección de seguridad DeFi. Al monitorear las transacciones en la etapa de mempool, Phalcon Security es capaz de identificar patrones anómalos en el instante en que una transacción de ataque entra en el mempool.

El sistema, impulsado por un motor de análisis inteligente, integra más de 200 firmas de ataque típicas. En los últimos seis meses, ha mantenido una tasa de falsos positivos ultra baja de menos del 0.0001%, logrando una detección de amenazas verdaderamente precisa.

El sistema aprovecha una estrategia patentada de puja de gas para garantizar que la transacción de defensa supere en velocidad a la transacción de ataque, mientras activa automáticamente la función de pausa de emergencia del protocolo.

Todo el proceso de respuesta admite múltiples modos de control de permisos — incluyendo billeteras EOA y multisig — proporcionando soluciones de seguridad flexibles para diferentes tipos de protocolos.

Si Resupply hubiera integrado el sistema Phalcon Security al desplegar el Market, el ataque podría haberse evitado por completo

Dentro de las 1.5 horas posteriores al despliegue del Market 0x6e90, el sistema Phalcon Security habría detectado automáticamente el nuevo despliegue del Market, analizado de manera inteligente sus parámetros de configuración e identificado el riesgo potencial de un ataque de donación.

El sistema habría enviado inmediatamente una alerta de riesgo al equipo del proyecto, sugiriendo agregar protección de liquidez inicial o ajustar los parámetros relevantes.

Incluso después de que ocurriera el ataque, desplegar Phalcon Security seguiría aportando un enorme valor a Resupply y a todo el ecosistema de Curve

Un sistema de monitoreo transparente y en tiempo real demuestra a los usuarios y a la comunidad el firme compromiso del equipo del proyecto con la seguridad, y el mecanismo de protección continua 24/7 garantiza que incidentes similares nunca vuelvan a ocurrir. Los datos públicos de monitoreo de seguridad mejoran la transparencia del proyecto y sirven como un medio crítico para reconstruir la confianza de la comunidad. Para los proyectos afectados, adoptar proactivamente una solución de seguridad de primer nivel demuestra su sentido de responsabilidad por la seguridad de los fondos de los usuarios, y asociarse con un líder de la industria como BlockSec también proporciona un fuerte respaldo para la reputación del proyecto en el campo de la seguridad.

Actualmente, más de $50 mil millones en activos han elegido confiar en la protección de Phalcon Security. Hemos detenido con éxito más de 20 ataques de hackeo en el mundo real, ahorrando más de $20 millones en pérdidas de activos. En los últimos seis meses, el sistema ha mantenido un registro perfecto de precisión en la detección y ha logrado velocidades de respuesta a nivel de milisegundos, manteniéndose siempre un paso adelante de los atacantes. Phalcon Security actualmente admite más de 20 redes blockchain importantes, incluyendo Ethereum, BSC y Arbitrum, proporcionando una protección de seguridad integral y multicadena para el ecosistema DeFi.

La pérdida de $10 millones de Resupply y otros innumerables incidentes de ataque nos dicen que, en el mundo DeFi, la seguridad no es una opción — es una necesidad para sobrevivir.

No esperes al próximo ataque para arrepentirte. Despliega ahora la protección de seguridad más fuerte para tu protocolo.

El equipo de expertos de BlockSec está listo para realizar una evaluación integral de seguridad para tu proyecto.

🔗 Phalcon Security:

https://blocksec.com/phalcon/security

🔗 Reserva una demo:

https://blocksec.com/book-demo

Get Real-Time Protection with Phalcon Security

Audits alone are not enough. Phalcon Security detects attacks in real time and blocks threats mid-flight.

phalcon security