Manueller Testplan auf Sepolia

Diese Seite ist eine von Hand ausführbare Checkliste für das Sepolia-Testnetz, gedacht für eine Person mit einem Wallet. Jeder Fall trägt eine feste Nummer der Form T-01, die in einem Bericht zitiert werden kann.

Bevor Sie beginnen. Dieser Plan bezieht sich auf die neue Version. Das öffentliche Manifest des Repositorys beschreibt das im Einsatz befindliche Sepolia-Deployment mit LP-Gebühren 100: Dieser Plan gilt dafür. Ein Fall, der auf die getestete Version nicht zutrifft, wird als „außerhalb des Versionsumfangs“ vermerkt, niemals als „Fehlschlag“.

Die genannten Werte stammen aus dem Code der neuen Version unter contracts/src/ und aus den Designentscheidungen vom 14. September 2026. Ein Verhalten, das nicht ermittelt werden konnte, ist mit „beim Test zu bestätigen“ markiert.

So verwenden Sie diesen Plan

Jeder Abschnitt stellt seine Fälle in einer Tabelle mit sechs Spalten dar. Die letzten beiden werden während der Abnahme ausgefüllt.

Eine gemäß einem Ablehnungsfall abgelehnte Transaktion ist ein Erfolg. Ein Hash bedeutet nur, dass die Transaktion eingereicht wurde: Nur der Beleg gibt Auskunft über den Erfolg.

Manche Fälle laufen nicht über die Oberfläche. In ihren aktuellen Quellen liest die dApp die ABI der im Einsatz befindlichen Version und stellt weder Aufträge mit exakter Ausgabe noch claimTeam() noch die detaillierten Abfragen der Walls bereit. Diese Fälle sind als „Direktaufruf“ markiert: Sie werden mit einem Werkzeug für Vertragsaufrufe auf den Adressen aus dem Manifest des getesteten Deployments ausgeführt.

1. Vorbereitung

Erfassen Sie diese Elemente vor dem ersten Swap: Sie dienen als Referenz für alle späteren Vergleiche.

• Das Netzwerk: Sepolia, Chain-ID 11155111.
• Die Adressen des getesteten Deployments, aus seinem Manifest gelesen: Token, Hook, PoolManager, poolId, Router, Lens, V2-Registry, Vault, Launcher; dann, sobald das Launchpad hinzugefügt ist, Governance-Vault und Forge. Kopieren Sie keinen privaten Schlüssel in Ihre Notizen.
• Die festgeschriebenen Parameter: fee, tickSpacing, LAUNCH_ETH, MIN_POOL_SUPPLY, launchTimestamp, moduleRevision.
• Der Anfangszustand: snapshot() des Lens, band() des Hooks, totalSupply() und totalBurned() des Tokens, pendingFloorEth, pendingAbsorbedTokens, wallCount(), activeWallCount(), teamAccrued, teamPaidCumulative, rewardReserve() des Vaults und die Blocknummer der Abfrage.

Planen Sie Test-ETH zusätzlich zu den getauschten Beträgen ein: Jede Transaktion zahlt ihr Gas, und mehrere Fälle erfordern abgelehnte Transaktionen, die ebenfalls Gas verbrauchen.

2. Start und Band

Bei der Initialisierung des Pools platziert der Hook seine gesamte Einlage in einer einzigen Position [minUsableTick, tickUpper], identifiziert durch BAND_SALT. tickUpper ist der auf den Abstand abgerundete Eröffnungstick, sodass die Position nur CUBIT enthält. Der Hook lehnt eine Einlage unterhalb von MIN_POOL_SUPPLY, also 80 % des Angebots, ab und verbrennt den Rundungsstaub.

Der vollständige Start überträgt außerdem 20 % des Angebots an die Reserve des Vaults und tätigt in derselben Transaktion einen Kauf über 0,1 ETH.

3. Kauf- und Verkaufsabläufe

Der Router stellt swapExactIn(key, zeroForOne, amountIn, amountOutMin, recipient, deadline) und swapExactOut(key, zeroForOne, amountOut, amountInMax, recipient, deadline) bereit. zeroForOne = true kauft CUBIT mit ETH.

In den aktuellen Quellen der dApp verwendet die Oberfläche nur die exakte Eingabe. Der Nutzer gibt immer den Betrag ein, den er zahlt; die erhaltene Menge ist ein schreibgeschütztes Feld. Abläufe mit exakter Ausgabe müssen daher per Direktaufruf des Routers getestet werden.

Ein Kauf sendet native ETH als msg.value. Ein Verkauf sendet den Wert null und erfordert eine ERC-20-Freigabe der CUBIT an den Router: Die Oberfläche fordert eine Genehmigung über den exakten Betrag an, nie unbegrenzt, sodass ein größerer Verkauf eine neue Genehmigung verlangt.

Der Router lehnt Teilausführungen ab: Eine nicht vollständig verbrauchte exakte Eingabe löst IncompleteInput aus, eine nicht vollständig erfüllte exakte Ausgabe löst InsufficientOutput aus. Da die Steuer auf den angeforderten Betrag bemessen wird, schützt der Abbruch den Nutzer.

Aus den Quellen der dApp gelesene Einstellungen der Oberfläche, während der Abnahme zu prüfen: Slippage-Toleranz standardmäßig 1,0 %, Eingabe auf zwei Dezimalstellen und den Bereich 0 bis 99,99 begrenzt; Mindestempfang in Ganzzahlen berechnet und auf den nächsten Wei aufgerundet; Quotierung 30 Sekunden aktuell; On-Chain-Frist = Zeitstempel der Blockchain plus 120 Sekunden minus Alter der Quotierung.

4. Steuern und Buchhaltung

Bei exakter Eingabe ist die Kaufsteuer im bereitgestellten Betrag enthalten und auf den nächsten Wei aufgerundet. Bei exakter Ausgabe kommt sie zum Pool-Anteil hinzu, sodass die auf die Gesamtsumme bezogene Steuer 3 % bleibt.

Bei einem Verkauf mit exakter Ausgabe beträgt die Steuer ceil(sortie × 1500 / 8500): Der Pool erzeugt die angeforderte Ausgabe plus die Steuer. Bei einem Verkauf mit exakter Eingabe beträgt sie ceil(brut × 15 %). Bei der Verteilung wird der Teamanteil abgerundet, und der gesamte Rest in Wei geht an die Walls.

In den aktuellen Quellen der dApp verlangt die Oberfläche, diese Sätze auf der Blockchain abzufragen, bevor sie einen Swap zulässt: Solange sie nicht geprüft sind, bleibt die Schaltfläche im Wartezustand.

5. Automatische Walls

Bei jedem Verkauf, mit exakter Eingabe wie mit exakter Ausgabe, ruft der Hook _collectCrossedWalls() und danach _placeWall() auf. Er leert zuerst alle Walls, die der Preis vollständig durchlaufen hat, von der nächstgelegenen bis zur entferntesten, und platziert dann alle wartenden ETH am Ziel 0,4 × prix courant + 0,6 × prix de lancement, das anhand des Preises nach dem Verkauf berechnet und auf den Tick gerundet wird. Liegt dieses Ziel nicht strikt oberhalb des Pool-Ticks, was auf oder unter dem Startpreis geschieht, wird die Wall 1 % unter dem aktuellen Preis platziert.

Eine geleerte Wall fügt ihre CUBIT zu pendingAbsorbedTokens hinzu und gibt ihre restlichen ETH, Gebühren und Staub, an pendingFloorEth zurück. Eine nur teilweise aufgebrauchte Wall bleibt bestehen. Nur ein Betrag, der zu klein ist, um Liquidität zu erzeugen, und der Extremfall eines Preises ganz oben im Tick-Bereich, wo keine Wall unter den Preis passt, lassen Mittel in pendingFloorEth warten: Der Verkauf wird deswegen nie abgelehnt. Der CUBIT-Router ruft anschließend deliverAbsorbed() in einem try/catch auf.

Die Referenz floorPrice() des Lens beschreibt die zuletzt finanzierte Wall, kein globales Minimum. Jede durchlaufene Wall kostet etwa 185 000 Gas: Innerhalb des Limits von 16 777 216 Gas einer Transaktion durchläuft ein Verkauf höchstens etwa 88 Walls.

6. mCUBIT Vault

Der Vault zahlt eine Belohnung in CUBIT, die ausschließlich aus rewardReserve entnommen wird. Sie beträgt DAILY_REWARD_BPS = 300, also 3 % der Einlage pro Zeitraum von 24 Stunden (REWARD_PERIOD), anteilig berechnet und auf einen Zeitraum gedeckelt: Darüber hinaus verfällt der Überschuss. Sie übersteigt nie den Saldo der Reserve und wird nie aus dem Kapital gezahlt.

Jede Einlage startet eine Sperre von 24 Stunden (LOCK_DURATION) für die gesamte Position des Wallets neu; eine Auszahlung vor Ablauf wird mit Locked abgelehnt. Eine Einlage, eine Auszahlung oder ein Abruf zahlt zuerst die erworbene Belohnung aus und startet den Zeitraum neu. Jedes Konto kann die Reserve mit fundRewardReserve(amount) speisen. Der Ablauf richtet sich nach dem Zeitstempel der Blockchain, nicht nach der Uhr des Browsers.

Die Belohnung wird ausschließlich in CUBIT gezahlt und mit claimCubit() abgerufen: Der Vault stellt keine Funktion für Belohnungen in WETH bereit.

7. Governance-Vault des Launchpads

Der Governance-Vault erhält die Startgebühren der Forge in ETH und die von den Walls der Forge-Kindmärkte aufgenommenen Token. Jede Einlage ist 30 Tage gesperrt (LOCK_DURATION), gerechnet ab ihrem eigenen Eingang. Nur der Deployer kann abrufen, dauerhaft und ohne Möglichkeit, dieses Recht zu übertragen, und nur die Tranchen, deren Datum verstrichen ist, von der ältesten zur neuesten. ETH wird unter dem Schlüssel ETH(), der Nulladresse, verbucht. Lesen Sie die ABI des getesteten Deployments vor der Abnahme erneut. Der Deployer kann die Sperre aller bestehenden und künftigen Einlagen mit extendLock verlängern; lockExtension() wächst nur und wird zu jedem Datum addiert.

Die automatische Übertragung aus den Walls der Kindmärkte wird durch T-52 geprüft, die Einlage der Startgebühr durch T-81. Die Fälle T-67 bis T-73 hinterlegen Test-Token per Direktaufruf; T-108 ruft das ETH einer Gebühr ab.

8. Forge

Die Forge ist ein öffentliches Launchpad, das als zukünftige Veröffentlichung vorgestellt wird. Sie ist nicht Teil des CUBIT-Starts: Sie wird danach zusammen mit ihrem Governance-Vault hinzugefügt. Notieren Sie ihre Adressen, sobald das Launchpad hinzugefügt ist.

Jedes Konto startet einen Kindmarkt gegen Zahlung der exakten Gebühr. Ein Forge-Kindmarkt hinterlegt sein gesamtes Angebot in seinem Band, die Forge erhält die Adresse des Governance-Vaults bei ihrer Erstellung, und jeder Start zahlt seine Gebühr von 0,005 ETH an diesen Vault, der sie behält: Der startende Account erhält sie nie zurück. Die Deployment-Salts sind an den startenden Account gebunden.

9. Austausch und Befugnisse

Die Authority der Registry kann vier Peripherieadressen jederzeit ohne Verzögerung austauschen: Vault, Router, Lens und Forge. Jeder Austausch emittiert ModuleUpdated, erhöht moduleRevision und schließt die betroffene Funktion, bis das Team sie wieder öffnet: Vault, Momentum oder Forge; der Austausch des Routers schließt keine Funktion. Ein Kandidat, der bereits registriert ist, an einen anderen Hook oder Token angebunden ist oder bereits Stake hält, wird mit InvalidModule abgelehnt.

Der Hook hat keinen Administrator, und niemand kann die Swaps oder den Mechanismus der Walls pausieren. Die Teamadresse behält dauerhafte Befugnisse: Sie erhält den Teamanteil der Steuern und tauscht die Module der Registry aus, die sie anschließend aktiviert.

10. Erwartete Ablehnungsfälle

Diese Tabelle dient während der gesamten Abnahme als Referenz. Die automatischen Walls fügen dem Verkauf keine Ablehnungen hinzu: Kann eine Wall nicht platziert werden, warten die Mittel, und nach einer fehlgeschlagenen Übertragung warten die CUBIT.

Achtung. In den aktuellen Quellen der dApp werden Vertragsfehler nicht übersetzt: Eine On-Chain-Ablehnung kann als rohe, in der Anzeige abgeschnittene Meldung erscheinen. Notieren Sie für jede ausgelöste Ablehnung den genau angezeigten Text und beurteilen Sie, ob er verständlich ist.

Rein anwendungsseitige Ablehnungen werden ebenfalls erfasst: veraltete Quotierung, geänderter Swap-Kontext, Wallet auf einer anderen Blockchain, gewechseltes Konto, geänderte Modulrevision, noch nicht geprüfte Steuersätze.

11. Anwendung

Diese Fälle werden mit der dApp durchgeführt. Die genannten Verhaltensweisen der Oberfläche stammen aus ihren Quellen und werden während der Abnahme geprüft.

12. Erfassungsbogen

Jede Tabelle der vorherigen Abschnitte ist der Erfassungsbogen ihres Abschnitts: Füllen Sie die Spalten „Beobachtetes Ergebnis“ und „Schweregrad“ Fall für Fall aus. Notieren Sie für das beobachtete Ergebnis mindestens den Transaktionshash oder den Abfrageblock und dann das Festgestellte.

Dem Bericht beizufügende Zusammenfassung:

Eine Abweichung bezieht sich auf die Nummer des Falls, niemals nur auf einen Screenshot. Fügen Sie Netzwerk, Adresse des Deployments, Block, Hash und Version der Anwendung bei.

Grenzen dieses Plans

Dieser Plan beschreibt, was der Code der neuen Version und die Entscheidungen vom 14. September 2026 vorsehen. Er stellt keine Validierung dar: Eine erfolgreiche Abnahme auf Sepolia ersetzt die Testkampagnen nicht.

Die Punkte „beim Test zu bestätigen“ müssen beobachtet und dann in diese Seite übernommen werden.

Quellen: contracts/src/CubitHook.sol, CubitLens.sol, interfaces/ICubitHook.sol, interfaces/ICubitLens.sol, libraries/BandLib.sol, libraries/WallLib.sol, periphery/CubitRouter.sol, CubitV2.sol, CubitVault.sol, CubitGovernanceVault.sol, CubitForge.sol, CubitLaunch.sol, die aktuellen Abläufe von dapp/src und die Designentscheidungen vom 14. September 2026, festgehalten in contracts/docs/REDESIGN_HANDOFF.md.