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

No Minimum Balance Check in Constructor

sammy0x100

Missing Minimum Balance Check in constructor which is not following the comments

Description

  • The constructor initializes state variables and ensures that the verifier is not the zero address

  • In the constructor is the following comment, Owner should fund 100 ETH at deployment (10 treasures × 10 ETH). This is however not enforced.

// @> //Owner should fund 100 ETH at deployment (10 treasures × 10 ETH).

Risk

Likelihood:

  • This occurs whenever the contract is being deployed

Impact:

  • The contact can be deployed with 0 ETH since there is no one stopping its deployment.

  • The impact is not very serious since claim() would revert

Proof of Concept

No PoC

Recommended Mitigation

just to be safe and make this good for production, it might be good to add the check in the constructor

​
constructor(address _verifier) payable {
if (_verifier == address(0)) revert InvalidVerifier();
// ← Add this line for minimum balance check
if (msg.value < 100 ether) revert NotEnoughFunds(); // enforces exactly the amount needed for 10 treasures
​
owner = msg.sender;
verifier = IVerifier(_verifier);
paused = false;
}
Updates

Lead Judging Commences

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

liquidity enforcement issues

The liquidity-enforcement issue arises because the protocol assumes the hunt will be funded with enough ETH to cover all rewards, but the contract itself does not actively enforce that invariant at deployment time. The constructor accepts arbitrary `msg.value` and only validates the verifier address, even though the contract hardcodes a reward of 10 ether and a maximum of 10 treasures, implying an expected full funding target of 100 ether; the README likewise states that the contract is expected to be funded with enough ETH to cover all rewards and notes that the default deployment flow uses 100 ether. Although the deployment script sets `DEFAULT_INITIAL_FUNDING = 100 ether`, it also allows that amount to be overridden via `vm.envOr("INITIAL_FUNDING", DEFAULT_INITIAL_FUNDING)`, and the only post-deployment balance check is that the contract balance equals the chosen `initialFunding`, not that the chosen amount is actually sufficient to fund the full hunt. As a result, the system can be deployed in an underfunded state after which otherwise valid claims will begin reverting with `NotEnoughFunds()` once the balance drops below a single reward payment.

Support

FAQs

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

Give us feedback!