Snowman Merkle Airdrop

First Flight #42
Beginner FriendlyFoundrySolidityNFT
100 EXP
View results
Submission Details
Impact: medium
Likelihood: medium
Invalid

Hardcoded static addresses in `input.json` expose airdrop to centralization, Sybil risk, and lack of reproducibility

Root + Impact

Description

Normal behavior:
Merkle tree input data should be generated based on transparent, verifiable sources — ideally on-chain events or snapshots — and should reflect eligibility in a deterministic and auditable manner.

The problem:

There is no documentation explaining how these addresses were selected, how the amounts were calculated, or whether any eligibility criteria like stake, activity, time were applied. Since this file is used directly as the source for Merkle leaf generation, this results in a system that:

  • Cannot be reproduced or validated by end users

  • Allows hidden Sybil insertions

  • Relies on full trust in whoever created the file

This input.json file hardcodes addresses and token amounts like this:

"0": { "0": "0x328809Bc894f92807417D2dAD6b7C998c1aFdac6", "1": "1" },
"1": { "0": "0x1D96F2f6BeF1202E4Ce1Ff6Dad0c2CB002861d3e", "1": "1" },
"2": { "0": "0xE55d6ba4bE0A6E0D87c4cA26B7C80779573Dc674", "1": "1" },
"3": { "0": "0xb72116984E306d834a0ae638688Ef9AF1f7FE2cd", "1": "1" },
"4": { "0": "0xEa61F454C2B4A5A16AB556DBE8DBB176C1D02177", "1": "1" }

Risk

Likelihood: Medium

  • This occurs every time input.json is used to generate a Merkle tree. If the file was created manually or without on-chain traceability, it's impossible to confirm fairness or prevent gaming.

  • When a malicious actor gets control over this file, they could insert Sybil wallets or inflate token amounts with no user knowing — since there’s no on-chain enforcement or audit trail validating the content.

Impact: Medium

  • Airdrop recipients may include Sybil wallets or arbitrary participants, damaging the fairness and decentralization of the Snowman distribution.

  • Users cannot verify their eligibility or audit the airdrop source, reducing transparency and potentially eroding trust in the protocol.


Proof of Concept

There is:

  • No reference to where these addresses came from

  • No timestamp, snapshot block, or user eligibility info

  • No cryptographic guarantee this file hasn't been tampered with

Any developer could silently insert fake addresses and generate a valid Merkle root.

{
"types": ["address", "uint256"],
"count": 5,
"values": {
"0": { "0": "0x328809Bc...", "1": "1" },
"1": { "0": "0x1D96F2f6...", "1": "1" },
"2": { "0": "0xE55d6ba4...", "1": "1" },
"3": { "0": "0xb7211698...", "1": "1" },
"4": { "0": "0xEa61F454...", "1": "1" }
}
}

Recommended Mitigation

The airdrop input file should not be manually crafted or opaque. Instead, inputs should be:

  • Deterministically derived from known sources (staking history, balances, off-chain CSVs)

  • Publicly documented, with clear inclusion logic

  • Reproducible by the community, ideally with a Git commit or hash fingerprint of the snapshot

This improves fairness, security, and decentralization of the Merkle airdrop process.


- Hardcoded JSON with opaque values
+ Dynamically generate input values from on-chain events or off-chain snapshots, then document the snapshot source
+ Add a commit hash or Merkle root of the raw source (CSV or snapshot block) to allow users to verify inclusion
+ Store snapshot metadata (block number, rules, source) and include it in `input.json` for traceability
Updates

Lead Judging Commences

yeahchibyke Lead Judge
3 months ago
yeahchibyke Lead Judge 2 months ago
Submission Judgement Published
Invalidated
Reason: Incorrect statement

Support

FAQs

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