概要
DEX との連携には、統合方法が複数あります。Uniswap の開発者ドキュメントでは、API・TypeScript SDK・オンチェーンでの直接操作という 3 つの方法が示されています。どれを選ぶかで、運用の手間・遅延・障害時の挙動が変わります。
プロトコルのバージョンも同時に走っています。最新は Uniswap v4 で、v2 と v3 も維持されています。v4 では Hooks によってプールの挙動を拡張できるため、「Uniswap に対応する」と一言で言っても、どのバージョンのどのプールを対象にするかで実装が変わります。
技術仕様
公式ドキュメントで確認した内容です。出典はページ末尾に記載しています。仕様は更新されることがあるため、実装前に一次資料をご確認ください。
- 最新バージョン
- Uniswap v4（v2 / v3 も維持）
- コントラクト
- Uniswap v4 / v3 / v2、v4 Hooks、Universal Router、Permit2、Smart Wallet、The Compact
- API・SDK
- Swapping API、TypeScript SDK（v4 / v3 / v2）、Trading API
- オンチェーンデータ
- Subgraph
- 約定方式
- UniswapX（フィラーによる約定）
- 統合方法
- API / TypeScript SDK / オンチェーン直接操作の 3 通り
受託の範囲
- 統合方法の選定（API / SDK / コントラクト直接）と、切り替え可能な抽象化
- Subgraph を用いたオンチェーンデータの取得と、社内データ基盤への取り込み
- スワップ実行時のスリッページ上限・期限（deadline）・承認（approve）の設計
- v4 Hooks を含む対象プールの選定と、バージョン差の吸収
- トランザクションの再送・置き換え（速度不足時）と、失敗時の状態復旧
実装で詰まりやすい点
実効価格を送信前に見積もる
板を持たない設計では、投入量が大きいほど実効価格が提示価格から離れます。許容できる下限を指定せずに送信すると、送信から確定までの間に他の取引でプール残高が動き、意図しない比率で約定します。
「Uniswap 対応」だけでは仕様が決まらない
v2 / v3 / v4 が並行しており、v4 では Hooks でプールの挙動が変わります。対象とするバージョンとプールを先に確定しないと、実装もテストも定まりません。
Subgraph の遅延を前提に置く
Subgraph はインデックス済みのデータを返すため、チェーンの最新状態とは差があります。残高や板の判断に使う場合は、遅延の許容量を決めたうえでオンチェーンの直接参照と使い分けます。
関連する解説記事
参照元
Crypto DEX API についてよくあるご質問
API と SDK とコントラクト直接、どれを選ぶべきですか。
要件次第です。導入の速さを優先するなら API、細かい制御が要るなら SDK、独自の実行経路や他プロトコルとの組み合わせが必要ならコントラクト直接になります。切り替えが起きうる前提で、呼び出し部分を差し替え可能にしておくのが実務的です。
複数の DEX に対応できますか。
対応します。プロトコルごとに実行経路と手数料の考え方が違うため、共通のインタフェースを定義して差異をアダプタに閉じ込めます。実効価格の見積もりと失敗時の復旧は共通化できる部分です。