Skip to main content
The Hyperlane protocol decouples the transport layer from the security layer of cross-chain message passing. To run a deployment, it relies on offchain agents that observe onchain activity and carry out either the transport or security aspects of the protocol.
  1. Hyperlane Validators are light offchain agents responsible for security - they observe messages on an origin chain’s Mailbox and if needed sign a merkle root that attests the current state of the mailbox.
  2. Relayers fulfil the message transport requirement of the protocol. They aggregate off-chain security metadata for the IInterchainSecurityModule interface and deliver messages to their recipients.

​
Validators

Validators fulfil the security requirement of the protocol, as part of the Multisig ISM or the Hyperlane AVS, by attesting to the validity of Mailbox messages and making their signatures available to a Relayer. This signature is stored and made publicly available (e.g. in an S3 bucket), which is then used by the offchain Relayer and Interchain Security Modules onchain. Validators are not networked together and do not need to reach consensus; they also do not regularly submit onchain transactions. Validators are configured with a number of block confirmations to wait before attesting to message finality. You can view the latencies here (Note that while this reflects the default ISM configuration, validators can configure their own confirmation thresholds based on their security requirements). If a reorg causes a different set or ordering of dispatched messages, the merkle tree that the validators are indexing will have an inconsistent root from the one already observed. When this happens, validators will halt signing new messages and write a reorg flag to their checkpoint storage (e.g., S3 bucket). Remediation is handled on a case-by-case basis. This is the agent that community operators run to help secure an origin chain, and it’s the most important duty one can perform to help decentralize message passing on Hyperlane. Note that just running a Validator doesn’t mean it’s actively contributing to securing messages: a Multisig ISM on the destination chain must have enrolled the Validator’s checkpoint-signing key, and that ISM must be used by message recipients. These agents are implemented in Rust and distributed as Docker images and binaries.
Learn more about Validators here

​
Relayer

A Hyperlane Relayer delivers interchain messages to their recipients. Relaying is permissionless, and one honest Relayer running between a chain pair is sufficient for ensuring liveness. Running a Relayer is:
  1. much more operationally complex than a Validator.
  2. not required for securing the network.
  3. only recommended for permissionless deployments of Hyperlane.
Hyperlane Relayers are configured to relay messages between one or more origin chains and destination chains. Every Hyperlane message involves two transactions:
  1. To dispatch and send a message on the origin chain.
  2. To process and deliver the message on destination chain.
A Relayer’s job is to deliver the message on the destination chain. To fulfill this responsibility:
  • The Relayer keeps track of new messages as they come in on the origin chain.
  • It checks the Interchain Security Module (ISM) specified by the recipient to gather the necessary metadata to secure the message. For example, it may retrieve Multisig ISM signatures from Validator checkpoint storage.
  • After assembling the security metadata, the Relayer then sends the message to the recipient on the destination chain.
If the message delivery fails (e.g. due to a lack of liquidity to transfer out of a Hyperlane Warp Route contract), the Relayer retries the delivery with an exponential backoff mechanism until successful. A Relayer has no special permissions in Hyperlane. If Relayer keys are compromised, only the tokens held by those keys are at risk.
Learn more about Relayers here.
⌘I