An issue was identified where SDLPoolCCIPControllerPrimary and SDLPoolCCIPControllerSecondary contracts hard-code LINK tokens as the fee token in the _buildCCIPMessage function. This design choice may lead to issues for users who do not possess LINK tokens.
The _buildCCIPMessage function in both SDLPoolCCIPControllerPrimary and SDLPoolCCIPControllerSecondary contracts hard-codes LINK tokens as the fee token. If a user doesn't have enough LINK tokens to cover the fee required for the CCIP message, the corresponding operation that attempts to initiate the CCIP message will revert
The current design may cause transactions to fail for users who lack LINK tokens, as the fee calculation is based on LINK. The lack of flexibility in fee payment options could impact user experience and participation in the CCIP mechanism.
Manual review.
Fee Payment Flexibility:
Allow users to choose between paying fees in LINK tokens or the native token by introducing a boolean flag or parameter (e.g., _payNative) in the _buildCCIPMessage function.
Implementation: Modify the _buildCCIPMessage function to include an option for native token fee payment.
e.g you can pass _payNative ? address(0) : address(linkToken) in _buildCCIPMessage like below
And then in building ccip message you can set feeToken: feeTokenAddress.
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.