Desbordamiento del multiplicador de comisión en Velocore

El 2 de junio de 2024, el exchange descentralizado Velocore — desplegado tanto en zkSync Era como en Linea — fue drenado por aproximadamente $6,8 millones en ETH mediante un bug de precisión/desbordamiento en la lógica del multiplicador de comisión de su contrato de pool CPMM estilo Balancer.

Qué ocurrió

Los pools CPMM (Constant Product Market Maker) de Velocore usaban un parámetro de multiplicador de comisión que escalaba con el tamaño de los retiros para desalentar el sifón de liquidez. El comportamiento previsto: los grandes retiros pagan mayores comisiones.

El atacante encontró que el cálculo de la comisión no tenía chequeo de límite superior y podía desbordarse a valores sin sentido:

1. El atacante invocó velocore__execute() directamente, simulando un retiro enorme para empujar el feeMultiplier a un valor artificialmente inflado.
2. Con el multiplicador establecido, effectiveFee1e9 (el parámetro de comisión por transacción, escalado a 1e9) se desbordó más allá del 100% — entrando en territorio de envoltura donde la matemática se rompía.
3. Usando un préstamo flash, el atacante inició el retiro real. La matemática de comisión rota causó que el contrato calculara la salida del swap incorrectamente.
4. Un posterior retiro pequeño de un solo token activó un underflow en otro lugar de la lógica de acuñación de tokens de liquidez, permitiendo al atacante acuñar una cantidad enormemente desproporcionada de tokens LP.
5. El préstamo flash fue reembolsado y el atacante se marchó con ~1.807 ETH, que puenteó a Ethereum mainnet y blanqueó a través de Tornado Cash.

Consecuencias

• Velocore contactó vía mensajes on-chain ofreciendo una recompensa white-hat del 10%; el plazo pasó sin respuesta.
• El protocolo había sido previamente auditado por Zokyo, Hacken y Scalebit — ninguno de los cuales había señalado la ruta de desbordamiento del multiplicador.
• Velocore pausó las operaciones en zkSync y Linea y efectivamente cerró.

Por qué importa

Velocore es uno de un pequeño conjunto de exploits post-auditoría que destacan los límites de la auditoría como defensa en profundidad: tres firmas de auditoría reputadas revisaron el código y el bug aún se lanzó. La razón probable es que el alcance de la auditoría rara vez incluye fuzzing con rangos enteros arbitrarios en cada función que muta estado — y la ruta específica que desbordó feeMultiplier solo era alcanzable mediante una secuencia particular de llamadas simulate + execute que ninguna herramienta de análisis estático señaló.

La respuesta de la industria ha sido superponer auditorías con pruebas de invariantes económicas (Echidna, invariantes de Foundry) que comprueban propiedades de lógica de negocio bajo secuencias aleatorias de llamadas, no solo el guantelete estándar "¿esta rama hace revert?".