This page covers the mental model and application-design checklist. For the canonical IBC component overview, packet lifecycle, and trust model, see IBC.
Mental model
| Concept | Meaning | Developer implication |
|---|---|---|
| Light client | Verifies another chain’s state from cryptographic proofs and consensus updates. | Cross-chain correctness should reduce to consensus and proof verification, not an operator committee. |
| Packet | A cross-chain message committed on a source chain and verified on a destination chain. | Applications should model the message as asynchronous. |
| Acknowledgement | A response proving the destination chain handled the packet. | Source-chain logic may need an acknowledgement branch. |
| Timeout | A safety path when a packet is not completed before its deadline. | User-facing flows need refund or recovery behavior. |
| Relayer | Off-chain actor that submits packet data and proofs between chains. | Relayer liveness affects completion time, not the underlying verification model. |
Solidity access
c8ntinuum exposes IBC functionality to smart contracts through precompiles:| Precompile | Role |
|---|---|
| ICS02 | Client updates and membership or non-membership verification against a verified counterparty state. |
| ICS20 | Fungible token transfer flows that use IBC packet semantics. |
Application design checklist
- Decide whether the contract only initiates a transfer or also tracks acknowledgement/timeout outcomes.
- Make timeout values explicit and visible to users.
- Treat relayer delay as a normal asynchronous condition.
- Keep source and destination address formats clear in UI and logs.
- Use the IBC breaker and rate-limiter pages to understand operational safety controls.