Cosmos経済圏とCardanoをつなぐ相互運用レイヤー

基準日：2026-08-13 JST

0. 結論

Injective × Cardano IBCの重要性は、単に「ADAを別チェーンへ送れるようになる」ことではない。

本質は、

Ouroboros PoSとeUTxOという、Cosmos系とは異なる設計を持つCardanoが、IBCという標準化されたチェーン間通信プロトコルへ参加するための実装を、public testnet同士のE2E試験まで進めたこと

にある。

現在、Cardano Foundationの cardano-ibc-incubator では、Cardano Preprod ↔ Injective Testnet のrouteを作り、IBC client、connection、transfer channel、relayerを組み合わせて双方向token transferを試せる段階まで進んでいる。

ただし、これはまだpre-productionである。特にCardano側の確率的finalityをIBCでどう扱うか、Cardano専用light clientの更新を長期間安全に維持できるか、observerへのtrust assumptionをどこまで減らせるか、といった課題が残る。

したがって現時点の評価は次の通りである。

1. まずCosmosとは何か

1-1. Cosmosは「1本の巨大チェーン」ではない

ここを最初に押さえる必要がある。

EthereumやCardanoは、一つのL1を中心に多数のアプリケーションが動くイメージが強い。一方、Cosmosの思想は、

用途ごとに独立したブロックチェーンを作り、それらを相互接続する

というものに近い。

Cosmos Stackは主に以下の構成要素から成る。

Cosmos SDKでは、bank、staking、governanceなどの標準moduleを組み合わせ、さらに独自moduleを追加してapplication-specific blockchain（用途特化型チェーン）を構築できる。

つまりCosmosは、

               IBC
                │
       ┌────────┼────────┐
       │        │        │
   Cosmos Hub  Osmosis  Injective
       │        │        │
       └────────┼────────┘
                │
           その他のchain

という独立したL1群を相互接続する発想で理解すると分かりやすい。

Cardanoとの違い

Cardano
  └─ 1つのL1上に多数のDApp

Cosmos
  └─ 独立した多数のL1をIBCで接続

もちろん実際には両者ともより複雑だが、設計思想の入口としてはこの違いが重要である。

2. Injectiveとは何か

2-1. Cosmos系の金融特化Layer 1

Injectiveは、Cosmos SDKを基盤にした金融用途特化型の独立L1 blockchainである。

Injective公式Docsでは、Cosmos SDKを拡張し、金融用途のためのnative moduleを組み込んでいる。代表例は次の通り。

Injectiveは「一般用途chainにDEXを載せる」のではなく、金融market infrastructure自体をL1のnative機能として持つ点が特徴である。

公式Docsは2026年4月時点で、Injectiveを高性能・相互運用可能な金融向けL1と位置づけ、110+ IBC networksとのinteroperabilityを掲げている。

ここで重要なのは、

Injectiveが110+ IBC networksと接続可能であることと、Cardanoが今回の接続だけで110+ chainすべてへ自動的に直結することは同義ではない

という点である。

Cardano側には各route・light client・channel・asset integrationなどの整備が必要になる。

3. IBCとは何か

IBCは Inter-Blockchain Communication Protocol の略である。

単なるtoken bridgeではなく、

独立したblockchain同士が、相手chainの状態を検証しながらdataを交換するための共通通信規格

と理解した方が正確である。

3-1. 一般的なBridgeとの違い

典型的なmultisig bridgeでは、

Chain A
  │
  │ asset lock
  ▼
Bridge contract
  │
  │ validator / signerが確認
  ▼
Chain B
  │
wrapped asset

のように、bridge operatorやsigner setへの信頼が重要になる。

IBC Classic / IBC v1の基本モデルでは、

Chain A                         Chain B
┌──────────────┐              ┌──────────────┐
│ Chain Bの状態 │              │ Chain Aの状態 │
│ を検証する    │              │ を検証する    │
│ Light Client │              │ Light Client │
└──────┬───────┘              └──────┬───────┘
       │                              │
       └──────── IBC packet ─────────┘
                       ▲
                       │
                    Relayer

という構造を取る。

Relayerは基本的に情報の運搬者であり、相手chainの正当性を保証する主体ではない。受信chain側のlight clientがproofを検証する。

4. IBCの4つの基本要素

IBCを理解するときは、次の4段階が分かりやすい。

token transferはIBC全体の一用途であり、fungible token transferには主にICS-20が使われる。

したがってIBCは、

token transfer

だけでなく、将来的には、

Chain Aの状態
     ↓
IBC message
     ↓
Chain Bのapplication処理

のようなcross-chain applicationにも使える。

5. Cardano × Injectiveでは何が実現したのか

Cardano Foundationの cardano-ibc-incubator では、CardanoにIBC v1を実装する取り組みが進められている。

現在の caribic 環境では、

Cardano Preprod
      │
      │ IBC
      ▼
Injective Testnet

のpublic network同士を使った試験が可能になっている。

公式READMEではInjective testnet側のallowed clientとして、

08-cardano-probabilistic

が登録されていることを確認できる。

route setupでは概ね、

1. Injective側にCardano light clientを作成
2. Cardano側にInjectiveのTendermint light clientを作成
3. IBC connectionを確立
4. ICS-20 transfer channelを開く
5. Hermes relayerを起動
6. Cardano → Injective token transfer
7. Injective → Cardano return leg

という流れを構成する。

成熟度を整理すると次のようになる。

したがって、

「CardanoとInjectiveのMainnet IBC bridgeが完成した」ではない。

正確には、

「異種設計のCardanoとInjectiveの間でIBCを動かす実装が、public testnet同士のE2E接続試験まで進んだ」

である。

6. 最大の難所：CardanoはTendermint系ではない

Cosmos SDK系chain同士であれば、多くの場合CometBFT/Tendermint系のconsensusとlight clientを利用できる。

Cosmos Hub
     ↕
Tendermint Light Client
     ↕
Injective

これに対してCardanoは、

• Ouroboros Proof of Stake
• eUTxO
• 確率的なsettlement/finality特性

を持つ。

したがってInjective側が、

「このCardano block・stateは、本当に十分settledしているのか」

をどう検証するかが核心になる。

7. 08-cardano-probabilistic light client

この問題に対してCardano Foundation側で開発されているのが、

`08-cardano-probabilistic`

である。

これは以前のMithril light client方式とは異なり、Cardano chain historyとstake-relatedな情報を使って、Cardano上のsettlementをheuristicに判断する設計である。

概念的には、

Cardano
   │
   │ block history / epoch context
   ▼
08-cardano-probabilistic
   │
   │ 十分にsettledした履歴か評価
   ▼
Injective

となる。

ここで名前に probabilistic と付いていることが非常に重要である。

Cardano Foundationの設計文書自身が、これは高速BFT finality modelではなく、より速いIBC settlementを得るためにrisk trade-offを置くheuristic modelだと説明している。

8. 現段階では「完全trustless」と表現しない方がよい

IBCという言葉から、

「light clientを使うから完全trustless」

と単純化してはいけない。

08-cardano-probabilistic の設計文書では、

• cryptographic finality certificateそのものではない
• accepted Cardano historyが後にreorgされた場合、IBC integration上のsafety failureになり得る
• block-history / epoch-stake data sourceの品質に運用上依存する
• faster acceptanceとexternal trust排除の間にtrade-offがある

ことが明示されている。

したがって現在の比較は概ねこうなる。

目標はtrust-minimized interoperabilityであるが、成熟したTendermint ↔ Tendermint IBCと同じsecurity assumptionだとはまだ言えない。

9. Cardanoからtokenを送ると何が起きるのか

ICS-20では、native assetそのものを物理的に別chainへ移動するわけではない。

典型的には、

Origin Chain
  │
  │ native token
  ▼
IBC escrow
  │
  │ packet
  ▼
===================
     IBC Channel
===================
  │
  ▼
Destination Chain
  │
IBC voucher representation

となる。

元のchainへ戻す場合は、

IBC voucher
    ↓
burn
    ↓
IBC packet
    ↓
origin-side escrow解除
    ↓
native asset返還

という構造になる。

またICS-20では、tokenがどのchannelを経由したかというdenom traceが保持される。

そのため、

Cardano → Injective

と、

Cardano → 別chain → Injective

では、同じorigin assetでも受信側で同一denomとして扱われない場合がある。

これはcross-chain liquidity fragmentationを考える上でも重要である。

なお、Mainnet ADAのproduction routeが完成したことは、2026-08-13時点では確認できない。

10. InjectiveとつながればCosmos全体につながるのか

ここは誤解しやすい。

Injective自体は多数のIBC networkと接続するinteroperable L1である。そのため将来的には、

Cardano
   ↕
Injective
   ↕
Cosmos / IBC ecosystem

という経済経路を構築できる可能性がある。

しかし、

Cardano ↔ Injective Testnetが成立した瞬間に、Cardanoが全IBC chainと直接接続されたわけではない。

Cardanoとのdirect routeを他chainへ広げる場合、そのchain側でCardano client typeを受け入れ、client、connection、channel、relayer、asset mapping等を整備する必要がある。

Injectiveは重要な最初の実証相手・金融ハブ候補だが、「唯一のgateway」である必要はない。

成功すれば将来的には、

                 Osmosis
                    ▲
                    │
Injective ◀──── Cardano ────▶ Other IBC Chain
                    │
                    ▼
                 Chain X

のようにCardanoからdirect IBC routeを増やしていく可能性もある。

11. なぜInjectiveが接続相手として重要なのか

Injectiveは金融特化L1である。

したがって将来Cardano assetがproduction環境で安全に利用可能になれば、

Cardano assets
      │
      │ IBC
      ▼
   Injective
      │
 ┌────┼─────────┐
 │    │         │
Spot Derivatives DeFi / RWA

のような金融利用が考えられる。

ただし、IBC routeが存在するだけではmarketは生まれない。

実際の経済利用には、

1. Mainnet route
2. security review
3. asset registration
4. wallet対応
5. oracle
6. market / DEX integration
7. liquidity provider
8. UX integration

が必要になる。

したがって、

IBC = 流動性そのもの

ではなく、

IBC = 流動性が安全に移動できる道路

と考えるのが適切である。

12. Cardanoにとって重要なのは「外へ出る」だけではない

利用者目線では、

「ADAをInjectiveへ持っていける」

ことが目立つ。

しかしCardano ecosystemの成長という観点では、むしろ逆方向も重要である。

Injective / IBC ecosystem
        │
        │ assets
        │ stablecoins
        │ liquidity
        │ users
        ▼
      Cardano
        │
 ┌──────┼────────┐
 │      │        │
DEX   Lending   RWA

Cardanoの弱点の一つは、native技術そのものよりも、外部流動性とCardano DeFiを結ぶ経路が相対的に細いことにある。

IBCがproduction品質に達し、主要asset・wallet・DEXが対応すれば、

• 外部stablecoin
• IBC native assets
• arbitrage capital
• traders
• cross-chain applications

がCardanoへ入りやすくなる。

この方向が実現すれば、Cardano DeFiにとってIBCは単なるbridgeではなく、外部資本への入口になる。

13. IBCはtoken transferだけではない

IBCの本質はcommunication protocolである。

ICS-20はそのapplicationの一つにすぎない。

将来的には、

Cardano上で条件成立
       ↓
    IBC packet
       ↓
Injective上のapplicationが処理
       ↓
    IBC response
       ↓
Cardano上のstate更新

というcross-chain applicationへ発展できる。

例えば概念上は、

Cardanoで担保をlock
       ↓
IBC message
       ↓
Injectiveで金融positionを作る
       ↓
結果をIBCで返す
       ↓
Cardano contractを更新

といった構成が考えられる。

ここまで進むと、「asset bridge」ではなく、

multi-chain application layer

になる。

14. 現在見えている大きな技術課題

public testnet試験へ進んだことで、PoCでは見えにくかった実運用課題も見え始めている。

Cardano Foundationの caribic READMEには、Injective側にあるCardano probabilistic light clientを更新するとき、Cardano blockのgapが大きくなるほどupdate payloadが膨らむ問題が記録されている。

READMEに示された試験例では、

• 約257 Cardano heightsのgapで約3.07 MB
• 約541 block gapで約4.27 MB

規模のupdateとなり、テスト環境のtransaction / block size制約に抵触する事例が説明されている。

つまり課題は、

Cardanoが進む
   ↓
Light Client updateが必要
   ↓
更新間隔が空く
   ↓
proof / witnessが肥大化
   ↓
Injectiveのtx / block制限に抵触
   ↓
client更新が困難

というものである。

これは非常に重要である。

PoCでは、

「一度つながるか」

が問題になる。

productionでは、

「24時間365日、障害や停止を挟んでも安全につなぎ続けられるか」

が問題になるからである。

15. 「つながる」から「つなぎ続ける」段階へ

Mainnet productionに必要なのは、単純なtoken transfer成功ではない。

Clientを継続更新
      ↓
Relayer停止への耐性
      ↓
timeout / acknowledgement処理
      ↓
chain upgrade対応
      ↓
reorg / conflicting history対応
      ↓
復旧手順
      ↓
asset safety

まで検証する必要がある。

したがって現在のCardano × Injective IBCは、

「通信できることを証明する段階」から、「通信路を長期間・安全に維持できることを証明する段階」へ移りつつある

と評価するのがよい。

16. Relayerは何をしているのか

現在のtest environmentではHermes relayerが使われる。

概念的には、

Cardano
   │
   │ packet + proof
   ▼
 Hermes
   │
   ▼
Injective

という運搬役である。

IBCの原則では、relayer自身を「正しさの保証者」として信用する必要はない。受信側light clientがproofを検証するからである。

したがって一般論では、relayer停止の主要問題は資産窃取よりliveness低下である。

ただしCardano用probabilistic clientには独自のsettlement assumptionがあるため、

「HermesがpermissionlessだからCardano IBC全体も完全trustless」

とは言えない。

securityはrelayerだけでなくlight clientの検証モデル全体で評価すべきである。

17. Cardano憲法との整合性

CardanoのRatified Constitutionでは、Tenet 6として、

Cardano Blockchain shall not unreasonably impede interoperability.

という相互運用性に関する原則が置かれている。

IBC接続は、この原則と技術ロードマップが比較的直接に重なる領域である。

Cardanoにとってinteroperabilityは単なるmarketing上の追加機能ではなく、ecosystem設計上の重要な原則として扱うことができる。

18. Cardano DeFiへの経済波及

IBC Mainnetが完成しただけではTVLは増えない。

経済効果が出るには、

IBC Mainnet
   ↓
security / reliability確立
   ↓
wallet対応
   ↓
主要asset route
   ↓
DEX / lending integration
   ↓
Liquidity Provider
   ↓
arbitrage
   ↓
slippage低下
   ↓
volume増加
   ↓
TVL・stablecoin liquidity増加

という下流のintegrationが必要になる。

したがって現時点で見るべきなのは価格ではなくマイルストーンである。

19. PRIMEとの関係

Cardano PRIMEのようなDeFi成長施策がCardano内部の資本だけを循環させる場合、

Cardano Treasury
      ↓
    incentive
      ↓
Cardano DeFi内で再配置

に終わる可能性がある。

一方、IBCなどの外部接続が成熟すれば、

外部資本・stablecoin
        ↓
Injective / IBC ecosystem
        ↓
       IBC
        ↓
     Cardano
        ↓
PRIME等のDeFi施策
        ↓
持続的なCardano DeFi liquidity

という構造を作れる可能性がある。

したがって大型DeFi施策の成果を見る際には、

「何ADAを配布したか」より、「外部からどれだけ持続的な資本・stablecoin・利用者をCardanoへ引き込んだか」

を重要KPIにすべきである。

20. 今後追跡すべきマイルストーン

今は①を越え、②〜⑤のproduction engineeringが重要になる段階と見る。

21. 5段階シナリオ分析

以下はCGTAによる推測であり、確定予測ではない。

中心シナリオはS4〜S3と考える。

22. BWtake & CGTAとしての評価ポイント

DRep・ADA holderとして見るなら、Injective × Cardano IBCは次のように評価するのが適切である。

高く評価できる点

• Cardanoが独自ecosystemの外へ標準protocolで接続しようとしている
• IBCという既存のinteroperability標準を活用している
• PoCではなくpublic testnet同士のroute構築へ進んだ
• token transferだけでなくcross-chain applicationへ拡張可能
• Cardano DeFiへの外部流動性流入経路になり得る
• Cardano Constitutionのinteroperability原則とも整合的

まだ慎重に見るべき点

• Mainnet接続ではない
• Mainnet ADA transferは未確認
• Cardano probabilistic light clientには固有のsecurity trade-offがある
• long-running client updateに実運用課題がある
• IBC接続だけでliquidityは生まれない
• Injective接続だけでCardanoが全Cosmos / IBC networkへ直接接続されるわけではない

23. 最終整理

Injective × Cardano IBCを一言で表すなら、

「CardanoからInjectiveへtokenを送るbridge」ではなく、「CardanoをIBCの共通通信圏へ参加させるための実証実装」

である。

Injectiveはその最初の重要な実証相手であり、金融特化L1であることから、技術実証が成功した場合の経済的な接続先としても相性がよい。

ただし、現在はまだ、

Concept
  ↓
Implementation
  ↓
Local Test
  ↓
Public Testnet E2E   ← 現在
  ↓
Long-run reliability
  ↓
Security hardening
  ↓
Mainnet
  ↓
Asset / Wallet / DeFi integration
  ↓
Real liquidity

の途中にいる。

したがってCGTAは、2026年のCardano interoperability関連では重要度の高い進展と評価する一方、評価の焦点は「接続発表」ではなく、

1. probabilistic light clientの成熟
2. update payload問題の解決
3. security review
4. Mainnet route
5. 実asset対応
6. 実cross-chain volume
7. Cardano DeFiへのnet inflow

へ移すべきだと考える。

出典・情報源

一次情報源・公式資料

1. Cardano Foundation - cardano-ibc-incubator / caribic README

Cardano Preprod ↔ Injective Testnet、08-cardano-probabilistic、client / connection / channel作成、Hermes、token-transfer試験、client update size問題。 https://github.com/cardano-foundation/cardano-ibc-incubator/blob/main/caribic/README.md

1. Cardano Foundation - Probabilistic Light Client Design

08-cardano-probabilistic の設計、Mithril方式との違い、settlement heuristic、security / trust trade-off。 https://github.com/cardano-foundation/cardano-ibc-incubator/blob/main/docs/probabilistic-light-client.md

1. IBC Protocol - How IBC Works

IBCのlight client、connection、channel、packet、relayerの基本構造。 https://ibcprotocol.dev/how-ibc-works

1. Cosmos Docs - The Cosmos Stack

Cosmos SDK、CometBFT、IBC、Cosmos EVMからなるmodular stack。 https://docs.cosmos.network/sdk/latest/learn/intro/cosmos-stack

1. Cosmos Docs - What is the Cosmos SDK

application-specific blockchain、module architecture、IBC interoperability。 https://docs.cosmos.network/sdk/latest/learn/intro/overview

1. Injective Docs - About Injective

Injectiveの金融特化L1としての位置づけ、IBC interoperability。 https://docs.injective.network/

1. Injective Docs - Native Developers Overview

Cosmos SDK module、exchange、tokenfactory、oracle、IBC等。 https://docs.injective.network/developers-native

1. Injective Docs - IBC

ICS-20 transfer、channel、IBC denom等。 https://docs.injective.network/developers-native/examples/ibc

1. Cosmos Docs - ICS-20 Fungible Token Transfer

escrow / voucher、denom trace、timeout / acknowledgement。 https://docs.cosmos.network/ibc/latest/spec/app/ics-020-fungible-token-transfer/README

1. Cardano Blockchain Ecosystem Constitution（Ratified Constitution）

Project source: Ratified Constitution.txt Tenet 6: interoperabilityを不合理に妨げないという原則。

Fact Check

• Cardano Preprod ↔ Injective Testnetのpublic-network試験：確認済み
• Injective Testnetで `08-cardano-probabilistic` がallowed client：確認済み
• 双方向token-transfer test leg：公式READMEで確認
• Mainnet Cardano ↔ Injective IBC：2026-08-13時点で未確認
• Mainnet ADA transfer：未確認
• CardanoがInjective接続だけで110+ IBC networksへ直接接続：誤り。Injective自身の接続範囲とCardanoのdirect connectivityは区別が必要
• probabilistic light clientのsecurity trade-off：Cardano Foundation設計文書で確認
• client update payload肥大化問題：公式 caribic READMEで確認

作成日時：2026-08-13 14:20 JST