fluxswap
Un protocolo de intercambio descentralizado (DEX) en Solidity, construido con Foundry. Pools de liquidez, router, staking y timelock - con invariantes y cobertura de pruebas completa.
Un protocolo de intercambio descentralizado (DEX) en Solidity: pools de liquidez, un router, staking y un timelock. El contrato mueve fondos reales, así que un bug no es una corrección para la siguiente versión, es dinero perdido. Por eso cuentan los invariantes y una cobertura de pruebas completa en Foundry, no decir que parece que funciona.
Introducción
La mayoría del software vive del hecho de que los bugs se pueden corregir. Un contrato on-chain te quita ese lujo: es inmutable y guarda el dinero ajeno. Eso invierte la forma en que escribes código, porque ya no compruebas que el camino feliz funcione, compruebas que una regla que debe cumplirse siempre no se pueda romper.
fluxswap está construido en torno a esa diferencia. Los pools de liquidez, un router, el staking y un timelock son funcionalidades, pero el verdadero trabajo reside en los invariantes que deben cumplirse tras cualquier secuencia posible de operaciones, incluida la que nadie previó.
Código que no puedes actualizar después
Una aplicación normal tiene un bug, publicas una corrección, la vida sigue. Un contrato on-chain es inmutable y guarda el dinero ajeno, así que un bug en la lógica del pool de liquidez no es un defecto, es un vector por el que alguien drena fondos. Aquí no hay versión número dos en la que lo arreglas.
Esa única propiedad lo cambia todo. Escribes suponiendo que cualquiera que mire el contrato busca una forma de romper sus reglas, y que la única defensa es demostrar que no se pueden romper.
Las pruebas individuales comprueban entradas concretas que inventas tú mismo, así que solo comprueban lo que ya anticipaste. Las pruebas de invariantes en Foundry hacen algo más fuerte: bombardean al azar el contrato con miles de secuencias de operaciones y tras cada una comprueban que la regla sigue cumpliéndose.
Las sumas de tokens cuadran, el producto de las reservas no baja, nadie retiró más de lo que ingresó. La diferencia es fundamental, porque es el fuzzer, no tú, quien inventa el escenario que rompe el contrato, y lo hace miles de veces seguidas.
El timelock, o tiempo para reaccionar
El timelock sobre las operaciones sensibles existe para que un cambio de parámetros no pueda introducirse de un minuto a otro. Incluso el propietario espera, y la comunidad ve lo que viene antes de que ocurra, con tiempo para reaccionar si el cambio es hostil.
Esta salvaguarda no protege contra un bug en el código sino contra el abuso de privilegios. Sin timelock, el propietario podría reajustar en silencio los parámetros del protocolo justo antes de un ataque. Con él, cada cambio de ese tipo es visible y diferido, lo que le quita el factor sorpresa.
La prueba en lugar de la esperanza
El resultado es un protocolo cuya seguridad se apoya en una demostración, no en la convicción de que probamos los casos más importantes. Los invariantes se sostienen a lo largo de miles de secuencias aleatorias, los cambios sensibles están diferidos por el timelock, y las reglas más peligrosas, como el producto constante de las reservas, se imponen directamente en el código del contrato.
Los invariantes y lo que garantizan
| Invariante | Lo que garantiza |
|---|---|
| Producto constante | el producto de las reservas no baja tras un swap |
| Suma de tokens | los depósitos igualan los retiros más el saldo |
| Retiro | nadie toma más de lo que puso |
| Timelock | los cambios de parámetros son diferidos y públicos |
Más proyectos
Más trabajos de la misma categoría - mira cómo abordamos retos parecidos.
¿Tiene un proyecto similar?
Escríbenos - el presupuesto es gratuito y llega en una hora.