Opus finding
Airlock.migrate reverts on native ETH migration because token1 is unconditionally transferred via ERC20.safeTransfer
highbugmedium
- src/Airlock.sol:195-210
The migrate flow special-cases token0 == address(0) (native ETH) but always calls ERC20(token1).safeTransfer for token1. If both branches are consistent (token0 < token1 ordering, and ETH is always token0), this is correct. However, the code only protects token0 from being ETH; it makes the implicit assumption that ETH cannot ever be token1. This is consistent with v3/v4 currency ordering (address(0) sorts lowest), but if an exitLiquidity implementation ever returns a swapped order or if a non-ETH zero address sentinel is used differently, transferring token1 as ERC20 will revert. This is a latent contract-API assumption that is not validated and represents a fragile contract.
Recommendation
Apply the same address(0) check for token1, or assert/document the token0<token1 ordering invariant via an explicit require so the failure mode is clear.