Relaying Sequence

Supported Features
- Compatible with all major EVM chains (Ethereum, Base, Optimism, Arbitrum, Polygon, and more)
- Request-driven design for configurable, on-demand relaying
- Transaction failure retry support
- Re-orgs
- Out-of-gas
- Inadequate gas price
- Tx network propagation fails to reach leader
- Invalid by the network, but valid by the submitting node
- Transaction Tracking API
- Remote signing support
- Concurrent packet intake and processing
- Configurable packet delivery latency via batching
- Ability to blacklist addresses (ex: OFAC)
- Transaction cost tracking
Getting Started
Prerequisites
- Go 1.24+
- Docker and Docker Compose
- A running proof API service
- RPC endpoints for the chains you want to relay between
Local Development
- Start Postgres and run migrations:
- Create a local config file (see Configuration Reference below).
- Create a local keys file (see Local Signing below).
- Run the relayer:
- gRPC API server on the address configured in
relayer_api.address - Prometheus metrics server on the configured address
- Relay dispatcher polling for new transfers
CLI Flags
Database Migrations
Database migrations must be run before starting the relayer. The relayer expects the database schema to already exist. Local Development:Design


API Interface
The relayer serves a gRPC server which clients use to specify what packets to relay and track packet relaying progress.Observability
Configuration Reference
The relayer is configured via a YAML file. Below is the complete configuration schema with all available options.Full Example
Section Reference
postgres
Database credentials are read from environment variables
POSTGRES_USER and POSTGRES_PASSWORD (default: relayer/relayer).
metrics
relayer_api
ibcv2_proof_api
Connection to the proof API service that generates relay transactions.
signing
Signing configuration. The mode is inferred from which fields are set:
- If
grpc_addressis set → remote signing (ignoreskeys_path) - Else if
keys_pathis set → local signing from key file - Else → fatal error at startup
coingecko (optional)
Used for tracking transaction gas costs in USD. If omitted, gas cost tracking is disabled.
chains.<chain_key>
Each entry under chains defines a chain the relayer can interact with.
chains.<chain_key>.cosmos
Required when type: cosmos.
chains.<chain_key>.evm
Required when type: evm.
chains.<chain_key>.ibcv2
IBC v2 relay configuration for this chain.
chains.<chain_key>.signer_gas_alert_thresholds
Signing
The relayer supports two signing modes, configured via thesigning block in the YAML config. The mode is inferred from which fields are populated:
- If
grpc_addressis set → remote signing (ignoreskeys_path) - Else if
keys_pathis set → local signing from key file - Else → fatal error at startup
Local Signing
Setsigning.keys_path to point to a JSON file containing private keys. The format is a map of chain IDs to key objects:
Remote Signing
For production deployments, the relayer can delegate signing to an external gRPC service. This keeps private keys isolated from the relayer process.SERVICE_ACCOUNT_TOKEN environment variable as a bearer token in gRPC metadata for authenticating requests to the signing service.
The remote signer must implement the following gRPC service:
Sign RPC accepts transaction payloads for EVM, Cosmos, and Solana chains and returns the appropriate signature format:
- EVM: Accepts serialized tx bytes + chain ID, returns
(r, s, v)signature components - Cosmos: Accepts sign doc bytes, returns a raw signature
- Solana: Accepts a base64-encoded transaction, returns a raw signature
Upcoming Features
- Solana support
Unsupported Features
- Charging end users fees to relay IBC transactions
- Relaying IBC v1 packets