SNARKeling Treasure Hunt
First Flight #59
Beginner FriendlyGameFiFoundry
100 EXP
View results
Previous Next
Submission Details
Severity: low
Valid

Incorrect Event Emission

n0d3_

Root + Impact

Description

Events are the primary way off-chain systems keep track of contract state changes. The Claimed event is intended to signal who successfully found a treasure and received the reward.

In the current implementation, the code transfers REWARD to the recipient, but logs the msg.sender. If a user uses a "relayer" or a secondary wallet to pay for gas while sending the funds to their hardware wallet (recipient), the public record will incorrectly show the gas-paying wallet as the winner.

// Root cause in the codebase
function claim(bytes calldata proof, bytes32 treasureHash, address payable recipient) external nonReentrant() {
// ... logic ...
(bool sent, ) = recipient.call{value: REWARD}("");
require(sent, "ETH_TRANSFER_FAILED");
​
@> emit Claimed(treasureHash, msg.sender); // Should be recipient
}

Risk

Likelihood: High

  • The code is hardcoded to log the wrong address.

Impact: Low

  • It does not result in a loss of funds (the money still goes to the right place), but it corrupts the "source of truth" for the hunt's history and creates confusion for users.

Proof of Concept

​

Recommended Mitigation

Update the event to emit the address that actually received the reward.

- 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!