LIVE ADA-- MCAP-- TVL-- STAKE-- EPOCH--
SIPO
速報 CardanoとInjectiveがテストネットでIBC接続、クロスチェーン資産移動が実現 57分前 速報一覧 →
HOMEDeep Dive › 🔬 Deep Dive|SundaeSwap v4発表──8つの新設計でDEXは「モジュール型の流動性基盤」へ
Deep Dive

🔬 Deep Dive|SundaeSwap v4発表──8つの新設計でDEXは「モジュール型の流動性基盤」へ

2026-08-02SIPO

CardanoのDEXは、ただ交換を速くする段階から、流動性そのものをどう組み立て、どう他のプロトコルへ開いていくかを競う段階へ入り始めました。

Sundae Labsは2026年7月31日JST、SundaeSwapプロトコルの次期メジャーバージョン「Sundae v4」の最初の詳細を発表しました。

今回の主役は、新しい画面や一つの高速化機能ではありません。プールを「トークンの準備金と、その準備金に対する持分を表すLPトークン」という最小単位まで整理し、価格曲線、取引条件、注文処理、外部プロトコルとの連携をモジュールとして組み替えられるようにする設計です。

Sundae Labsはこれを「Professional DeFi」というテーマで説明しています。

目指しているのは、SundaeSwapだけで完結するDEXではなく、プロの流動性提供者、ステーブルコイン、レンディング、合成資産、オーダーブック、将来のL2までが、同じ流動性と注文フローへ接続できる基盤です。

利用者にとっての価値は、複雑な経路を意識せず、より良い価格、低いスリッページ、扱いやすい指値注文へ近づける可能性にあります。ただし、発表された8つの例が初日からすべて利用できるわけではありません。監査結果、ベンチマーク、公開日程、v3流動性の移行方法も続報待ちです。

本稿では、Sundae v4が何を変えようとしているのかを8つの設計から読み解き、利用者、流動性提供者、開発者にとっての意味と、ローンチ後に確認すべき点を整理します。

公式発表はこちらです。

先に結論

  • Sundae v4の中心は、流動性プールをモジュール化し、価格曲線、取引制限、注文処理、外部プロトコル連携を用途に応じて組み替えられるようにすることです。
  • 自動ルーティングは、複数のプールや経路へ注文を分割し、より良い受取額を探すDEXアグリゲーターの役割を、SundaeSwapの注文そのものへ組み込もうとします。
  • 集中流動性、複数資産プール、カスタムVault、Linear Swaps、部分約定は、薄い流動性を効率よく使い、プロの運用要件にも対応するための道具として位置づけられています。
  • Sundae Labsは、v4のコードは完成し監査も終盤で、発表から1か月以内に中核機能から段階的なローンチを始める予定だと説明しています。
  • ただし、全機能が初日から使えるわけではありません。監査報告、実測性能、ルーティング品質、手数料、管理権限、v3からの移行条件が、今後の重要な確認項目です。

Sundae v4は何を変えるのか

Sundae Labsは、これまでの歩みを三つの段階で振り返っています。

v1は、スマートコントラクト機能を得たばかりのCardanoへDEXの基本機能を持ち込みました。v2は利用体験を改善し、v3は新しいCardano機能と技術を活用して、同社説明ではスループットを10倍に拡大しました。

v4の問いは、その延長だけではありません。

「CardanoのDeFiが、より効率的で、革新的で、広い市場と競争できるためには何が必要か」。その答えとして、Sundae Labsはプールを完成品ではなく、組み替え可能な部品の集合として設計し直しました。

一般的なAMMでは、資産ペア、価格曲線、手数料、注文方法などが一つのプール設計へ強く結びつきます。v4では、プールの核を準備金とLP持分へ絞り、それ以外を設定可能なモジュールとして扱います。

たとえるなら、完成した一種類のアイスクリームを配る店から、土台、フレーバー、トッピング、提供方法を用途に合わせて組み立てられるキッチンへ変わるイメージです。

重要なのは、自由にフォークできることだけではありません。Sundaeのエコシステムへ適合するモジュールであれば、SundaeSwapの画面、注文フロー、アグリゲーター連携などへ接続できると説明されています。

プロトコルや流動性提供者は、自前でDEX全体を一から立ち上げず、必要な部分だけを設計し、既存の利用者導線と流動性ネットワークへ参加できる可能性があります。

8つの設計をどう読むか

1.自動ルーティング──DEXの中にアグリゲーターを組み込む

現在のCardano DeFiでは、利用者が受け取りたい資産、最低受取額、実行先のプールなどを明示し、DEXアグリゲーターが複数のDEXやプールを比較して最良の経路を探す方法が広く使われています。

Sundae v4では、経路選択を注文の一部にします。利用者は必要なら経路を固定できますが、通常はスクーパーが注文を複数のプールや経路へ分割し、受取額を最大化します。

Sundae Labsによれば、この最適化で生まれた余剰はスクーパーではなく利用者へ渡るよう、スマートコントラクトで強制されます。

利用者にとって分かりやすい価値は、どのプールを選ぶかを毎回判断しなくても、より良い価格へ自動的に近づける可能性があることです。一方、実際の価値は、経路探索の速度、見積もりと約定の差、分割による追加手数料、スクーパー間の競争を測って初めて評価できます。

2.プロトコル間の合成──一つの注文でDeFiを横断する

自動ルーティングの対象は、SundaeSwap内のプールだけではありません。

発表では、ADAからButaneの合成金トークンMIDASへ交換するとき、ADAをADAbの発行に使ってからMIDASへ交換する経路が有利なら、その処理を一つの原子的な取引として組み込む例が示されています。

ステーブルコイン交換ではIndigoのPeg Stability Moduleを使い、市場が不安定なときは清算処理と連携し、Sundae自身のオーダーブックやDeFi Kernelのような汎用オーダーブックから流動性を取り込む構想も挙げられています。

うまく機能すれば、利用者は複数のアプリを渡り歩かず、一つの注文で複数のDeFi機能を利用できます。プロトコル側には新しい注文フローが入り、流動性提供者には取引量と手数料機会が増える可能性があります。

同時に、接続先が増えるほど、依存するスマートコントラクト、オラクル、価格、清算、障害経路も増えます。「原子的に実行できる」ことと「接続先を含めて安全である」ことは同じではないため、統合ごとの監査と失敗時の挙動が重要になります。

3.カスタムVault──流動性を預けるだけから、運用する仕組みへ

Sundae v4では、プロジェクトや運用者が目的に合わせたVaultを構築できると説明されています。

たとえば、資本の一部を別のDeFiプロトコルへ配分しながら、仮想的な準備金を使って取引を可能にする設計や、外部オラクルに応じて集中流動性の範囲を自動調整する設計です。

これは、流動性を一つのプールへ置くだけでなく、運用方針を持つ金融商品へ発展させる方向です。Sundae Labsは、CardanoのDeFi Liquidity BudgetやAlphaGrowthの取り組みが、こうした仕組みを活用する時機をつくる可能性があると見ています。

一方で、再利用される資本や外部戦略には、スマートコントラクト、オラクル、流動性、管理者、連鎖的な損失のリスクがあります。利回りの高さだけでなく、資産がどこへ配分され、誰が方針を変えられ、どの条件で出金できるかを確認する必要があります。

4.複数資産プール──一組のペアから、資産バスケットへ

従来のCardano DEXでは、ADA/SUNDAEやUSDM/USDCxのように、二つの資産で一つのプールをつくる形が基本です。

v4では、ADA、SUNDAE、INDY、WRTのような複数資産を一つのプールへまとめる例が示されています。

一つひとつのペアでは取引量が少なくても、複数資産の取引需要を集めれば、同じ資本をより多くの取引に使える可能性があります。流動性を多くのペアへ細かく分けずに済むため、薄い市場での資本効率を改善する狙いです。

ただし、流動性提供者はプール内のすべての資産へ価格リスクを持ちます。ある資産の急落や信用不安が、プール全体の構成を大きく変える可能性もあります。資産数が増えるほど、価格曲線、重み、リバランス、手数料、引き出し条件の理解が欠かせません。

5.集中流動性──UTxOネイティブに価格帯へ資本を集める

集中流動性は、流動性をすべての価格帯へ均等に広げるのではなく、取引が多いと考える範囲へ集める考え方です。範囲内では少ない資本でも厚い板に近い効果をつくり、スリッページを抑え、取引量と手数料機会を高められる可能性があります。反対に、市場価格が範囲外へ出ると、そのポジションは手数料を得られません。

Sundae v4は、これをCardanoのUTxOモデルに合わせて実装します。

発表では、価格帯ごとに状態を持つ複数の小さなプールへ流動性を分け、自動ルーティングが複数範囲を横断して価格を組み合わせる構成が説明されています。

ここで大切なのは、Cardano全体の取引が一つの状態を共有するわけではないことです。CardanoのeUTxOモデルでは、異なるUTxOを使う取引は並列に処理できますが、同じUTxOを同時に消費することはできません。v4は流動性状態を複数の小さな単位へ分け、ルーターが必要な範囲を組み合わせることで、集中流動性とUTxOの並列性を両立させようとしています。

6.Linear Swaps──ステーブルコインを予測可能な1対1交換へ

複数のステーブルコインは、発行体、法域、担保、償還方法が異なるため、エコシステムの耐性を高めます。一方、限られた流動性が多くのペアへ分散しやすいという問題があります。

Sundae v4のLinear Swapsは、流動性提供者が信頼するステーブルコインのバスケットを用意し、1対1の固定比率に予測可能な手数料を加えて交換する設計です。

Sundae Labsは、価格曲線によるスリッページやインパーマネントロスを避け、決済や他の製品へ組み込みやすくできると説明しています。

ただし、これはすべてのステーブルコインが常に同じ価値を保つことを保証する仕組みではありません。特定資産への需要が偏れば在庫が枯渇し、通常のプールへ注文を逃がす必要があります。発行体リスク、償還リスク、デペッグも残ります。

v4では、減った資産を伝統的な金融経路などから戻す利用者へ報奨を出す仕組みを設け、裁定へ暗黙に任せるのではなく、在庫回復の誘因を明示するとしています。

7.部分約定──大きな指値注文を時間に分ける

AMMで指値注文を出す場合、プールの表示価格が指定価格へ到達しても、大きな注文では自分自身の取引が価格を動かすため、希望した条件ですべてを約定できないことがあります。

Sundae v4では、注文コントラクトを部分的に実行できるようにします。利用者が用意する手数料予算に応じ、スクーパーが注文を複数の小さな実行へ分けます。

自動ルーティングが一つの注文を複数の場所へ分ける仕組みだとすれば、部分約定は一つの注文を時間へ分ける仕組みです。

これにより、大きな指値注文を中央集権型取引所で期待する動きへ近づける可能性があります。ただし、分割回数に応じた費用、完了までの時間、未約定分の扱い、価格が離れた場合のキャンセル条件は、利用者が理解しやすい形で示す必要があります。

8.将来のCardanoとL2へ備える

Sundae Labsは、v4をアップグレード可能にし、MidgardとLeiosで検証したと説明しています。将来のnested transactions、account address enhancements、programmable tokensといった機能も取り込みやすいよう、プールモジュールを設計したとしています。

さらに、Sundae v4とGummiworm L2を共同設計し、一部のv4プールの流動性がGummiworm L2内の取引を満たし、反対にL2側の流動性がv4の取引へ使われる構想を示しました。

これは長く使える設計を目指す重要な方向です。ただし、Midgard、Leios、将来機能、Gummiwormとの連携は、それぞれの開発段階と依存関係を持ちます。「対応を想定して設計した」ことと、「Cardanoメインネットで現在利用できる」ことは分けて読む必要があります。

誰に何が変わるのか

Sundae v4の8つの設計は、三つの利用者像に整理すると理解しやすくなります。

一般の利用者

複数プール、価格帯、外部プロトコルを自動的に横断し、より良い受取額を探せる可能性があります。指値注文も部分約定によって期待する動きへ近づき、ステーブルコイン交換は予測可能な条件で他の製品へ組み込みやすくなるかもしれません。

理想的な体験は、裏側の複雑さが増えても、利用者の操作はむしろ簡単になることです。

流動性提供者

二資産の単純なAMMだけでなく、複数資産、集中流動性、運用戦略、固定比率交換など、目的に合う形を選べる可能性があります。

その代わり、収益とリスクの理解は難しくなります。価格帯から外れるリスク、複数資産へのエクスポージャー、外部戦略の損失、在庫枯渇、管理権限を、商品ごとに確認する必要があります。

プロトコルと事業者

独自DEXを一から構築しなくても、必要な価格曲線、規制・リスク条件、Vault、外部連携をモジュールとして設計し、SundaeSwapのUIと注文フローへ参加できる可能性があります。

これが「Professional DeFi」の核心です。SundaeSwapを一つのアプリから、複数の金融商品が接続する流動性ネットワークへ広げようとしています。

まだ確定していないこと

今回の発表は、v4の全仕様とローンチ計画を確定させる最終文書ではありません。Sundae Labs自身も「最初の詳細」と位置づけ、次の情報は今後共有するとしています。

  • v3の既存流動性をv4へどう移行するか
  • 中核機能と後続機能の具体的な公開順序
  • 監査結果と、指摘事項への対応
  • v3との比較を含む性能ベンチマーク
  • 各モジュールの権限、アップグレード、緊急停止の設計
  • 経路分割、部分約定、外部プロトコル連携を含む手数料体系
  • Midgard、Leios、Gummiworm連携の検証範囲と利用条件

「コード完成」「監査終盤」はSundae Labsによる発表時点の説明です。公開された監査報告や本番環境の実測に置き換えて確認する必要があります。

SIPOが注視する5つのポイント

1.自動ルーティングが本当に利用者の受取額を改善するか

重要なのは、経路数の多さではなく、ネットワーク手数料、スクーパー費用、外部プロトコル費用を含めた最終受取額です。見積もりと実際の約定、混雑時の成功率、余剰が利用者へ戻ることを確認したい点です。

2.モジュールの自由度と安全性をどう両立するか

自由に組み替えられることは強みですが、不適切な価格曲線、強い管理権限、危険な外部戦略も接続できる可能性があります。公式UIへ表示される基準、監査済み表示、リスク分類、権限の可視化が重要です。

3.薄い流動性を本当に効率よく使えるか

複数資産プール、集中流動性、Linear Swapsは、限られた資本をより有効に使うための設計です。TVLだけでなく、実効スプレッド、スリッページ、取引量、LP収益、価格帯外の時間、在庫枯渇を継続して見る必要があります。

4.外部プロトコルとの合成が障害時にも理解しやすいか

一つの注文が複数のプロトコルを通るとき、どこで失敗し、どの手数料がかかり、資産がどのコントラクトへ触れるのかを利用者が確認できる必要があります。原子的な実行、失敗時の全体巻き戻し、代替経路の選び方が観測点です。

5.段階的ローンチが透明に進むか

最初は小さな中核機能から始まり、確信を得ながら機能を追加する方針は、慎重で現実的です。各段階の公開範囲、監査、バグ修正、管理権限、流動性移行、利用者保護が、追跡できる形で示されることを期待します。

Cardano DeFiは「アプリ」から「接続可能な市場」へ

Sundae v4の面白さは、集中流動性や部分約定といった個々の機能だけにあるのではありません。

自動ルーティングが複数のプールとプロトコルを横断し、モジュール型プールが異なる資産、価格曲線、運用条件を受け入れ、将来はL2の流動性とも接続する。その全体像は、DEXを一つの交換アプリから、Cardano DeFi全体の流動性を編成する市場基盤へ変えようとしています。

この構想が実現すれば、利用者は裏側の複雑さを意識せず、より良い条件へ到達できるかもしれません。流動性提供者は、資本の置き方をより細かく選べます。プロトコルは、単独で市場を立ち上げずに注文フローへ参加できます。

一方で、接続と自由度が増えるほど、リスクも組み合わされます。だからこそ、監査、権限、経路、費用、実測値を見える形にすることが、Professional DeFiのもう半分になります。

Sundae Labsは、v4を「ほぼ準備できるまで話さなかった」と説明しました。ここから必要なのは、驚きの発表を、検証可能で使い続けられるプロトコルへ変えることです。

Sundae v4が、Cardanoの薄い流動性を弱点として抱えるのではなく、複数の市場とプロトコルを賢くつなぐ出発点にできるのか。SIPOも段階的なローンチと実測を追っていきます。

※本稿はSundae Labsの発表内容と公開技術資料を整理したもので、特定のトークン、流動性プール、Vault、DeFiサービスの利用・投資を推奨するものではありません。DeFiにはスマートコントラクト、価格変動、流動性、ステーブルコイン、オラクル、管理権限、外部プロトコル連携などのリスクがあります。

一次ソース

透明性メモ

本稿は2026年8月1日JST時点のSundae Labs公式X投稿、X Article「Introducing Sundae v4」、Cardano公式技術資料、関連プロジェクトの公開リポジトリをもとに作成しました。

SIPO.TOKYOでは、2026年7月31日公開のDaily Intel内でSundaeSwap v4の発表を短く紹介していましたが、v4を主題とする単独記事は確認できませんでした。本稿は、その発表内容を8つの設計と実運用上の観測点に分けて詳しく解説するものです。

Sundae v3の10倍のスループット、v4のコード完成、監査終盤、MidgardとLeiosでの検証、各機能の効果は、今回のSundae Labs発表にもとづく説明です。SIPOはv4のコード、監査報告、ベンチマーク、本番環境、v3移行を独自に検証していません。今後公開される資料と実測に応じて、必要な更新を行います。