Deploy.run() should deploy MerkleAirdrop with zkSync USDC as i_airdropToken, then send 100 USDC (4 × 25e6) of that same token to the contract so the four recipients can claim it. The README (L124) says the team will deploy with this script, and the script's own L17 comment reads "Send USDC -> Merkle Air Dropper".
The constructor token comes from s_zkSyncUSDC (L8, 0x1D17CbCf0D6d143135be902365d2e5E2a16538d4), but the funding transfer at L18 hard-codes a second literal, 0x1d17CBcF0D6D143135aE902365D2E5e2A16538D4. Lowercased, the two differ in one hex digit (...143135be90... vs ...143135ae90...), so they are two different addresses, not two casings of one. Both are valid EIP-55 checksums, so solc accepts them without a warning. i_airdropToken is immutable, and claim (L39) is the only place the contract moves an ERC20. The funded tokens can therefore never be paid out or recovered.
Likelihood:
The failure happens on every run of the in-scope script as written. Both addresses are hard-coded literals, and the README states that this script is how the contract will be deployed. No attacker and no unusual condition is needed.
Nothing flags the mismatch at deployment time: deployment and funding both complete without a revert, as the PoC shows. The defect only appears once users' claims start reverting.
Impact:
Every claim by every recipient reverts. When the constructor address has no code, OZ 5.0.2 SafeERC20 reverts with AddressEmptyCode. When a live token sits there, the airdrop holds none of it and the transfer reverts on insufficient balance.
The 100 USDC sent to the airdrop in the other token has no way out. The token address is immutable, claim moves only i_airdropToken, and claimFees moves only ETH; the PoC shows the 100e6 balance unchanged after claimFees. In the reverse case, where the funded address has no code, the L18 funding call itself reverts and the script cannot ship a funded airdrop. Either way, the script as written cannot produce a working airdrop.
The PoC does not call the script directly. A DeployMirror contract reproduces the token handling of Deploy.run() with the L8, L11, L16 and L18 literals copied character for character. vm.startBroadcast/stopBroadcast are dropped, and the mirror plays the broadcaster, so it also becomes the owner. The Merkle root is a parameter, built as a 4 × 25e6 tree, so the token mismatch is tested on its own, separately from the root-amount bug. A 6-decimal ERC20 mock is etched at the funded address (ae). The tests show:
the baseline: one shared token address lets all four users claim;
the bug with no code at be: deployment succeeds silently, every claim reverts with AddressEmptyCode(be), and 100e6 stays locked after claimFees;
the bug with a live token at be: every claim reverts with ERC20InsufficientBalance, and 100e6 stays locked;
the reverse branch: funding reverts when the ae address has no code.
Run from the repository root, with the file saved as test/PoC_AD-02.t.sol:
Result: Suite result: ok. 4 passed; 0 failed; 0 skipped.
## Description The `s_zkSyncUSDC` address in `Deploy.s.sol` is incorrectly set, leading to a failure in the claiming process. This error results in funds being stuck in the `MerkleAirdrop` contract due to the immutability of the token address. ## Impact All funds become permanently trapped in the `MerkleAirdrop` contract, rendering them inaccessible for claiming or transfer. **Proof of Concept:** To demonstrate the issue, a test contract can be added and executed using the following command: `forge test --zksync --rpc-url $RPC_ZKSYNC --mt testDeployOnZkSync` Use the RPC URL `https://mainnet.era.zksync.io` for testing. <details> <summary>Proof Of Code</summary> ```javascript // SPDX-License-Identifier: MIT pragma solidity 0.8.24; import { MerkleAirdrop, IERC20 } from "../src/MerkleAirdrop.sol"; import { Test, console2 } from "forge-std/Test.sol"; contract MerkleAirdropTest is Test { MerkleAirdrop public s_airdrop; uint256 s_amountToCollect = (25 * 1e6); // 25.000000 address s_collectorOne = 0x20F41376c713072937eb02Be70ee1eD0D639966C; bytes32 s_proofOne = 0x32cee63464b09930b5c3f59f955c86694a4c640a03aa57e6f743d8a3ca5c8838; bytes32 s_proofTwo = 0x8ff683185668cbe035a18fccec4080d7a0331bb1bbc532324f40501de5e8ea5c; bytes32[] s_proof = [s_proofOne, s_proofTwo]; address public deployer; // From Deploy.t.sol bytes32 public s_merkleRoot = 0x3b2e22da63ae414086bec9c9da6b685f790c6fab200c7918f2879f08793d77bd; address public s_zkSyncUSDC = 0x1d17CBcF0D6D143135aE902365D2E5e2A16538D4; uint256 public s_amountToAirdrop = 4 * (25 * 1e6); function setUp() public { deployer = makeAddr("deployer"); deal(0x1D17CbCf0D6d143135be902365d2e5E2a16538d4, deployer, 100 * 1e6); vm.deal(s_collectorOne, 100 ether); } function testDeployOnZkSync() public { if (block.chainid != 324) { return; } vm.startPrank(deployer); // From here there is the code from run() s_airdrop = deployMerkleDropper(s_merkleRoot, IERC20(s_zkSyncUSDC)); // Send USDC -> Merkle Air Dropper IERC20(0x1d17CBcF0D6D143135aE902365D2E5e2A16538D4).transfer(address(s_airdrop), s_amountToAirdrop); // end code from run vm.stopPrank(); vm.startPrank(s_collectorOne); s_airdrop.claim{ value: s_airdrop.getFee() }(s_collectorOne, s_amountToCollect, s_proof); vm.stopPrank(); } function deployMerkleDropper(bytes32 merkleRoot, IERC20 zkSyncUSDC) public returns (MerkleAirdrop) { return (new MerkleAirdrop(merkleRoot, zkSyncUSDC)); } } ``` </details> ## Recommendations To resolve the issue, update the s_zkSyncUSDC address in Deploy.s.sol to the correct value: ```diff - address public s_zkSyncUSDC = 0x1D17CbCf0D6d143135be902365d2e5E2a16538d4; + address public s_zkSyncUSDC = 0x1d17CBcF0D6D143135aE902365D2E5e2A16538D4; ```
The contest is live. Earn rewards by submitting a finding.
Submissions are being reviewed by our AI judge. Results will be available in a few minutes.
View all submissionsThe contest is complete and the rewards are being distributed.