> ## Documentation Index
> Fetch the complete documentation index at: https://docs.raydium.io/llms.txt
> Use this file to discover all available pages before exploring further.

# AMM v4 数学

> 定数積不変式、AMM v4 のフィー規約、リザーブからオーダーブック価格への変換、ターゲットオーダーグリッド構築、および PnL 決済ステップ。

<Info>
  **このページは AI による自動翻訳です。すべての内容は英語版を正とします。**

  [英語版を表示 →](/products/amm-v4/math)
</Info>

## 不変式

プールは `coin_reserve × pc_reserve = k` を維持します。ここで（2026-07 OpenBook 削除後）：

```
coin_reserve = coin_vault_balance - accrued_pnl_coin
pc_reserve   = pc_vault_balance   - accrued_pnl_pc
```

注目すべき点は 2 つです：

1. リザーブは現在 **ボールトのみ** です。過去のオープンオーダー項（プールが OpenBook リミットオーダーとしてエスクローしていたトークン）は削除されました。削除前からずっと実質的にはゼロでした。オンチェーンのボールト残高から直接 `k` を計算できます。
2. PnL 累積（`need_take_pnl_*`）が差し引かれるため、管理者がフィーを回収する際に曲線が保存されます。CPMM の `protocol_fees_*` 除外と同じ原理です。

プログラムはこれを `calc_total_without_take_pnl_no_orderbook` で計算します（古いオーダーブック対応バージョンは削除されました）。

すべての `Swap*` 操作は、LP のフィー分をリザーブに戻した後、`k' ≥ k` を強制します。

## フィー規約

AMM v4 は CPMM / CLMM の `1/1_000_000` 規約ではなく、**比率フィー**（分子/分母ペア）を使用します。オンチェーンの `Fees` 構造体（プログラムソースの [`Fees::initialize`](https://github.com/raydium-io/raydium-amm/blob/master/program/src/state.rs) を参照）のデフォルトは：

```
Fees {
  min_separate_numerator:    5,
  min_separate_denominator:  10_000,   //  5/10_000 = 0.05%

  trade_fee_numerator:      25,
  trade_fee_denominator:    10_000,    // 25/10_000 = 0.25% — OpenBook リミットオーダー価格設定に使用

  pnl_numerator:            12,
  pnl_denominator:          100,       // 12/100   = 12%   — スワップフィーの プロトコル分

  swap_fee_numerator:       25,
  swap_fee_denominator:     10_000,    // 25/10_000 = 0.25% — AMM パススワップの総フィー
}
```

解釈（公開メインネットデフォルト）：

* **総スワップフィー：** `swap_fee = amount_in × 25 / 10_000 = 0.25%`（総入力の）。
* **プロトコル分：** `pnl_numerator / pnl_denominator = 12 / 100 = 12%` **スワップフィーの**、つまり `0.25% × 12% = 0.03%`（ボリュームの）。この分は PnL カウンターに累積され、`WithdrawPnl` で回収されます。
* **LP 分：** スワップフィーの残り `88%`、つまり `0.25% × 88% = 0.22%`（ボリュームの）。プール内に留まり、`k` を増加させます。
* **ファンド分なし。** AMM v4 には CPMM/CLMM のファンドフィー分割がありません。

`pnl_numerator / pnl_denominator` は取引ボリュームではなく **フィーの** 分数であることに注意してください。これらのフィールド名の一般的な誤読です。

`trade_fee_numerator / trade_fee_denominator`（同じく `25 / 10_000`）は、OpenBook 統合が AMM のリミットオーダーグリッドのフィー込み価格を計算する際に歴史的に使用されていました。OpenBook コードが削除されたため、このフィールドは遺物です。アクティブなスワップフィーは `swap_fee_*` です。

これらのデフォルトからの逸脱は稀ですが、いくつかのレガシープールに存在します。見積もりを提示する前に、常に `AmmInfo.fees` からフィーを読み取ってください。

## 直接スワップ数学（AMM パス）

最も単純なケース：ユーザーが OpenBook と相互作用せずにプールのボールトに対してスワップします。プールの内部リザーブ（オンブック配置を含む）が分母です。

**SwapBaseIn（正確な入力）：**

```
amount_after_fee = amount_in − ceil(amount_in × swap_fee_numerator / swap_fee_denominator)
amount_out = amount_after_fee × out_reserve
           / (in_reserve + amount_after_fee)
require(amount_out >= minimum_amount_out)
```

ここで使用されるリザーブはボールト残高（累積 PnL を差し引いたもの）です。歴史的には、この式は AMM が OpenBook オーダーにロックしていたトークンも追加していました。**その項は削除されました** — 有効なリザーブは現在、生のボールト残高から保留中の PnL を差し引いたものに等しくなります。OpenBook 側をリフレッシュするために使用されていた `MonitorStep` / 暗黙的決済パスは削除されました。

**SwapBaseOut（正確な出力）：**

```
amount_in_after_fee = ceil(in_reserve × amount_out / (out_reserve − amount_out))
amount_in_gross     = ceil(amount_in_after_fee × swap_fee_denominator
                            / (swap_fee_denominator − swap_fee_numerator))
require(amount_in_gross <= maximum_amount_in)
```

## オーダーブック相互作用（歴史的）

<Note>
  **削除されました。** このセクションで説明されているグリッド構築は、AMM v4 が元々曲線を OpenBook マーケットにミラーリングした方法を反映しています。OpenBook 統合（`MonitorStep` クランクと `build_orders` グリッドロジックを含む）は **プログラムから削除されました**（2026-07 アップグレード）。以下の数学は、オンチェーンの `target_orders` / `amm_open_orders` アカウントがかつてサイズ設定されていた内容の歴史的文脈として保存されています。
</Note>

ユーザースワップとは別に、AMM v4 は歴史的に OpenBook マーケットに **グリッド** のリミットオーダーを配置していました。グリッドは `AmmInfo` パラメータから計算されました：

* **`depth`** — 片側あたりの価格レベル数。
* **`amount_wave`** — レベルあたりのサイズの基本単位。
* **`min_size`**、**`coin_lot_size`**、**`pc_lot_size`** — OpenBook マーケット制約。
* **`state_data.swap_acc_coin_fee`**、**`swap_acc_pc_fee`** — 最後の `TakePnl` 以降の累積フィーカウンター。

プログラムは現在の曲線価格から一定比率ステップで歩を進めることで、レベルごとの価格を導出します：

```
price_level(k) = curve_price × (1.0001 ^ k)       # 概念的に
size_level(k)  = amount_wave × f(depth, k)        # depth で段階的に減少
```

正確な価格とサイズは `build_orders` で計算された `target_orders` によって決定され、各 `MonitorStep` で `amm_open_orders` と比較されます。相違があれば、キャンセルと新規ポストが発生します。OpenBook で新たに約定したオーダーは、OpenBook 側をリフレッシュする次の操作でプールボールトに決済されます。

インテグレーターがグリッドを計算する必要はめったにありません（Raydium キーパーがそれを維持します）が、以下を知ることは有用です：

* 重要な **オンブック** リクイディティを持つプールは、そのリクイディティが `k` に貢献し、アイドル状態ではありません。
* 古い OpenBook マーケット（イベントキューが満杯、クランクがブロック）はグリッド更新を防ぎます。その後、AMM は次のクランクまで、見えるオーダーブックから逸脱した価格を引用できます。

## 決済ステップ（PnL）

0.03% プロトコル分は `state_data.need_take_pnl_coin` と `state_data.need_take_pnl_pc` に累積されます。`TakePnl` はこれらの金額をボールトから管理者指定の宛先に移動し、カウンターをゼロにします。

重要な性質：不変式のリザーブは常に **累積 PnL を差し引いて** 計算されるため、`TakePnl` は曲線を移動させません。これは CPMM 規約と一致します。

## 実例

プール状態：

* `coin_reserve = 1_000_000_000_000`（1,000,000 コイン側；6 デシマル）
* `pc_reserve   = 2_000_000_000_000`（2,000,000 pc 側；6 デシマル）
* フィー：デフォルト `swap = 25/10_000`、`pnl = 3/10_000`。

ユーザー：`SwapBaseIn` 正確入力 `1_000_000_000` コイン（1,000 コイン）。

```
swap_fee        = ceil(1_000_000_000 * 25 / 10_000)    = 2_500_000
amount_after_fee =                                      997_500_000

amount_out = amount_after_fee * pc_reserve
           / (coin_reserve + amount_after_fee)
           = 997_500_000 * 2_000_000_000_000
           / (1_000_000_000_000 + 997_500_000)
           ≈ 1_995_015_009  (1,995.015 pc)

// 2_500_000 スワップフィーのうち：
pnl_share = 2_500_000 * 3 / 25  = 300_000    (プロトコルへ need_take_pnl_coin 経由)
lp_share  = 2_500_000 * 22 / 25 = 2_200_000  (coin_reserve に留まる)

new coin_reserve = 1_000_000_000_000 + 1_000_000_000                 = 1_001_000_000_000
                   (このうち 300_000 は累積 PnL)
  curve coin_reserve = 1_001_000_000_000 − 300_000 = 1_000_999_700_000
new pc_reserve   = 2_000_000_000_000 − 1_995_015_009                 ≈ 1_998_004_984_991

k' = curve_coin_reserve * new_pc_reserve
   ≈ 2.000_002_701E24
k  = 1_000_000_000_000 * 2_000_000_000_000
   = 2.0E24
k' > k   ✓
```

LP 分（`2_200_000`）はどこにも分割されません — それは単に `k'` を上昇させる残差です。

## 精度ルール

* リザーブ乗算は `u128` を使用；最終除算はゼロ方向に丸めます。
* `swap_fee` は切り上げ（プールが過少請求しないように）。
* `SwapBaseOut` の `amount_in` は切り上げ（ユーザーが過少支払いしないように）。
* 極端なリザーブ比率を持つプールは非常に小さい入力で `ZeroTradingTokens` に当たる可能性があります。CPMM と同じ規約です。

## CPMM との制限事項

* AMM v4 のリザーブはボールトのみなので、ボールト残高（`need_take_pnl_*` を差し引いたもの）から直接見積もることが **できます** — AMM がロックしていた `open_orders.free` / `open_orders.locked` 金額を追加する以前の要件はもはや適用されません。SDK / API 見積もりが最も簡単なオプションのままです。
* AMM v4 は構造化されたオンチェーン TWAP を公開していません。AMM v4 バックアップ価格を必要とする外部コンシューマーは、トレードログから自分で計算する必要があります。
* Token-2022 はサポートされていません。

## 次のステップ

* [`products/amm-v4/instructions`](/ja/products/amm-v4/instructions) — `SwapBaseIn`、`Deposit` などがどこに組み込まれるか。
* [`products/amm-v4/fees`](/ja/products/amm-v4/fees) — 完全なフィーメカニクス、`TakePnl` の詳細。
* [`algorithms/constant-product`](/ja/algorithms/constant-product) — 共有導出。

ソース：

* [Raydium AMM プログラムソース — `raydium-io/raydium-amm`](https://github.com/raydium-io/raydium-amm)
* Raydium SDK v2 `Liquidity` モジュール