CardanoとInjectiveのIBC接続――初の実働テストネットが開く金融圏と本番化への課題

はじめに――「密かに稼働」は本当なのか

「Injectiveが密かにCardanoとのIBC接続を稼働させた」と、アナリストの@0xfaseeh氏が指摘したというニュースが流れた。

IBC（Inter-Blockchain Communication）は、異なるブロックチェーン間で、資産やデータを認証付きpacketとしてやり取りするための標準プロトコルである。もしCardanoがIBC経由でInjectiveと結ばれれば、中央集権型取引所へADAを送って売買する方法とは別に、Cardano資産をオンチェーンのまま外部金融圏へ運べる経路が生まれる。

ニュースの方向性は正しい。しかし、2026年8月21日時点では「単一の個人アカウントによる未確認情報」という説明は古くなっている。

Cardano Foundationは2026年6月の月次報告で、InjectiveがCardano IBC moduleを実装し、beta版がtestnetで稼働していると公表した。7月の月次報告でも、CardanoとInjectiveがtestnet上でIBC接続され、InjectiveがCardanoへのlive on-chain IBC railを持つ最初のblockchainになったと確認している。

したがって、現在の正確な表現は次のようになる。

Cardano PreprodとInjective Testnetの間では、Cardano初の実働IBC接続が成立し、test tokenの往復移転まで実証されている。ただし、Cardano MainnetとInjective Mainnetを結ぶ本番bridgeではなく、実ADA・実INJを移動できる段階ではない。

「密かに」という表現も適切ではない。開発は公開GitHubで進められ、Cardano Foundationが5月にはInjectiveとOsmosisへCardano light client統合のpull requestを提出したことを報告し、6月にはtestnet betaの稼働を公表していた。派手な一般向け発表より先に、公開リポジトリと開発報告の中で実装が進んでいた、という意味なら理解できるが、秘密裏に稼働させたわけではない。

1．ニュースのファクトチェック

この接続は単なる計画や画面上のmock-upではない。公式リポジトリには、Cardano Preprodから公開Injective Testnet injective-888へのend-to-end手順があり、client生成、connection確立、channel開設、packet relay、voucherのmint・burn、資産のescrow・unescrowまで試験できる。

一方、同じリポジトリは実装をpre-productionと位置づけ、production deploymentには推奨しないと明記している。技術的な実在性は高いが、本番成熟度はまだ低い。

2．現在動いているもの

Injective Testnetでは、Cardano用client typeである08-cardano-probabilisticがallowed clientとして登録されている。Cardano側にはInjectiveを追跡するTendermint light clientを作成し、双方のclientを結ぶconnectionとICS-20 transfer channelを開く。

ここで注意したいのは、公式demoで確認されているのは主として直接的なtoken transferであることだ。Cardano IBC Incubatorの説明では、DEX-style swap legが用意されているのは現状Osmosis向けであり、Injective向けdemoはCardanoからInjectiveへの送付と帰還を試す構成である。

したがって、次の二つは区別しなければならない。

• ADAを表すtest voucherをInjective Testnetへ送れる
• ADA市場がInjectiveのCLOBで開設され、実際の流動性を伴って取引できる

前者は実証済みだが、後者はまだ実現していない。

3．ADAはどのようにInjectiveへ移動するのか

ADAそのものがCardanoから消えてInjectiveへ移るわけではない。IBCのICS-20 transferは、基本的にescrowとvoucherの組み合わせで資産の一貫性を保つ。

CardanoからInjectiveへ送る場合

1. ユーザーがCardano Preprod上でtest ADAの送信transactionに署名する。
2. test ADAがCardano側のIBC escrow scriptにロックされる。
3. 送信packetとIBC stateの更新がCardanoのHostStateへ記録される。
4. Hermes relayerがpacketと証明をInjective Testnetへ運ぶ。
5. Injective側のCardano light clientが、Cardano側の状態を検査する。
6. 検証に成功すると、Injective上でADAを表すICS-20 voucherがmintされる。

Cardanoへ戻す場合

1. Injective上のADA voucherをburnする。
2. 帰還packetと証明をrelayerがCardanoへ運ぶ。
3. Cardano側がInjectiveの状態を検証する。
4. Cardano側でescrowされていたtest ADAが受取人へ解放される。

INJをCardanoへ送る場合は逆になる。INJはInjective側でescrowされ、Cardano側ではINJを表すCardano native token型voucherがmintされる。帰還時にはCardano側voucherをburnし、Injective側のINJをunescrowする。

公式のend-to-end testには、voucherのmint・burnだけでなく、Cardano native assetのescrow・unescrow、denomination traceの照合、往復後の残高回復まで含まれている。

4．「中央管理者なし」はどこまで正しいのか

IBCでは、relayerが二つのchainの間でpacketとproofを運ぶ。標準的なIBC設計では、relayerは資産を預かるcustodianではない。悪意あるrelayerが偽packetを送っても、受信chain上のlight clientとIBC logicが正しく検証すれば拒否される。

その意味では、少数の署名者が鍵を管理し、署名者の合意だけで資産をunlockまたはmintするmultisig bridgeより、IBCは検証可能性の高い設計を取り得る。

しかし、IBCという規格を使うだけで自動的に完全trustlessになるわけではない。安全性は、相手chainの状態を検証するlight clientの実装と、そのlight clientが置く信頼前提によって決まる。

今回のCardano接続では、この部分に重要な留保がある。

5．Cardano固有の難問――08-cardano-probabilistic

Cosmos SDK／Tendermint系chainでは、validator署名を伴うblock headerとapp_hashを使い、特定のheightにおける相手chainの状態をlight clientで検証しやすい。

一方、CardanoはOuroboros Praosによる確率的settlementとEUTXOを採用している。現時点では、IBCが通常想定する形でCardanoの任意UTxO状態を証明する汎用的なinclusion proofが整っていない。この非対称性を埋めるため、Cardano IBC Incubatorは独自のSTT architectureと実験的な08-cardano-probabilistic light clientを採用している。

このclientは、あるCardano blockの後ろに積み上がったblock群を観察し、depth、block producerの多様性、producerが代表するstakeを組み合わせて「IBCで受け入れるのに十分settleした」と判定する。

24というdepthだけで決めるのではない。一定数以上の異なるSPOが後続blockを作り、それらのSPOが合計で一定以上のactive stakeを代表していることも求める。これにより、単純なblock数だけよりはCardanoの分散したblock生成状況を反映できる。

しかし、これはTendermint型light clientやBFT finalityと同等ではない。公式設計書自身が、その点を明確に警告している。

• accepted historyが後からreorgされた場合、IBC側では安全性障害になる
• IBCには、相手chainで既に実行されたstateを巻き戻す標準機構がない
• canonical historyは、現在は設定されたnode／Ogmios observer viewに依存する
• epoch contextの正当性を完全に独立認証できていない

特にepoch contextには、stake weight、VRF key hash、nonce、KES設定、epochのslot境界などが含まれる。現在は、一度受け入れたepoch contextと異なる情報が後から届けばmisbehaviourとしてclientをfreezeできる。

ただしこれは、最初に受け入れたcontextが暗号学的に正しいことを保証するものではない。不正だが内部的には整合したcontextを最初のrelayerまたはobserverが供給し、その後に正直なobserverが現れなければ、矛盾を検出できない可能性が残る。

したがって現状を「中央管理者を完全に排除したtrustless bridge」と呼ぶのは強すぎる。

より正確には、次のように評価できる。

カストディ型bridgeより検証可能性の高いIBC方式をCardanoへ移植したが、Cardano側のcanonical historyとepoch contextについて、observerおよびsettlement heuristicへの明示的な信頼前提が残る実験実装である。

6．なぜMithril方式から変更したのか

Cardano IBCでは、以前Mithril light clientが中心的な候補だった。Mithrilは、Cardano stake pool群の署名を集約し、Cardanoの状態について相手chainへ持ち運べるcryptographic artifactを提供できる。

しかし、Mithril certificateはchain tipから遅れて生成される。IBC transferやcross-chain swapでは、証明を待つために数百Cardano blockを要する可能性があり、DeFiのUXとして現実的ではなかった。このため旧08-cardano-mithril clientはdeprecated／disabledとなり、低latencyを優先するprobabilistic方式へ移行した。

将来的にはOuroboros Perasが重要になる可能性がある。Perasは投票とcertificateによってCardanoのsettlementを約2分程度へ短縮することを目標としている。Cardano IBCの公式設計書も、Cardanoのfinalityが5分未満になれば、現在のlight client方式が恩恵を受けると述べている。

推測だが、Peras certificateまたはそれに基づくcanonical state証明をIBC側で検証できれば、現在のobserver依存を減らし、速度と安全性の両立に近づける可能性がある。ただし、Perasを08-cardano-probabilisticへどう統合するかについて、確定した公式仕様は確認できていない。

7．Cardano DeFiにとっての意味

この接続の価値は、単にADAを別chainへ送れることではない。Cardano資産がInjectiveの金融engineへ到達できる可能性にある。

Injectiveは金融特化L1として、protocol levelにon-chain orderbook、spot、perpetual futures、futures、oracle、insurance fund、shared liquidityなどのmoduleを持つ。Cardano native assetが安全にInjectiveへ到達し、正式なmarketと十分な流動性が用意されれば、Cardano側だけでは得にくかったCLOB型取引やderivatives市場へ接続できる。

ただし、資産を運べることと、その資産が金融商品として利用できることは別である。

ADA voucherがInjectiveへ到着しても、対応market、oracle、liquidity provider、wallet表示、risk managementがなければ、実質的には「置いておけるtoken」にとどまる。Cardano側へINJ voucherが来ても、CardanoのDEXやlending protocolがそのassetを採用しなければ利用範囲は広がらない。

8．CardanoがCosmos全体と自動接続されたわけではない

IBCは共通言語だが、Injectiveとのchannelが一つ開いただけで、Cardanoが全IBC chainと自動的に接続されるわけではない。

各counterparty chainには、原則として次の作業が必要になる。

1. Cardano light clientを実装・登録する。
2. 08-cardano-probabilisticをallowed clientとして許可する。
3. 相互のIBC clientを作成する。
4. connectionを確立する。
5. ICS-20などのapplication channelを開く。
6. relayerを継続的に運用する。
7. asset originとdenomination traceをwallet・explorerで表示する。

Injectiveを経由して別のIBC chainへ多段転送する場合には、Packet Forward Middlewareなどのrouting機構と、各hopでのsecurity assumptionを追加評価する必要がある。

したがってInjectiveは、現時点で「CardanoからIBC世界への完成済みhub」ではない。

Cardanoが非Cosmos型chainとしてIBCへ入れることを示した、最初の実働gatewayである。

この位置づけが妥当である。

9．本番化までに残る課題

特にCardano側のHostState UTxOは、IBCのclient、connection、channel、packetなどのstateを一つのrootとして管理する。stateを変更するtransactionは同じHostState UTxOを消費して後継UTxOを作るため、異なるIBC操作であっても同時並行処理しにくい。

開発側は複数更新のbatching、またはstateを複数UTxOへshardingする案を挙げているが、production strategyはまだ確定していない。

10．Mainnet移行前に確認すべき条件

Mainnetへ進む場合、少なくとも次の項目を確認する必要がある。

1. 独立したsecurity audit報告書が公開されているか。
2. Gateway、Ogmios、epoch observerが複数化されているか。
3. epoch contextを暗号学的または複数sourceで認証できるか。
4. 複数の独立relayerが継続運用できるか。
5. relayer feeまたは外部報酬制度が用意されているか。
6. transfer上限、rate limit、circuit breakerが設けられているか。
7. walletとexplorerがorigin chain、channel、denom trace、return pathを表示するか。
8. HostState競合に対するbatchingまたはshardingが実装されているか。
9. client upgrade、freeze、再開、資産回収の手順が公開されているか。
10. 初期Mainnet TVLに上限を設け、段階的に拡大するか。

「testnetでcodeが動く」ことは重要な第一歩だが、「大きな実資産を安全に預けられる」こととは異なる。本番化を評価するときは、Mainnetという名称よりも、light clientのtrust model、運用主体の分散、損失制限、復旧手順を見る必要がある。

11．今後18か月の5段階シナリオ

以下は公式予測ではなく、2026年8月21日時点の公開情報に基づくCGTAの推定である。

中心シナリオはS3、次点がS4である。

Perasによる高速settlement、Cardano canonical stateのproof、複数observer、段階的TVL capが揃えばS4からS5へ近づく。反対に、「IBCだからtrustless」という説明だけで大きなTVLを受け入れれば、S2またはS1のriskが上昇する。

12．総合評価

おわりに――これは完成ではなく、入口が開いたニュースである

今回のニュースは、単なる噂ではない。Cardano PreprodとInjective Testnetの間で、IBC client、connection、channel、packet relay、tokenの往復処理が実際に動いている。Cardanoにとっては、IBCをCosmos専用技術ではなく、自らのEUTXOとOuroborosへ適応できることを示した重要な技術的milestoneである。

一方で、「実ADAがInjectiveへ流れ始めた」「CardanoがCosmos全体と完全trustlessにつながった」と理解するのは早い。現在の実装は実験的なprobabilistic light clientを採用し、Cardano historyとepoch contextについてobserverへの信頼を残している。InjectiveのCLOBやderivativesでADAを利用するには、Mainnet化だけでなく、market、oracle、liquidity、wallet表示、risk managementも必要になる。

現段階を最も正確に表すなら、次のようになる。

CardanoとInjectiveは、Cardano初の実働IBC testnet接続を成立させた。資産の往復移転まで実証されているが、observer依存を残す実験的light clientを用いたpre-production段階であり、実ADA・実INJを扱うMainnet bridgeとしてはまだ利用できない。

このニュースの価値は、完成品が登場したことではない。CardanoがInjectiveの金融engine、さらに将来のIBC経済圏へ接続するための「最初の実働入口」が開いたことである。

用語集

出典・情報源

1. Cardano Foundation, Cardano Foundation Monthly Update: May 2026
2. Cardano Foundation, Cardano Foundation Monthly Update: June 2026
3. Cardano Foundation, Cardano Foundation Monthly Update: July 2026
4. Cardano Foundation GitHub, Cardano IBC Incubator README
5. Cardano Foundation GitHub, Cardano Preprod to Injective Testnet End-to-End Walkthrough
6. Cardano Foundation GitHub, Probabilistic Light Client Design
7. Cardano Foundation GitHub, Known Issues, Asymmetries, and Architectural Considerations
8. Cardano Foundation GitHub, Aiken Property and Fuzzing Invariants
9. IBC Protocol, How the IBC Protocol Works
10. IBC Protocol, 12 Myths and Realities About the IBC Protocol
11. Injective, Understanding Injective Architecture and Consensus
12. Cardano, Ouroboros Peras: Accelerating Transaction Settlement on Cardano
13. 添付資料「Cardano_epoch」：Epoch 650のJST期間確認に使用

注記

• 確認基準日：2026-08-21 JST
• 将来予測と確率は公式見解ではなく、公開情報に基づくCGTAの推定である。
• 独立監査報告書、Mainnet開始日、初期TVL上限、Perasとの具体的統合方式は確認できていない。
• 暗号資産の移転・運用にはsmart contract、bridge、oracle、流動性、価格変動などのriskがある。

作成日時：2026-08-21 JST