Relayer

Documentation Index

Fetch the complete documentation index at: https://docs.cosmos.network/llms.txt

Use this file to discover all available pages before exploring further.

The IBC v2 Relayer is an enterprise-ready IBC v2 relaying service for universal relaying across Cosmos, EVM, and Solana environments. It is built for high-performance, policy-aware cross-chain operations, including Cosmos-to-Cosmos, Cosmos-to-EVM, EVM-to-EVM, Solana-to-Cosmos, and Solana-to-EVM connectivity. The relayer uses a request-driven model. Clients submit a source transaction hash through the relayer API, and the relayer handles packet delivery across the relay lifecycle. The relayer is designed for organizations that require:

1. High-performance relay control, with request-driven APIs and configurable batching, concurrency, and finality settings.
2. Production-ready signing, with support for local keys or an external gRPC signer.
3. Operational safety controls, including built-in OFAC sender checks for EVM relay requests.
4. Production observability, including Prometheus metrics, /health, transaction tracking, and optional gas cost tracking.
5. Full lifecycle support for recv, ack, and timeout flows, with retry handling across the relay pipeline.

​

Expanded connectivity and features

The Enterprise relayer offering emphasizes three advantages for cross-chain operations:

1. Universal coverage, with support positioned around new network connectivity including Solana, Hyperledger Besu, Ethereum, Base, Arbitrum, and other EVM networks.
2. Full lifecycle support, covering cross-chain workflows including packet relaying, proof and attestation construction, fee management, and real-time tracking.
3. Policy-based packet selection, enabling compliance-oriented packet filtering and prioritization at the relay layer.

​

Key capabilities

• Multi-chain EVM support, compatible with Ethereum, Base, Optimism, Arbitrum, Polygon, and other EVM-compatible networks.
• Request-driven relaying, packets are relayed on demand when a client submits a transaction hash through the relayer API.
• Automatic retry, recv, ack, and timeout transactions include retry handling across the relay pipeline.
• Transaction Tracking API, clients can poll the Status API with a transaction hash to follow packet progress through the relay lifecycle.
• Remote signing, the relayer can delegate transaction signing to an external gRPC signer service so private keys are kept outside the relayer process.
• Batching, recv, ack, and timeout packets can be accumulated and submitted in batches with configurable size, timeout, and concurrency settings.
• Address blacklisting, EVM relay requests can be rejected when the transaction sender is on the built-in OFAC blacklist.
• Gas cost tracking, transaction costs can be tracked per chain and exposed through Prometheus metrics.

​

The best available option for universal IBC relaying

​

Architecture

The relayer runs as a standalone service with three main components: a gRPC API server, a Postgres database, and a relay dispatcher. When a client submits a relay request, the relayer verifies the source transaction, extracts packet data, stores transfer state in Postgres, requests relay transaction data from the Proof API, and then submits the necessary recv, ack, or timeout transactions through its processing pipeline. For a full end-to-end architecture view, see the Deployment Overview. For proof construction and attestation details, see the Proof API and Attestor documentation.

​

Source Code

The source code is available in the cosmos/ibc-relayer repository.

​

Available Documentation

• IBC v2 Relayer Overview
• IBC v2 Relayer Guide
• Proof API
• Cosmos ↔ EVM Interoperability Tutorial
• Deployment Overview
• Attestor

​

Availability

The IBC v2 Relayer repository is published under a Source Available Evaluation License. Production or commercial use requires an Enterprise License from Cosmos Labs. See the license file for details. Please contact Cosmos Labs for enterprise licensing.