Relayer
A relayer is responsible for ensuring messages are delivered to their recipients. Relayers are a permissionless but integral part of the Hyperlane protocol. Anyone can run a relayer!
Want to run a relayer? Follow the Relayer guide.
Running your own relayer involves deploying an IGP contract and maintaining token exchange rates and gas prices inside of it to accurately charge message delivery fees. Therefore, we only recommend doing this while setting up a permissionlessly deployed bridge, rather than reusing an existing bridge.
Relayers are configured to relay messages between two or more chains. A relayer observes the origin Mailbox contracts, watching for new messages. When a new message is detected, the relayer queries the destination chain to determine the message recipient's Interchain Security Module.
The relayer is then responsible for collecting the metadata needed by that ISM. This will vary by ISM, and may include signatures from one or more validators, merkle proofs, zero knowledge proofs, and more!
Finally, the relayer delivers the message to its recipient by calling Mailbox.process() on the destination chain with the aforementioned metadata.
The relayer will periodically retry metadata gathering and message submission. This is important to improve resilience against validator downtime or temporary spikes in transaction fees on the destination.
The relayer does not receive direct token incentives from the protocol, but operators can configure their fee structure for the messages they process, enabling them to earn revenue streams for providing their critical service. For more information, check out interchain gas payments.
Relayers can easily configure the messages that they wish to process. Currently, the relayer will support:
- A sender/recipient whitelist.
- A sender/recipient blacklist.
- The ability to accept payments on the origin chain for processing a message on the destination chain.
For convenience, Hyperlane will run an open source and configurable relayer agent, implemented as a rust binary. If you'd like to run your own relayer, we've open sourced the binary here.
Error handling
The relayer will periodically retry messages when processing fails, using an exponential backoff strategy. Currently, there is no fixed maximum number of retries after which the relayer will cease to attempt processing a message. However, this is not a guarantee of indefinite retries, and operators should not rely on this as a service level agreement (SLA).