Debugging Messages
How to use the Hyperlane Explorer to debug messages
Then paste a sender/recipient address or a transaction hash into the top search field. All matching messages will be shown in the result list. Click the row for more details.
Retrieving a transaction in the Hyperlane Message Explorer
You'll know that a message failed to process because the bar at the top of the Message Explorer will turn red and the upper right section of the page will feature error reasons indicating why the message wasn't able to process.
Failed transaction from Fuji to Goerli
If your message was not delivered it can be due to several factors:
If the destination domain identifier (
uint32) is not known to relay clients they will have no way to deliver your message. Refer to the domain identifiers docs for supported domains and the canonical identifiers to use when sending messages to these destinations.If the recipient address (
bytes32) is not a contract address that implements the IMessageRecipient interface, the relayer will not be able to deliver your message. EVM addresses (
address) must be left-padded with zeroes to be compliant. Refer to the send encoding section for details and a pure addressToBytes32 utility function. If gas estimation of the message recipient's
IMessageRecipient.handle() function fails, the relayer will not deliver the message. The relayer will continue to estimate gas for message delivery, as state changes may allow for successful delivery of a previously undeliverable message.Users are not currently required to pay relaying fees but eventually this will be necessary for the economic sustainability of the protocol.
An underfunded message implies the gas paid for message delivery is insufficient. The relayer registered on the gas paymaster can
claim these fees to compensate for gas costs incurred on the destination chain. The relayer client uses the eth_estimateGasRPC on the destination chain to determine the absolute cost of relaying a message, uses the CoinGecko API to calculate the exchange rate between the two chains native assets, and will only pay for message processing if the message relay was funded appropriately on the source chain's paymaster (within some acceptable price deviation).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 insteadLast modified 15d ago