Explorer debugging
Debugging failed messages
You'll know that a message failed to process because the message status near the top of the page will show as "Error" and the upper right section of the page will specify a reason why the message wasn't able to be processed.
If your message was not delivered it can be due to several factors.
Invalid destination
If the destination domain identifier (uint32
) is not known to relay clients they will have no way to deliver your message. Refer to the domains for known domains and the canonical identifiers to use when sending messages to these destinations.
Invalid recipient
If the recipient address (bytes32
) is not a contract address that implements the IMessageRecipient
, the relayer will not be able to deliver your message.
// SPDX-License-Identifier: MIT OR Apache-2.0
pragma solidity >=0.6.11;
interface IMessageRecipient {
function handle(
uint32 _origin,
bytes32 _sender,
bytes calldata _message
) external payable;
}
EVM addresses (address
) must be left-padded with zeroes to be compliant. Refer to the TypeCasts library for a pure addressToBytes32
utility function, and the message dispatch section for other details.
Unprocessable
If the gas estimation of the message recipient's IMessageRecipient.handle()
function fails, relayers will not be able to deliver the message. Relayers will continue to estimate gas for message delivery, as state changes may allow for successful delivery of a previously undeliverable message.
If you have a use case which is not accommodated by this behavior, please reach out on Discord.
Underfunded
An underfunded message implies the interchain gas payments made to deliver this message are insufficient.
Relayers use the eth_estimateGas
RPC on the destination chain to determine the absolute cost of relaying a message. If this amount exceeds the total amount of gas paid for on the origin chain, relayers will typically refuse to deliver a message.
You can manually pay for interchain gas to resolve this.
Using Etherscan
You can also look at the Etherscan page of the recipient on the destination chain however be aware that the processing transaction won't show up on list of transactions as you would typically imagine. The reason for that is that relayers actually call the Mailbox contracts which in turn call the handle
function on the recipient. Thus, you will find evidence of processing on the under the Internal Txns
tab instead