Tatsächlicher Versionsstatus
Die neuen Regeln für mehrere feste Walls werden derzeit implementiert und validiert. Sie wurden noch nicht erneut auf Sepolia bereitgestellt. Die angebundene dApp verwendet weiterhin eine frühere Version mit 0,30 % LP-Gebühren.
Diese Ausgabe des Leitfadens ist auf den 10. September 2026 datiert. Sie stützt sich auf die Quellen und Berichte des Repositorys, ohne eine neue Netzwerkbestätigung in Echtzeit durchzuführen.
Drei getrennte Zustände
| Bereich | In dieser Ausgabe beschriebener Zustand |
|---|---|
| Angeforderte Spezifikation | Kauf 3 % Team; Verkauf 15 % (12 % Walls, 3 % Team); LP-Fee 100 = 0,01 %; Ziel zum Zeitpunkt T; feste Walls; in ETH zu kalibrierende Basis von 7k |
| Solidity-Arbeitsstand | Neue Implementierung und API in Arbeit; Kompilierung gemeldet, vollständige Validierung läuft noch |
| An die dApp angebundenes Sepolia | Frühere Version: Kauf 15 %, Verkauf 3 %, LP-Fee 3000 = 0,30 %, mit V2-Registry und austauschbaren Modulen |
Die neue Steuerverteilung ersetzt die Verteilung der in den Quellen genannten Coderevision 991fca9. Die Ergebnisse dieser Revision validieren diese Änderung nicht. Änderungen an lokalen Quellen ändern keine bereits bereitgestellten Verträge. Eine Synchronisierung der Dokumentation verschiebt keine Mittel eines früheren Pools.
Was die historischen Berichte belegen
Der Sepolia-Bericht beschreibt das Deployment einer früheren Version, Prüfungen von Runtimes und Verknüpfungen, Käufe und Verkäufe zur Abnahme, eine Wall-Platzierung und die Prüfung der Ablehnung unzulässiger Aktionen.
Diese Nachweise gehören zu dieser Version. Sie testen nicht automatisch den Tick-Index, den Erhalt mehrerer Walls, ihre Restbestände oder die Schnittstellen der neuen Regeln.
Die in roadmapdev.md und früheren Berichten veröffentlichten Testzahlen werden daher nicht als Validierungszähler des aktuellen Arbeitsstands dargestellt.
Was keine vollständige Validierung darstellt
Eine erfolgreiche Kompilierung prüft die Erzeugung von Bytecode. Sie belegt allein weder Buchhaltungsinvarianten noch das Verhalten einer Reihe durchlaufener Walls, die Konsistenz des Frontends oder eine Transaktion auf dem gewählten Netzwerk.
Ebenso bedeutet der Vergleich von Runtime-Hashes nicht, dass die Quellen auf einem Explorer veröffentlicht wurden. Automatisierte Frontend-Tests ersetzen keine Abnahme mit einem echten Browser- oder mobilen Wallet.
Weiterhin offene Bedingungen
Die neue Version benötigt eigene Ergebnisse für Szenarien, Invarianten, Integration und Deployment. Eine Kompilierung und erste gezielte Tests wurden während der Erstellung dieses Leitfadens gemeldet; sie schließen die vollständige Kampagne nicht ab. Die Kalibrierung der Basis von 7k, die verknüpften Bibliotheken, die ABI und die Frontend-Ansichten müssen mit den Endergebnissen übereinstimmen.
Bei Revision 991fca9 umfasst die vollständige Solidity-Testsuite 133 erfolgreiche und 15 fehlgeschlagene Tests von insgesamt 148. Die 7 gezielten Tests für mehrere Walls bestehen in einer getrennten Kampagne. Diese Ergebnisse und ihre Grenzen stehen im Bericht zum veröffentlichten Stand.
Vor einer Produktionsfreigabe müssen außerdem die betriebliche Validierung, die unabhängige Prüfung von Strict-Burn und Berechtigungen, die Wallet-Abläufe, die Aggregatorkompatibilität sowie die Aufnahme auf einer Netzwerkumgebung oder einem kanonischen Fork nachgewiesen werden.
Das Projekt wird in diesem Leitfaden nicht als mainnetbereit erklärt.
Welcher Quelle folgen
Ausgangspunkt ist der französische Bericht zur Revision 991fca9. Sein Hinweisbanner zur neuen Überarbeitung hat Vorrang vor den weiter unten stehenden historischen Beschreibungen.
Die öffentlichen Manifeste unter contracts/deployments/ identifizieren die Deployments; ihre Adressen und Metadaten müssen mit dem On-Chain-Zustand abgeglichen werden. Der Leitfaden erzeugt kein Manifest für eine nicht veröffentlichte Version.
Die Quellenseite erläutert die Lesereihenfolge und die inzwischen historischen Dokumente.