État réel des versions
La nouvelle politique à plusieurs murs fixes est en cours d’implémentation et de validation. Elle n’a pas été redéployée sur Sepolia. Le dapp raccordé utilise encore une version antérieure à 0,30 % de frais LP.
Cette édition du guide est datée du 10 septembre 2026. Elle s’appuie sur les sources et les rapports du dépôt, sans effectuer une nouvelle attestation réseau en temps réel.
Trois états distincts
| Périmètre | État décrit par cette édition |
|---|---|
| Spécification demandée | Achat 3 % équipe ; vente 15 % (12 % murs, 3 % équipe) ; fee LP 100 = 0,01 % ; cible instant T ; murs fixes ; base 7k à calibrer en ETH |
| Workspace Solidity | Nouvelle implémentation et API en chantier ; compilation rapportée, validation complète encore en cours |
| Sepolia raccordé au dapp | Ancienne version : achat 15 %, vente 3 %, fee LP 3000 = 0,30 %, avec registre V2 et modules remplaçables |
La nouvelle répartition des taxes remplace la répartition de la révision de code 991fca9 citée dans les sources. Les résultats de cette révision ne valident pas cette modification. Changer les sources locales ne change pas les contrats déjà déployés. Une synchronisation de documentation ne déplace pas les fonds d’un ancien pool.
Ce que les rapports historiques attestent
Le bilan Sepolia décrit le déploiement d’une version précédente, des vérifications de runtimes et de liaisons, des achats et ventes de recette, un placement du mur et des contrôles de refus d’actions inéligibles.
Ces preuves appartiennent à cette version. Elles ne testent pas automatiquement l’index des ticks, la conservation de plusieurs murs, leurs reliquats ou les interfaces de la nouvelle politique.
Les nombres de tests publiés dans roadmapdev.md et dans d’anciens bilans ne sont donc pas affichés comme compteurs de validation du workspace actuel.
Ce qui ne constitue pas une validation complète
Une compilation réussie vérifie la production de bytecode. Elle ne démontre pas à elle seule les invariants comptables, le comportement d’un ensemble de murs traversés, la cohérence frontend ou une transaction sur le réseau choisi.
De même, la comparaison de hashes de runtimes ne signifie pas qu’une publication des sources a été faite sur un explorateur. Les tests automatisés du frontend ne remplacent pas une recette avec un wallet navigateur ou mobile réel.
Conditions encore ouvertes
La nouvelle version doit disposer de ses propres résultats de scénarios, invariants, intégration et déploiement. Une compilation et de premiers tests ciblés ont été rapportés pendant cette rédaction ; ils ne terminent pas la campagne complète. La calibration de la base 7k, les bibliothèques liées, les ABI et les vues du frontend doivent être cohérents avec les résultats finaux.
À la révision 991fca9, la suite Solidity complète compte 133 réussites et 15 échecs sur 148 tests. Les 7 tests ciblés multi-murs passent dans une campagne distincte. Ces résultats et leurs limites figurent dans le bilan de l'état publié.
Avant une ouverture de production restent aussi à établir les validations opérationnelles, la revue indépendante du strict-burn et des permissions, les parcours wallets, la compatibilité des agrégateurs et l’absorption sur un environnement réseau ou fork canonique.
Le projet n’est pas déclaré prêt pour le mainnet dans ce guide.
Quelle source suivre
Le point de départ est le bilan français de la révision 991fca9. Son bandeau sur la nouvelle révision prime sur les descriptions historiques situées plus bas.
Les manifestes publics sous contracts/deployments/ identifient les déploiements ; leurs adresses et leurs métadonnées doivent être confrontées à l’état on-chain. Le guide ne fabrique pas un manifeste pour une version non diffusée.
La page Sources précise l’ordre de lecture et les documents devenus historiques.