The _beforeInitialize function is designed to validate that the ReFi token is present in the pool before initialization. According to the protocol's design, every pool should contain the ReFi token as either currency0 or currency1 to enable the rebate mechanism.
However, the validation logic contains a critical bug where it checks currency1 twice instead of checking both currency0 and currency1. As a result, any pool where ReFi appears in currency0 will incorrectly revert during initialization, even though such a pool is valid and should be allowed.
Likelihood:
The vulnerability triggers whenever a pool is initialized with the ReFi token as currency0 and any other token as currency1
Users attempting to create legitimate ReFi pools with ReFi as the first token will inadvertently create invalid pools that pass validation
Impact:
The hook's core functionality (applying fees and managing rebates) will fail since swap direction logic depends on ReFi token position
Users will experience unexpected reverts or incorrect fee calculations when attempting to swap in these pools
Protocol reputation damage as pools appear to work during initialization but fail during actual usage
Add this test to RebateFiHookTest.t.sol:
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.