We’ll try to clarify the scenario and our reasoning behind the question to ensure there’s no misunderstanding.
The concern is not about the IM calculation itself—since we understand it is calculated retroactively—but rather about operational race conditions that may arise when fee changes occur close to the fee deduction timing.
Here’s the scenario we’re referring to:
Suppose a fee increase is executed at time T0.
The network fee deduction (via the smart contract) happens shortly after at T1, but before the validator cluster has time to top up or adjust its balance.
If the increased fee suddenly exceeds the available balance in the cluster’s validator wallet (especially in setups with consolidated validators), this could potentially trigger a liquidation event because the account may fall below the required collateral threshold.
Key Point:
Even though the IM is calculated in retrospect, the liquidation check based on solvency and fee coverage happens in real-time. So the risk is in the timing mismatch between:
When the fee change is executed, and
When the contract enforces the deduction or solvency check.
We’re simply asking if this kind of timing could, under current contract logic, lead to a liquidation, and if so, whether this has been accounted for in the implementation (e.g., time buffers, grace periods, warnings). We’ve seen the IM rewards delayed for +1month at least one during the program, that’s why we raise the question.
The proposed fee deduction will be implemented as part of the IM script and has no impact on the on-chain contract or the liquidation mechanism. The IM calculation itself is handled entirely off-chain.
To clarify how on-chain liquidations work: network fees are paid continuously. The fee is deducted from your cluster’s balance on a per-block basis — it’s not a one-time deduction at a specific point (T0), but rather a gradual, ongoing process.
When the network fee is updated, it directly affects the runway of all clusters. A lower fee extends a cluster’s runway since less is being deducted per block, while a higher fee shortens it due to increased deductions. This is why fee updates are communicated in advance and why it’s important to maintain a sufficient buffer in your cluster balance to avoid unexpected liquidations.
