Uniswap v2 定数積モデル(x*y=k)|DEX構築の判断軸
AMM、価格インパクト、集中流動性、Hooks、不変量。DEXやトークン流動性を設計する前提知識。
AMM、レンディング、ステーブルコイン、Perps、運用Vault、MEVを、用語の暗記ではなく 「まず理解する、次に比べる、最後に自社で使えるか考える」順番で整理します。
このロードマップは、プロトコル名を覚えるための一覧ではありません。自社プロダクトにDeFiを組み込むとき、どの機能を使い、どのリスクを背負い、どこを外部に任せるのかを判断するために読みます。
DEX、レンディング、ステーブルコイン、Perpsを名前で追う前に、自社プロダクトで必要なのが交換、担保、決済、取引、利回りのどれなのかを切り分けます。
価格インパクト、清算、ペッグ崩壊、MEV、スマートコントラクト不具合を、利用者保護と運用責任の観点で読みます。
API接続、流動性提供、独自実装では、監査、鍵管理、障害対応、ユーザー説明の責任範囲が変わります。
DeFiはプロトコル名から入ると断片的になります。読者がつまずきやすい「何ができるのか」「どこで壊れるのか」「自社で触るなら何を背負うのか」の順に学びます。
交換、貸借、安定資産、派生取引、利回りを、プロトコル名ではなく金融機能として整理します。
価格インパクト、清算、MEV、流動性枯渇、ステーブルコイン崩壊を知ると、仕組みの理解が深まります。
既存プロトコル接続、独自実装、API/RPC利用のどれを選ぶかで、流動性、担保、監査、運用責任が変わります。
すべてを一気に読む必要はありません。DeFiの地図を持ったうえで、交換、貸借、安定資産、取引インフラ、利回り、リスクの順に進むと理解しやすくなります。
AMM、価格インパクト、集中流動性を理解し、DEXやトークン流動性の基本を押さえます。
レンディングを利回り商品ではなく、担保、借入、清算で動くリスクエンジンとして理解します。
ステーブルコインを、価値を固定する仕組みと崩れる条件の両方から整理します。
最後に、市場で価値がどこに抜かれるか、プロトコルがどう競争するかを確認します。
記事は単独でも読めますが、領域ごとに読むと「何を理解するための記事か」が見えます。初回は気になる領域だけで十分です。
AMM、価格インパクト、集中流動性、Hooks、不変量。DEXやトークン流動性を設計する前提知識。
DEX連携や自社トークンの流動性設計で、価格インパクトとLP設計を説明できる状態を目指します。
自社トークンの流動性設計、DEX連携、大口取引時の価格影響を説明する場面。
自社で流動性を持つべきか、既存DEXに接続するだけでよいか。
Aave、Compound、Morpho、Health Factor。レンディングを「利回り」ではなくリスクエンジンとして読む。
レンディングを利回りではなく、担保率、金利、清算が連動するリスク管理システムとして理解します。
担保付き貸借、証拠金取引、利回り商品、清算リスクを説明する場面。
担保・清算ロジックを自社で持つか、既存レンディングに接続するか。
CDP、LST担保、合成ドル、アルゴリズム型の失敗。価値を固定する設計と崩れる条件を整理。
価値を固定する仕組みと、ペッグが崩れる条件を比較できる状態を目指します。
決済、担保、会計上の表示、利回り商品の基準資産を検討する場面。
自社で発行するのか、既存ステーブルコインを使うのか、担保リスクをどこまで見るのか。
funding、vAMM、GLP、orderbook、Hyperliquid API。取引所を作る・接続する・評価するための設計論。
Perps DEXを、取引画面ではなく、価格形成、清算、流動性供給、API接続の構造として理解します。
取引所連携、デリバティブ機能、マーケットデータ取得、トレーディング基盤を検討する場面。
自社で取引機能を持つか、既存Perps/APIへ接続するか、どのリスクをユーザーに見せるか。
ERC-4626、Yearn、Pendle、Flash Loan。利回り商品や自動運用を作るときの共通部品。
利回りを、魔法の収益ではなく、原資産、戦略、リスク移転の組み合わせとして分解します。
自動運用、利回り表示、ポイント施策、資産管理機能を検討する場面。
利回りの原資、戦略変更時の説明責任、損失時の責任範囲をどこまで持つか。
Flash Loan裁定、MEV、垂直統合L1。プロトコルが実市場でどう競争し、どこで価値が抜かれるか。
プロトコルが実市場でどう攻撃され、どこで価値が抜かれるかを説明できる状態を目指します。
DEX、レンディング、Perps、独自チェーンで、利用者保護や収益設計を検討する場面。
MEVや裁定を防ぐのか、受け入れるのか、プロトコル設計でどこまで制御するか。
DeFiを理解したあとに重要なのは、どのプロトコルが有名かではなく、自社がどの責任を持つのかです。実装前に次の論点を言語化してください。
「DeFiを使う」ではなく、交換、貸借、担保、決済、利回り、取引インフラのどれを自社体験に組み込むのかを明確にします。
スマートコントラクトだけでなく、流動性、清算、価格乖離、オラクル、MEV、外部プロトコル依存まで見ます。
異常時の停止、問い合わせ、再開判断、外部プロトコル障害時の説明責任を、実装前に決めます。
事業アイデアの初期段階から、プロトコル選定、PoC範囲、リスク設計、 運用体制まで、実装前に整理すべき論点を一緒に確認できます。
DeFiの設計は物理インフラ、独自チェーン、セキュリティと接続します。目的に応じて別テーマのロードマップへ移動できます。