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

Wrong Event Emission

sammy0x100

Faulty event emisssion in claim function causing wrong information being logged

Description

  • The 'claim' function is used by the recipient to claim their reward using the zk proof and the treasure hash

  • At the end of the function however the event is emitted with wrong information.

@> emit Claimed(treasureHash, msg.sender);

Risk

Likelihood:

  • The payment goes out to the 'recipient' but it will be shown as going to msg.sender by off-chain indexers and explorers.


Impact:

  • The wrong address will be displayed as the beneficiary when the event logs out

  • Anyone can submit valid ZK proofs on behalf of different callers and misdirect who "appeared" to have found the treasure in the event logs.

  • Misleading leaderboards or statistics


Proof of Concept

This PoC test shows a test that shows how one participant calling the 'claim' function can lead to misleading data being logged due to the bug in the event emission code.

// PoC: Caller delegation with misleading event
function testEventMismatch() public {
address alice = address(0xAAAA);
address bob = address(0xBBBB);
bytes32 treasureHash = keccak256("treasure1");
bytes calldata validProofForAlice = getProof(alice, treasureHash);
// Bob calls claim() with Alice's proof and Alice as recipient
vm.prank(bob);
treasureHunt.claim(validProofForAlice, treasureHash, payable(alice));
// Events logged:
// emit Claimed(treasureHash, bob);
// Should be:
//emit Claimed(treasureHash, alice);
}

Recommended Mitigation

The mitigation is not complicated just correct the address logged off in the event to the correct one that is the 'recipient' not 'msg.sender'

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

Appeal created

sammy0x100 Submitter
18 days ago
s3mvl4d Lead Judge 15 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!