FeeCollector cannot burn all the RAAC tokens that meant to be burned when distributes collected fees.
When distributes collected fees, some fees are expected to burned if the corresponding fee type's burnShare is not 0.
FeeCollector::_processDistributions()
However, when burn() is called in RAACToken, burn tax is charged and if feeCollector is not address(0), some RAAC tokens are sent back to FeeCollector, results in some tokens cannot be fully burned.
burnRate is set in FeeCollector to reduce the total circulating supply, creating a scarcity of the cryptocurrency. Fail to burn the expected amount of RAAC tokens will not increase the token's value based on basic supply and demand dynamics.
Please run forge test --mt testAudit_CannotFullyBurn.
Manual Review
It is recommended not to charge burn tax when the caller is FeeCollector.
This is by design, sponsor's words: Yes, burnt amount, done by whitelisted contract or not always occur the tax. The feeCollector is intended to always be whitelisted and the address(0) is included in the _transfer as a bypass of the tax amount, so upon burn->_burn->_update it would have not applied (and would also do another burn...). For this reason, to always apply such tax, the burn function include the calculation (the 2 lines that applies) and a direct transfer to feeCollector a little bit later. This is done purposefully
This is by design, sponsor's words: Yes, burnt amount, done by whitelisted contract or not always occur the tax. The feeCollector is intended to always be whitelisted and the address(0) is included in the _transfer as a bypass of the tax amount, so upon burn->_burn->_update it would have not applied (and would also do another burn...). For this reason, to always apply such tax, the burn function include the calculation (the 2 lines that applies) and a direct transfer to feeCollector a little bit later. This is done purposefully
This is by design, sponsor's words: Yes, burnt amount, done by whitelisted contract or not always occur the tax. The feeCollector is intended to always be whitelisted and the address(0) is included in the _transfer as a bypass of the tax amount, so upon burn->_burn->_update it would have not applied (and would also do another burn...). For this reason, to always apply such tax, the burn function include the calculation (the 2 lines that applies) and a direct transfer to feeCollector a little bit later. This is done purposefully
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.