The issue in the RAACToken contract arises due to the interaction between the FeeCollector mechanism and the burn function. When FeeCollectionDisabled is active (feeCollector set to address(0)), no tax is applied upon burning, and the taxAmount remains in the msg.sender account. However, when fees are collected and distributed through distributeCollectedFees, the _processDistributions function attempts to burn shares[1] of RAACToken. If FeeCollectionDisabled is disabled, the amount - taxAmount of RAACToken gets stuck in the FeeCollector contract, as the function does not properly account for this state. This results in unclaimed tokens accumulating in the contract instead of being properly processed or burned.
In the RaacToken contract, the owner can enable or disable the feeCollector address. This logic is implemented in the setFeeCollector function, as seen in FeeCollectionEnabled and FeeCollectionDisabled.
So, upon burning RAACTokens, if the feeCollector address is address(0), it means FeeCollectionDisabled is active. In this case, no tax is applied upon burning, and the taxAmount remains in the msg.sender account, while amount - taxAmount is burned.
Based on this feature of the RAACToken contract, an issue has occurred in the FeeCollector contract. The problem arises in the distributeCollectedFees function which distributes collected fees according to protocol rules, and calls internal _processDistributions to transfer and allocated these collected fees. Specifically, shares[1] of the RAACToken is burned, So if FeeCollectionDisabled is disabled. As a result, the amount - taxAmount of RAACToken gets stuck in the FeeCollector contract.
The issue causes RAACTokens to get stuck in the FeeCollector contract.
Manual Review
Implement a fallback mechanism to recover or reallocate unclaimed tokens.
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.