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.
هذه الصفحة مُترجَمة آليًا بواسطة الذكاء الاصطناعي. النسخة الإنجليزية هي المرجع المعتمد.عرض النسخة الإنجليزية →
كل معاملة على Solana تحدد (بشكل صريح أو ضمني) معاملين: حد وحدات الحساب (الحد الأقصى للـ CUs التي قد تستهلكها المعاملة؛ الافتراضي هو 200,000 × عدد التعليمات حتى الحد الأقصى للمعاملة) ورسم الأولوية بالميكرو-لامبورت لكل وحدة حساب. عدم تحديد حد أدنى لأي منهما يؤدي إلى فشل المعاملات — حدود CU المنخفضة جداً تسبب
ProgramFailedToComplete؛ رسوم الأولوية المنخفضة جداً تجعل المعاملة معلقة حتى انتهاء صلاحيتها.الإعدادات الاثنان
setComputeUnitLimit(units)— يحد من الحسابات؛ تدفع المعاملة مقابلunitsCUs على الأكثر.setComputeUnitPrice(microLamports)— عرض رسم الأولوية، بالميكرو-لامبورت لكل وحدة حساب. إجمالي رسم الأولوية =units × microLamports × 1e-6لامبورت.
250_000 × 50_000 / 1e6 = 12,500 لامبورت ≈ 0.0000125 SOL ≈ $0.003 عند $200 SOL. رسوم الأولوية بهذا الحجم لا تعني شيئاً بالنسبة لمعظم تبديلات المستخدمين ولكنها مادية للبوتات التي تنفذ 1000 معاملة/يوم.
معايير CU لكل تعليمة
معايير من سجلات التنفيذ على الشبكة الرئيسية، متوسطة عبر التشغيلات الأخيرة. الأرقام تقريبية (±15%)؛ أعد القياس لتدفقاتك المحددة.| التعليمة | SPL Token | Token-2022 (بسيط) | Token-2022 (رسم التحويل) |
|---|---|---|---|
| CPMM initialize_pool | 180,000 | 200,000 | — |
| CPMM swap_base_input | 140,000 | 180,000 | 200,000 |
| CPMM swap_base_output | 150,000 | 185,000 | 205,000 |
| CPMM deposit | 130,000 | 160,000 | 180,000 |
| CPMM withdraw | 120,000 | 150,000 | 170,000 |
| CLMM create_pool | 70,000 | 85,000 | — |
| CLMM open_position_v2 | 120,000 | 140,000 | 160,000 |
| CLMM increase_liquidity_v2 | 150,000 | 175,000 | 195,000 |
| CLMM decrease_liquidity_v2 | 140,000 | 165,000 | 185,000 |
| CLMM swap_v2 (0 tick crossings) | 170,000 | 205,000 | 225,000 |
| CLMM swap_v2 (1 tick crossing) | 220,000 | 255,000 | 275,000 |
| CLMM swap_v2 (3 tick crossings) | 320,000 | 355,000 | 375,000 |
| CLMM collect_fee | 80,000 | 95,000 | 105,000 |
| AMM v4 swap_base_in | 140,000 | — | — |
| AMM v4 deposit | 120,000 | — | — |
| AMM v4 withdraw | 110,000 | — | — |
| Farm v6 create_farm | 70,000 | 85,000 | — |
| Farm v6 deposit (1 reward slot) | 130,000 | 155,000 | 175,000 |
| Farm v6 deposit (3 reward slots) | 220,000 | 255,000 | 275,000 |
| Farm v6 withdraw | يطابق deposit | ||
| Farm v6 harvest | يطابق deposit | ||
| Farm v3/v5 deposit | 100,000 | — | — |
| LaunchLab initialize | 100,000 | — | — |
| LaunchLab buy_exact_in | 140,000 | — | — |
| LaunchLab graduate | 250,000 | — | — |
المعاملات المركبة
اجمع الميزانيات الفردية وأضف:- +1,500 CU لكل CPI frame — الحد الثابت للتشغيل الزمني لكل استدعاء برنامج متقاطع.
- +20,000 CU لكل إنشاء ATA —
create_associated_token_accountليست مجانية. - +5,000 CU لـ
setComputeUnitLimit/setComputeUnitPriceلكل واحدة.
units × microLamports، لذا فإن حوالي 25% إفراط في الميزانية يكلف 25% إضافية في رسم الأولوية).
تقدير رسم الأولوية
سوق الرسوم المحلي في Solana يعني أن رسوم الأولوية هي لكل حساب قابل للكتابة. المعاملة التي تكتب إلى حساب ساخن (حالة مجموعة شعبية) تدفع أكثر من المعاملة التي تكتب إلى حساب بارد. مستوى الرسوم العام ليس المقياس الصحيح لمبادلات Raydium؛ تريد الرسوم على المجموعات المحددة التي تلمسها.الاستراتيجية 1: مُقدّر موفر RPC
كل موفر RPC رئيسي ينشر مُقدّر رسم أولوية يستعلم عن الرسوم الأخيرة على حسابات محددة:Min / Low / Medium / High / VeryHigh / UnsafeMax. اربطها بالنسب المئوية:
| المستوى | النسبة المئوية | حالة الاستخدام |
|---|---|---|
| Min | الـ 25 | حركة المرور في الخلفية، بوتات غير عاجلة |
| Low | الـ 50 | مبادلات المستخدم العادية |
| Medium | الـ 60 | الافتراضي لواجهات المحفظة |
| High | الـ 75 | المراجحة الحساسة للوقت |
| VeryHigh | الـ 95 | التصفيات، خروج الفرصة الأخيرة |
getPriorityFeeEstimate)، Triton (getRecentPrioritizationFees مع قائمة الحسابات)، QuickNode (مماثل).
الاستراتيجية 2: استعلام RPC مباشر
استخدم RPC معياريgetRecentPrioritizationFees:
الاستراتيجية 3: الضبط الذاتي التاريخي
للبوتات التي تنفذ تدفقاً ثابتاً، تتبع معدلات الهبوط مقابل انتهاء الصلاحية:التعامل مع فشل استنزاف CU
العرض: المعاملة تفشل معexceeded maximum number of instructions allowed (200000) أو ProgramFailedToComplete.
التشخيص:
- رفع حد CU. إذا كانت معاملتك تستخدم 195 ألف من ميزانية 200 ألف، ارفع إلى 300 ألف.
- قسّم المعاملة. إذا كنت تضرب الحد الأقصى البالغ 1.4M لكل معاملة، اقسم إلى معاملتين.
harvest then stakeعلى المزرعة نموذجي لتقسيمه عندما تكون المكافآت كثيرة. - قلل الحسابات. كل حساب قابل للكتابة إضافي يضيف ~2,000 CU. تقليص الحسابات غير المستخدمة يساعد في الحالات الحدية.
- استخدم جداول البحث. بحث LUT هو ~50 CU لكل عنوان معاد، مما يوفر 5,000 CU لمرجع حساب كامل لكل إدخال.
التعامل مع المعاملات المعلقة
العرض: المعاملة مقدمة، لا تتأكد أبداً، تنتهي في النهاية معBlockhashNotFound.
التشخيص:
getSignatureStatuses([sig])يعودnull→ القائد لم يرها.- يعود
{ confirmationStatus: null }→ القائد رآها لكن لم يضمنها.
- رفع رسم الأولوية. أعد الإرسال بـ 2× الرسم الحالي.
- أعد البناء مع blockhash جديد. عمر Blockhash حوالي 60 ثانية؛ بعد ذلك المعاملة غير صالحة بغض النظر عن الرسوم.
- بث متعدد الـ RPC. بعض RPCs لديها اتصالات قائدة أفضل من غيرها. أرسل إلى 3-5 بالتوازي.
- التبديل إلى Jito bundles. انظر
integration-guides/routing-and-mev. تتجاوز الحزم قوائم الانتظار العامة للحزم.
تحت الاختناق
عندما تكون الشبكة مختنقة (لوحات معلومات Jupiter / Jito bundle تظهر تراكماً، ارتفاع كمون RPC، معدلات انتهاء الصلاحية ترتفع)، اضبط:| المعامل | الظروف العادية | الظروف المختنقة |
|---|---|---|
| حد CU | +25% فوق التقدير | +25% فوق التقدير (بدون تغيير) |
| نسبة مئوية رسم الأولوية | الـ 50 | الـ 75-95 |
| عدد المحاولات | 3 | 5-7 |
| تأخير إعادة المحاولة | 500ms | 1000ms |
| استخدام Jito bundles | اختياري | موصى به بقوة |
| تحديث Blockhash عند إعادة المحاولة | نعم | نعم، إلزامي |
- النسبة المئوية الـ 75 لرسم الأولوية > 500 ألف ميكرو-لامبورت: اختناق.
- Jito النسبة المئوية الـ 50 للنصيحة > 0.001 SOL: اختناق.
- RPC p99 > 2s: مشكلة خاصة بـ RPC أو اختناق.
ميزانية الرسوم للبوتات
بوت التداول الذي ينفذ ~1000 معاملة/يوم يحتاج إلى ميزانية رسم أولوية. تقدير قريب:الأخطاء الشائعة
1. نسيان حد CU
الافتراضي هو 200 ألف CUs × (التعليمات في المعاملة). مبادلة تعليمة واحدة تفترض 200 ألف؛ هذا كافٍ لـ CPMM على SPL Token لكن ليس لـ CLMM مع tick crossings أو أي شيء Token-2022. اضبطها دائماً بصراحة.2. رسم الأولوية على الحساب الخاطئ
إذا قدرت رسم الأولوية ضد mint الرمز لكن الحساب الساخن هو حالة المجموعة، تقديرك منخفض جداً. حالة المجموعة هي حساب قابل للكتابة الصحيح لـ Raydium.3. الرسوم تتساقط مع حد CU
total_priority_fee = units × microLamports. رفع units من 200 ألف إلى 1 مليون عند 50 ألف ميكرو-لامبورت/CU يضاعف رسم الأولوية 5×. لا تفرط في ميزانية CU فقط في الحالات؛ قيس.
4. إصدار المعاملة الافتراضي
المعاملات القديمة لديها حدود حساب أقل؛ المعاملات V0 مع جداول البحث للعناوين تفتح مسارات أكبر. يستخدم SDK V0 بشكل افتراضي فيtxVersion: TxVersion.V0. لا تنزل إلى legacy إلا إذا كنت تحتاج توافق المحفظة.
5. skipPreflight يخفي أخطاء CU
skipPreflight: true يرسل المعاملة بدون محاكاة محلية. توفر ~100ms لكن تخسر ردود فعل مبكرة على استنزاف CU. استخدمه فقط على إعادة المحاولات، وليس على المحاولة الأولى.
مؤشرات
integration-guides/routing-and-mev— استراتيجيات حزمة Jito.integration-guides/aggregator— تجميع المعاملات.integration-guides/cpi-integration— تراكم CU عبر CPIs المركبة.- توثيق برنامج Solana compute budget
- Solana
getRecentPrioritizationFeesRPC - Helius priority fee API
- المعايير: سجلات التنفيذ على الشبكة الرئيسية (اختبارات تكامل Raydium SDK، أبريل 2026).


