Skip to content
CCPEDIAby Unity Nodes
SIGs

Canton IBC: native IBC v2 between Canton and Cosmos chains

1 posts12 viewsLast activity 2d ago

CIPs mentionedCIP-0056
  1. saadaltafofficialOP

    Summary
    I’m looking for a Tech & Ops Committee champion for a Development Fund proposal that makes Canton a native IBC v2 counterparty. Any Cosmos chain on a recent ibc-go could then send assets to Canton through its existing ICS-20 transfer module, with no custom bridge per chain. Received assets would land as CIP-0056 holdings, so they work in existing Canton wallets and apps.

    Problem
    There is no path today between native Canton assets and the Cosmos ecosystem. The Cosmos team has opened cosmos/ibc#1525 (“Canton support”) and notes that full IBC “would also require a Daml implementation.” Their Zenith PoC covers EVM chains built on Canton, not native Daml assets. None of the bridge proposals in canton-dev-fund cover Cosmos or IBC.

    Approach

    • IBC v2 core and ICS-20 written in Daml, with packets, receipts, acks and timeouts as contracts.
    • Canton → Cosmos: Cosmos chains verify Canton packets with ibc-go’s existing attestations light client. Attestors sign Merkle roots over the gateway’s packet commitments, building on the commitment primitive in o1Labs’ proposal (#577) rather than a new scheme.
    • Cosmos → Canton: attestor secp256k1 signatures verified inside Daml using DA.Crypto.Text.
    • The gateway runs as a decentralized party with a confirmation threshold, so no single operator can move funds.

    Scope of the first proposal (single objective)
    One working IBC v2 connection between Canton DevNet/TestNet and one Cosmos testnet: transfer in, transfer out, timeout refund, with an open-source relayer path and docs. Native CometBFT verification (which needs ed25519 in Daml) and quorum signing for the commitment roots would be separate follow-on proposals.

    Draft milestones

    1. Daml IBC v2 core + ICS-20 → CIP-0056, tested on LocalNet.
    2. Relayer support and first round-trip transfer with a Cosmos testnet.
    3. Gateway as a decentralized party, rate limits, TestNet deployment and docs.
    4. Security review and remediation.

    About me
    Saad Altaf, BeencoLabs. I run Cosmos SDK chain infrastructure day to day (validators, relayers, indexers) across servers fleet.

    Ask
    Looking for a champion from the Tech & Ops Committee, and feedback from the Canton Protocol & Multi-Synchronizer and Decentralized Attestor Pools SIGs on the gateway design.