Guide

Required setup instructions

Configuration

The relayer is responsible for watching for new messages on the origin chain(s) and delivering them to their destination chains. This involves being able to submit transactions to many destination chains, and therefore requires access to a key for signing transactions. There are two supported key types: hexadecimal private keys (for in-memory signing), and AWS KMS based keys (best practice for production environments).

Hexadecimal keys

A hexadecimal private key used for in-memory signing can be used by your relayer to sign transactions. This is the recommended setup for testing or development purposes.

pageHexadecimal keys

AWS KMS keys

An AWS KMS key can be used by your relayer to sign transactions. This is the recommended setup for production relayers.

pageAWS KMS keys

Reference

Also take a look at the Agent configuration page and the Configuration reference for a full list of configuration possibilities. The list below is not complete, however it should be enough to get started.

Your relayer takes as configuration the following:

ArgumentDescription

--relayChains

Comma separated names of the origin and destination chains to relay messages between. Example: ethereum,polygon,avalanche (See also the Configuration reference for how to specify origin and destination chains independently)

--chains.[chain_name].connection.url

An RPC url for chain_name. Example: --chains.ethereum.connection.url='http://localhost:8545' Relayers must set multiple connection URLs, one for each chain it interacts with.

--whitelist

An optional whitelist. The relayer will only relay messages that match this whitelist. See Message filteringfor more info.

--blacklist

An optional blacklist. The relayer will not relay messages that match this blacklist. See Message filteringfor more info.

--db

The path to where the validator should write persistent data to disk. Ensure this path to be persistent when using cloud setups. When using Docker, make sure to mount the persistent path/volume into the container. See Configuration referencefor more info

--allowLocalCheckpointSyncers

Environment variableDescription

CONFIG_FILES

Setup-specific configuration

These configurations requirements differ depending on which Guide instructions you followed.

If you created Hexadecimal keys, use these configs.

ArgumentDescription

--defaultSigner.key

A hexadecimal private key used to sign transactions for all chains. Example: --defaultSigner.key=123...def

For chain-specific signers take a look at the Configuration reference

Installation

The recommended installation method for a production environment is using a Docker image.

Docker image

To download the docker image, run:

docker pull gcr.io/abacus-labs-dev/hyperlane-agent:8127fa5-20230823-161309

Start Relaying

Running the binary

Refer to the Installation instructions to access the relayer binary.

Configuration can be placed in a relayer.env file, for example:

relayer.env
# These are example values to roughly illustrate
# what a .env file should look like

HYP_BASE_RELAYCHAINS=ethereum,polygon,avalanche
HYP_BASE_DB="/hyperlane_db"
# ...
# ...

To run the relayer binary with the environment variables specified in relayer.env:

Find the latest Docker image and set it to the environment variable $DOCKER_IMAGE.

Using the --env-file flag, we can pass in the environment variables to the relayer:

docker run \
  -it \
  --env-file relayer.env \
  --mount type=bind,source="$(pwd)"/hyperlane_db,target=/hyperlane_db \
  $DOCKER_IMAGE \
  ./relayer

For example, if your local validator is writing signatures to /tmp/hyperlane-validator-signatures-ethereum, you should mount a directory for the Docker container:

docker run \
  -it \
  --env-file relayer.env \
  --mount type=bind,source="$(pwd)"/hyperlane-validator-signatures-ethereum,target=/tmp/hyperlane-validator-signatures-ethereum,readonly \
  --mount type=bind,source="$(pwd)"/hyperlane_db,target=/hyperlane_db \
  $DOCKER_IMAGE \
  ./relayer

Relayers needs to index all historic messages for the origin chain(s). This information is stored in a local database on disk (set with db in the config). This means running a relayer for the first time may take some extra time to catch up with the current state.

Last updated