A design issue in the trove management system causes the redeem_collateral function to revert under certain conditions, even when sufficient troves exist in the system to allow redemptions.
Root Cause
The trove manager enforces a rule that at least one active trove must always remain for the managed asset. This constraint is implemented through the require_more_than_one_trove_in_system function.
However, this rule applies individually to every trove manager associated with each supported asset. Since some assets are less utilized than others, this creates an imbalance. For example, the Fluid system currently has 3 troves open for wstETH compared to 146 open for ETH.
If a user attempts to redeem USDF, the redemption will fail if even a single trove manager (for any asset) has only one active trove, regardless of the number of troves available across the entire system. This effectively blocks the redemption process despite there being sufficient collateral system-wide.
Impact
This design limitation could hinder the usability of the protocol, especially as new assets are introduced dynamically. The redeem functionality, being a critical part of the pegging mechanism for USDF, may fail under scenarios where less-utilized assets have only one trove active. This poses a risk to the stability of the USDF peg and limits the protocol’s efficiency.
Proposed Solution
Since this issue stems from a design issue rather than a straightforward coding bug, resolving it requires careful consideration. One possible approach might involve revisiting the requirement for every trove manager to maintain at least one active trove. However, giving up this constraint could have implications for other parts of the system, so is it a good choice?
So to be honest, I don't think I'm qualified to propose a solution to this issue.
Proof of Concept
Proof of Concept
Run the following command after applying the git diff:
forc test test_close_trove_fails_for_a_single_trove --logs -> runs the test