slippage-modeling について
Solana DEXの執行コストを見積もり、AMMの仕組みや実際の見積もりからスリッページをモデル化するスキルです。トレーダーが取引サイズを制限し、損益分岐コストを評価するための資料とスクリプトを備えています。
主な機能
- 01AMM・CLMMのスリッページモデル化
- 02Jupiterの見積もりによる曲線フィッティング
- 03総執行コストと損益分岐点の推定
- 04スリッページ上限に基づく最大取引サイズの計算
- 05分割取引とTWAPの計画
活用シーン
- 01取引サイズごとのスリッページ評価
- 02損益分岐分析への取引コストの反映
- 03大口注文の分割計画
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ agiprolabs/ claude-trading-skills --skill slippage-modelingインストール後、Claude Code で/slippage-modelingを入力して読み込まれたか確認します。
同梱ファイル
SKILL.md と一緒にインストールされる参考資料やスクリプト。
references/cost_model.mdslippage_math.mdscripts/execution_cost.pyslippage_curve.py詳細
スリッページのモデリング
実行コストを推定し、AMM の仕組みと実測された見積もりからスリッページ曲線をモデル化して、コストを許容範囲内に抑える最適な取引サイズを特定します。
スリッページとは?
スリッページとは、取引を決めた時点での予想価格と、実際に受け取る約定価格との差です。分散型取引所では、スリッページは決定論的で測定可能です。隠れた注文板の動向に左右される CEX のスリッページとは異なります。
例:トークンを 0.001 SOL で購入できると予想していたとします。取引は 0.00105 SOL で約定します。この 5%の差がスリッページです。利益を直接減らし、損益分岐点を引き上げます。
スリッページの原因
1. AMM の価格インパクト(主な原因)
自動マーケットメーカーは、流動性が消費されるにつれて価格が変動するボンディングカーブを使用します。定積 AMM(x * y = k)の場合:
price_impact = Δx / (x + Δx)
ここで、x は入力トークンの準備金、Δx は取引サイズです。準備金が 100 SOL のプールで 1 SOL の取引を行うと、約 1%の価格インパクトが発生します。準備金が 10 SOL の場合、約 10%になります。
詳細な導出と CLMM の調整については、references/slippage_math.md を参照してください。
2. DEX 手数料
スワップごとに、取引から差し引かれる手数料が発生します。
| DEX | 手数料 | 備考 |
|---|---|---|
| Raydium | 0.25% | 標準的な AMM プール |
| Orca | 0.30% | Whirlpool の集中流動性プール |
| Meteora | 0.1–2.0% | ボラティリティに応じた動的手数料 |
| PumpFun | 1.0% | ボンディングカーブのフェーズ |
3. 優先手数料
Solana のバリデーターは、コンピュートユニット価格の高いトランザクションを優先します。ネットワークが混雑している場合や、時間に制約のある取引では、次のようになります。
- 通常:0.0001 SOL(無視できる程度)
- 競争的な水準:0.001–0.01 SOL
- 混雑が激しい場合:0.01–0.1 SOL
4. MEV(サンドイッチ攻撃)
サーチャーは保留中のスワップを検知し、サンドイッチ攻撃を仕掛けます。あなたの取引前に購入して価格を引き上げ、取引後に売却して差額を得ます。MEV コストは次の要因によって変わります。
- 取引サイズ(大きいほど、狙われやすくなります)
- トークンの流動性(流動性の低いプールほど、操作しやすくなります)
- スリッページ許容度の設定(許容度が高いほど、抽出できる額が増えます)
脆弱な取引での一般的な MEV コスト:0–200 bps。
5. 古い見積もり
見積もりを受け取ってからトランザクションがオンチェーンに記録されるまでの間(Solana では 0.4–2 秒)に、価格が変動する可能性があります。ボラティリティの高いトークンは、この間に 50–500 bps 変動することがあります。
定積スリッページの計算式
準備金 (x, y) と不変量 k = x * y を持つプールの場合:
SOL でトークンを購入する(入力 Δx SOL):
tokens_received = y * Δx / (x + Δx)
effective_price = Δx / tokens_received = (x + Δx) / y
spot_price = x / y
price_impact = effective_price / spot_price - 1 = Δx / (x + Δx)
トークンを SOL に売却する(入力 Δy トークン):
sol_received = x * Δy / (y + Δy)
effective_price = sol_received / Δy = x / (y + Δy)
spot_price = x / y
price_impact = 1 - effective_price / spot_price = Δy / (y + Δy)
重要なポイント:スリッページは trade_size / (reserves + trade_size) に応じて増加します。小規模な取引ではほぼ線形ですが、取引サイズが準備金に近づくにつれて急激に増加します。
クイックリファレンス表
| 取引 / 準備金比率 | スリッページの概算 |
|---|---|
| 0.1% | 0.1% (1 bp) |
| 1% | 1.0% (100 bps) |
| 5% | 4.8% (476 bps) |
| 10% | 9.1% (909 bps) |
| 25% | 20% (2000 bps) |
| 50% | 33% (3333 bps) |
CLMM のスリッページ
集中流動性マーケットメーカー(Orca Whirlpools、Meteora DLMM)は、特定の価格帯に流動性を集中させます。
- 有効な価格帯内:集中係数に応じて、定積方式よりスリッページが低くなります
- ティック境界をまたぐ場合:次のティックの流動性が乏しいと、追加のスリッページが発生します
- 概算:
clmm_slippage ≈ cp_slippage / concentration_factor
適切に管理されたポジションでの一般的な集中係数:5–50x。
実測スリッページの測定
理論式は単一プールでのルーティングを前提としています。実際には、Jupiter は複数のプールやルートを集約します。実測による測定のほうが正確です。
- 複数の取引サイズ(0.01、0.1、1、5、10、50 SOL)で Jupiter
/quoteに問い合わせます - 各サイズで出力額と実効価格を記録します
- 最小の取引サイズ(現物価格の代用)を基準に、スリッページを bps で計算します
- べき乗則モデルを当てはめます:
slippage_bps = a * trade_size^b
これにより、実際のルーティング動作、複数プールへの分割、利用可能な流動性を捉えられます。
実装の全容については、scripts/slippage_curve.py を参照してください。
総執行コストモデル
total_cost_bps = price_impact_bps + fee_bps + priority_fee_bps + mev_risk_bps
total_cost_sol = trade_size_sol * total_cost_bps / 10_000
各要素の内訳と計算例については、references/cost_model.md を参照してください。
損益分岐分析
往復取引(買いと売り)の場合:
roundtrip_cost_bps = entry_impact + exit_impact + 2 * fee_bps + 2 * priority_bps + mev_bps
利益を得るには、トークン価格が有利な方向に roundtrip_cost_bps を超えて動く必要があります。エントリー時のスリッページが 200 bps、エグジット時のスリッページが 200 bps、手数料が 50 bps のトークンの場合:
roundtrip = 200 + 200 + 50 = 450 bps = 4.5%
損益分岐に達するだけでも、少なくとも 4.5% の価格変動が必要です。
自動的なコスト推定については、scripts/execution_cost.py を参照してください。
最適な取引サイズ
スリッページのしきい値に対する最大サイズ
スリッページ曲線 s(q) = a * q^b をもとに、最大取引サイズを求めます:
q_max = (threshold_bps / a) ^ (1/b)
複数トランシェでの執行
大口注文を分割すると、各トランシェが部分的にリセットされた注文板(CLMM の場合)に対して執行されるため、またはトランシェ間に裁定取引者がリバランスできるため、合計スリッページを抑えられます。
n_tranches = ceil(total_size / q_max)
tranche_size = total_size / n_tranches
wait_between = 2-10 seconds (allow arb rebalancing)
TWAP 戦略
時間加重平均価格での執行:
- 注文全体を同じサイズのトランシェに分割します
- 一定間隔(例:10 秒ごと)でトランシェを 1 つずつ執行します
- 合計スリッページは、一度に執行する場合より大幅に低くなります
- トレードオフ:執行中に価格が不利な方向へ動く可能性があります
トークンカテゴリ別のスリッページ
| カテゴリ | プールの通常 TVL | 1 SOL のスリッページ | 10 SOL のスリッページ |
|---|---|---|---|
| 優良銘柄 | >$10M | <5 bps | <20 bps |
| 中型銘柄 | $100K–$10M | 10–50 bps | 50–500 bps |
| 小型銘柄 | $10K–$100K | 50–200 bps | 500–2000 bps |
| マイクロ銘柄/PumpFun | <$10K | 200–2000 bps | 多くの場合、執行不可 |
連携ポイント
- liquidity-analysis:プールの TVL とリザーブデータを取得し、スリッページ推定に利用します
- position-sizing:スリッページ曲線から求めた最大取引サイズを、ポジションサイズの制約として使用します
- jupiter-api:実測スリッページの測定に使用する実際の見積もりを取得します
- risk-management:リスク/リワードの計算に執行コストを含めます
- dex-pool-analysis:スリッページの要因となるプールの仕組みを理解します
ファイル
リファレンス
| ファイル | 説明 |
|---|---|
references/slippage_math.md | AMM のスリッページ導出、CLMM の調整、複数プールのルーティング計算 |
references/cost_model.md | 総執行コストの要素、損益分岐分析、コスト比較表 |
スクリプト
| ファイル | 説明 |
|---|---|
scripts/slippage_curve.py | Jupiter の見積もりから実測スリッページ曲線を作成し、べき乗則モデルを当てはめます |
scripts/execution_cost.py | 特定の取引について、総執行コストと損益分岐点を推定します |