Skip to main content
A Hyperlane implementation for a new chain architecture is comprised of the following:
  1. Contracts: expose the interface for application developers to send and receive messages with
  2. Agents: operate the protocol by adding security and relaying messages
  3. Applications: applications that use the protocol and demonstrate its capabilities
Before getting started here, it is recommended to review the protocol documentation.
If you would like to dive deeper, check out some of the Hyperlane implementations that are currently available:

1. Contracts

Below describes the onchain contract spec for the Hyperlane protocol. It uses solidity types for familiarity but everything should be generalizable to other languages.
  • address should be interpreted as the local chain’s address type.
  • payable describes a function that allows callers to pass native tokens.
  • Ensure events are properly emitted for all important state changes.
  • Clearly document any deviations from the reference implementation and their rationale.

Considerations

Byte representation:
  • Be aware that different chains may have different native types for representing bytes. For example, StarkNet uses felt252 for contract addresses, which may not fully accommodate 32-byte addresses used in other chains.
  • Implement proper conversion and validation mechanisms when dealing with cross-chain addresses.
Serialization:
  • Pay close attention to how message fields are serialized, especially for variable-length data like the message body.
  • Ensure that the serialization method used (e.g., abi.encodePacked equivalent) behaves consistently across different chain implementations.

Message

The message is the core data structure used by the Hyperlane protocol. It is a packed data structure that contains all the information needed to route a message from one domain to another.

Mailbox

The mailbox is the entrypoint for developers to send and receive messages from. Make sure that localDomain is immutable to prevent unauthorized changes that could compromise cross-chain security. Implementations:
In addition to default and custom hooks, Hyperlane introduces the concept of a Required Hook that is used for post processing of ALL dispatches. Make sure to call the required hook before the default or custom hook.

dispatch

Dispatches a message to the destination domain and recipient.
Dispatches a message to the destination domain and recipient, and provides metadata for the default hook.
Dispatches a message to the destination domain and recipient, and provides metadata for a custom hook to use instead of the default.

process

Attempts to deliver message to its recipient. Verifies message via the recipient’s ISM using the provided metadata.

latestDispatchedId

Returns the latest dispatched message ID used for auth in post-dispatch hooks.

Message Recipient

A contract that wants to receive a message must expose the following handler.
They may optionally specify a security module to verify messages before they are handled.
After implementing these three contracts, you can reach your first milestone to test, mocking a message transfer, by calling a Mailbox’s dispatch function to send a message to a recipient and assert that the recipient received the message. See a Foundry test case here.

Interchain Security Module

Interchain security modules are used to verify messages before they are processed.

moduleType

Returns an enum that represents the type of security model encoded by this ISM.
Relayers infer how to fetch and format metadata from this type.

verify

Defines a security model responsible for verifying interchain messages based on the provided metadata.
Static module management - Our Solidity implementation defines MultisigISMs as static and part of the bytecode which might not be possible in other chains. You may need to implement dynamic modules for the ISM instead.

Validator Announce

Validators announce their signature storage location so that the relayer can fetch and verify their signatures.

announce

Announces a validator signature storage location

getAnnouncedStorageLocations

Returns a list of all announced storage locations

Multisig ISM

Implements a security module that checks if the metadata provided to verify satisfies a quorum of signatures from a set of configured validators.
It is a common error when implementing this ISM to allow a single validator’s signature to be passed multiple times and errantly achieve quorum. Take care to ensure validators cannot be double counted and add a negative test case for this. See solidity test_verify_revertWhen_duplicateSignatures for example.

Metadata

To be used with the MESSAGE_ID_MULTISIG module type implementation in the relayer. The metadata must be formatted as follows:

validatorsAndThreshold

Returns the set of validators responsible for verifying message and the number of signatures required. Can change based on the content of _message
After implementing the MultisigISM, you reach the second milestone to test that your Mailbox only processes after a recipient’s ISM returns true. You can test that with a TestISM that you can statically set to accept or reject any message. See a Foundry test case here.

Interchain Gas Paymaster

The gas paymaster is used to pay for the gas required in message processing on the destination chain. This is not strictly required if the relayer is willing to subsidize message processing.
Implement robust checks for sufficient gas payment, considering chain-specific token handling. Our solidity implementation charges native message value but for other chains, you may need to charge a specific token and scale the gas overhead and tokenExchangeRate accordingly.

payForGas

Deposits msg.value as a payment for the relaying of a message to its destination chain.
Although you can specify a refundAddress, overpayment may not be refunded to the message sender if you are composing hooks together.

GasPayment

Emitted when a payment is made for a message’s gas costs.

DestinationGasConfigSet

Emitted when the gas oracle for a remote domain is set.

2. Agents

Below describes the agent spec for a new chain implementation. The rust implementations hope to support all chains, but the spec is intended to be chain agnostic.

Message Indexing

All agents must index messages from the origin mailbox. In the solidity mailbox, we emit an event for each message dispatched. Other chains may have different ways of surfacing this information, but the agent must be able to get message content reliably and with consistent ordering — see the message indexer trait.

Validator

In addition to indexing messages dispatched from the mailbox, validators produce attestations for the messages they observe to be used on the destination chain for security.

Checkpoint

Validators produce attestations called checkpoints from the Mailbox which commit via merkle root to all dispatched message IDs.
Validators use the latest checkpoint method on the mailbox trait to get the latest checkpoint from the mailbox and submit signatures to some highly available storage using the checkpoint syncer trait.

Checkpoint with Message ID

Validators use indexed messages to join the checkpoint with the corresponding message ID emitted from the mailbox.
They also publish these augmented checkpoints on their syncer.
You can test your validator by configuring it with a chain with the above contracts and observe that it creates valid signatures.

Relayer

In addition to indexing messages dispatched from the mailbox, a relayer processes messages on the destination chain. This requires building metadata that satisfies the message recipient’s ISM verification requirements, and signing transactions that process the message on the destination mailbox.

Metadata Builders

Each module type implies a different metadata format for message verification to succeed. A Relayer will need each module trait (eg multisig) to be implemented.

Message Processor

The relayer will attempt to process messages on the destination mailbox (see message processor). If
  • the message recipient ISM returns an unknown module type
  • module type is known but metadata fails to verify
  • metadata verifies but dry running (gas estimation) message processing fails
then the message will be kicked to an exponential backoff retry queue. The relayer relies on implementations of the mailbox and ism traits for these checks.

Gas Payment Enforcement

The Relayer may also require gas payment for a specific message ID on the origin chain before processing the message on the destination chain. To do this, they must have an IGP deployed with their address set as beneficiary and index gas payment events. See gas payment enforcement trait. We recommend to start with no gas payment enforcement policy and then gradually support more restrictive ones.

Testing

Once you have implemented an MVP of the relayer, you should create an end-to-end test that:
  1. Spins up local origin and destination chains.
  2. Deploys your contracts onto both chains.
  3. Run validators for the origin chain.
  4. Run a relayer between both chains.
  5. Observe that upon dispatch of a message of the origin chain, the validator observes the message, creates a signature and the relayer appropriately processes your message via the ISM that specifies the validator on the destination chain.
See this end-to-end test on the Rust codebase for inspiration.
After validating the agents with local end-to-end tests, it is recommended that you also run end-to-end tests with real testnets.

3. Applications

Hyperlane Warp Routes

Token router application that routes tokens between domains on demand.

transferRemote

Transfers amountOrId token to recipient on destination domain.

Transfer Message

To be interoperable with Hyperlane Warp Routes on other chains, the body of a transfer message must be a byte packed TransferMessage struct.