Rebasing tokens, which are tokens that can automatically adjust balances over time due to mechanisms like interest accrual or airdrops, are not properly handled by the Tadle protocol. This oversight can lead to potential losses for both users and the protocol.
Rebasing tokens dynamically change a user's balance without requiring any action from the user. This can happen due to mechanisms such as interest accrual, inflation, or airdrops.
In the Tadle protocol, when tokens are deposited into a user's account via the TokenManager::addTokenBalance
function, the protocol updates the userTokenBalanceMap
state to reflect the deposit. However, the protocol assumes that the token balance remains static, which is not the case with rebasing tokens.
Issues:
Missed Gains: If a user deposits a rebasing token, the gains from the rebase (increased balance) will not be properly reflected in their Tadle account. This means users could miss out on additional tokens that would have otherwise accrued.
Inaccurate Accounting: Conversely, if a token undergoes a negative rebase (balance decreases), the protocol may still reflect the pre-rebase balance, leading to inaccurate accounting and potential overvaluation of collateral.
User Impact: Depositors may miss out on gains that should have accrued while their assets were locked as collateral in Tadle.
Protocol Impact: Tadle could suffer losses if it continues to overvalue collateral after a negative rebase, leading to an increased risk of bad debt.
Manual code review.
Documentation: Clearly document that rebasing tokens is not supported as collateral within the protocol. This will help inform users and prevent unintended consequences.
Handle Rebasing Tokens: If supporting rebasing tokens is necessary, implement balance checks before and after token transfers to account for any changes in the token balance. This will ensure accurate accounting and prevent potential losses.
Periodic Balance Updates: Implement periodic updates to user balances for rebasing tokens, ensuring that the protocol and the users are in sync with the current token balances.
Implementing these recommendations will mitigate risks associated with rebasing tokens and ensure that the protocol accurately reflects user balances.
Valid medium, there are disruptions to the ability to take market actions. The following functions will be disrupted without the possibiliy of reaching settlement, since the respective offers cannot be created/listed regardless of mode when transferring collateral token required to the CapitalPool contract or when refunding token from user to capital pool during relisting. So withdrawal is not an issue - `createOffer()` - reverts [here](https://github.com/Cyfrin/2024-08-tadle/blob/04fd8634701697184a3f3a5558b41c109866e5f8/src/core/PreMarkets.sol#L96-L102) - `listOffer()` - reverts [here](https://github.com/Cyfrin/2024-08-tadle/blob/04fd8634701697184a3f3a5558b41c109866e5f8/src/core/PreMarkets.sol#L355-L362) - `relistOffer()` - reverts [here](https://github.com/Cyfrin/2024-08-tadle/blob/04fd8634701697184a3f3a5558b41c109866e5f8/src/core/PreMarkets.sol#L515-L521) - `createTaker()` - reverts [here](https://github.com/Cyfrin/2024-08-tadle/blob/04fd8634701697184a3f3a5558b41c109866e5f8/src/core/PreMarkets.sol#L831-L836) I believe medium severity is appropriate although the likelihood is high and impact is medium (only some level of disruption i.e. FOT tokens not supported and no funds at risk)
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.