SNARKeling Treasure Hunt

First Flight #59
Beginner FriendlyGameFiFoundry
100 EXP
View results
Submission Details
Severity: low
Valid

Incorrect address emitted in Claimed event leads to misleading logs

The contract emits the Claimed event with msg.sender instead of the actual payout recipient, causing off-chain systems to misinterpret who received the reward.

Description

  • The contract emits the caller (msg.sender) instead of the actual recipient:

event Claimed(bytes32 indexed treasureHash, address indexed recipient);
// ...
// @> Emits msg.sender instead of recipient
emit Claimed(treasureHash, msg.sender);

Risk

Likelihood

  • Occurs on every successful claim()

Impact

  • Off-chain systems (indexers, dashboards, analytics) record incorrect recipient

  • Breaks accounting, attribution, and monitoring

  • Can mislead users and auditors analyzing contract activity

Proof of Concept

Add this test

function testClaimEventEmitsWrongRecipient() public {
(
bytes memory proof,
bytes32 treasureHash,
address payable recipient
) = _loadFixture();
vm.prank(participant);
vm.expectEmit(true, true, false, false);
// Expect recipient, but contract emits msg.sender instead
emit TreasureHunt.Claimed(treasureHash, recipient);
// This will FAIL because actual emitted value is msg.sender
hunt.claim(proof, treasureHash, recipient);
}

Recommended Mitigation

- emit Claimed(treasureHash, msg.sender);
+ emit Claimed(treasureHash, recipient);
Updates

Lead Judging Commences

s3mvl4d Lead Judge 18 days ago
Submission Judgement Published
Validated
Assigned finding tags:

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.

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.

Give us feedback!