Skip to main content

Bridge Relayers

The Specter infrastructure operates two Hyperlane-based bridge relayer services that enable cross-chain messaging between Specter and external EVM chains. The hyperlane-bridge-relayer handles bidirectional messaging between Base and Specter, while the hyperlane-multi-chain-relayer extends this to Ethereum, Base, and Arbitrum simultaneously.

Hyperlane Overview

Hyperlane is a permissionless interchain messaging protocol. It provides a standardized interface for sending and receiving messages across chains through a pair of core contracts:

  • Mailbox: The entry and exit point for cross-chain messages. Sending chains call dispatch() to send messages; receiving chains call process() to deliver them.
  • ISM (Interchain Security Module): Defines the security model for validating inbound messages. Specter uses a Multisig ISM where a configurable set of validators must sign off on a message before it can be processed.

The bridge relayers watch for outbound messages on source chains and deliver them to destination chains, paying gas on both sides.

Hyperlane Bridge Relayer

The hyperlane-bridge-relayer handles bidirectional messaging between Base and Specter.

Message Flow: Base to Specter

Base Chain                          Relayer                         Specter Chain
│ │ │
│ User calls Mailbox.dispatch() │ │
│ on Base │ │
│──── Dispatch event ─────────────▶│ │
│ │ Validates message + ISM │
│ │── Mailbox.process() ──────────▶│
│ │ │
│ │ Recipient contract receives │
│ │ handle() callback │

Message Flow: Specter to Base

Specter Chain                       Relayer                         Base Chain
│ │ │
│ Contract calls Mailbox │ │
│ .dispatch() on Specter │ │
│──── Dispatch event ─────────────▶│ │
│ │ Validates message + ISM │
│ │── Mailbox.process() ──────────▶│
│ │ │
│ │ Recipient contract receives │
│ │ handle() callback │

Watched Contracts

ChainContractEvent
BaseHyperlane MailboxDispatch(sender, destination, recipient, message)
SpecterHyperlane MailboxDispatch(sender, destination, recipient, message)

Use Cases

  • Token bridging: Users bridge ERC20 tokens from Base to Specter, where they are minted as GhostERC20 tokens.
  • Governance messages: Cross-chain governance proposals or votes relayed between chains.
  • State synchronization: Contract state updates propagated from one chain to another.

Hyperlane Multi-Chain Relayer

The hyperlane-multi-chain-relayer extends cross-chain messaging to multiple chains simultaneously: Ethereum, Base, and Arbitrum.

Architecture

┌──────────┐     ┌──────────┐     ┌──────────┐
│ Ethereum │ │ Base │ │ Arbitrum │
│ Mailbox │ │ Mailbox │ │ Mailbox │
└─────┬────┘ └─────┬────┘ └─────┬────┘
│ │ │
│ Dispatch │ Dispatch │ Dispatch
│ events │ events │ events
│ │ │
└────────────────┼────────────────┘


┌────────────────────────┐
│ Multi-Chain Relayer │
│ │
│ Watches all chains │
│ Routes messages to │
│ correct destinations │
└───────────┬────────────┘


┌──────────────┐
│ Specter │
│ Mailbox │
└──────────────┘

The multi-chain relayer maintains RPC connections to all four chains and multiplexes event watching across them. When a Dispatch event is detected on any source chain with Specter as the destination, the relayer:

  1. Fetches the full message payload from the source chain.
  2. Retrieves the ISM metadata required for validation (validator signatures).
  3. Calls Mailbox.process() on Specter with the message and metadata.

For outbound messages from Specter, the relayer determines the destination chain from the message's destination domain ID and delivers accordingly.

Chain Configuration

ChainDomain IDRPC
Ethereum1Ethereum mainnet/testnet RPC
Base8453Base RPC
Arbitrum42161Arbitrum One RPC
Specter5446Specter RPC

Interchain Security Module (ISM)

The ISM deployed on Specter defines how inbound messages are validated. Specter uses a Multisig ISM that requires a threshold of validator signatures before a message can be processed:

  • Validators are off-chain signers that attest to the validity of messages on source chains. They watch the source chain's Mailbox for Dispatch events and produce signatures over the message content and metadata.
  • Threshold is the minimum number of valid signatures required. For example, a 2-of-3 multisig requires at least 2 out of 3 validators to sign.

The relayer collects validator signatures as part of the message delivery process and includes them in the process() call.

Gas Management

Bridge relayers pay gas on both the source chain (for event monitoring) and the destination chain (for process() calls). Each relayer maintains funded operator wallets on all chains it interacts with:

RelayerFunded Wallets
hyperlane-bridge-relayerBase, Specter
hyperlane-multi-chain-relayerEthereum, Base, Arbitrum, Specter

Gas costs are monitored and logged. The relayers implement gas price estimation and retry logic with escalating gas prices for stuck transactions.

Error Handling

  • RPC failures: The relayers implement automatic RPC failover. If the primary RPC for a chain becomes unresponsive, the relayer switches to a backup RPC endpoint.
  • Message delivery failure: If process() reverts on the destination chain, the relayer retries with increased gas. After a configurable number of retries, the message is logged as failed for manual investigation.
  • Reorgs: The relayers wait for a configurable number of block confirmations before processing Dispatch events, reducing the risk of delivering messages from reorged blocks.

Configuration

ParameterDescription
SPECTER_RPC_URLSpecter chain RPC
BASE_RPC_URLBase chain RPC
ETHEREUM_RPC_URLEthereum RPC (multi-chain only)
ARBITRUM_RPC_URLArbitrum RPC (multi-chain only)
OPERATOR_PRIVATE_KEYRelayer operator private key (funded on all relevant chains)
SPECTER_MAILBOX_ADDRESSHyperlane Mailbox contract on Specter
BASE_MAILBOX_ADDRESSHyperlane Mailbox contract on Base
CONFIRMATIONSBlock confirmations to wait before processing events