refactor: contracts

[MarcosNicolau]

Summary

• Encode validFrom in the Merkle leaf so each claim leaf represents a vesting stage gated by timestamp.
• Add claimBatch entry point to claim multiple stages in one tx with a single transferFrom.
• Replace mapping(address => bool) hasClaimed with per-stage tracking keyed by keccak256(claimer, leaf).
• Extract _verifyAndMark internal helper shared by claim and claimBatch.

Notes

• Breaking change to the claim ABI (claim now takes validFrom) and to the Merkle leaf format. Any off-chain tree builder must be updated before this is deployed.
• Storage layout change: hasClaimed key type changes from address to bytes32. Safe for a fresh deploy; not an in-place upgrade.

[JuArce]

/claude /codex

[github-actions]

Codex Code Review

Findings

1. High - Upgrade storage/key semantic break can re-enable already-claimed accounts
   File: ClaimableAirdrop.sol, ClaimableAirdrop.sol, ClaimableAirdrop.sol
   hasClaimed changed from mapping(address => bool) to mapping(bytes32 => bool) and lookups now use claimKey = keccak256(abi.encode(msg.sender, leaf)).
   For an upgradeable proxy, this effectively changes how claimed state is addressed. Existing claimed flags written under the old address-based keyspace will not be recognized by the new logic, so users who claimed before upgrade can claim again if still present in the merkle root.

Actionable fix:

• Preserve backward compatibility by keeping a legacy check (e.g., old address-claim state) during transition, or
• Explicitly guarantee/prove this upgrade is only deployed before any claims happen on that proxy instance.

No other concrete security/bug/performance issues stood out in this diff.

[claude]

Low: batch emits a single event, losing per-stage auditability

Off-chain indexers (and future auditors) can only see the total amount transferred, not which individual stages were claimed. Consider emitting one TokensClaimed event per stage inside _verifyAndMark, or adding a separate StagesClaimed event that logs the stage details.

[claude]

Review: ClaimableAirdrop vesting refactor

Overall the design is sound — per-stage claim tracking, nonReentrant on both entry points, and state written before any external call. Two inline findings plus one deployment hazard below.

---

Medium — in-place upgrade allows re-claims by existing claimants

hasClaimed changes its key type from address to bytes32. Both occupy the same storage slot but keys are computed differently:

• Old: hasClaimed[msg.sender]
• New: hasClaimed[keccak256(abi.encode(msg.sender, leaf))]

If this is deployed as an in-place upgrade of a live contract, every previously-claimed address looks unclaimed to the new code. Combined with an updated Merkle root they could claim again.

The PR description flags this, but the contract has no guard — no reinitializer that migrates or locks old entries, no revert in _authorizeUpgrade, no NatSpec warning on the storage variable. A misapplied upgrade would silently allow double-claims. At minimum add a /// @custom:storage-layout-breaking-change or equivalent NatSpec on the mapping so the hazard is visible in the source.

---

See inline comments for the two lower-severity findings.

[JuArce]

Testing WIP