Triggering maintenance
Maintenance functions are permissionless: a user or bot can call them without an administrative role. The contract’s rules decide whether the operation is eligible.
| Call | Intended effect | Compensation |
|---|---|---|
raiseFloor() |
Place eligible funds in a wall according to the version’s policy | Capped bounty from the ladder |
rebalance() |
Reorganize the ladder and perform the planned allocations | Capped bounty from the ladder |
burnAbsorbed() |
Destroy isolated inventory | No bounty |
The name raiseFloor is retained in the historical API. With the new formula, a new wall’s level can be below that of a previously funded wall.
Manual workflow
- Check the deployment and data freshness on the Keepers page.
- Read the eligibility supplied by the Lens: cooldown, movement, reserve and pause status.
- Simulate the call with the account that will send it and compare the estimated cost with any bounty.
- Send the transaction, then check its receipt and events.
An action that becomes ineligible between reading and execution can be rejected. An RPC error does not provide eligibility information.
Rebalance conditions
The sources require movement of at least 1 250 ticks from the last rebalance reference and a 25-block delay. The pool must be initialized and maintenance permitted.
The function does not allow arbitrary choices of bands, the sweep share or the walls’ beneficiary.
Placement conditions
An insufficient reserve, a target that cannot be placed in the current state, pool constraints or a pause may prevent raiseFloor().
If no placement is possible, new fees remain pending and older walls keep their ticks. Read the exact rejection names and new previews in the validated ABI of the new version.
The bounty is not a guaranteed return
The parameters in the code reviewed are 50 bps of ETH moved, or 0.50%, capped at 0.01 ETH. For wall placement, the amount is also limited by the ladder’s available idle ETH.
The actual cost depends on gas used, gas price and the final state. The bounty does not come from funds allocated to walls. A keeper may voluntarily perform an unprofitable operation to maintain service.
Pausing and burning
The guardian can pause raiseFloor() and rebalance() during its period of authority. Swaps remain accessible through a compatible integration, and burnAbsorbed() is not suspended by this maintenance pause.
Guardian expiry and V2 module administration are separate issues. Permissions and replacements.
Automating this workflow
The services/keeper service reads the Lens, simulates and tracks receipts. A dry-run mode allows verification without sending a transaction. Continuous operations, gas funding and recovery logs still need to be organized. Operations guide.
Sources: entry points and constants in CubitHook.sol, CubitLens.canRebalance, services/keeper/src/index.ts and its README.