メンテナンスの実行

メンテナンス関数は許可不要（permissionless）です。利用者やボットは管理者権限なしで呼び出せ、コントラクトのルールが実行可否を決めます。

raiseFloor は旧 API 名を維持します。新式では新しい買い壁が過去に資金配置した壁より低くなる場合があります。

手動の手順

1. Keepers ページのデプロイとデータの鮮度を確認します。
2. Lens の実行資格、クールダウン、移動、準備金、停止状態を読みます。
3. 送信アカウントで模擬実行し、予想コストと報酬を比較します。
4. 取引を送信し、レシートとイベントを確認します。

読取りと実行の間に条件を満たさなくなれば拒否されます。RPC エラーは実行資格の情報ではありません。

リバランスの条件

ソースでは前回リバランスの基準から 1 250 tick 以上の移動と 25 ブロック経過を要求します。プールの初期化とメンテナンス許可も必要です。

帯、sweep 比率、買い壁の受益者を任意には選べません。

配置の条件

準備金不足、現状態で配置できない目標、プール制約、停止は raiseFloor() を妨げます。

配置できなければ新手数料は待機し、既存買い壁は tick を維持します。正確な拒否名と新プレビューは新版の検証済み ABI を参照します。

報酬は利益を保証しない

確認したコードでは移動 ETH の 50 bps、つまり 0,50 %、上限 0,01 ETH です。買い壁配置ではラダーの利用可能な idle ETH にも制限されます。

実費は gas 使用量、gas 価格、最終状態に依存します。報酬は買い壁専用資金から出ません。keeper はサービス維持のため自主的に赤字で実行できます。

停止とバーン

guardian は権限期間中 raiseFloor() と rebalance() を停止できます。互換連携によるスワップは利用でき、burnAbsorbed() はこの停止の対象外です。

guardian の期限と V2 モジュール管理は別の話です。権限と交換。

手順の自動化

services/keeper は Lens を読み、シミュレーションとレシート追跡を行います。dry-run で取引なしに確認できます。継続運用、gas 資金、復旧ログは準備が必要です。運用ガイド。

出典：入口と定数は CubitHook.sol, CubitLens.canRebalance, services/keeper/src/index.ts およびその README。