Both receive() and fallback() functions perform identical operations (emitting the same event), which is redundant and wastes deployment gas. One function can handle all ETH reception scenarios.
Either receive() or fallback() alone can handle incoming ETH, making the other redundant.
Both functions on lines 258-260 and 263-265 do exactly the same thing: emit SepEthDonated event with msg.sender and msg.value.
Likelihood:
Both functions exist in every deployment
Code duplication is present in 100% of deployments
Impact:
Wastes deployment gas by duplicating identical functionality
Increases bytecode size unnecessarily, making the contract more expensive to deploy
Both functions perform the same action when the contract receives ETH:
Remove the receive function and keep only fallback for ETH donations. As fallback method can handle all the scenrios:
✅ Ether transfers with or without data → handled by fallback()
✅ Unknown function calls → handled by fallback()
✅ Calls to non-existing function → handled by fallback()
✅ Plain ETH transfers → handled by fallback()
OR remove the fallback function and keep only receive for ETH donations. As receive method can handle almost possible scenrios:
✅ Ether transfers without data → handled by receive()
✅ Plain ETH transfers → handled by receive()
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.