L-01 Claim Event Emits Caller Instead of Actual Payout Recipient
Description
The Claimed event is defined with an indexed recipient field, but the contract emits msg.sender instead of the actual payout recipient address.
This causes the event log to diverge from the real reward destination recorded in state transitions and ETH flow.
Risk
This issue does not directly cause fund loss, but it weakens observability and auditability:
off-chain monitoring may record the wrong recipient
analytics and indexing pipelines may misinterpret reward payouts
incident review and user support may rely on misleading event data
Proof of Concept
The event definition is:
but the emitted value is:
If a caller submits a valid claim on behalf of a different recipient, the event logs the caller instead of the actual reward receiver.
Recommended Mitigation
Emit the real payout recipient instead of msg.sender.
Lead Judging Commences
incorrect event parameter
The event is declared as event `Claimed(bytes32 indexed treasureHash, address indexed recipient);`, which clearly indicates that the second indexed field is meant to represent the reward recipient, but `claim()` emits `Claimed(treasureHash, msg.sender)` instead of `Claimed(treasureHash, recipient)`, even though the ETH transfer is sent to recipient and the proof itself is constructed around the public inputs (treasureHash, recipient). As a standalone finding, this is appropriately low severity because it is fundamentally an event/accounting inconsistency rather than a direct loss-of-funds issue: the core state transition and payout still follow the intended recipient, but off-chain consumers reading the event log will observe incorrect metadata about who was associated with the claim.
Rewards 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.