Skip to main content
The IBC CLI exposes a relayer API and an attestation API, plus a shared health service. The relayer’s API has two main parts:
  • Relay takes the transaction that sent the packets.
  • Packets reports how far each of them got.
The attestor’s API serves the attestations a light client verifies. A relayer is its usual caller, gathering proofs for a packet it is delivering. An operator calls it directly to check which attestor is answering and how far behind the head it will sign. Both services listen on server.listenAddr, defaulting to 0.0.0.0:3000. The ProverService described at the end of this page is one you implement and the relayer calls, to support a light client the CLI has no built-in prover for. The CLI does not serve it. To list running services:
A process lists only the services it is running. The attestation service joins this list when the config gives it a local attestor to serve; the relayer above had none.

Health checks

Both relayers and standalone attestors expose the standard grpc.health.v1.Health service on their API address. Check is supported; Watch returns UNIMPLEMENTED. With reflection enabled, check readiness using:
The request’s service field selects the check:

Relayer service

ibc.v2.relayer.RelayerApiService. ibc relayer relay and ibc relayer packets call these two.

Relay

Relay tracks the packets emitted by a source transaction and submits the transactions required to complete them.

RelayRequest

Field names in these tables are the schema’s. The JSON encoding uses lowerCamelCase, so tx_hash is sent as txHash. all_packets takes every packet for which this relayer has a configured client and route. Packets without one are skipped, and the request succeeds even when that leaves nothing to relay.

SelectedPackets

PacketSelector

A selected_packets request fails if any packet it names is absent or has no configured route. Naming a packet that is already selected, in flight, or finished succeeds and changes nothing. Relay answers with every send packet in the transaction, including the ones it will not carry.

RelayResponse

ObservedPacket

PacketSelection

A successful call means the relayer recorded the request. Packets reports what happens after that.

Packets

Packets lists the packets this relayer is aware of, most recent first.

PacketsRequest

PacketFilter

Every field is optional, and a request with none returns everything the relayer has recorded.

PacketsResponse

Results are paged. Ask again with next_cursor while has_more is set.

PacketStatus

TransactionInfo

PacketState

NOT_SELECTED and PENDING are still open. The other four are final. REJECTED means the packet arrived and the application refused it, which is a completed relay and a failed application call. RELAY_FAILED means a permanent error stopped the relayer, wherever the packet had got to.

Attestation service

ibc.v2.attestor.AttestationService. One process can run several attestors, so every request names one.

Attestation

Both attestation calls return this shape. attested_data is what was signed. A light client accepts the attestation when its threshold of attestors or more sign the same data.

StateAttestation

Retrieves an attestation for a state at a given height.

StateAttestationRequest

StateAttestationResponse

A height above what LatestHeight reports is refused, so ask for the height first.

PacketAttestation

Retrieves an attestation for a set of packets.

PacketAttestationRequest

CommitmentType

commitment_type selects what is being proven, which differs by direction. A delivery proves a packet commitment, an acknowledgement proves an acknowledgement commitment, and a timeout proves that no receipt exists.

PacketAttestationResponse

One request carries at most 100 packets, each at most 128 KB, and a request over either limit is refused.

LatestHeight

Returns the latest height the attestor will generate attestations for.

LatestHeightRequest

LatestHeightResponse

Offset zero attests up to the chain’s finalized tag. Above zero, the attestor reads latest and subtracts finalityOffset.

Info

Returns identity information about a configured attestor.

InfoRequest

InfoResponse

address is what a light client checks signatures against. So this call is how an operator confirms that the running attestor is the one an on-chain client expects.

Prover service

ibc.v2.prover.ProverService. A relayer runs one prover per light client it submits to. Pointing a client end at this service replaces the built-in prover with a remote one, so a light client the CLI does not implement can be supported by serving these three calls. Every request names the client it is scoped to, so one service can serve many clients across many chains.

Client

Every request carries one, identifying the light client the call is scoped to.

LatestProvableHeight

LatestProvableHeight returns the highest height a subsequent ClientUpdatePayloads and PacketProofs call sharing that height can currently succeed at, with that height’s counterparty-chain timestamp. The relayer calls this first and proves at the height it returns, so a prover paces the relayer by holding the height back until it can prove at it.

ClientUpdatePayloads

ClientUpdatePayloads returns the encoded light-client updates that bring the client to a height. Each payload is opaque to the relayer, which passes it unchanged as updateMsg in one router updateClient call, in order, ahead of the packets in the same transaction. A prover whose client cannot reach a height in one update returns several.

PacketProofs

PacketProofs proves each packet’s membership or non-membership at a height, one proof per packet with indices aligned to the request. proofs is one proof per requested packet, in request order, so a response of a different length than the request is an error. The relayer submits all proofs of one response in a single transaction, in that order; a prover may therefore put material the whole batch shares (such as an account proof) only in the first proof.

Packet

The packet a proof is requested for.

Acknowledgement

The acknowledgement supplied for a packet when requesting an acknowledgement proof.

Next steps

  • Configuration for server.listenAddr and the attestors block these calls read.
  • CLI commands for the commands that make these calls.