Core Contracts

Summary

The DEToken should not be transferable to prevent Rtoken from becoming stuck in the StabilityPool. The current implementation allows DEToken transfers, which disrupts the underlying accounting logic of the StabilityPool. This can lead to situations where users cannot withdraw their Rtoken from the pool, causing financial losses and operational issues.

Vulnerability Details

Root Cause

1. Transferable DEToken Breaks Accounting
   The StabilityPool relies on a 1:1 mapping between DEToken balances and Rtoken deposits. When DEToken is transferred, this mapping is broken because the userDeposits mapping in the StabilityPool is tied to the original depositor (msg.sender), not the current DEToken holder.

2. Example Scenario

   • User A deposits 100 Rtoken and receives 100 DEToken.

   • User A transfers 100 DEToken to User B.

   • User B attempts to withdraw Rtoken from the StabilityPool.

   • The StabilityPool checks userDeposits[msg.sender], which is tied to User A. Since User B has no deposit record, the withdrawal fails.

   • User A cannot withdraw either because they no longer hold the DEToken required for the withdrawal process.

Impact

No one can withdraw the Rtokens of already transffered DEToken.

Recommendations

1. Override Transfer Functions
   Modify the DEToken contract to override the transfer and transferFrom functions, preventing transfers entirely:

   function transfer(address to, uint256 amount) public override returns (bool) {

   revert("DEToken: Transfers are disabled");

   }

   ​

   function transferFrom(address from, address to, uint256 amount) public override returns (bool) {

   revert("DEToken: Transfers are disabled");

   }