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 callprocess()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
| Chain | Contract | Event |
|---|---|---|
| Base | Hyperlane Mailbox | Dispatch(sender, destination, recipient, message) |
| Specter | Hyperlane Mailbox | Dispatch(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:
- Fetches the full message payload from the source chain.
- Retrieves the ISM metadata required for validation (validator signatures).
- 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
| Chain | Domain ID | RPC |
|---|---|---|
| Ethereum | 1 | Ethereum mainnet/testnet RPC |
| Base | 8453 | Base RPC |
| Arbitrum | 42161 | Arbitrum One RPC |
| Specter | 5446 | Specter 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
Dispatchevents 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:
| Relayer | Funded Wallets |
|---|---|
| hyperlane-bridge-relayer | Base, Specter |
| hyperlane-multi-chain-relayer | Ethereum, 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
Dispatchevents, reducing the risk of delivering messages from reorged blocks.
Configuration
| Parameter | Description |
|---|---|
SPECTER_RPC_URL | Specter chain RPC |
BASE_RPC_URL | Base chain RPC |
ETHEREUM_RPC_URL | Ethereum RPC (multi-chain only) |
ARBITRUM_RPC_URL | Arbitrum RPC (multi-chain only) |
OPERATOR_PRIVATE_KEY | Relayer operator private key (funded on all relevant chains) |
SPECTER_MAILBOX_ADDRESS | Hyperlane Mailbox contract on Specter |
BASE_MAILBOX_ADDRESS | Hyperlane Mailbox contract on Base |
CONFIRMATIONS | Block confirmations to wait before processing events |