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.