Skip to main content
IBC v2 Relayer is a standalone, production-ready, request-driven relayer service for the IBC v2 Protocol. The relayer supports interoperating between a Cosmos-based chain and major EVM networks (Ethereum, Base, Optimism, Arbitrum, Polygon, and more). The core relayer service has been used in production since 2023 via Skip Go, and is now modularized to be run on-prem by clients who cannot leverage the Skip Go managed service.

Relaying Sequence

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

  1. Start Postgres and run migrations:
  1. Create a local config file (see Configuration Reference below).
  2. Create a local keys file (see Local Signing below).
  3. Run the relayer:
The relayer will start:
  • 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:
This starts PostgreSQL and runs migrations automatically. Using the migrate CLI:
Using the relayer migrations container:

Design

Design The relayer has three main components — the gRPC server which clients use to interact with the relayer, a Postgres database, and the core relayer. The gRPC server populates the database with packets, which the core relayer monitors and updates as it progresses in relaying those packets. Relaying Pipeline The relayer is designed as a pipeline composed of a set of asynchronously running processors. Transfers pass through the processors sequentially. Some pipeline steps process transfers individually while others process transfers in batches.

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_address is set → remote signing (ignores keys_path)
  • Else if keys_path is 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 the signing block in the YAML config. The mode is inferred from which fields are populated:
  • If grpc_address is set → remote signing (ignores keys_path)
  • Else if keys_path is set → local signing from key file
  • Else → fatal error at startup

Local Signing

Set signing.keys_path to point to a JSON file containing private keys. The format is a map of chain IDs to key objects:
For EVM chains, the private key is a hex-encoded ECDSA private key. For Cosmos chains, it is a hex-encoded secp256k1 private key.

Remote Signing

For production deployments, the relayer can delegate signing to an external gRPC service. This keeps private keys isolated from the relayer process.
The remote signer connection uses the 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:
The 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