The _burn() function in ERC20Internals.sol does not emit a Transfer event to address(0) as required by the ERC20 standard.
According to the ERC20 specification: "A token contract which destroys tokens SHOULD trigger a Transfer event with the _to address set to 0x0 when tokens are burned."
The current implementation burns tokens and updates balances correctly but fails to emit the required event, making burns invisible to off-chain systems.
Note: The function updates state correctly but never emits the required Transfer(from, address(0), value) event.
Likelihood: High
Every burn operation is affected. This is not an edge case - it affects 100% of token destruction operations.
Impact: High
ERC20 Non-compliance: The token does not meet the ERC20 standard
Incorrect supply tracking: Block explorers show wrong circulating supply
DeFi integration failures: Protocols that track burns cannot function correctly
Audit failures: Token will fail formal ERC20 compliance audits
The exploit was confirmed using a Foundry test that demonstrates no Transfer event is emitted during burning.
Setup:
Deploy the Token contract
Mint tokens to alice
Set up event recording using vm.recordLogs()
Action:
Call token.burn(alice, 100e18) to burn 100 tokens from alice
Retrieve all emitted logs
Result:
No Transfer event found in logs
Tokens were successfully burned and balance updated
Off-chain systems have no visibility into this burn
Supporting Code:
Test Results:
Add the Transfer event emission to the _burn() function after updating the balance and total supply.
This ensures the token emits the standard Transfer event for all burning operations, restoring ERC20 compliance and enabling off-chain tracking.
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.
The contest is complete and the rewards are being distributed.