The claimFees() function allows the owner to withdraw all accumulated ETH fees from the contract.
However, the function emits no event after a successful withdrawal. Every other state-changing action in the contract — token claims — emits a Claimed event. The absence of a corresponding event for fee withdrawals means that on-chain monitoring tools, indexers, and off-chain observers have no standard way to detect when fees are collected, how much was withdrawn, or how frequently the owner calls this function. The only way to detect a withdrawal is to parse raw call data or monitor ETH balance changes, both of which are significantly more complex and error-prone than event listening.
Likelihood:
Every call to claimFees() produces no log entry — any monitoring system that relies on event logs to track contract activity silently misses every fee withdrawal for the lifetime of the contract
A protocol dashboard or subgraph built on top of this contract has no data source for fee withdrawal history, requiring a full transaction trace scan instead of a simple log query
Impact:
Fee withdrawal activity is invisible to standard on-chain transparency tools — users and auditors cannot verify how much ETH the owner has collected or reconstruct the withdrawal history without a full archive node trace
Absence of event logging is inconsistent with the rest of the contract's design, where Claimed is emitted for every token transfer — the missing event creates a blind spot specifically around the owner's privileged action
The missing event means that a fee withdrawal transaction leaves no trace in the contract's event log. Any listener subscribed to the contract's logs — such as a subgraph, a monitoring bot, or a front-end — receives no notification when the owner withdraws. The contrast with the claim() function makes the omission clear:
Declare a FeesClaimed event and emit it inside claimFees() before the ETH transfer. Capture the balance into a local variable first so the withdrawn amount is recorded in the event rather than relying on the caller to infer it from balance diffs. Replace payable(owner()) with payable(msg.sender) for consistency, since onlyOwner already guarantees the caller is the owner.
The contest is live. Earn rewards by submitting a finding.
Submissions are being reviewed by our AI judge. Results will be available in a few minutes.
View all submissionsThe contest is complete and the rewards are being distributed.