権限と交換

CUBIT は、識別情報が固定され管理者のいない中核と、周辺モジュールを管理するチームアドレスを区別します。チームアドレスの権限は恒久的です。

固定されるもの

周辺 setter はトークン、主フック、PoolManager、poolId、レジストリのアンカーを交換しません。

トークンは一度限りの接続でフックを認可します。中核の税率、ローンチ時 FDV、バンドの配置形状には setter がなく、バンドは一度置かれると引き出されません。中核を変える新ポリシーには新版・検証・デプロイが必要で、旧プールを自動更新しません。

フックに管理者はいない

フックには管理者がいません。誰もスワップや買い壁の仕組みを一時停止できません。

したがって、どのアドレスも売却や買い壁の配置を停止できません。フックのルールはデプロイされたとおりに適用されます。

チームの役割

チームアドレス TEAM_ADDRESS はフックに固定されており、レジストリ CubitV2 の authority() として機能します。その権限は恒久的です。チーム分の税（購入 3 %、売却 3 %）を受け取り、レジストリのモジュールを交換してから有効化します。Vault、ルーター、Lens、Forge はいつでも即座に、予告期間なしで交換できます。交換可能な四つのアドレスは次のとおりです：

変更ごとに ModuleUpdated を発行し moduleRevision を増加し、チームが再び公開するまで該当する機能を閉じます。Vault、Lens、Forge を交換すると、それぞれ Vault、Momentum、Forge が閉じ、ルーターの交換で閉じる機能はありません。操作前に新アドレスとコードを確認します。

交換の及ぶ範囲

交換はそのトランザクションで直ちに効力を持ちます。交換により次を決められます：

• CUBIT の買い壁が吸収した CUBIT が、その後の送付でどこへ行くか：フックは登録済みの Vault に届けます。
• 将来のローンチ手数料がどこへ行くか：登録済みの Forge が自身のガバナンス Vault に支払います。
• dapp がどのルーターを使うか。

交換が触れないもの：

• 中核：トークン、フック、バンド、買い壁、税
• 既存の Vault に既にある残高：元本と報酬準備金

チームはこのアドレスの秘密鍵を保護します。

互換性検査の限界

正しいアドレスを宣言する getter は想定接続を示すだけで、候補コード全体の安全性や将来実装の proxy・悪意ある動作の不在は証明しません。

そのためチームが将来操作用の周辺コードを選びます。各交換、bytecode、相互作用の検証が必要です。

預入れ済みの資金

Vault の交換は、旧コントラクトに預け入れられた CUBIT も報酬準備金も移しません。ポジション、期限、出金は旧 Vault に残ります。レジストリは一覧を保ち、画面はこれらを継続表示する必要があります。

旧ルーターは引き続きスワップに使え、フック税の対象のままです。旧ルーターへの承認は新しいルーターには適用されません。

Forge 交換は将来のローンチに関係し、既存の子は自身のコントラクトと、自身をローンチした Forge のガバナンス Vault を維持します。

これらの setter は欠陥コントラクトを遡って修復せず、保有資金も移しません。オンチェーン出金可否と画面での提供可否は別々に確認します。

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

ガバナンス Vault には管理者も早期出金もありません。ETH のローンチ手数料と子市場の買い壁が吸収したトークンを受け取り、各預入れは受領時から 30 日間ロックされ、その後は Vault のデプロイヤーだけが請求できます。この権利は恒久的で、譲渡する関数はありません。そのアカウントへの明示的な信頼を前提とします。このデプロイヤーは、現在と将来の預入れを含む Vault 全体のロックをいつでも延長でき、短縮する関数はありません。

承認と署名

承認は特定 spender に紐付き、レジストリの現行アドレスには追従しません。改訂・モジュール変更時、特に承認とスワップ間で画面は操作を再検証する必要があります。

プロトコルの操作はすべてトランザクションです。署名する前に、送信先アドレスとチェーンを確認します。

出典： CubitV2.sol, CubitHook.sol, periphery/CubitGovernanceVault.sol, contracts/docs/MODULE_SETTERS.md および画面側の検査 releases.ts / vault.ts。