Summary

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.

Vulnerability Details

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

Impact

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.

Tools Used

Manual review.

Recommendations

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.