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

[M-01] Deployment script lacks validation for sufficient initial funding leading to insolvency

velo

Root + Impact

Description

  • The TreasureHunt protocol is designed with fixed parameters: REWARD = 10 ETH and MAX_TREASURES = 10. To function correctly and honor all 10
    potential claims, the contract must be funded with at least 100 ETH upon deployment

  • The issue lies in the Deploy.s.sol script, which retrieves the INITIAL_FUNDING amount from an environment variable but fails to validate if
    this amount is sufficient to cover the protocol's total liabilities. If the operator misconfigures the .env file or passes a lower value during
    deployment, the contract will be successfully deployed but will be insolvent before the hunt is completed

// contracts/scripts/Deploy.s.sol
​
function run() external {
// ...
// @> Root Cause: initialFunding is pulled from environment without a floor-price check
uint256 initialFunding = vm.envOr("INITIAL_FUNDING", DEFAULT_INITIAL_FUNDING);
​
vm.startBroadcast(deployerKey);
verifier = new HonkVerifier();
// @> The contract is deployed with potentially insufficient funds
hunt = new TreasureHunt{value: initialFunding}(address(verifier));
vm.stopBroadcast();
​
// @> This only verifies the balance matches the input, not the protocol requirement
require(hunt.getContractBalance() == initialFunding, "UNEXPECTED_BALANCE");
// ...
}

Risk

Likelihood:

  • This is a realistic scenario involving operator error during deployment to a live network (e.g., Mainnet or Sepolia).

  • Foundry scripts often rely on environment variables that can be easily mistyped or misconfigured in high-pressure deployment environments

Impact:

  • Protocol Insolvency: If the contract is underfunded (e.g., only 50 ETH), the last 5 participants who find physical treasures will be unable to
    claim their rewards. Their claim() transactions will revert with NotEnoughFunds(), leading to a breakdown in trust and financial loss for the
    finders

Proof of Concept

If the script is executed with the following command:
INITIAL_FUNDING=10000000000000000000 forge script Deploy.s.sol ... (which is only 10 ETH)

  1. The script will execute successfully without any warnings.

  2. The TreasureHunt contract goes live with a balance of only 10 ETH.

  3. The first successful claimant receives the 10 ETH.

  4. All subsequent 9 claimants (2nd to 10th) will have their valid proofs rejected by the contract due to insufficient balance, even though they
    found the physical treasures

function test_InsolvencyFromDeploymentScript() public {
// 1. Simulate an incorrect INITIAL_FUNDING value from the deployment script (e.g., 10 ETH)
uint256 insufficientFunding = 10 ether;
​
// 2. The Deploy.s.sol script would proceed to deploy the contract with this value
// There is no 'require(initialFunding >= 100 ether)' validation in the script
TreasureHunt insolventHunt = new TreasureHunt{value: insufficientFunding}(address(mockVerifier));
​
console.log("Contract deployed with balance:", address(insolventHunt).balance / 1e18, "ETH");
​
// 3. The first winner performs a valid claim
insolventHunt.claim("", keccak256("TREASURE_1"), payable(address(0x111)));
console.log("Winner 1 claimed 10 ETH. Remaining contract balance:", address(insolventHunt).balance);
​
// 4. REAL VULNERABILITY PROOF: The second winner attempts to claim
// Even though they have a valid ZK proof, the transaction REVERTS because funds are exhausted
vm.prank(attacker);
vm.expectRevert(abi.encodeWithSelector(TreasureHunt.NotEnoughFunds.selector));
insolventHunt.claim("", keccak256("TREASURE_2"), payable(address(0x222)));
​
console.log("Winner 2 failed to claim due to protocol insolvency caused by the deployment script!");
}

Recommended Mitigation

It is recommended to add a strict validation check within the run() function of the deployment script. The script should verify that the
initialFunding is at least equal to the total reward liability of the hunt (MAX_TREASURES * REWARD).

function run() external {
uint256 initialFunding = vm.envOr("INITIAL_FUNDING", DEFAULT_INITIAL_FUNDING);
+
+ // Ensure the contract is fully funded for all 10 rewards (10 * 10 ETH)
+ uint256 requiredFunding = 100 ether;
+ require(initialFunding >= requiredFunding, "ERROR: Deployment funding must be at least 100 ETH");
​
vm.startBroadcast(deployerKey);
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!