L2MessageReceiver contract: changing config.sender address will result in stuck minting messages.
The L1Sender contract is responsible of managing and redirecting calls from L1 to L2 gateways.
The Distribution contract will call the L1Sender contract when the stakers of pools claim their rewards via Distribution.claim function, where a mint message is going to be sent to the L2MessageReceiver contract on Arbitrum chain, and this operation is done via the layer zero endpoint on the Ethereum chain (via send function implemented by the layer zero endpoint):
The mint message is going to be received and executed by the L2MessageReceiver contract on Arbitrum; where it will check if the sender of the lz message is the authorized L1Sender contract address before minting the MOR tokens to the claimer address:
So as can be noticed: the config.receiver in L1Sender contract should be the config.sender in the L2MessageReceiver contract as the L2MessageReceiver._nonblockingLzReceive function will extract the first encoded address from the senderAndReceiverAddresses_ argument.
Knowing that the L2MessageReceiver implements a non-blocking receive mechanism, where any failed mint messages are catched and saved in the L2MessageReceiver contract so that they can be executed later:
if the admin of the L2MessageReceiver contract changes the config.sender address; this will result in failed messages to never be executed as the aforementioned check on the sender address will revert.
This will result in users losing their entitled rewards, as the Distribution contract will reset their uncalimed rewards to zero when they claim them, optimistically assuming that their rewards will be successfully minted on L2, and the L2MessageReceiver will never be able to execute their failed rewards minting.
L1Sender.sendMintMessage function/ L127-L137
L2MessageReceiver._nonblockingLzReceive function/ L97-L101
L2MessageReceiver.setParams function
Manual Review.
In L2MessageReceiver contract : add a mechanism to cache the config.sender address for the failed messages so that they can be executed later even if the config.sender address is changed.
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.