Request

ما هي Request؟

تعد Request بروتوكولاً مفتوح المصدر لطلبات الدفع المشفّرة وتسوية المدفوعات، يتيح للشركات أو الأفراد إنشاء طلب دفع موقَّع يشبه الفاتورة، وتخزين بيانات الطلب على بنية تحتية لامركزية، وربط المدفوعات اللاحقة على السلسلة بذلك الطلب من دون التنازل عن وصاية الأموال لمُعالج مدفوعات. لا تتمثل المشكلة الأساسية للبروتوكول في «نقل الرموز» على نحوٍ مجرّد، وهو ما تقوم به بالفعل العديد من المحافظ وبوابات الدفع، بل في إنشاء كيان محاسبي قابل للتحقق حول عملية الدفع: من الذي طلبها، وما المبلغ المستحق، وما العملة أو وحدة الحساب المستخدمة، وأين تمت التسوية، وما إذا كان بالإمكان اكتشاف الدفع وتسويته تلقائياً.

تتمثل ميزة Request العملية في تكاملها مع تدفقات العمل وليس في طبقة إجماع أساسية؛ إذ تجمع بين طلبات دفع موقَّعة، وتخزين على IPFS، وربط معرفات المحتوى (CID) على السلسلة، وأحداث مرجعية للمدفوعات، وWebhooks، وأدوات واجهات برمجة التطبيقات (API)، وتوجيه مدفوعات متعدد السلاسل، لتشكّل عنصراً أساسياً في البنية الخلفية للأنظمة المالية، كما هو موضَّح في توثيق شبكة Request ونظرة عامة على البروتوكول. docs.request.network

لا تُعد Request شبكة من الطبقة الأولى مهيمنة، ولا Rollup، ولا سوق إقراض DeFi كبير؛ بل هي طبقة تطبيقات متخصصة لمدفوعات العملات المشفّرة وأدوات المطورين، مبنية حول الفوترة المشفّرة، واكتشاف المدفوعات، وتسويتها.

حتى أواخر مايو 2026، وضع مزوّدو بيانات السوق عملة REQ ضمن فئة الرموز ذات القيمة السوقية الصغيرة إلى المتوسطة، لا ضمن الأصول المشفّرة ذات الأهمية النظامية؛ إذ أظهر موقع CoinMarketCap ترتيب Request قرب المركز 384، في حين عرض CoinGecko وDeFiLlama أرقاماً مختلفة لرأس المال السوقي بسبب تباين منهجيات احتساب المعروض المتداول وتوقيت القياس. وبالنسبة لهذا النوع من البروتوكولات، يُعد TVL مؤشراً محدود الفائدة؛ فصفحة Request Network على DeFiLlama تعرض بيانات الخزينة وسوق الرمز بدلاً من رقم TVL تقليدي لسوق إقراض أو صانع سوق آلي (AMM)، وهو ما يتسق مع دور Request كبنية تحتية للمدفوعات لا كحوض لودائع المستخدمين. وتُعد مؤشرات الحجم أكثر دلالة، مثل حجم المدفوعات والنشاط التجاري المعالَج؛ إذ يشير موقع المؤسسة إلى أكثر من 2 مليار دولار من حجم المدفوعات المعالَج وتغطية واسعة للعملات المستقرة، في حين يتتبّع لوحة متابعة نشاط Request التي يديرها المجتمع المدفوعات اليومية وحجمها، لكنها لا توفّر شريحة مستخدمين يومية/شهرية (DAU/MAU) واضحة يمكن مقارنتها بالمحافظ أو البورصات الموجّهة للمستهلكين. (coinmarketcap.com)

من أسّس Request ومتى؟

تأسست Request في عام 2017 على يد كريستوف لاسوي و إتيان تاتور، وكلاهما مرتبط بمشروع التقنيات المالية السابق MONEYTIS؛ ويصنّف Y Combinator شبكة Request كشركة لفصل شتاء 2017 مقرّها باريس، مع لاسوي مؤسساً/مديراً مالياً وتاتور مؤسساً/مديراً تقنياً. ويُعد سياق الإطلاق مهماً: ظهرت REQ خلال دورة عروض العملات الأولية (ICO) في 2017، حين حاولت العديد من المشاريع توسيع استخدامات إيثيريوم إلى ما هو أبعد من تحويلات الرموز لتشمل المحاسبة والتجارة وأتمتة الأعمال. وتُشير قواعد بيانات ICO التاريخية إلى أن بيع الرمز تم في أكتوبر 2017، مع معروض أولي يقارب مليار رمز REQ، على الرغم من أن المعروض الحالي أقل بعد عمليات الحرق وتغييرات احتساب الرموز. ويشكّل هذا «العُمْر» ميزة وعبئاً في آن واحد: فقد نجحت Request في اجتياز عدة دورات سوقية مع الحفاظ على برمجيات عاملة، لكنها تتحمّل أيضاً الإرث السمعةي المشترك بين مشاريع رموز المنفعة من حقبة 2017، التي كثيراً ما سبقت رواياتها الأولية مستوى التبنّي الفعلي على المدى القريب. (ycombinator.com)

تضيق رواية المشروع بمرور الوقت.

فبينما كان الإطار الأصلي هو شبكة مدفوعات لامركزية واسعة للفواتير وسلاسل التتبع المحاسبية والامتثال لقوانين التجارة وطلبات الدفع العالمية، بات التركيز الحالي للمنتج أكثر تشغيلية وأقل أيديولوجية، ويتمحور حول المدفوعات المشفّرة المعتمدة على واجهات برمجة التطبيقات (API)، والفوترة على السلسلة، واكتشاف المدفوعات، والتوجيه عبر السلاسل، والمدفوعات الدُفْعية، والمدفوعات المتكررة، وتسوية المدفوعات.

يتضح هذا التطور في تحديثات المؤسسة لعام 2025؛ إذ أطلقت Request واجهة API V2، والمدفوعات الجزئية، وWebhooks محسّنة، وتدفّقات عمل من التشفير إلى العملات الورقية (crypto-to-fiat)، والمدفوعات الدُفْعية، ووظائف الدفع عبر السلاسل، بدلاً من محاولة أن تصبح سلسلة كتل عامة جديدة. ومن الناحية المؤسسية، يمثّل هذا تحوّلاً من «باي بال على البلوكشين» إلى طبقة وسطية (Middleware) لفرق المالية، ومقدّمي خدمات الدفع، والشركات المشفّرة الأصل التي تحتاج إلى سجلات دفع منظَّمة عبر سلاسل متعددة. request.network

كيف تعمل شبكة Request؟

لا تمتلك Request آلية إجماع خاصة بها من نوع إثبات العمل (PoW) أو إثبات الحصّة (PoS) أو رسوم بيانية لاتوجيهية (DAG) أو مجموعة مدقّقين أو مُسلسِل معاملات أو Rollup. إنها بروتوكول هجين يعمل خارج السلسلة وداخلها؛ إذ يخزّن معظم محتوى الطلبات على IPFS، ويثبّت معرف محتوى IPFS على السلسلة، ويعالج المدفوعات عبر عقود ذكية على سلاسل التسوية المدعومة.

يشير التوثيق إلى أن الطلبات تُنشأ من خلال تخزين معرفات المحتوى (CID) على شبكة Gnosis، بينما يمكن أن تتم المدفوعات على أكثر من 20 سلسلة متوافقة مع EVM أو على NEAR؛ ثم يُحتسب رصيد الطلب عن طريق فهرسة أحداث المدفوعات على السلسلة المرتبطة بمرجع دفع مشتق. من الناحية التقنية، تُعد Request بروتوكولاً في طبقة التطبيقات وواجهة برمجة تطبيقات للمطورين ترث خصائص الاستمرارية والنهائية من الشبكات الخارجية مثل Gnosis وEthereum وBase وArbitrum وOptimism وPolygon وغيرها، بدلاً من توفير ميزانية أمان خاصة بها في طبقة الأساس. docs.request.network

الآلية المميِّزة في البروتوكول هي «مرجع الدفع». ففي النموذج الموصى به المعتمد على المرجع، يربط معرّف فريد مشتق من بيانات الطلب بين دفعة على البلوكشين والفاتورة أو طلب الدفع الأساسي؛ حيث تقوم عقود وسيطة بتحويل الأموال إلى المستلم وإطلاق أحداث تتضمّن مبلغ الدفع والمرجع، بينما تقوم Subgraphs بفهرسة هذه الأحداث لأغراض التسوية اللاحقة.

لا يستخدم النظام التجزئة (Sharding) أو Rollups بالمعرفة الصفرية (ZK-rollups) كآليات تحجيم أصلية، كما أن نموذج التحقق لديه أقرب إلى تسوية قائمة على فهرسة الأحداث مضافاً إليها بيانات طلبات موقَّعة، منه إلى التحقق من براهين Rollup التشفيرية. وتوفّر «عُقَد Request» بوابةً تربط بين IPFS والعقود الذكية وThe Graph؛ وتشغّل المؤسسة عُقَداً لتسهيل عمل المطورين، لكنها تنصح الجهات التي تبني تطبيقات إنتاجية بتشغيل عُقدتها الخاصة، وهو أمر مهم لأن الاعتماد على بوابات وواجهات برمجة تطبيقات تستضيفها المؤسسة يمثّل متجه مركزية، حتى لو كانت بيانات الطلبات والعقود الأساسية مفتوحة المصدر.

تضيف الطلبات الخاصة طبقة من التشفير غير المتماثل و AES؛ حيث تُشفَّر محتويات الطلب بمفتاح AES، ثم يُشفَّر هذا المفتاح نفسه بمفاتيح عمومية لكل طرف معني قبل تخزينه على IPFS. docs.request.network

ما هي توكنوميكس عملة REQ؟

تُعد REQ رمزاً معيارياً من نوع ERC‑20 أُطلق في الأصل بمعروض يقارب المليار وحدة، ويُفهم منحنى معروضه على أنه شبه ثابت مع آلية حرق محدودة، وليس أصل انبعاثات تضخمي. حتى أواخر مايو 2026، أدرج موقع Etherscan عقد الرمز ERC‑20 عند العنوان 0x8f8221afbb33998d8584a2b05749ba73c37a938a مع حدّ أقصى للمعروض الكلي يبلغ نحو 999.416 مليون REQ، بينما أشار CoinMarketCap إلى معروض متداول يقارب 796.7 مليون REQ، وعرض CoinGecko رقماً مختلفاً للمعروض المتداول، مما يبرز أن تعريف «المتداول» يعتمد على كيفية تصنيف الاحتياطيات والجسور والأرصدة غير النشطة.

وأفادت لوحة المتابعة المجتمعية بأنه تم حرق نحو 583 ألف REQ، وهي نسبة صغيرة من المعروض الأصلي؛ لذا فإن الأثر الانكماشي موجود لكنه غير كافٍ بمفرده ليشكّل أطروحة استثمار مركزية. (etherscan.io)

إن تراكم القيمة في REQ غير مباشر ويجب التعامل معه بحذر.

يشير التوثيق إلى عقود للرمز REQ وآلية الحرق يمكنها قفل و جسر و حرق REQ عند تخزين الطلبات، بينما تصف وثائق واجهة API رسماً بروتوكولياً قدره 5 نقاط أساس على المدفوعات المعالَجة عبر واجهة API، مع سقف يبلغ نحو 25 دولاراً أو 25 يورو بالنسبة للعملات المستقرة الرئيسية المدعومة بالدولار الأمريكي واليورو.

هذه الآليات ليست بمثابة عائد تقليدي من نوع إثبات الحصّة، ولا تُؤمَّن Request عن طريق staking لعملة REQ كما تُؤمَّن Ethereum عن طريق مدقّقي ETH. وتصف بعض المصادر الخارجية منفعة REQ من حيث مكافحة الرسائل المزعجة (Anti-spam)، والحوكمة، والـ Staking، والخصومات، والاستقلالية، غير أن التوثيق التقني الرسمي الحالي لا يعرض سوق Staking سائلاً كبيراً، أو جدول مكافآت لمدقّقين، أو برنامج انبعاثات دوري لحاملي REQ.

وبناءً عليه، فإن القراءة الأكثر تحفّظاً لتوكنوميكس REQ هي أنها رمز منفعة/حوكمة قديم الطراز نسبياً بمعروض محدود وعناصر حرق مرتبطة بالاستخدام، بينما قد يتراكم معظم أثر الاستخدام القريب المدى على مستوى طبقة المنتج وخدمات واجهات برمجة التطبيقات التي تديرها المؤسسة أكثر مما يتجه تلقائياً إلى حاملي الرمز السلبيين. docs.request.network

من يستخدم Request؟

الفارق بين التداول المضاربي لرمز REQ والمنفعة الفعلية لشبكة Request جوهري. فحجم تداول الرمز في البورصات يعكس سيولة السوق وتدوير المستثمرين، بينما يُقاس استخدام البروتوكول بصورة أفضل بعدد الطلبات المنشأة، والمدفوعات المكتشفة، وحجم المدفوعات، وتبنّي واجهات برمجة التطبيقات، ودرجة التكامل في تدفقات عمل الأقسام المالية.

وقد حوّل تحديث نظام Request البيئي في مايو 2025 تركيز التقارير عمداً من عدد المعاملات الإجمالي إلى «عدد المدفوعات»، لأن إنشاء الفواتير، والموافقة عليها، ورفضها، وغيرها من الإجراءات يمكن أن يضخّم مؤشرات المعاملات دون أن يعكس نشاط تسوية حقيقياً.

كما تعرض لوحة المتابعة المجتمعية حجم المدفوعات وعددها عبر السلاسل المدعومة، لكن هذه مؤشرات يومية متقلّبة لا ينبغي تفسيرها على أنها أعداد ثابتة للمستخدمين النشطين. قطاعياً، تتموضع Request عند تقاطع مدفوعات العملات المشفّرة، وتسوية العملات المستقرة، والفوترة، والرواتب، والمحاسبة، وإدارة الخزينة، بدلاً من مجالات سيولة DeFi أو الألعاب أو المضاربة على الـ NFT. request.network

إن أقوى دلائل التبنّي تتمثل في التكامل مع منتجات واضحة في مجالات المالية أو عمليات العملات المشفّرة، وليس في أعداد محافظ مجهولة. Request’s أصدرت تحديثات النظام البيئي لعام 2025 قائمة بالبناة النشطين، بما في ذلك Animal Social Club وintrXn و0 Finance وAllora وRequest Finance، في حين أشارت التحديثات السابقة أيضًا إلى Huma Finance وBSOS وJoba Network وغيرها من المشاركين في النظام البيئي.

في أكتوبر 2025، أعلنت Kryptos أنها قامت بدمج واجهة برمجة تطبيقات Request Network لتشغيل الفوترة داخل Kryptos Enterprise، مع توفير Request لإنشاء الفواتير، والتسوية على السلسلة، وwebhooks للأحداث، والمصالحة؛ كما أشار ذلك الإعلان إلى لقطة اعتماد خاصة بـ Kryptos ذاتها تضم أكثر من 200,000 مستخدم مسجّل، وأكثر من 50 شركة Web3 تم إلحاقها في المراحل الأولى، وآلاف عمليات الدمج مع المحافظ، ومنصات التداول المركزية (CEX)، والبروتوكولات اللامركزية (DeFi)، والشبكات. ينبغي قراءة هذه الأرقام على أنها تعكس حجم منصة الشريك أكثر من كونها تبنّيًا مباشرًا لحاملي عملة REQ، لكنها ما تزال أكثر جوهرية من شائعات الشراكات غير الموثقة. request.network

ما هي المخاطر والتحديات التي تواجه Request؟

المخاطر التنظيمية التي تواجه Request أكثر دقة من تلك التي تواجه منصات التداول أو بروتوكولات الإقراض أو خالطات الخصوصية، لكنها ليست معدومة. لم تُظهر عمليات البحث العامة ونصوص شكاوى هيئة الأوراق المالية والبورصات الأميركية المتاحة عبر نتائج البحث أن REQ ذُكرت كرمز مميز في شكاوى هيئة SEC الرئيسية ضد Coinbase أو Binance في عام 2023، ولا توجد دعوى قضائية نشطة ومعلنة على نطاق واسع تستهدف Request Network بشكل محدد حتى أواخر مايو 2026.

هذا لا يشكّل ملاذًا آمنًا تنظيميًا. فقد تم بيع REQ في حقبة عروض الطرح الأولي للعملات (ICO) عام 2017، وهي تُتداول في الأسواق الثانوية، وقد دقّق المنظّمون في الولايات المتحدة تاريخيًا في الرموز التي وُزِّعت لتمويل تطوير البروتوكولات.

كما أن نشاط المدفوعات في البروتوكول يتقاطع مع قضايا مكافحة غسل الأموال (AML)، وفحص العقوبات، وإجراءات اعرف عميلك (KYC)، وتنظيم العملات المستقرة، وتحويل الأموال، ومتطلبات الإبلاغ الضريبي، خصوصًا في الحالات التي يدعم فيها Request التسوية من العملات المشفرة إلى العملات الورقية، وفحص المحافظ، وفوترة الشركات. خطر المركزية هنا عملي أكثر منه نظري: فواجهة برمجة التطبيقات التي تديرها المؤسسة، ولوحة التحكم، وصفحة الدفع الآمنة، وعُقد Request، وبنية كشف المدفوعات قد تخلق اعتمادًا تشغيليًا حتى لو بقيت العقود البرمجية ومجموعات التطوير ونموذج البيانات مفتوحة المصدر. sec.gov

المنافسة شديدة لأن المشكلة التي يواجهها مستخدمو Request يمكن التعامل معها من عدة اتجاهات. فمعالجو الدفع التقليديون يضيفون تسويات بالعملات المستقرة؛ ومعالجو الدفع المشفّر المركزيون قادرون على تقديم الامتثال، وسياسات ردّ المبالغ (chargebacks)، ومخارج إلى العملات الورقية، ولوحات تحكم للتجار؛ ويمكن للمحافظ ومنصات التداول إضافة روابط الدفع مباشرة؛ كما يمكن لمزودي حلول المحاسبة المشفرة للمؤسسات بناء وظائف تسوية الفواتير ضمن حزمهم الخاصة. وداخل عالم Web3، يمكن لأدوات مثل Safe، والمنتجات الشبيهة بـ Coinbase Commerce، وأدوات خزانة الـ multisig، ومنصات الرواتب، ومزودي الدفع بالعملات المستقرة عند نقاط البيع، ولوحات المحاسبة على السلسلة، وواجهات برمجة التطبيقات للتوجيه عبر السلاسل أن تستوعب كلٌ منها جزءًا من مسار عمل Request.

التهديد الاقتصادي يتمثل في أن رسم Request البالغ 5 نقاط أساس وآلية حرق REQ المرتبطة به قد يتعرّضان لضغط تنافسي نحو الانخفاض إذا أصبحت عملية توجيه المدفوعات وتسويتها ميزة معيارية في واجهات برمجة التطبيقات. وتعتمد قدرة المشروع على الدفاع عن نفسه على ما إذا كان المطوّرون سيتعاملون مع كائن الفاتورة في Request، ومعيار مرجع الدفع، وأدوات المصالحة بوصفها طبقة تكامل دائمة، لا مجرد غلاف ملائم يمكن استبداله بسهولة. docs.request.network

ما هو التوقع المستقبلي لـ Request؟

يبدو أن خريطة طريق Request على المدى القريب تركز على تعميق المنتج أكثر من إعادة اختراع طبقة الإجماع. تشير وثائق موثقة لعام 2025 ومطلع 2026 إلى الانتقال إلى واجهة برمجة التطبيقات V2، ومدفوعات العملات المستقرة عبر السلاسل، والمدفوعات المجمّعة، والمدفوعات الجزئية، ومسارات العملات المشفرة إلى العملات الورقية، والمدفوعات المتكررة، وتخصيص الرسوم، وتحسين تبديل المحافظ والشبكات، وتوسيع نطاق تتبع المدفوعات، ودعم أكثر من 25 سلسلة عبر واجهة برمجة التطبيقات. وتُعد المدفوعات عبر السلاسل ذات أهمية خاصة لأنها تعالج نقطة ألم تشغيلية حقيقية: قد يحتفظ الدافعون بعملة USDT على Optimism بينما تطلب الفواتير USDC على Base، ولا ترغب فرق المالية في إدارة الجسور والمقايضات ورموز الغاز والمصالحة يدويًا.

تشير وثائق Request إلى أن المدفوعات عبر السلاسل تدعم USDC (USDC)، وUSDT (USDT)، وDAI (DAI) عبر Ethereum (ETH)، وArbitrum One (ARB)، وBase، وOP Mainnet (OP)، مع ترتيب مسارات التحويل استنادًا إلى رسوم المعاملة وسرعة المعالجة؛ وتشير صفحة المنتج العامة للمدفوعات عبر السلاسل إلى أن Request تستخدم توجيه LI.FI مع الإبقاء على منطق موحّد لاكتشاف المدفوعات وwebhooks. request.network

العائق البنيوي هو كثافة التبنّي. لا تحتاج Request إلى التفوق على Ethereum أو Visa أو Stripe أو كل معالج مدفوعات بالعملات المستقرة بصورة شاملة؛ بل تحتاج إلى ما يكفي من تطبيقات الأعمال، ومنتجات المحاسبة، ومزودي خدمات الدفع (PSPs)، والفرق المالية الأصلية للعملات المشفرة كي تتوحّد حول طبقة الطلب-والمصالحة الخاصة بها. سيناريو الهبوط هو أن تصبح مدفوعات العملات المستقرة مدمجة مباشرة في المحافظ والبنوك وواجهات برمجة تطبيقات منصات التداول، تاركة Request كأداة مطورين صغيرة مع قدرة محدودة على التقاط القيمة عبر الرمز.

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

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