> ## 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، وتحويل الأسعار من الاحتياطيات إلى سجل الأوامر، وبناء شبكة الأوامر المستهدفة، وخطوة تسوية الأرباح والخسائر.

<Info>
  **هذه الصفحة مُترجَمة آليًا بواسطة الذكاء الاصطناعي. النسخة الإنجليزية هي المرجع المعتمد.**

  [عرض النسخة الإنجليزية →](/products/amm-v4/math)
</Info>

## الثابت

يحافظ المجمّع على `coin_reserve × pc_reserve = k`، حيث:

```
coin_reserve = coin_vault_balance
             + orders_posted_on_openbook.base
             + pending_coin_fill_not_yet_settled
pc_reserve   = pc_vault_balance
             + orders_posted_on_openbook.quote
             + pending_pc_fill_not_yet_settled
             - accrued_pnl_pc
```

هناك نقطتان مهمتان:

1. تتضمّن الاحتياطيات **الكميات المرسلة على OpenBook**. تبقى أوامر AMM المحدّدة بسعر جزءًا من سيولتها — لم تُفقَد في سجل الأوامر، بل مودعة هناك. الحساب من أرصدة الخزينة على السلسلة فقط يقلّل من تقدير الاحتياطيات.
2. استحقاق الأرباح والخسائر (`need_take_pnl_*`) يُطرح حتى يبقى المنحنى ثابتًا عندما يسحب المسؤول الرسوم. نفس المبدأ المستخدم في CPMM مع استبعاد `protocol_fees_*`.

كل عملية `Swap*` تفرض `k' ≥ k` بعد إضافة حصة رسوم مزودي السيولة مرة أخرى إلى الاحتياطيات.

## اتفاقية الرسوم

يستخدم AMM v4 **رسوم النسبة** (أزواج البسط/المقام) بدلاً من اتفاقية `1/1_000_000` الخاصة بـ CPMM / CLMM. تُعدّل بنية `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

  swap_fee_numerator:       25,
  swap_fee_denominator:     10_000,    // 25/10_000 = 0.25% — الرسم الإجمالي على تبديلات AMM
}
```

التفسير (الافتراضيات المنشورة على شبكة Mainnet):

* **إجمالي رسم الـ swap:** `swap_fee = amount_in × 25 / 10_000 = 0.25%` من المدخل الإجمالي.
* **حصة البروتوكول:** `pnl_numerator / pnl_denominator = 12 / 100 = 12%` **من رسم الـ swap**، الذي يساوي `0.25% × 12% = 0.03%` من الحجم. تتراكم هذه الحصة في عدادات الأرباح والخسائر ويسحبها `WithdrawPnl`.
* **حصة مزودي السيولة:** الـ `88%` المتبقية من رسم الـ swap، التي تساوي `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؛ يساوي `swap_fee` بشكل افتراضي لكن يُقرأ من مسار كود مختلف.

الانحرافات عن هذه الافتراضيات نادرة ولكنها موجودة على عدد قليل من المجمّعات القديمة؛ اقرأ دائمًا الرسوم من `AmmInfo.fees` قبل الاقتباس.

## رياضيات الـ swap المباشرة (مسار 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)
```

الاحتياطيات المستخدمة هنا هي الاحتياطيات **الفعلية**. تاريخيًا كانت `coin_vault_balance + coin_posted_on_openbook + ...` (خزينة AMM بالإضافة إلى الرموز المقفلة في أوامر OpenBook). **بعد إلغاء تفعيل OpenBook، يصبح الرصيد على السجل صفرًا**، لذا تساوي الاحتياطيات الفعلية أرصدة الخزينة الأولية. مسار `MonitorStep` / التسوية الضمنية الذي اعتاد تحديث جانب OpenBook لم يعد مطلوبًا عمليًا.

**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؛ المجمّعات لم تعد تُرسل أو تحافظ على أوامر في OpenBook. الرياضيات أدناه محفوظة للسياق — تشرح ما كانت حسابات `target_orders` / `amm_open_orders` على السلسلة مخصصة له ولماذا يتحقق البرنامج من معاملات `MonitorStep` ذات الصلة على الرغم من أن المحتفظ لم يعد يشغّلها.
</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)        # مخروطي حسب العمق
```

يتم تحديد الأسعار والأحجام الدقيقة بواسطة `target_orders` المحسوبة في `build_orders` ومقارنتها مع `amm_open_orders` في كل `MonitorStep`. أي اختلاف يؤدي إلى إلغاءات وإرسالات جديدة. الأوامر المملوءة حديثًا على OpenBook تتسوى في خزائن المجمّع على العملية التالية التي تحدّث جانب OpenBook.

نادرًا ما يحتاج المدمجون إلى حساب الشبكة — محتفظ Raydium يحافظ عليها — لكن من المفيد معرفة أن:

* المجمّع الذي يحتوي على سيولة كبيرة **على السجل** له تلك السيولة تساهم في `k`، وليس معطلة.
* سوق OpenBook القديم (قائمة الأحداث ممتلئة، الكرانك محظور) يمنع تحديثات الشبكة؛ يمكن لـ AMM بعد ذلك أن ينقل أسعارًا تختلف عن سجل الأوامر المرئي حتى الكرانك التالي.

## خطوة التسوية (الأرباح والخسائر)

تتراكم حصة البروتوكول بنسبة 0.03% في `state_data.need_take_pnl_coin` و`state_data.need_take_pnl_pc`. يسحب `TakePnl` هذه الكميات من الخزائن إلى الوجهة المحددة من قِبل المسؤول، ثم يصفّر العدادات.

خاصية حاسمة: تُحسب الاحتياطيات في الثابت دائمًا **ناقص** استحقاق الأرباح والخسائر، لذا `TakePnl` لا يحرّك المنحنى. هذا يطابق اتفاقية CPMM.

## مثال تطبيقي

حالة المجمّع:

* `coin_reserve = 1_000_000_000_000` (1,000,000 جانب coin؛ 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` coin (1,000 coin).

```
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)

// من رسم الـ swap البالغ 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 استحقاق أرباح وخسائر)
  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   ✓
```

حصة مزودي السيولة (`2_200_000`) لا تُفصل في أي مكان — إنها ببساطة الباقي الذي يزيد من `k'`.

## قواعد الدقة

* تستخدم مضاعفات الاحتياطيات `u128`؛ الأقسام النهائية تقرّب نحو الصفر.
* `swap_fee` تقرّب لأعلى (بحيث لا يقلّل المجمّع من الرسوم).
* `amount_in` لـ `SwapBaseOut` تقرّب لأعلى (بحيث لا يقلّل المستخدم من السداد).
* المجمّعات ذات نسب الاحتياطيات القصوى يمكنها ضرب `ZeroTradingTokens` على مدخلات صغيرة جدًا؛ نفس اتفاقية CPMM.

## القيود مقارنة بـ CPMM

* تتضمّن احتياطيات AMM v4 الجزء المودع في OpenBook، لذا لا يمكن للمدمج أن ينقل بشكل صحيح من `getTokenAccountBalance` وحدها. استرجع دائمًا الحالة الكاملة (الخزائن + `open_orders.free` + `open_orders.locked`)، أو استخدم الـ SDK / API quote.
* لا يكشف AMM v4 عن TWAP منظمة على السلسلة. المستهلكون الخارجيون الذين يريدون سعرًا مدعومًا بـ AMM-v4 يجب أن يحسبوه بأنفسهم من سجلات التداول.
* Token-2022 غير مدعوم.

## الخطوات التالية

* [`products/amm-v4/instructions`](/ar/products/amm-v4/instructions) — حيث يتصل `SwapBaseIn` و`Deposit` وغيرهما.
* [`products/amm-v4/fees`](/ar/products/amm-v4/fees) — آلية الرسوم الكاملة، تفاصيل `TakePnl`.
* [`algorithms/constant-product`](/ar/algorithms/constant-product) — الاشتقاق المشترك.

المصادر:

* [مصدر برنامج Raydium AMM — `raydium-io/raydium-amm`](https://github.com/raydium-io/raydium-amm)
* وحدة `Liquidity` من Raydium SDK v2