You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The protocol allows users to configure a topUpSource for their position, which automatically pulls underflown value to prevent liquidation in the event of undercollateralization. Any external party can call manualLiquidation() to liquidate a position if its health drops below 1.0. However, the manualLiquidation() function does not attempt to utilize the configured topUpSource before executing the liquidation. Because automated rebalancing relies on an asynchronous queue ( asyncUpdate()) , there is a critical time window where an unhealthy position can be liquidated by a third party before the protocol's internal bot can pull the available backup funds. This penalizes users who correctly utilized the protocol's safety features to secure their positions.
Recommendation
Modify the manualLiquidation() function to actively attempt a rebalance before evaluating the position's health for liquidation. By calling _rebalancePositionNoLock() with the force parameter set to true, the protocol will attempt to pull funds from the topUpSource. If the source is sufficiently funded, the position's health will be restored, and the subsequent health assertion will correctly revert the liquidation attempt.
As @jordanschalm pointed out, this suggestion is not feasible because calling into a topUpSource during a liquidation involves executing external, user-provided code. If the topUpSource contains logic that panics or reverts, it would create a "poison pill" that prevents the position from ever being liquidated, since cadence has no mechanism of recovering from panics.
Rationale:
Systemic Risk: Forcing a rebalance within the manualLiquidation() flow creates a Denial of Service (DoS) vector. A malicious or poorly integrated source could block liquidations indefinitely, leading to unrecoverable bad debt for the protocol.
Liquidation Priority: The protocol must prioritize solvency and the ability to close underwater positions over the convenience of a backup funding source that failed to trigger via the rebalancing.
Conclusion:
We will not implement the recommendation to modify manualLiquidation(). The topUpSource remains a best-effort safety mechanism.
Activity
holyfuchs commentedon Mar 12, 2026
As @jordanschalm pointed out, this suggestion is not feasible because calling into a
topUpSourceduring a liquidation involves executing external, user-provided code. If thetopUpSourcecontains logic that panics or reverts, it would create a "poison pill" that prevents the position from ever being liquidated, since cadence has no mechanism of recovering from panics.Rationale:
manualLiquidation()flow creates a Denial of Service (DoS) vector. A malicious or poorly integrated source could block liquidations indefinitely, leading to unrecoverable bad debt for the protocol.Conclusion:
We will not implement the recommendation to modify
manualLiquidation(). ThetopUpSourceremains a best-effort safety mechanism.