Core Contracts

Description:
The burn function in the token contract contains a critical logic flaw that allows users to evade the burn tax when the feeCollector address is set to address(0). When a user burns tokens, the function calculates a tax amount based on the burnTaxRate, burns only the non-taxed portion from the user's balance, and attempts to transfer the tax to the feeCollector. However, if the feeCollector is set to the zero address, the tax transfer is skipped entirely, resulting in the tax amount remaining in the user's wallet.

Impact:
This vulnerability has severe economic and security implications:

1. Token Supply Manipulation: Users can intentionally evade the burn tax, resulting in fewer tokens being removed from circulation than the protocol design intends.

2. Economic Model Disruption: If the token's monetary policy relies on a specific burn rate to maintain scarcity, this vulnerability undermines the entire economic model.

3. Unfair Advantage: Knowledge of this vulnerability creates an information asymmetry where aware users pay lower effective taxes than unaware users.

4. Protocol Revenue Loss: Beyond the immediate tax evasion, the protocol loses potential fee revenue that would have been generated from properly handled burn operations.

The severity is high because it directly compromises a core economic mechanism of the token and allows informed users to gain advantages over uninformed users and the protocol itself.

Proof of Concept:
The vulnerability can be exploited through the following process:

1. A user observes that the feeCollector address has been set to address(0), perhaps through a protocol governance decision or as an initial state.

2. The user initiates a burn transaction for 1,000 tokens with a 5% burn tax rate.

3. The contract calculates the tax amount: 1,000 * 5% = 50 tokens.

4. The contract burns only 950 tokens (amount - taxAmount) from the user's balance.

5. When executing the conditional check to transfer the tax, both conditions are evaluated:

   • taxAmount > 0 evaluates to true (50 tokens is greater than 0)

   • feeCollector != address(0) evaluates to false (feeCollector is the zero address)

6. Since the compound condition evaluates to false, the tax transfer is skipped entirely.

7. The result is that only 950 tokens are burned, and the 50 tokens that should have been collected as tax remain in the user's wallet.

8. From an economic perspective, the user has effectively burned 950 tokens while retaining 50 tokens that should have been either burned or collected as fees.

Recommended Mitigation:
Implement proper handling of the burn tax regardless of the feeCollector status:

1. Modify the burn function to burn the full amount including tax when feeCollector is the zero address:

   function burn(uint256 amount) external {

   uint256 taxAmount = amount.percentMul(burnTaxRate);

   if (taxAmount > 0) {

   if (feeCollector != address(0)) {

   _burn(msg.sender, amount - taxAmount);

   _transfer(msg.sender, feeCollector, taxAmount);

   } else {

   // Burn the full amount including tax

   _burn(msg.sender, amount);

   }

   } else {

   _burn(msg.sender, amount);

   }

   }

2. Add explicit events to log burn operations, including the actual amount burned and tax collected or burned.

3. Consider adding a pausable mechanism for burn operations if needed, rather than relying on the feeCollector address to control tax collection behavior.

4. Add comprehensive unit tests verifying burn behavior in all fee collector states.

This approach ensures that the burn tax is properly applied in all scenarios, maintaining the integrity of the token's economic model.