Flexible and secure interoperability for financial institutions

It’s 2:13 a.m. A treasury team in New York sends a high-value transfer from its Cosmos settlement chain to a partner institution in Asia. The funds arrive promptly, and the confirmation data streams into their ops dashboard thousands of miles away. The compliance team sleeps soundly. They know that full visibility and transparency are ensured and that automations within their transfer system will handle compliance checks.

The Inter-Blockchain Communication Protocol (IBC) is the Cosmos ecosystem’s flagship interoperability standard, and its reach extends well beyond Cosmos-native chains. It now connects to networks including Ethereum, Solana, Optimism, Hyperledger Besu, and more.

For enterprise operators, this breadth of connectivity is table stakes. What matters equally is how securely, reliably, and transparently those connections operate in production. That’s where two new infrastructure components come in: the IBC Relayer and the IBC Attestor. Together, they provide enterprises with the security controls, compliance tooling, and observability required to run cross-ledger infrastructure in regulated production environments.

This post provides a technical overview of what each component does, how they work together, and how the system architecture is structured.

The IBC Attestor: Lightweight, Pluggable Trust

The IBC Attestor is a stateless trust layer behind cross-chain data and asset transfers over IBC. It does not move tokens itself. Rather, it produces cryptographic attestations of transaction status, so other components can relay those transactions with confidence. It supports counterparty trust by providing explicit, verifiable signatures governed by enterprise security rules.

An attestor's job is simple: watch the ledger, verify its state, and provide a signature. Each chain type (EVM, Cosmos, Solana) has its own adapter that knows how to query and understand block state. It is a chain-agnostic service.

Security Properties

Each attestor has a public key that is registered on-chain, and the system is configured to require a signature quorum, such as 3 of 5 attestors, before accepting a cross-chain message. That means no single attestor can approve or forge a transfer on its own; an attacker would need to compromise multiple trusted signers at once.

Attestor instances are chosen and managed by the network operator. Each instance can be deployed on a separate infrastructure, across different cloud providers, or backed by hardware security modules (HSMs) and AWS KMS for key management and rotation.

This separation of concerns allows operators to enforce security policies at the attestor level: different teams can manage different signers, and the quorum requirement ensures that no single point of failure can compromise the trust layer.

Finally, instances are highly configurable. For example, you can combine them with another verification method like zk-state proofs, or modify finality so that attestations are faster than the underlying chain’s finality.

The result is a trust model that is both extensible to new networks and anchored by clear, enforceable security and compliance controls.

The IBC Relayer

While the attestor is about generating trust, the relayer is about executing transactions.

The IBC Relayer is a standalone, request-driven service for the IBC protocol. Internally, the relayer runs as an asynchronous processing pipeline backed by a database: it receives relay requests, records transfer state, queues execution work, and manages delivery across networks from start to finish.

Rather than continuously scanning chains for events, the relayer only processes packets that are explicitly submitted through its API. This request-driven design simplifies access controls such as OFAC address blacklisting without requiring changes to the underlying IBC protocol, and ensures gas is spent only when actual transfers occur.

The relayer also exposes Prometheus metrics covering relay latency, gas costs by chain, retry rates, gas balances, and more. These metrics provide operators with real-time visibility into relay performance, costs, and throughput across networks. Transfers can be batched for efficiency, automatically retried on temporary failures (such as re-organizations or out-of-gas errors), and tracked through a clear status lifecycle so participants can see the state of their transactions.

Security Properties

The relayer supports external key management through a remote signing interface: signing keys can reside in an existing KMS or HSM deployment, accessed via a dedicated signing service. This means private keys remain isolated from the relayer process, and operators can integrate cross-chain relaying into their existing security infrastructure without modifying key custody workflows.

The combination of request-driven execution, externalized signing, and comprehensive metrics means the relayer operates as managed, production-grade infrastructure with the same operational rigor teams expect from core network services.

System Architecture

Returning to the treasury team in New York, they need to issue on-chain assets and transfer them securely to partner institutions and regulated counterparties across connected networks. This requires predictability, resilience, strong security controls, and a complete audit trail.

At a high level, their flow looks like this:

1. A transfer starts on the source network.The transfer is submitted, and a cross-chain message is created.
2. The relayer takes over execution.The transfer is submitted to the relayer, which records it, queues work, and manages delivery.
3. Attestors independently verify what happened.Multiple attestor services observe the same state change and produce signed attestations.
4. Signatures are collected to the required threshold. Attestations are gathered until the policy is satisfied (for example, 3 of 5).
5. The destination network processes the transfer.The relayer submits the destination transaction using that verified attestation data.
6. The full lifecycle is closed and tracked.Status is updated end-to-end, and metrics are emitted to dashboards. The full lifecycle is transparent and persisted in a database, so that compliance has a complete audit trail.

The reverse direction follows the same model. That symmetry is what makes the stack practical in production: one operational pattern, one trust model, and one monitoring surface across multiple network pairs.

Why This Matters for Enterprise

Enterprise blockchain deployments live and die on security, compliance, and observability. The IBC Relayer and Attestor are designed with all three in mind as first-class constraints.

For teams like that New York treasury desk, this is what turns cross-chain into a repeatable business capability. Whether you are connecting Cosmos to Ethereum, Solana, or any other network environment, you get the same guarantees: verifiable trust, controlled execution, and full lifecycle visibility.

The IBC Relayer and IBC Attestor are components that can be licensed through Cosmos Enterprise. For more information, contact institutions@cosmoslabs.io.

Further resources:

Docs: https://docs.cosmos.network/enterprise/components/interoperability/deployment

IBC relayer source code: https://github.com/cosmos/ibc-relayer

IBC attestor source code: https://github.com/cosmos/ibc-attestor