IBC

Overview

c8ntinuum uses IBC (Inter-Blockchain Communication) for trust-minimized cross-chain messaging. Unlike bridge protocols that rely on trusted intermediaries, IBC uses light-client verification — safety reduces to the security assumptions of the underlying chains’ consensus. c8ntinuum implements IBC v2 (Eureka) and exposes IBC functionality directly to Solidity via the ICS02 and ICS20 precompiles.

IBC v2/Eureka support is a network and release-level capability. Before building production cross-chain logic, confirm the target channel, client type, and enabled precompile behavior against the target c8ntinuum release and the Precompile ABI Reference.

Key Components

Light Client (ICS-02)

Verifies the state of a counterparty chain using cryptographic proofs. Each client maintains a ClientState (parameters) and evolving ConsensusState snapshots. c8ntinuum registers the Tendermint light client (07-tendermint); the allowed client types are 07-tendermint and 09-localhost.Access from Solidity via the ics02 precompile.

Token Transfers (ICS-20)

Standardized cross-chain token transfer protocol. Supports composable cross-chain payments and asset movement without application-specific bridging logic.Access from Solidity via the ics20 precompile.

Packet Lifecycle

SendPacket — Application data committed on source chain
RecvPacket — Destination verifies proof, executes OnRecvPacket
Acknowledgement — Source verifies ack, finalizes or reverts
Timeout — If deadline passes, source triggers rollback

IBC from Solidity

c8ntinuum’s precompiles enable smart contracts to participate directly in IBC flows:

// Pseudocode: import ICS20I and construct Height timeoutHeight per the ABI reference.
ICS20I(0x0000000000000000000000000000000000000802).transfer(
    "transfer",
    sourceChannel,
    denom,
    amount,
    address(this),    // sender: must be the direct caller of the precompile (this contract holds the tokens)
    receiver,
    timeoutHeight,
    timeoutTimestamp, // channel-N (IBC v1): Unix nanoseconds; IBC v2 client ID: Unix seconds (see below)
    memo
);

The timeoutTimestamp rules depend on what you pass as sourceChannel. For a channel ID (channel-N, IBC v1), it is an absolute Unix time in nanoseconds, and 0 disables the timestamp timeout only when timeoutHeight is set, because both cannot be zero. For an IBC v2 client ID, it is an absolute Unix time in seconds that must be non-zero and no more than 24 hours after the current block time; set timeoutHeight to zero. The sender argument must equal the immediate caller of the precompile: an EOA calling it directly, or the calling contract itself. Otherwise the call reverts with msg.sender address ... does not match the requester address .... Use Precompile ABI Reference for the exact Height struct, return value, events, and revert behavior.

Trust Model

c8ntinuum’s IBC design avoids adding a privileged correctness third party. The trust model is:

Source chain consensus — validators agree on the packet
Light client verification — destination chain verifies source state

This eliminates the single point of failure that bridge operator committees represent.

Learn

Core Concepts

Chain Architecture

Execution and EVM

Interoperability and IBC

Modules & Precompiles

Transaction Lifecycle

Overview

Key Components

IBC from Solidity

Trust Model

​Overview

​Key Components

​IBC from Solidity

​Trust Model

Overview

Key Components

IBC from Solidity

Trust Model