As distributeRewards
, there is a function that sends rewards to all secondary chains.
It loops the process of _distributeRewards
for the number of chains. However, it sends a message to CCIP in _distributeRewards
.
The message to CCIP can fail for various reasons, in which case the entire distributeRewards
will fail.
It is undesirable for a failure in one chain to spill over into another chain.
The _distributeRewards
function includes a process that loops through as many _distributeRewards
as there are chains.
for (uint256 i = 0; i < numDestinations; ++i) {
_distributeRewards(whitelistedChains[i], tokens, distributionAmounts[i]);
}
https://github.com/Cyfrin/2023-12-stake-link/blob/549b2b8c4a5b841686fceb9c311dca9ac58225df/contracts/core/ccip/SDLPoolCCIPControllerPrimary.sol#L90-L92
In the _distributeRewards
function, ccipSend
is used to send CCIP messages.
However, this fails for various reasons.
Some are due to the values set in this contract, and some are due to circumstances on the CCIP side.
(https://docs.chain.link/ccip/api-reference/errors)
bytes32 messageId = router.ccipSend(_destinationChainSelector, evm2AnyMessage);
https://github.com/Cyfrin/2023-12-stake-link/blob/549b2b8c4a5b841686fceb9c311dca9ac58225df/contracts/core/ccip/SDLPoolCCIPControllerPrimary.sol#L284
In other words, the possibility of failure should always be considered.
It is inevitable that the failure of one chain that is scheduled to be sent will disadvantage the users of that chain.
However, users of other unrelated chains should not be disadvantaged.
In critical functions, the impact of one chain is adversely affecting users in other unrelated chains (they can not receive rewards)
Manual
try/catch
, etc., to prevent spillover to unrelated chains.
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.