تُظهر "الضريبة المخفية" في سولانا ممارسات استنزافية في الرسوم

المؤلف: SpecialistXBT

منذ سنوات، كشفت مقالة بعنوان "Payment for Order Flow on Solana" عن جزء مظلم في سوق رسوم Solana، ما أثار اهتمامًا كبيرًا على تويتر باللغة الإنجليزية.

PFOF (الدفع مقابل تدفق الأوامر) هي نموذج تجاري ناضج منذ فترة طويلة في القطاع المالي التقليدي. شركة Robinhood استخدمت هذا النموذج لإطلاق مفهوم "التداول بدون عمولات"، مما مكنها من التفوق على شركات السمسرة القديمة. هذه الاستراتيجية لم تقتصر على تحقيق أرباح ضخمة لRobinhood، بل أجبرت عمالقة الصناعة مثل Charles Schwab وE-Trade على تقليدها، مما غير مشهد الوساطة المالية في الولايات المتحدة.

في عام 2021 وحده، جمعت Robinhood ما يقرب من مليار دولار من الإيرادات عبر PFOF، وهو ما شكل نصف إيراداتها لذلك العام. حتى في عام 2025، بقيت أرباحها الفصلية من PFOF تصل إلى مئات الملايين من الدولارات، ما يظهر مدى الربحية الكبيرة وراء هذا النموذج التجاري.

في الأسواق التقليدية، يفضل صانعو السوق بشدة أوامر المستثمرين الأفراد. السبب بسيط: أوامر الأفراد غالبًا ما تعتبر "غير سامة"، لأنها تعتمد عادة على العواطف أو الاحتياجات الفورية ولا تتضمن توقعات دقيقة للتغيرات المستقبلية في الأسعار. صانعو السوق يمكنهم الاستفادة من الفرق بين أسعار البيع والشراء دون القلق من مواجهة متداولين مطلعين (مثل المؤسسات الكبيرة).

استنادًا إلى هذا الطلب، تعمل شركات الوساطة مثل Robinhood على تجميع تدفقات أوامر المستخدمين وبيعها بالجملة إلى صانعي السوق الكبار مثل Citadel، مما يتيح لهم جني أرباح ضخمة.

في الأسواق المالية التقليدية، تعمل الجهات التنظيمية إلى حد ما على حماية المستثمرين الأفراد. على سبيل المثال، تطالب لجنة الأوراق المالية والبورصات (SEC) بموجب قوانين مثل "اللائحة الوطنية لنظام السوق" بضمان تنفيذ الأوامر المجمعة بأسعار لا تقل عن أفضل الأسعار المتوفرة في السوق.

لكن في عالم التقنية "على السلسلة" الذي يفتقر إلى التنظيم، تستغل التطبيقات عدم التوازن في المعلومات لتجعل المستخدمين يدفعون رسومًا إضافية أعلى بكثير من الحاجة الفعلية لتوصيل المعاملات، ثم يتم الاستفادة من هذه الرسوم بشكل غير شفاف. هذا السلوك في جوهره يشبه فرض "ضريبة خفية" على المستخدمين غير المحميين.

تحقيق الأرباح من حركة المرور

بالنسبة للتطبيقات التي تمتلك قواعد مستخدمين كبيرة، فإن استراتيجيات تحقيق الأرباح من حركة المرور أكثر تنوعًا مما تتصور.

التطبيقات الأمامية والمحافظ يمكنها تحديد وجهة معاملات المستخدمين، الطريقة التي تتم بها، وحتى سرعة الإرسال إلى السلسلة. في كل مرحلة من دورة حياة المعاملة، هناك فرص خفية يمكن من خلالها استغلال قيمة المستخدم إلى أقصى حد.

بيع وصول المستخدمين إلى صانعي السوق

تمامًا مثل Robinhood، يمكن لتطبيقات على Solana بيع "حق الوصول" إلى صانعي السوق.

RFQ (طلب عرض الأسعار) يعكس هذه الفكرة مباشرة. على عكس نموذج AMM التقليدي، يسمح RFQ للمستخدمين (أو التطبيقات) بالتواصل مباشرة مع صانعي السوق للحصول على الأسعار وتنفيذ الصفقات. على منصة Solana، قامت Jupiter وغيرها من التجميعات بدمج هذا النموذج (JupiterZ). في هذا النظام، يمكن للتطبيقات الأمامية فرض رسوم اتصال على صانعي السوق، أو بشكل أكثر مباشرة، تجميع أوامر الأفراد وبيعها بالجملة. مع تضييق الفروقات السعرية على السلسلة، يتوقع المؤلف أن يصبح هذا النوع من الأعمال "بيع المستخدمين" أكثر انتشارًا.

بالإضافة إلى ذلك، هناك نوع من التحالف بين DEXs والتجميعات. تعتمد AMMs ذات الملكية وصناعات DEX بشكل كبير على حركة المرور التي توفرها التجميعات، بينما يمكن للتجميعات فرض رسوم على الجهات التي توفر السيولة وإعادة توزيع جزء من الأرباح كخصومات للتطبيقات الأمامية.

على سبيل المثال، عندما يوجه محفظة Phantom معاملة المستخدم إلى Jupiter، قد يدفع مزودو السيولة الأساسيون (مثل HumidiFi أو Meteora) رسومًا إلى Jupiter للحصول على حق تنفيذ هذه المعاملة. بعد أن تتلقى Jupiter هذه الرسوم، يمكنها مشاركة جزء منها مع Phantom.

رغم أن هذه الفكرة لم تُثبت بعد علنًا، يعتقد المؤلف أنه في ظل الدوافع الربحية، فإن هذه "القواعد الخفية لتقسيم الأرباح" داخل الصناعة هي أمر طبيعي جدًا.

الأوامر السوقية المستغلة

عندما ينقر المستخدم على "تأكيد" في محفظته ويوقع على المعاملة، فإن الأمر في جوهره يصبح "أمرًا سوقيًا" مزودًا بمعلمات الانزلاق السعري (Market Order).

أما بالنسبة للتطبيقات الأمامية، فهناك طريقتان للتعامل مع هذا الأمر:

النهج الإيجابي: بيع فرص "Backrun" (المتابعة الخلفية) الناتجة عن المعاملة لشركات التداول الاحترافية وتقاسم الأرباح. Backrun يشير إلى حالة حيث يؤدي أمر شراء المستخدم في DEX1 إلى رفع أسعار الرموز فيه، ثم يقوم الروبوت بالمشاركة في نفس الكتلة بشراء الرموز من DEX2 (دون التأثير على أسعار شراء المستخدم في DEX1) ثم بيعها في DEX1 للربح.

النهج السلبي: مساعدة المتداولين الذين يستخدمون تقنية "Sandwich" (الأرباح من الهجوم الساندويشي) في استغلال المستخدم، مما يؤدي إلى رفع أسعار تنفيذ المستخدم.

حتى عند اتباع النهج الإيجابي، لا يعني ذلك أن التطبيقات الأمامية تعمل بنزاهة، حيث يمكنها عمدًا تأخير إرسال المعاملة إلى السلسلة لتعظيم قيمة "Backrun". في ظل الدافع الربحي، قد تقوم التطبيقات الأمامية أيضًا بتوجيه المستخدم إلى تجمعات سيولة ضعيفة عمدًا لخلق تقلبات سعرية أكبر ومساحة أكبر للأرباح.

وفقًا للتقارير، تعمل بعض التطبيقات الأمامية المعروفة على Solana على تنفيذ العمليات المذكورة أعلاه.

من يحصل على رسومك الإضافية؟

إذا كانت الأساليب المذكورة أعلاه تتطلب بعض المهارات التقنية، فإن التلاعب بالرسوم "الشفافة" أقل تعقيدًا بكثير.

على Solana، تنقسم الرسوم التي يدفعها المستخدمون إلى قسمين:

- رسوم الأولوية: تُعتبر رسومًا داخلية للبروتوكول وتُدفع مباشرة إلى المدققين.

- الرسوم الإضافية: وهي رسوم يتم إرسالها إلى أي عنوان SOL، وعادةً ما يتم دفعها إلى مقدمي خدمات "التنفيذ" مثل Jito. ثم يقرر مقدم الخدمة كيفية تقسيم هذه الرسوم بين المدققين وتوزيع الأرباح (Rebate) على التطبيقات الأمامية.

لماذا نحتاج إلى مزودي الخدمات التشغيلية؟ نظرًا لأن شبكة Solana تصبح معقدة للغاية أثناء الازدحام، فإن بث المعاملات العادية يمكن أن يفشل بسهولة. يلعب مزودو الخدمات التشغيلية دور "ممر VIP"، حيث يقدمون مسارات محسنة خصيصًا ويعدون المستخدمين بتحميل المعاملات بنجاح على السلسلة.

إن السوق المعقدة لبناة الكتل (Builder Market) ونظام التوجيه المجزأ لدى Solana قد ولّد هذا الدور الخاص، وخلق مساحة كبيرة للتربح على جانب التطبيقات. وغالبًا ما تحث التطبيقات المستخدمين على دفع رسوم صغيرة باهظة لضمان "النجاح"، ثم تقسم هذه الرسوم الإضافية مع مزودي الخدمات التشغيلية.

حجم تدفقات المعاملات والرسوم

لنلقِ نظرة على بعض البيانات. في الأسبوع من 1 إلى 8 ديسمبر 2025، شهدت شبكة Solana إنتاج 450 مليون معاملة.

وكان مزود الخدمة Jito مسؤولًا عن معالجة 80 مليون معاملة منها، مستحوذًا على حصة سوقية مهيمنة بنسبة 93.5% في سوق البناة. ومن بين هذه المعاملات، كانت الغالبية مرتبطة بالتبديل (Swaps)، وتحديثات الأوراكل، وعمليات صناع السوق.

داخل هذا الحوض الكبير من التدفقات، غالبًا ما يدفع المستخدمون رسومًا باهظة من أجل "السرعة". ولكن هل تُستخدم هذه الأموال حقًا للإسراع؟

ليس ذلك بالضرورة. تشير البيانات إلى أن المحافظ ذات النشاط المنخفض (عادةً الأفراد) تدفع رسومًا أولية مرتفعة للغاية. وبالنظر إلى أن الكتل لم تكن ممتلئة في ذلك الوقت، فمن الواضح أن هؤلاء المستخدمين تعرضوا لرسوم زائدة.

تستغل التطبيقات خوف المستخدمين من فشل المعاملات لإقناعهم بتعيين رسوم صغيرة مرتفعة للغاية، ثم من خلال الاتفاقيات مع مزودي الخدمات التشغيلية، تحتفظ بجزء كبير من هذه الرسوم الإضافية.

نموذج سلبي: Axiom

لإظهار هذا النموذج "الاستغلالي" بشكل أكثر وضوحًا، أجرى الكاتب دراسة حالة متعمقة على تطبيق Axiom الرائد على Solana.

يتصدر تطبيق Axiom شبكات Solana في الرسوم المتولدة من المعاملات، ليس فقط بسبب كثرة مستخدميه، ولكن أيضًا بسبب استغلاله الشديد لهم.

تشير البيانات إلى أن متوسط الرسوم الأولية (p50) التي يدفعها مستخدمو Axiom يصل إلى 1,005,000 lamports. وبالمقارنة، تدفع محافظ التداول العالي التردد حوالي 5,000 إلى 6,000 lamports فقط. الفارق هنا يصل إلى 200 ضعف.

أما بالنسبة للرسوم الصغيرة (Tips)، فإن الحالة مشابهة.

يدفع مستخدمو Axiom رسومًا صغيرة أعلى بكثير من متوسط السوق عند استخدام خدمات Nozomi وZero Slot وغيرهما من مزودي الخدمات التشغيلية. وتستغل التطبيقات الحساسية الشديدة للمستخدمين تجاه السرعة لتحقيق أرباح مزدوجة دون أي عواقب سلبية على المستخدمين.

وصّف الكاتب الأمر بجرأة قائلاً: "الغالبية العظمى من الرسوم التي يدفعها مستخدمو Axiom تعود في النهاية إلى جيوب فريق Axiom."

استعادة سلطة تحديد الرسوم

الاختلال الجوهري بين الحوافز الموجهة للمستخدمين وتلك الخاصة بالتطبيقات هو السبب الجذري للفوضى الحالية. المستخدمون لا يعرفون ما هي الرسوم المعقولة، بينما التطبيقات تفضل الحفاظ على هذه الفوضى.

لكسر هذه الحلقة، نحتاج إلى معالجة بنية السوق من الأساس. ومن المتوقع تقديم آليات جديدة مثل مقترحي التوازي المتعدد (MCP) وآلية ترتيب الأولويات (Priority Ordering) وآلية الرسوم الأساسية الديناميكية بحلول عام 2026، والتي قد تكون الحل المثالي للمشكلة.

مقترحو التوازي المتعدد (Multiple Concurrent Proposers)

النموذج الحالي لمقترح واحد في Solana يسهل تشكيل احتكارات مؤقتة، حيث يمكن للتطبيقات السيطرة على سلطة تجميع المعاملات عبر التعامل فقط مع القائد الحالي (Leader). ومع MCP، سيكون هناك العديد من المقترحين الذين يعملون بشكل متزامن في كل فتحة زمنية (Slot)، مما يزيد من تكلفة الهجمات والاحتكار، ويعزز مقاومة الرقابة، ويصعّب على التطبيقات التحكم في المستخدمين من خلال السيطرة على عقدة واحدة.

آلية ترتيب الأولويات (Priority Ordering)

عبر فرض بروتوكول لترتيب الأولويات "بناءً على الرسوم الأولية"، يتم إزالة العشوائية (Jitter) من عملية الترتيب. وهذا يقلل من حاجة المستخدمين للاعتماد على خدمات تسريع مثل Jito لضمان "النجاح". بالنسبة للمعاملات العادية، لن يكون على المستخدمين تخمين الرسوم الصغيرة المناسبة، بل يدفعون فقط داخل البروتوكول، وسيقوم جميع المدققين على الشبكة بمعالجتها وفقًا لقواعد محددة.

الرسوم الأساسية الديناميكية (Dynamic Base Fee)

هذه الخطوة الأكثر أهمية. يحاول Solana إدخال مفهوم الرسوم الأساسية الديناميكية المشابهة لإيثريوم.

لن تكون الرسوم عشوائية بعد الآن، بل سيصدر المستخدم تعليماته للبروتوكول مباشرةً: "أوافق على دفع رسوم تصل إلى X lamports كحد أقصى لهذه المعاملة."

سيقوم البروتوكول بتحديد الرسوم تلقائيًا بناءً على حالة الازدحام الحالية. إذا كانت الشبكة غير مزدحمة، يتم فرض رسوم منخفضة؛ وإذا كانت مزدحمة، يتم فرض رسوم مرتفعة. هذا النهج يعيد سلطة تحديد الرسوم من التطبيقات والوسطاء إلى خوارزميات البروتوكول الشفافة.

جلبت الميمز الازدهار إلى Solana، لكنها أيضًا تركت جذورًا للمشاكل، مما أشعل السعي القصير الأجل للربح. لتحقيق رؤية ICM الحقيقية، لا يمكن لـ Solana السماح للتطبيقات المسيطرة على التدفقات الأمامية والبروتوكولات المسيطرة على البنية التحتية بالتواطؤ أو التصرف بلا مبالاة.

كما يقول المثل: "نظف منزلك قبل أن تدعو الضيوف"، فقط من خلال ترقية بنية التكنولوجيا الأساسية، واستخدام الوسائل التقنية لإزالة أسس التربح، وتطوير بنية سوقية عادلة وشفافة تضع مصلحة المستخدمين أولًا، يمكن لـ Solana أن تمتلك الثقة الكافية للاندماج مع النظام المالي التقليدي والمنافسة فيه.