burnTaxRate is double accounted in the function burn(RAACToken.sol)
Summary
when function burn is called, it first takes burnTaxRate and transfers it to feeCollector, then function _update is called where swapTaxRate is taken and again burnTaxRate is taken and this burn tax amount is sent to address(0).so when function burn is called, it takes two times burnTaxRate which is unfair.
Vulnerability Details
1. When the function mint is called, it calls function _update where swapTaxRate + burnTaxRate is taken/accounted for.
2. but when function burn is called, it first takes burnTaxRate and transfers it to feeCollector, then function _update is called where swapTaxRate is taken and again burnTaxRate is taken.
3. so when function burn is called, it takes two times burnTaxRate which is unfair.
\
Impact
** when function burn is called, it takes two times burnTaxRate which is unfair.**
Tools Used
manual review
Recommendations
take 1 time burnTaxRate in the function burn.
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.