The _beforeInitialize hook is designed to enforce a security rule: only pools that contain the ReFi token as one of the two traded assets are allowed to use this hook. This prevents the hook from being accidentally (or maliciously) attached to unrelated pools.
The current implementation contains a critical logic error: it checks key.currency1 twice instead of checking both currency0 and currency1. As a result, the validation completely ignores whether the ReFi token is present as currency0. Whenever the ReFi token has the lower address (and is therefore sorted into currency0), the condition always evaluates to true and reverts, even though the pool is perfectly valifunction _beforeInitialize(address, PoolKey calldata key, uint160) internal view override returns (bytes4) {
// @> BUG: currency1 is checked twice – currency0 is never examined
if (Currency.unwrap(key.currency1) != ReFi &&
Currency.unwrap(key.currency1) != ReFi) {
revert ReFiNotInPool();
}
}
Likelihood:
Occurs on every pool initialization attempt
Triggers whenever ReFi token address < paired token address
Impact:
Hook deployment fails for half of all possible token orderings
Users/owners cannot create valid ReFi pools with standard token ordering
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.