The mitigation mainly solves the issue that when the distributor rate is changed to 0, the corresponding token gets stuck in the RevenueTrader. So the mitigation adds a returnTokens function which can be called when the rate is zero to send the tokens back to the backingManager:
However there is a little issue need to be noticed, that if the asset is unregistered by governance, the token will still be stuck in the RevenueTrader because of the require(assetRegistry.isRegistered(erc20s[i]) check.
But I think its risk is acceptable becuase governance has no motive to do that and governance can also register the asset again at any time to get these tokens back to the BM.
Lines of code
Vulnerability details
Comments
The mitigation mainly solves the issue that when the distributor rate is changed to 0, the corresponding token gets stuck in the
RevenueTrader
. So the mitigation adds areturnTokens
function which can be called when the rate is zero to send the tokens back to the backingManager:However there is a little issue need to be noticed, that if the asset is unregistered by governance, the token will still be stuck in the RevenueTrader because of the
require(assetRegistry.isRegistered(erc20s[i])
check.But I think its risk is acceptable becuase governance has no motive to do that and governance can also register the asset again at any time to get these tokens back to the BM.