Estado real de las versiones
La nueva política de múltiples muros fijos está en implementación y validación. No se ha redesplegado en Sepolia. El dapp conectado todavía utiliza una versión anterior con un 0,30% de comisiones LP.
Esta edición de la guía está fechada el 10 de septiembre de 2026. Se apoya en las fuentes e informes del repositorio, sin realizar una nueva certificación de red en tiempo real.
Tres estados distintos
| Alcance | Estado descrito por esta edición |
|---|---|
| Especificación solicitada | Compra 3% equipo; venta 15% (12% muros, 3% equipo); fee LP 100 = 0,01%; objetivo en el instante T; muros fijos; base 7k por calibrar en ETH |
| Workspace Solidity | Nueva implementación y API en desarrollo; compilación comunicada, validación completa aún en curso |
| Sepolia conectado al dapp | Versión antigua: compra 15%, venta 3%, fee LP 3000 = 0,30%, con registro V2 y módulos sustituibles |
La nueva distribución de tasas sustituye la distribución de la revisión de código 991fca9 citada en las fuentes. Los resultados de esa revisión no validan esta modificación. Cambiar las fuentes locales no cambia los contratos ya desplegados. Una sincronización de documentación no mueve los fondos de un pool antiguo.
Qué acreditan los informes históricos
El informe Sepolia describe el despliegue de una versión anterior, verificaciones de runtimes y conexiones, compras y ventas de aceptación, una colocación de muro y controles de rechazo de acciones inelegibles.
Estas pruebas pertenecen a esa versión. No prueban automáticamente el índice de ticks, la conservación de múltiples muros, sus remanentes ni las interfaces de la nueva política.
Por tanto, los números de pruebas publicados en roadmapdev.md y en informes antiguos no se muestran como contadores de validación del workspace actual.
Qué no constituye una validación completa
Una compilación correcta verifica la producción de bytecode. Por sí sola, no demuestra los invariantes contables, el comportamiento de un conjunto de muros atravesados, la coherencia del frontend ni una transacción en la red elegida.
Del mismo modo, comparar hashes de runtimes no significa que las fuentes se hayan publicado en un explorador. Las pruebas automatizadas del frontend no sustituyen pruebas de aceptación con una cartera real de navegador o móvil.
Condiciones todavía pendientes
La nueva versión debe disponer de sus propios resultados de escenarios, invariantes, integración y despliegue. Durante esta redacción se comunicaron una compilación y primeras pruebas dirigidas; no concluyen la campaña completa. La calibración de la base 7k, las bibliotecas vinculadas, las ABI y las vistas del frontend deben ser coherentes con los resultados finales.
En la revisión 991fca9, la suite Solidity completa cuenta con 133 pruebas superadas y 15 fallidas de un total de 148. Las 7 pruebas dirigidas de múltiples muros se superan en una campaña distinta. Estos resultados y sus límites figuran en el informe del estado publicado.
Antes de abrir producción también quedan por establecer las validaciones operativas, la revisión independiente del strict-burn y de los permisos, los recorridos de carteras, la compatibilidad con agregadores y la absorción en un entorno de red o fork canónico.
El proyecto no se declara listo para mainnet en esta guía.
Qué fuente seguir
El punto de partida es el informe francés de la revisión 991fca9. Su aviso sobre la nueva revisión prevalece sobre las descripciones históricas posteriores.
Los manifiestos públicos de contracts/deployments/ identifican los despliegues; sus direcciones y metadatos deben contrastarse con el estado on-chain. La guía no fabrica un manifiesto para una versión no publicada.
La página Fuentes precisa el orden de lectura y los documentos que se han vuelto históricos.