Solo con fines educativos; no constituye asesoramiento de inversión. Invertir puede ocasionar pérdidas.
Respuesta directa
Un ataque de inflación del primer depósito tiene como objetivo una bóveda ERC-4626 vacía o casi vacía. El atacante deposita una cantidad pequeña para recibir las primeras participaciones y después transfiere directamente los activos subyacentes a la bóveda. Esta donación aumenta totalAssets() sin aumentar totalSupply(), haciendo más valiosa cada participación existente.
Si el depósito de la víctima se convierte con ese tipo de cambio manipulado, la división entera puede redondear el resultado a muy pocas participaciones o a cero. Los activos de la víctima permanecen en la bóveda, mientras que el atacante, como titular de las participaciones en circulación, puede rescatar el derecho inflado. Es un problema de manipulación del tipo de cambio y de deslizamiento, no un defecto de la interfaz ERC-4626.
Cómo funciona
En una bóveda sencilla sin comisiones ni desplazamientos protectores, las participaciones acuñadas por un depósito son aproximadamente assets * totalSupply / totalAssets. ERC-4626 exige que el cálculo de participaciones para una cantidad de activos favorezca a la bóveda mediante redondeo hacia abajo. Con tipos de cambio normales la pérdida por redondeo es pequeña, pero un depósito con valor inferior a una participación puede perder el 100% por redondeo cuando se ha inflado su precio.
El ataque depende de los detalles de la implementación. Una transferencia directa de ERC-20 puede aumentar los activos contabilizados por la bóveda sin acuñar participaciones, especialmente cuando totalAssets() lee el saldo de tokens de la bóveda. El atacante también debe adelantarse a la víctima cuando la oferta de participaciones es muy baja. Las bóvedas que usan otra contabilidad o defensas explícitas quizá no sean vulnerables de la misma manera.
Ejemplo
Supón que una bóveda vacía vulnerable comienza con una tasa de 1:1. El atacante deposita 1 unidad de activo y recibe 1 participación, y luego dona directamente 999 unidades. La bóveda tiene ahora 1,000 activos respaldando 1 participación. La víctima deposita 999 unidades, por lo que el cálculo ingenuo es 999 * 1 / 1,000 = 0 participaciones tras el redondeo entero.
La bóveda pasa a tener 1,999 activos y solo existe la 1 participación del atacante. Si el depósito permite un resultado de cero participaciones y no hay comisiones ni otras restricciones, el atacante puede rescatar esa participación por los 1,999 activos: la 1 unidad depositada originalmente, las 999 unidades donadas y las 999 unidades depositadas por la víctima. Su beneficio bruto es de 999 unidades de la víctima, antes de los costes de transacción.
Riesgos y defensas
Los implementadores pueden reducir el riesgo aportando liquidez inicial significativa, quemando o bloqueando las participaciones iniciales, exigiendo un resultado mínimo de al menos una participación o usando un diseño de tipo de cambio con activos y participaciones virtuales. La implementación de OpenZeppelin añade cantidades virtuales y admite más precisión mediante un desplazamiento de decimales; en el modelo documentado, las participaciones virtuales capturan parte de cada donación, haciendo que la manipulación no sea rentable o sea mucho más costosa. Cada defensa tiene supuestos y debe probarse frente a transferencias directas, límites de redondeo, comisiones, pérdidas y comportamientos inusuales de los tokens.
Los usuarios y las integraciones deben tratar previewDeposit() como una cotización, no como un mínimo garantizado. Envía los depósitos mediante una función o un router que imponga una cantidad mínima aceptable de participaciones y revierta si no se alcanza. Antes de depositar en una bóveda nueva o con pocas participaciones, revisa totalAssets(), totalSupply(), la fórmula de conversión de la implementación y si las transferencias de tokens no solicitadas afectan a la contabilidad. Una cotización favorable del frontend no protege una transacción cuyo orden de ejecución pueda cambiarse.
Errores comunes
-
Mito 1: ERC-4626 garantiza por sí mismo un tipo de cambio seguro. El estándar define una interfaz común y un comportamiento de redondeo, pero no hace que todas las implementaciones sean inmunes a la manipulación del tipo de cambio.
-
Mito 2: Llamar a
previewDeposit()justo antes dedeposit()garantiza ese resultado. El estado de la cadena puede cambiar entre las llamadas o antes de la ejecución. La ruta de depósito necesita un límite mínimo de participaciones que pueda hacerse cumplir. -
Mito 3: Rechazar solo los depósitos con cero participaciones elimina el ataque. Evita el resultado más extremo, pero un atacante aún puede hacer que un depósito reciba pocas participaciones y sufra una gran pérdida por redondeo. Las defensas deben limitar el deslizamiento aceptable, no exigir únicamente un resultado distinto de cero.
Temas relacionados
- Estándar de bóvedas ERC-4626
- Prueba de fraude
- Toma de control del inicializador de un contrato actualizable
- Contrato inteligente
- Simulación de transacciones
Fuentes
- ERC-4626: bóvedas tokenizadas - Ethereum Improvement Proposals (consultado: 2026-08-20)
- Estándar de bóvedas tokenizadas ERC-4626 - OpenZeppelin (consultado: 2026-08-20)
- Implementación ERC4626 de OpenZeppelin - OpenZeppelin (consultado: 2026-08-20)