Root cause: MESSAGE_TYPEHASH misspells the EIP-712 type string as addres and adds spaces. Impact: signatures produced by standard wallets never validate, so eligible users cannot claim their Snowman

Description

SnowmanAirdrop inherits OpenZeppelin's EIP712 and requires an ECDSA signature on every claim. The comment on the constant states it is "used for EIP-712 compliant message signing", so a signature produced by any EIP-712 wallet call should validate.

The type string it hashes is not valid EIP-712. The word address is misspelled as addres, and EIP-712 encodeType forbids the whitespace that has been added inside the argument list. The canonical form is SnowmanClaim(address receiver,uint256 amount). Because the type hash differs, the digest a wallet computes never equals the digest the contract computes, and every such signature is rejected.

The two sides disagree permanently:

The rest of the EIP-712 setup is fine, so the type string is the only fault: rebuilding the domain separator by hand reproduces getMessageHash exactly, and swapping only the type hash back to the broken one makes the same claim succeed.

Risk

Likelihood:

• Every user who signs through a wallet hits this, on every claim attempt, from deployment onward. eth_signTypedData_v4 produces the canonical type hash by definition, and personal_sign prefixes the payload, so both standard paths are rejected.

• A valid signature is demanded on every claim, including when the receiver is the transaction sender, so there is no path around it for a normal user.

Impact:

• Eligible recipients who farmed Snow across the 12 week window cannot exchange it for the NFT through any ordinary interface, and the delegated claim the README advertises, having someone claim on their behalf with v, r, s, does not work for wallet users.

• Nothing can be repaired after deployment: MESSAGE_TYPEHASH is a compile time constant, the contract has no owner, no setter and no upgrade path, and i_merkleRoot is immutable, so the only remedy is redeploying with a new root.

Proof of Concept

The affected party is any eligible recipient, alice here, one of the five in script/flakes/input.json. The protocol side is SnowmanAirdrop, validating against a type hash no standard tool produces. There is no attacker here, the protocol simply rejects its own users. Deployed via their own Helper.s.sol.

Output:

Three further checks close the obvious objections. A personal_sign signature over the contract's own digest is rejected too, so both standard wallet methods fail. Alice cannot claim even as the sender herself, so this is not limited to the delegated flow. And deploying the same airdrop with only the type string corrected makes the canonical signature validate, pinning the typo as the sole cause.

To be straight about the one remaining route: a user could call getMessageHash and sign that raw bytes32 directly, which is what their own test suite does with vm.sign. That is why I file this as Medium rather than higher. It is not a route ordinary users have, since MetaMask removed plain eth_sign and hardware wallets refuse to sign an opaque hash by default.

Recommended Mitigation

Correct the type string to the canonical EIP-712 form:

While there, getMessageHash passes a struct into abi.encode, which encodes identically here but is fragile if the struct changes. Encode the fields explicitly: