---
# System prepended metadata

title: ICP IBC integration

---

# Internet Computer Protocol (ICP) IBC interation


The Internet Computer is a sharded blockchain platform that can scale out by provising additional subnet blockchains. Smart contracts on one subnet can seamlessly interact with smart contracts on other subnets by X-Net messaging authenticated with threshold BLS signatures. Smart contracts are WASM modules with associated memory pages (which can store up to 404GB of data), and can interact with other smart contracts by sending asynchronous messages following the actor model. We have SDKs for Rust, TypeScript, Python and Motoko, a language purposefully designed for ICP. Furthermore developers have built smart contracts in C, C++ and Haskell.

Certain subnets are enabled with additional threshold crypto protocols. Currently, smart contracts can request ECDSA (over the Bitcoin curve secp256k10) signatures.

This allows ICP smart contracts to securely sign transactions for other chains. Further threshold crypto protocols are currently in preparation (Schnorr and EdDSA signing, as well as [vetKeys](https://medium.com/dfinity/unleashing-the-power-of-vetkeys-first-public-demo-and-developer-bounties-3ade3a096b29)).

This capability allows to send authenticated messages securly from ICP to e.g. Cosmos chains, and would be a much more efficient path than verifying BLS signatures in a Cosmos chain.

However, this does not yet help to read state from other chains.

For Bitcoin, there is a dedicated ICP subnet that runs a Bitcoin Adapter process next to the ICP replica process. The Bitcoin Adapter implements part of the Bitcoin protocol, connects to the Bitcoin P2P network, and provides block data to a Bitcoin smart contract. The Bitcoin smart contract acts as a (SPV) light client for Bitcoin, checks proof of work and computes the current Bitcoin UTXO set, and provides an API to all other smart contracts. More information about the Bitcoin integration can be found [here](https://wiki.internetcomputer.org/wiki/Bitcoin_Integration)

For Ethereum, we plan to eventually have a dedicated subnet where ICP nodes run an Ethereum node in a parallel process. For now, however, smart contracts can use the [EVM RPC smart contract](https://github.com/internet-computer-protocol/ic-eth-rpc) to fetch data from Ethereum and other EVM compatible chains. The EVM RPC smart contract fetches data from multiple cloud RPC providers and only accepts data if a quorum RPC providers returns the same result. The EVM RPC smart contract uses a feature called [HTTPS outcalls](https://wiki.internetcomputer.org/wiki/HTTPS_outcalls), which allows smart contracts to call APIs under the hood. On a side note, we've done the experiment to port the [Helios Rust-based Ethereum Light Client to ICP](https://github.com/eigerco/ethereum-canister).


The Bitcoin and Ethereum Integration are the basis of [ckBTC](https://defillama.com/protocol/ckbtc?denomination=BTC) and [ckETH](https://defillama.com/protocol/cketh?denomination=ETH). Those tokens are fully-backed by BTC and ETH, and are controlled by smart contracts and threshold signatures, and thus have lower trust assumptions in comparison to typical bridged or wrapped assets.

For reading state from Cosmos chains, we could either imagine a similar model than the EVM RPC smart contract or - better - the IBC model with a smart contract that verifies consensus of the respective Cosmos chain. Because of HTTPS outcalls, we can also get rid of relayers and fetch the data directly from RPC endpoints.


Hence, I'd be interested in exploring a communication model where IBC messages are authenticated via ECDSA signatures from ICP to a Cosmos chain, and via the normal IBC consensus verification method from a Cosmos chain to ICP.

