مبادلة عبر السلاسل من TON إلى Polygon: كيف تعمل

محفظتك المليئة بـ USDT موجودة على TON، لكن الدفع مطلوب على Polygon — فهناك الغاز رخيص، وهناك نُشِر عقد DeFi الخاص بك، وهناك يستقبل المستلِم أمواله. المسار المعتاد: السحب إلى منصة تداول، وانتظار الإيداع، ثم البيع، ثم الشراء، ثم السحب من جديد إلى Polygon. أربع خطوات، وأربع عمولات، وتحقّق من الهوية (KYC)، وثقة كاملة بوسيط يحتفظ بأموالك طوال تلك الدقائق. بالنسبة إلى الإنسان هذا مزعج فحسب. أما بالنسبة إلى وكيل ذكاء اصطناعي يُفترض أن ينجز ذلك باستقلالية، فالمسار غير صالح أصلًا: الوكيل لا يجتاز إجراءات KYC، ولا ينبغي أن يحتفظ بالمفتاح الخاص لحساب على منصة تداول.

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

لماذا المبادلة من TON إلى Polygon، وما دور TONNode

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

• دفع مستحقات طرف مقابل لا يستقبل الأموال إلا على Polygon؛
• تعزيز مركزك في بروتوكول منشور على Polygon بينما رصيدك على TON؛
• منح وكيل الذكاء الاصطناعي القدرة على نقل القيمة بين الشبكات بنفسه بناءً على أمرك — لكن دون أي وصول إلى مفاتيحك.

TONNode هو خادم MCP مُستضاف لشبكة TON (الموقع: tonnode.io). وMCP (Model Context Protocol) هو المعيار الذي يستدعي عبره وكلاء الذكاء الاصطناعي — Claude وCursor وChatGPT/Codex وأي عميل MCP — أدوات خارجية. فبدلًا من تعليم الوكيل نقاط REST الطرفية والتوقيع نيابةً عنه على المعاملات، تمنحه مجموعة من 16 أداة خاصة بـ TON، ويقرّر هو بنفسه أيّها يستدعي. خمس من هذه الأدوات الـ16 مخصّصة للعمل عبر السلاسل — وهي بالضبط ما ينقل القيمة خارج TON، بصورة غير احتجازية، ودون تخزين أي مفاتيح على الخادم.

قيد مهم في آلية العمل: في TONNode تكون TON دائمًا هي المصدر. المسار يخرج من TON إلى الخارج؛ وPolygon هنا شبكة وجهة لا نقطة انطلاق.

تفصيل يخصّ المصطلحات: GRAM هو Toncoin بعد إعادة تسميته (تمّت إعادة التسمية في يونيو 2026)، أما الشبكة نفسها فما زالت تُسمّى TON. وفي بقية النص، GRAM = العملة الأصلية لشبكة TON.

كيف تعمل المبادلة عبر السلاسل من TON إلى Polygon: ضمان HTLC الذرّي

مشكلة أي تبادل بين شبكتين أنهما لا تريان بعضهما. لا يوجد حَكَم مشترك يضمن أنك إن دفعت أموالك على TON فستستلمها على Polygon. والحل الكلاسيكي هو ضمان HTLC الذرّي (hashed timelock contract). والتشبيه المناسب: خزنة بقفلين ومؤقّت.

ويقوم ذلك على عنصرين أساسيين — قفل التجزئة وقفل الوقت:

1. السر وتجزئته. يُولَّد سرّ عشوائي S، وتُحسب منه التجزئة H = hash(S). وتقفل عقود الضمان على الشبكتين الأموالَ «تحت التجزئة» H.
2. قفل التجزئة. لا يستطيع فكّ الأموال من الضمان إلا من يقدّم S الذي ينتج عنه H نفسه. وما دام السر غير مكشوف، تبقى الأموال مقفلة على الجانبين.
3. قفل الوقت. لكل ضمان موعد نهائي. فإن لم يُكشف السر قبله، تعود الأموال متاحة للمُرسِل — وهذا تأمين ضد التعليق.

وجوهر الفكرة أن كشف السر على إحدى الشبكتين يتيح رياضيًا سحب الأموال على الأخرى: فما إن يظهر S على السلسلة حتى يستخدمه الطرف المقابل لإتمام نصفه من الصفقة. ومن هنا تأتي الذرّية: إما أن تتم الصفقة كاملة على الشبكتين، وإما ألّا تتم في أي منهما وتعود الأموال. أما الحالة الوسطى «خرجت الأموال من TON ولم تصل إلى Polygon» فلا وجود لها بحكم التصميم.

ينسّق TONNode هذا البروتوكول عبر خمس أدوات، لكن — وهذا جوهري — السر يُسلَّم إليك ولا يبقى على الخادم، وجميع معاملات TON توقّعها أنت بمحفظتك.

أدوات العمل عبر السلاسل الخمس: من عرض السعر إلى التسوية

الأدوات الخمس متاحة على أي خطة. وفيما يلي المسار الكامل ووظيفة كل أداة فيه.

1. get_crosschain_quote — عرض السعر

كم ستستلم على Polygon مقابل المبلغ المُرسَل من TON. يستدعيها الوكيل أولًا ليعرض السعر والمسار قبل توقيع أي شيء. وتعيد معطيات الصفقة التي تُبنى عليها المعاملة لاحقًا.

2. build_crosschain_swap_tx — معاملة ضمان HTLC غير موقّعة

تجمّع معاملة غير موقّعة تقفل أموالك في الضمان على جانب TON، وتعيد السر. والمعاملة بصيغة رسالة TonConnect؛ توقّعها محفظتك أنت لا الخادم. أما السر فتحتفظ به لديك — ستحتاجه في مرحلة التسوية.

3. track_crosschain_swap — مراحل الصفقة على الشبكتين

تُظهر المرحلة التي بلغتها الصفقة: هل قُفل الضمان على TON، وهل انعقد الضمان المقابل على Polygon، وهل صار كل شيء جاهزًا للتسوية. إنها «لوحة مراقبتك» للشبكتين معًا.

4. disclose_crosschain_secret — كشف السر لإتمام التسوية

تكشف السر لإتمام التسوية — لكن بعد أن يؤكّد فحصٌ على السلسلة جاهزية الطرفين فقط. والترتيب هنا حاسم: لا يجوز كشف السر قبل أن ينعقد الضمان المقابل فعليًا على Polygon. تتحقّق الأداة من حالة الشبكتين، وعندها فقط تسلّم السر للكشف.

5. build_crosschain_refund — استرداد الأموال من الضمان

تجمّع معاملة استرداد غير موقّعة إذا تعلّقت الصفقة وسمح قفل الوقت باستعادة المبلغ المقفول. وسنعود إلى هذا السيناريو بعد قليل.

وهكذا يبدو الأمر في محادثة مع الوكيل:

بادِل 250 USDT من TON إلى USDC على Polygon.
أظهر لي عرض السعر أولًا، ثم جمّع المعاملة،
ودعني أوقّعها بمحفظتي، وتابع الحالة،
ولا تكشف السر إلا حين يجهز طرفا الضمان معًا.

المسار الكامل خلف الكواليس:

1. get_crosschain_quote       → السعر والمسار من TON إلى Polygon
2. build_crosschain_swap_tx   → ضمان HTLC غير موقّع + السر S
   (يوقّع المستخدم في محفظته عبر TonConnect)
3. track_crosschain_swap      → ننتظر جاهزية الشبكتين
4. disclose_crosschain_secret → كشف S بعد التحقق على السلسلة → التسوية
5. build_crosschain_refund    → فقط إذا حدث خلل

المنطق هو نفسه المتّبع في المبادلة من TON إلى Ethereum — لا يتغيّر سوى شبكة الوجهة.

لماذا هذا غير احتجازي: الخادم لا يوقّع ولا يحتفظ بالمفاتيح

هنا يمرّ الخط الفاصل الأهم. فعدم الاحتجاز ليس كلمة تسويقية بل خاصية معمارية. أدوات العمل عبر السلاسل في TONNode غير احتجازية بصرامة: الخادم لا يوقّع أبدًا ولا يحتفظ أبدًا بأموالك ولا بمفاتيحك الخاصة. فهو يعيد رسائل TonConnect غير موقّعة، والتوقيع تضعه محفظتك أنت.

لنأخذ build_crosschain_swap_tx مثالًا. تسلّمك الأداة مسوّدة المعاملة والسر — لكنها لا تنفّذ أي تحويل. ولن يتحرّك شيء قبل أن تؤكّد ذلك في محفظتك. والمفتاح الخاص لا يغادر المحفظة ولا يمرّ عبر الخادم بأي صورة. والأمر نفسه ينطبق على سرّ HTLC: يُسلَّم إليك، ولذلك فحتى التسوية تديرها أنت لا مشغّل الخادم.

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

وحديث منفصل عن @ton/mcp الرسمي من TON Foundation. إنه أداة قوية ورسمية، لكن بنيته مختلفة: فهو محفظة-وكيل احتجازية (نظام split-key — مفتاح operator لدى الوكيل، ومفتاح owner لدى المستخدم)، يوقّع بنفسه ولا يدعم العمل عبر السلاسل (TON فقط). وله مزاياه الخاصة — الإنفاق المستقل، والتعامل مع NFT وDNS، والصفة الرسمية من TON Foundation. والفرق صريح: ذاك احتجازي وعلى TON وحدها؛ وTONNode غير احتجازي، مع دعم العمل عبر السلاسل وخيار الاستضافة. المقارنة المفصّلة على صفحة المقارنة مع الرسمي.

القائمة الكاملة للشبكات المدعومة (ولماذا لا وجود لـ TRON بعد)

تجري المبادلة عبر السلاسل في TONNode من TON إلى إحدى شبكات الوجهة التالية:

• Ethereum
• Arbitrum
• Base
• BNB Chain
• Polygon
• Avalanche

في كل الحالات تكون TON هي المصدر، والشبكة المذكورة هي الوجهة. أما TRON فغير مدعومة بعد. فضمان HTLC الذرّي يشترط وجود آلية متوافقة لعقد hashed-timelock على جانب الوجهة، مدمَجة في مسار الصفقة. والشبكات الست المذكورة تنتمي إلى العائلة المتوافقة مع EVM، وتستطيع TON بناء ضمان مقابل فيها. أما TRON فلم تُدرَج في هذا المسار بعد — لا لأن ذلك «مستحيل من حيث المبدأ»، بل لأن تكامل هذه الشبكة تحديدًا غير موجود في المنتج حاليًا. فلا تبنِ خططك على TRON قبل أن تظهر في القائمة رسميًا.

منطق Polygon لا يختلف في شيء عن مسار Ethereum؛ وإن أردت نظرة عامة، فهناك تحليل أول MCP ينقل القيمة عبر السلاسل انطلاقًا من TON.

ماذا تفعل إذا تعلّقت الصفقة: الاسترداد من الضمان

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

لكل عقد ضمان قفل وقت. فإذا لم تكتمل الصفقة وانقضت المدة، فالأموال لا «تحترق» ولا تبقى لدى الخادم — بل تعود إليك. ولن تكون قد كشفت السر في هذه الأثناء (وهذا هو الصواب — إذ لن تسلّمه disclose_crosschain_secret قبل أن تتأكد جاهزية الطرفين على السلسلة).

أما الاسترداد نفسه فتنفّذه build_crosschain_refund: تجمّع معاملة غير موقّعة توقّعها أنت بمحفظتك، فتعود الأموال المقفلة إلى عنوانك على TON. والخادم هنا أيضًا لا يوقّع شيئًا ولا يحتفظ بشيء.

تعلّقت المبادلة إلى Polygon ولم تتم التسوية.
أعِد لي أموالي من الضمان.

يستدعي الوكيل track_crosschain_swap ليتأكد من أن التسوية لم تتم وأن قفل الوقت يسمح بالاسترداد، ثم يستدعي build_crosschain_refund — وتوقّع أنت. وأسوأ نهاية لصفقة متعلّقة هنا هي أن تستعيد مالك، لا أن تخسره.

كيف تربطه وتجرّبه: إعداد MCP والمفتاح المجاني

يمكنك البدء مجانًا ومحليًا. حزمة @tonnode/mcp مفتوحة المصدر (رخصة MIT)، ومتاحة على npm وGitHub (tonnode/mcp)، وتعمل عبر بروتوكول ADNL الأصلي لشبكة TON دون طبقات HTTP وسيطة.

مجانًا ومحليًا. مجموعة أدوات القراءة كاملة بإعداد عام، دون مفتاح:

{
  "mcpServers": {
    "ton": {
      "command": "npx",
      "args": ["-y", "@tonnode/mcp"]
    }
  }
}

وسيشغّل عميل MCP الخادم بنفسه عبر npx.

النقطة الطرفية المُستضافة — حين تحتاج إلى سعة تمرير مضمونة ومفتاح خاص بك:

{
  "mcpServers": {
    "ton": {
      "type": "http",
      "url": "https://mcp.tonnode.io/mcp",
      "headers": { "Authorization": "Bearer tn_live_…" }
    }
  }
}

الأدوات الـ16 كلها متاحة على جميع الخطط — أنت تدفع مقابل سعة التمرير فقط، لا مقابل الوصول إلى الوظائف:

• Hobby — مجانية إلى الأبد، 60 طلبًا/دقيقة؛
• Pro — 29 دولارًا/شهر، 300 طلب/دقيقة؛
• Scale — 199 دولارًا/شهر، 1200 طلب/دقيقة.

ويُصدَر مفتاح Hobby المجاني فور تسجيل الدخول، دون بطاقة بنكية. أما الخطط المدفوعة فتُسدَّد بـ GRAM أو USDT على شبكة TON عبر TonConnect، أو بـ BTC/ETH/SOL وعملات أخرى عبر فاتورة xRocket في Telegram.

وملاحظتان صريحتان حتى لا تكون التوقعات مبالغًا فيها: عمق السجل الأرشيفي ما زال ضمن خارطة الطريق (العقدة قيد المزامنة)، ولا توجد في TONNode حاليًا أدوات لـ NFT وDNS، كما لا توجد webhooks ولا مُرحِّل gasless ولا ضمانات مكتوبة لزمن التشغيل. ومنتج العمل عبر السلاسل هو بالضبط تلك الأدوات الخمس الموصوفة أعلاه، وهي تنقل القيمة فعليًا من TON إلى Polygon بصورة غير احتجازية.

---

جرّب العمل عبر السلاسل بنفسك. احصل على مفتاح Hobby المجاني وجمّع أول مبادلة TON → Polygon بوكيلك: tonnode.io/dashboard?plan=hobby. وإن أردت أولًا استعراض مجموعة الأدوات الـ16 كاملة، فزُر صفحة الأدوات.