Double Taxation When Burning RAAC
Summary
In the RAACToken.sol contract the burn function applies the taxAmount multiple times, first in _burn and then in _update. This will lead to excessive taxation and incorrect token burning.
Vulnerability Details
The vulnerability arises from the burn function, which calculates a taxAmount and applies it during the _burn process. However, the _update function, which is called internally by the ERC20 contract, also applies the tax again. This results in the tax being applied multiple times on the same amount. For example, if a user tries to burn 100 tokens and the tax amount is 10, the tax will be applied on these 10 tokens again, leading to excessive taxation and incorrect burning.
Impact
By applying the tax multiple times, users will end up burning more tokens than intended, leading to an unfair reduction in their token balance. This can cause financial losses for users and undermine the trust and integrity of the tokenomics. The excessive taxation can also disrupt the intended deflationary mechanism of the RAAC token, affecting its value and market dynamics.
Tools Used
Manual Review
Recommendations
To mitigate this vulnerability, ensure that the tax is applied only once during the burn process.
Lead Judging Commences
RAACToken::burn applies burn tax twice when transferring to feeCollector, causing excess tokens to be burned and reduced fees to be collected
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
RAACToken::burn applies burn tax twice when transferring to feeCollector, causing excess tokens to be burned and reduced fees to be collected
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
Appeal created
RAACToken::burn applies burn tax twice when transferring to feeCollector, causing excess tokens to be burned and reduced fees to be collected
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
Prize pool breakdown
Live
The contest is live. Earn rewards by submitting a finding.
Appeals
This is your time to appeal against judgements on your submissions.
Appeals Review
Appeals are being carefully reviewed by our judges.