تُعد عمليات المبادلة عبر السلاسل سهلة الوصف، لكنها أصعب بكثير في التنفيذ.
قد يرى المستخدم إجراءً بسيطًا فقط: اختيار توكن على سلسلة بلوكشين واحدة، واختيار توكن آخر على سلسلة بلوكشين مختلفة، ثم تأكيد العملية واستلام الأصل في الوجهة.
ومع ذلك، يتطلب ذلك من واجهة المستخدم أن تتولى سلسلتان مستقلتان تنسيق عملية تبادل دون الاعتماد على دفتر أستاذ (ledger) واحد، مع إدارة السيولة وتنفيذ المعاملة والرسوم وحالات الفشل.
في 16 يونيو 2026، أتاحت STON.fi عمليات المبادلة عبر السلاسل بين TON وEVM عبر تطبيقها (dApp). شملت الإطلاق الأولي ربط TON بكل من Ethereum وBase وBNB Chain وPolygon، مع حد مؤقت قدره 1000 دولار لكل عملية.
السؤال المهم إذاً ليس فقط ما إذا كان STON.fi قد انتقل عبر السلاسل.
هذه هي الطريقة التي تحدث بها المبادلة فعلاً.
❑ بُنيت التقنية وراء الإطلاق قبل الإطلاق
لم يكن إطلاق يونيو ميزةً معزولة.
تُظهر السيرة التطويرية الخاصة بـ STON.fi أن Omniston تطوّرت من تجميع سيولة TON إلى بنية تنفيذ أوسع.
في مايو 2026، أدخلت Omniston v1beta8 اختبارات عبر السلاسل عبر بيئة sandbox، حيث عرَضت في البداية تدفقات TON إلى عملات مستقرة على Base. فصلت البنية بين اكتشاف العروض وتنسيق التنفيذ والتسوية وتتبع التنفيذ.
يهم هذا التطور لأن Omniston صُممت أصلاً حول تجميع السيولة.
كان دورها سابقاً هو جمع السيولة من مصادر متعددة وإيجاد مسارات للتبادلات داخل TON. تضيف البنية الأحدث تسوية الأوامر، حيث يمكن للمحلّلين تنفيذ الأوامر القابلة للتنفيذ عبر السلاسل.
بعبارة أخرى، فإن إطلاق الربط عبر السلاسل يمثل توسيعاً لنظام تنفيذ قائم بدلاً من كونه منتج جسراً منفصلاً تماماً.
❑ لا تتطلب عملية تبديل عبر السلاسل بالضرورة وجود جسر
نموذج الجسر المعتاد بسيط نسبياً.
يكون أحد الأصول مقفلاً أو مؤمَّناً بطريقة ما على سلسلة المصدر. ثم يتم إتاحة تمثيل لذلك الأصل على سلسلة أخرى، غالباً كرمزٍ مُغلَّف.
تتبع Omniston نهجاً مختلفاً.
يصف STON.fi ذلك بأنه طبقة تنفيذ عبر السلاسل قائمة على «المحلِّل» باستخدام عقود الهشّ المؤقتة، أو HTLCs. يبقى أصل الوجهة محلياً لسلسلة الوجهة بدلاً من أن يتم إنشاؤه كتَعريف مُغلَّف بواسطة Omniston.
يجمع HTLC بين شرطين:
1. يجب كشف سر تشفيري قبل أن يمكن المطالبة بالأموال.
2. إذا لم يحدث ذلك خلال فترة محددة، يمكن رد الأموال بعد انتهاء صلاحية المؤقت (timelock).
في تبديل عبر السلاسل، تربط Omniston بين جوجي HTLCs اثنين.
يوجد واحد على سلسلة المصدر وواحد على سلسلة الوجهة. كلاهما يستخدم شرطاً تشفيرياً واحداً. عند إفشاء السر، يمكن أن تحدث المطالبات المقابلة على الجانبين. إذا لم يكتمل الشرط المطلوب، يوفر المؤقت مساراً للاسترداد.
هذه هي الآلية الأساسية وراء الادعاء بأن المبادلة يمكن أن تتم تسويتها بذرياً.
❑ من أين تأتي السيولة
لا يحتاج المستخدم إلى إيجاد شخص آخر مستعد لاتخاذ الجهة المقابلة من الصفقة.
بدلاً من ذلك، تستخدم Omniston نموذج RFQ.
تعني RFQ طلب عرض سعر (Request for Quote).
يطلب المستخدم سعراً لزوج أصول محدد ولَكمية معينة. يرد المحلّلون بعروض قابلة للتنفيذ. المحلِّل هو بشكل أساسي مزوّد سيولة محترف أو صانع سوق يمكنه توفير جانب الوجهة من الصفقة.
يُفوِّض/يُقرّ المحلِّل بسيولة جهة الوجهة الخاصة به.
على سبيل المثال، ضع في الاعتبار معاملة مبسطة من TON إلى Ethereum.
يُريد المستخدم تبديل USDT على TON إلى USDC على Ethereum.
يقدّم المستخدم الطلب.
يوفر المحلِّل عرضاً (quote).
يتم تأمين جهة المصدر عبر HTLC المناسبة، بينما يلتزم المحلِّل بسيولة USDC الخاصة بالوجهة من خلال HTLC مماثل على Ethereum.
الجانبان يشتركان في الشرط التشفيري نفسه.
بمجرد إفشاء السر، يمكن للمستخدم المطالبة بأصل الوجهة ويمكن للمحلِّل المطالبة بأصل المصدر.
لذلك لا يعد «المحلِّل» بمجرد تسليم أصل الوجهة لاحقاً. تتم المزامنة/السيولة الخاصة به كجزء من عملية التسوية.
❑ ماذا يحدث عندما تسوء الأمور؟
هنا تبرز أهمية بنية HTLC.
لنفترض أن المحلِّل لا ينجز جانبه من العملية.
لم تُستوفَ حالة التسوية المقصودة.
في النهاية، يسمح المؤقّت (timelock) للأموال المعنية بالعودة.
يخلق ذلك تمييزاً مهماً بين فشل التنفيذ وفقدان الأموال.
إن فشل العرض (quote) لا يعني بالضرورة أن الأموال تحركت بالفعل. إذا لم يوفّر أي محلِّل عرضاً مقبولاً، فلا يلزم أن تبدأ المبادلة (swap).
بمجرد أن يدخل الأمر في عملية التسوية، توفر آلية HTLC مسار الاسترداد (refund) الموثَّق إذا لم يُفشَ السر المطلوب خلال الفترة المسموح بها.
ومع ذلك، توجد مؤهلات تقنية مهمة.
تصف وثائق STON.fi اللاحقة أيضاً «التعبئة الجزئية» للأوامر الأكبر. يمكن تقسيم الأمر إلى صفقات فرعية مستقلة، لكل واحدة شروط تسوية خاصة بها.
لذلك يجب ألا يُفهم لفظ «ذري (atomic)» على أنه يعني أن كل أمر كبير يجب دائماً أن يُسوّى كمعاملة واحدة غير قابلة للتجزئة.
الوصف الأدق هو أن كل تنفيذ مرتبط بـ HTLC مُصمم للتسوية بشكل ذري (atomically)، بينما يمكن أن تتكون الأوامر الأكبر من عدة أجزاء يمكن تسويتها بشكل مستقل.
❑ تم تقييد الإطلاق عمداً
عند الإطلاق، كان STON.fi يدعم:
TON
Ethereum
Base
سلسلة BNB
Polygon
كان اختيار الأصل الأولي موجهاً بشدة نحو العملات المستقرة، بما في ذلك USDT و USDC، مع PUSD وUSDC على Polygon. كما قدم STON.fi حدًا مؤقتًا قدره 1,000 دولار لكل معاملة.
لا ينبغي الخلط بين ذلك والتوسع الحالي في الشبكات.
كما توثّق مواد رسمية لاحقة شبكات وأصولاً إضافية، بما في ذلك Arbitrum و Avalanche و TRON وRobinhood Chain و X Layer.
تكتسب هذه التفرقة أهمية لأن قائمة الشبكات الحالية لا ينبغي تقديمها كما لو أن كل شبكة كانت متاحة في 16 يونيو.
كان الإطلاق نقطة انطلاق.
❑ «بلا رسوم» لا يعني «بدون رسوم»
منطقة أخرى تستحق شرحاً دقيقاً هي الغاز.
تصف وثائق Omniston الخاصة بـ STON.fi تنفيذاً بلا رسوم (gasless) لتدفقات معينة على سلسلة مصدر EVM.
بدلاً من أن يقدم المستخدم معاملة السلسلة مباشرةً، يقوم المستخدم بتوقيع تفويض أو أمر. يمكن بعد ذلك للمحلِّل تقديم المعاملة ودفع تكلفة غاز البلوكشين.
يمكن أن يزيل ذلك الحاجة لأن يحتفظ مستخدم EVM برمز الغاز الأصلي للسلسلة من أجل المبادلة نفسها.
لكن هذا لا يعني أن كل جزء من العملية مجاني.
قد تتطلب موافقة الرمز (token approval) غازاً اعتماداً على المحفظة والرمز ومسار التنفيذ. كما تقول STON.fi أيضاً إن الغاز لا يزال مطلوباً عندما تكون TON هي سلسلة المصدر.
إذن العبارة الصحيحة هي:
تدعم Omniston سيناريوهات تنفيذ بلا رسوم، وليس المعاملات بلا رسوم بشكل شامل (على نحو عام).
تهم هذه التفرقة أي شخص يقيم تجربة المستخدم الفعلية.
الأمان: ماذا تمت مراجعته فعلاً؟
❑ تتطلب ادعاءات الأمان طبقةً إضافية من الحذر.
تشير وثائق أمان STON.fi إلى مراجعة Trail of Bits في يناير 2025 لنظام TON AMM DEX v2. تتناول هذه المراجعة نظام الـDEX ولا ينبغي تقديمها كمراجعة كاملة للمعمارية الحية عبر السلاسل الخاصة بـ Omniston.
تُبلغ STON.fi أيضاً عن مراجعة TonTech لعقود الضمان (escrow) الخاصة بـ Omniston التي لم تجد مشكلات حرجة. ومع ذلك، لا يتاح التقرير الكامل للجمهور وفقاً لتوثيق المشروع.
وهذا يعني أن الأدلة تدعم القول إن مكونات محددة خضعت لمراجعة أمنية.
لا يدعم ذلك القول بأن النظام الكامل عبر السلاسل قد تم إثبات أمانه بشكل مستقل.
يمثل هذا الفرق أهمية لأن عمليات التدقيق ومراجعات الأمان تقلل من عدم اليقين؛ لكنها لا تُلغيه.
❑ الأرقام لا تخبرنا بعد بمدى حجم تبني الربط عبر السلاسل
يُبلغ STON.fi حالياً على موقعه عن ما يقارب 8 مليارات دولار كحجم إجمالي على مدار الوقت، و27 مليون دولار في TVL، و6 ملايين مبادِل عبر الزمن، و37 مليون عملية مبادلة عبر الزمن.
تمنح هذه الأرقام سياقاً لبروتوكول STON.fi الأوسع.
ومع ذلك، لا ينبغي تقديمها باعتبارها إحصاءات عبر السلاسل.
لم أجد بياناتً موثَّقة بشكل مستقل تُثبت مقدار الحجم أو المستخدمين أو المعاملات التي تم توليدها تحديداً بواسطة ميزة الربط عبر السلاسل.
هذا يترك فجوة بحث مهمة.
يمكن التحقق من الإطلاق نفسه.
حجم التبني سؤال منفصل.
❑ ماذا يعني هذا بالنسبة لمستخدمي TON
التغيير العملي الفوري هو الوصول.
لا يحتاج مستخدم TON بالضرورة إلى مغادرة واجهة STON.fi للوصول إلى الأصول على شبكات EVM المدعومة.
وبالمثل، يمكن لمستخدم EVM استخدام نفس البنية لنقل الأصول القائمة على TON عندما تتوفر في المسار مسارات مُحلِّل مدعومة.
بالنسبة للمطوّرين، قد تكون الأهمية أوسع.
لا تُوصف Omniston بأنها بنية تحتية حصرية لواجهة STON.fi. تقول STON.fi إن البروتوكول مصمم للتكامل عبر واجهات SDK وAPI، بما يتيح للمحافظ والتجميعات والبورصات وتطبيقات DeFi الأخرى البناء فوقه.
وهذا يعني أن السؤال طويل الأجل ليس فقط عدد السلاسل التي تظهر داخل تطبيق STON.fi.
هل يمكن أن تصبح عمليات التنفيذ المعتمدة على المحلِّلين بنية تحتية قابلة لإعادة الاستخدام لتطبيقات أخرى؟
❑ ما الذي تُثبتُه الأدلة، وما الذي لا يزال بلا إجابة
تُثبت الأدلة أن STON.fi أطلق تبديلات مباشرة عبر السلاسل TON × EVM في يونيو 2026.
كما يحدد ذلك البنية الموثَّقة: اكتشاف العروض عبر RFQ، وسيولة يوفّرها المحلِّل، وتسوية HTLC مترابطة.
ما لا يزال غير واضح هو الأمر نفسه الذي يُعد مهماً:
لا توجد مجموعة بيانات مُتحقق منها بشكل مستقل ضمن المصادر التي تمت مراجعتها تُظهر الحجم الإجمالي أو المستخدمين الفريدين أو تركّز المحلّلين أو معدل الفشل لميزة الربط عبر السلاسل.
يتطلب الوضع الحالي لحد معاملة 1,000 دولار الأصلي أيضاً الحذر، لأن مواد الإطلاق والمواد اللاحقة تشير إلى الحد، بينما لا تثبت الوثائق الحالية بشكل واضح تاريخ إزالة نهائي.
هذه الفجوات لا تُبطل التكنولوجيا.
فهي ببساطة تحدد ما يمكن وما لا يمكن المطالبة به بشكل مسؤول اليوم.
القصة الأكبر
لذلك فإن إطلاق STON.fi عبر السلاسل أقل ما يكون حول إضافة «زر جسر» إلى DEX وأكثر حول تغيير طبقة التنفيذ تحت المبادلة.
تجمع البنية الموثّقة بين RFQ لاكتشاف السيولة، وحلّالين لسيولة الوجهة، وHTLCs للتسوية المشروطة.
تتجنب هذه المقاربة الحاجة لأن تقوم Omniston نفسها بإصدار تمثيل مُغلَّف لأصل الوجهة.
ما إذا كانت هذه البنية يمكن أن تتوسع إلى سيولة أعمق وأحجام معاملات أكبر وتبنٍّ أوسع، سؤال تجريبي ستجيب عنه بيانات الاستخدام المستقبلية.
حتى الآن، فإن أقوى استنتاج هو أضيق:
تبديلات TON × EVM تعمل حالياً، والآلية موثَّقة، والبنية تختلف بشكل جوهري عن جسر تقليدي للأصول المُغلَّفة. يبقى السؤال: مدى أداء هذه البنية على نطاق واسع.
❑ مرجع
الموقع الرسمي websitel لـ STON.fi
https://reference-url-citation.invalid/15
إطلاق STON.fi عبر السلاسل
إعلان
https://reference-url-citation.invalid/16
شرح Omniston: تبديلات عبر السلاسل و HTLCs
https://reference-url-citation.invalid/17
Omniston v1beta8 وطبقة تنفيذ عبر السلاسل
https://reference-url-citation.invalid/18
نموذج التنفيذ بلا رسوم لدى Omniston
https://reference-url-citation.invalid/19
توثيق محلّل Omniston
https://reference-url-citation.invalid/20
وثائق مطوري STON.fi
https://reference-url-citation.invalid/21
الحساب الرسمي X لـ STON.fi
https://reference-url-citation.invalid/22
برنامج سفير STON.fi
https://reference-url-citation.invalid/23
دليل STONbassador
https://reference-url-citation.invalid/24
مصادر البحث ومصادر الأمان
مراجعة أمن Trail of Bits، مراجعة أمن STON.fi TON AMM DEX v2.
مراجعة TonTech لعقود ضمان Omniston.
المراقبة الأمنية من CertiK لـ STON.fi.
معلومات منحة اكتشاف الثغرات HackenProof.