Sepolia での手動テスト計画

このページは、ウォレットを持つ人が Sepolia テストネットワーク上で手作業で実行できるチェックリストです。各ケースには T-01 形式の固定番号が付いており、報告で引用できます。

始める前に。 この計画は新バージョンを対象とします。リポジトリの公開マニフェストは LP 手数料 100 の稼働中の Sepolia デプロイを記述しており、この計画はそれに適用されます。テスト対象の版に該当しないケースは「版の対象範囲外」と記録し、決して「失敗」とは記録しません。

記載する値は、contracts/src/ にある新バージョンのコードと、2026 年 9 月 14 日の設計上の決定に基づきます。確認できなかった動作には「テスト時に要確認」と記しています。

この計画の使い方

各セクションは、ケースを 6 列の表で示します。最後の 2 列は受入検証中に記入します。

拒否ケースのとおりに拒否された取引は成功です。hash は取引が提出されたことを示すだけで、成功はレシートでのみ判断できます。

一部のケースは画面を通しません。 現在のソースでは、dapp は稼働中のバージョンの ABI を読んでおり、exact-output 注文も claimTeam() も買い壁の詳細な読取りも提供していません。これらのケースには「直接呼出し」と記しており、テスト対象デプロイのマニフェストにあるアドレスに対して、コントラクト呼出しツールで実行します。

1. 準備

最初のスワップの前に、次の項目を記録します。以降のすべての比較の基準になります。

• ネットワーク：Sepolia、チェーン ID 11155111。
• テスト対象デプロイのアドレス（マニフェストから読む）：トークン、フック、PoolManager、poolId、ルーター、Lens、V2 レジストリ、Vault、ローンチャー。ローンチパッドの追加後は、ガバナンス Vault と Forge。秘密鍵をメモにコピーしないでください。
• 固定パラメーター：fee、tickSpacing、LAUNCH_ETH、MIN_POOL_SUPPLY、launchTimestamp、moduleRevision。
• 初期状態：Lens の snapshot()、フックの band()、トークンの totalSupply() と totalBurned()、pendingFloorEth、pendingAbsorbedTokens、wallCount()、activeWallCount()、teamAccrued、teamPaidCumulative、Vault の rewardReserve()、および読取りのブロック番号。

交換する金額に加えてテスト用 ETH を用意してください。各取引は gas を支払い、いくつかのケースでは拒否される取引が必要で、それらも gas を消費します。

2. ローンチとバンド

プールの初期化時、フックは預入れの全額を、BAND_SALT で識別される単一のポジション [minUsableTick, tickUpper] に配置します。tickUpper は開始 tick を間隔に合わせて切り下げた値なので、ポジションには CUBIT しか含まれません。フックは MIN_POOL_SUPPLY（供給量の 80 %）未満の預入れを拒否し、丸めによる端数をバーンします。

完全なローンチでは、供給量の 20 % も Vault の準備金に入れ、同じトランザクションで 0.1 ETH の購入を行います。

3. 購入と売却の手順

ルーターは swapExactIn(key, zeroForOne, amountIn, amountOutMin, recipient, deadline) と swapExactOut(key, zeroForOne, amountOut, amountInMax, recipient, deadline) を公開しています。zeroForOne = true は ETH で CUBIT を購入します。

dapp の現在のソースでは、画面は exact-input しか使いません。 利用者は常に支払う金額を入力し、受取数量は読取り専用の欄です。したがって exact-output の手順は、ルーターへの直接呼出しでテストする必要があります。

購入は msg.value でネイティブ ETH を送ります。売却は value ゼロで送り、ルーターに対する CUBIT の ERC-20 承認が必要です。画面はちょうどその金額の承認を求め、無制限の承認は求めないため、より大きな売却には新しい承認が必要です。

ルーターは部分約定を拒否します。全額消費されない exact-input は IncompleteInput、全量提供されない exact-output は InsufficientOutput になります。税は要求額に基づいて計算されるため、取り消しは利用者を保護します。

dapp のソースから読んだ画面設定（受入検証で確認する）：スリッページ許容度は既定値 1.0 %、入力は小数 2 桁までかつ 0 から 99.99 の範囲。最低受取量は整数で計算し、wei 単位で切り上げ。見積もりは 30 秒間有効。オンチェーン期限 = チェーンの timestamp + 120 秒 − 見積もりの経過時間。

4. 税と会計

exact-input では、購入税は渡された金額に含まれ、wei 単位で切り上げられます。exact-output では、プール部分の上に加算されるため、合計に対する税の割合は 3 % のままです。

exact-output の売却では、税は ceil(sortie × 1500 / 8500) です。プールは要求された出力に加えて税を生み出します。exact-input の売却では、税は ceil(brut × 15 %) です。配分ではチーム分が切り捨てられ、wei 単位の残りはすべて買い壁に入ります。

dapp の現在のソースでは、画面はスワップを許可する前にこれらの税率をチェーン上で読むことを要求します。確認されるまで、ボタンは待機状態のままです。

5. 自動買い壁

exact-input でも exact-output でも、売却のたびにフックは _collectCrossedWalls() を呼び、次に _placeWall() を呼びます。まず価格が完全に通過したすべての買い壁を近いものから遠いものへ順に空にし、次にすべての待機中の ETH を目標 0.4 × prix courant + 0.6 × prix de lancement に配置します。目標は売却後の価格で計算し、tick に丸めます。ローンチ価格以下のようにこの目標がプールの tick より厳密に上にない場合は、買い壁を現在価格の 1 % 下に配置します。

空にされた買い壁は、その CUBIT を pendingAbsorbedTokens に加え、残りの ETH（手数料と端数）を pendingFloorEth に戻します。一部消費されただけの買い壁はその場にとどまります。流動性を作るには小さすぎる金額と、価格が tick 範囲の最上端にあり価格の下に買い壁を置く余地がない極端な場合だけが、資金を pendingFloorEth で待機させます。これを理由に売却が拒否されることは決してありません。その後、CUBIT ルーターが try/catch の中で deliverAbsorbed() を呼び出します。

Lens の参照値 floorPrice() は最後に資金供給された買い壁を示し、全体の最低価格ではありません。通過される買い壁 1 つにつき約 185 000 gas かかるため、1 トランザクションの上限 16 777 216 gas の範囲内で 1 回の売却が通過できる買い壁は最大で約 88 です。

6. mCUBIT Vault

Vault は rewardReserve からのみ引き出される CUBIT 建ての報酬を支払います。報酬は DAILY_REWARD_BPS = 300、すなわち 24 時間の期間（REWARD_PERIOD）あたり預入額の 3 % で、比例計算され、1 期間分が上限です。それを超えた分は失われます。準備金の残高を超えることはなく、元本から支払われることもありません。

各預入れは、ウォレットの全ポジションについて 24 時間のロック（LOCK_DURATION）を再開します。期限前の引出しは Locked で拒否されます。預入れ、引出し、請求はまず獲得済みの報酬を支払い、期間を新たに開始します。どのアカウントも fundRewardReserve(amount) で準備金に資金を追加できます。期限はブラウザーの時計ではなく、チェーンの timestamp で判断します。

報酬は CUBIT のみで、claimCubit() で請求します。Vault は WETH 報酬の関数を一切公開していません。

7. ローンチパッドのガバナンス Vault

ガバナンス Vault は、Forge のローンチ手数料（ETH）と、Forge の子市場の買い壁が吸収したトークンを受け取ります。各預入れは、それぞれの受領時から 30 日間ロックされます（LOCK_DURATION）。請求できるのはデプロイヤーだけで、この権利は恒久的で譲渡できません。期日を過ぎたロットのみを古い順に請求できます。ETH はキー ETH()（ゼロアドレス）で記帳されます。受入検証の前にテスト対象デプロイの ABI を読み直してください。デプロイヤーは extendLock で現在と将来のすべての預入れのロックを延長でき、lockExtension() は増えるだけで各期日に加算されます。

子市場の買い壁からの自動送付は T-52 で、ローンチ手数料の預入れは T-81 で確認します。T-67 から T-73 のケースでは直接呼出しでテスト用トークンを預け入れ、T-108 では手数料の ETH を請求します。

8. Forge

Forge は将来のリリースとして紹介する公開ローンチパッドです。CUBIT のローンチには含まれず、後からガバナンス Vault とともに追加されます。ローンチパッドの追加後にそのアドレスを記録してください。

どのアカウントも正確な手数料を支払えば子市場をローンチできます。Forge の子市場は供給量の全額を自身のバンドに預け入れ、Forge は構築時にガバナンス Vault のアドレスを受け取り、各ローンチは 0.005 ETH の手数料をこの Vault に支払い、Vault がそれを保持します。ローンチした側に返金されることはありません。デプロイ salt はローンチするアカウントに結び付けられます。

9. 交換と権限

レジストリの authority は、Vault、ルーター、Lens、Forge の四つの周辺アドレスをいつでも遅延なく交換できます。交換のたびに ModuleUpdated が発行され、moduleRevision が増え、該当する機能（Vault、Momentum、Forge）はチームが再び公開するまで閉じます。ルーターの交換で閉じる機能はありません。登録済みの候補、別のフックや別のトークンに接続された候補、既に stake のある候補は InvalidModule で拒否されます。

フックには管理者がいません。誰もスワップや買い壁の仕組みを一時停止できません。チームアドレスは恒久的な権限を保持し、チーム分の税を受け取り、レジストリのモジュールを交換してから有効化します。

10. 想定される拒否ケース

この表は受入検証全体を通じた参照用です。自動買い壁は売却に拒否を追加しません。買い壁を配置できない場合は資金が待機し、失敗した送付は CUBIT を待機させたままにします。

注意点。 dapp の現在のソースでは、コントラクトのエラーは翻訳されていません。オンチェーンの拒否が、表示上切り詰められた生のメッセージとして表示される場合があります。発生させた拒否ごとに、表示された正確なテキストを記録し、理解できる内容か判断してください。

アプリ側だけの拒否も記録します：期限切れの見積もり、変更されたスワップ状態、別チェーン上のウォレット、変更されたアカウント、変更されたモジュール改訂、まだ確認されていない税率。

11. アプリケーション

これらのケースは dapp で実施します。記載する画面の動作はソースに基づくもので、受入検証で確認します。

12. 記録シート

前のセクションの各表が、そのセクションの記録シートそのものです。ケースを進めながら「観察結果」と「重大度」の列を記入してください。観察結果には少なくとも取引 hash または読取りブロックを記し、そのうえで確認した内容を書きます。

報告に添付する集計：

差異は必ずケース番号に対して報告し、スクリーンショットだけで報告してはいけません。ネットワーク、デプロイのアドレス、ブロック、hash、アプリのバージョンを添えてください。

この計画の限界

この計画は、新バージョンのコードと 2026 年 9 月 14 日の決定が想定することを記述したものです。検証そのものではありません。Sepolia での受入検証が成功しても、テストキャンペーンの代わりにはなりません。

「テスト時に要確認」の項目は、観察したうえでこのページに反映する必要があります。

出典： 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、 dapp/src の現在の手順、および contracts/docs/REDESIGN_HANDOFF.md に記録された 2026 年 9 月 14 日の設計上の決定。