وہ ڈویلپرز جنہوں نے STON.fi ٹوکن سویپ (swap) کو سینڈ باکس (sandbox) میں چلانے کے لیے تیار کر لیا ہے، اب انہیں خبردار کیا جا رہا ہے کہ مین نیٹ (mainnet) پر منتقلی صارفین کے فنڈز کو ختم کر سکتی ہے اگر کوڈ میں چند بظاہر بے ضرر شارٹ کٹس چھوڑ دیے جائیں۔ ایک ڈویلپر بلاگ پر جاری کردہ کمیونٹی کے ذریعے تیار کردہ چیک لسٹ ان عین نکات کی نشاندہی کرتی ہے جہاں زیادہ تر انٹیگریشنز (integrations) ناکام ہو جاتی ہیں اور پروڈکشن کے لیے تیار لانچ کے لیے ایک ٹھوس نسخہ پیش کرتی ہے۔

یہ منتقلی کیوں اہم ہے

STON.fi ایک ایسا روٹر (router) فراہم کرتا ہے جو TON بلاک چین پر متعدد DEXes پر لیکویڈیٹی (liquidity) کو یکجا کرتا ہے۔ وہ پروجیکٹس جو صارفین کو ون کلک سویپ (one-click swap) کی سہولت دینا چاہتے ہیں، عام طور پر فرنٹ اینڈ یا اسمارٹ کانٹریکٹ ریپر (smart-contract wrapper) سے روٹر کو کال کرتے ہیں۔ ٹیسٹ ماحول میں روٹر کا ایڈریس اسٹیٹک (static) ہوتا ہے، فیس کا شیڈول معلوم ہوتا ہے، اور سینڈ باکس غلط سمت میں بھیجے گئے ٹرانزیکشنز کو برداشت کر لیتا ہے۔ تاہم، مین نیٹ پر، روٹر کو اپ گریڈ کیا جا سکتا ہے، فیس کے پیرامیٹرز تبدیل ہو سکتے ہیں، اور ایک غلط ایڈریس حقیقی ٹوکنز کو کسی ایسے کانٹریکٹ پر بھیج سکتا ہے جو اب فعال نہ ہو۔ اس لیے مالیاتی خطرات ایک ہموار صارف تجربے اور اس نقصان کے درمیان فرق پیدا کرتے ہیں جو راتوں رات کسی پروجیکٹ کی ساکھ کو نقصان پہنچا سکتا ہے۔

سب سے عام غلطی: ویلیوز کو ہارڈ کوڈ (hard-coding) کرنا

ناکام لانچز میں ایک بار بار ہونے والا پیٹرن روٹر ایڈریس یا فیس کے مستقل (constants) کو ہارڈ کوڈ کرنا ہے جو ٹیسٹنگ کے دوران درست تھے۔ جب STON.fi اپنے روٹر کو اپ گریڈ کرتا ہے—جو کارکردگی کو بہتر بنانے یا بگ (bugs) کو ٹھیک کرنے کے لیے ایک معمول کا واقعہ ہے—تو ہارڈ کوڈ شدہ ایڈریس مزید کسی فعال کانٹریکٹ کی طرف اشارہ نہیں کرتا۔ اس کے نتیجے میں یا تو انٹیگریشن ایک ایسا ایرر (error) دیتی ہے جو صارفین کو کبھی نظر نہیں آتا، یا اس سے بھی بدتر، یہ خاموشی سے فنڈز کو ایسے ایڈریس پر بھیج دیتی ہے جو انہیں پراسیس نہیں کر سکتا۔ کمیونٹی گائیڈ ایک اصول پر زور دیتی ہے: STON.fi REST API کو یہ فیصلہ کرنے دیں کہ کون سا روٹر استعمال کرنا ہے۔

مرحلہ وار حفاظتی چیک لسٹ

یہ چیک لسٹ ہجرت کے عمل کو چار منطقی تہوں میں تقسیم کرتی ہے—انویئرمنٹ (environment)، کانٹریکٹ انٹریکشن (contract interaction)، فیس کیلکولیشن (fee calculation)، اور ایج کیس ہینڈلنگ (edge-case handling)۔

  • انویئرمنٹ ویری ایبلز (environment variables) کی جلد تصدیق کریں۔ ٹیسٹنگ کے دوران WebSocket اینڈ پوائنٹ اور REST API بیس URL کو سینڈ باکس پر رکھیں؛ لانچ سے پہلے انہیں مین نیٹ نوڈز (nodes) پر منتقل کر دیں۔ یہاں ایک ٹائپو (typo) حقیقی سویپ کو ٹیسٹ روٹر کی طرف موڑ سکتا ہے، جس سے ٹوکنز ہمیشہ کے لیے لاک ہو سکتے ہیں۔

  • کانٹریکٹ ایڈریسز کو کبھی ایمبیڈ (embed) نہ کریں۔ STON.fi API کے خلاف ایک سمولیشن ریکویسٹ (simulation request) چلائیں، رسپانس سے موجودہ روٹر ایڈریس حاصل کریں، اور اسے رن ٹائم پر اپنے dexFactory (یا مساوی کانٹریکٹ فیکٹری) میں فراہم کریں۔ یہ مستقبل میں ہونے والی کسی بھی روٹر اپ گریڈ کے مطابق خود بخود ڈھل جاتا ہے۔

  • فیس کا حساب فوری طور پر (on the fly) لگائیں۔ API کے کنفیگریشن پے لوڈ (configuration payload) سے فیس پیرامیٹرز حاصل کریں اور انہیں اپنے فیس میتھ (fee-math) روٹین میں استعمال کریں۔ ہارڈ کوڈ شدہ فیصد اس لمحے ہی غیر متعلقہ ہو جاتے ہیں جب پلیٹ فارم اپنی معیشت (economics) میں تبدیلی کرتا ہے۔

  • آفیشل SDK اور TonConnect کو ترجیح دیں۔ SDK آپ کے لیے BOC (Bag of Cells) اسٹرکچرز بناتا ہے اور اس میں گیس لمٹس (gas limits)، ڈیٹا انکوڈنگ، اور سگنیچر ویلیڈیشن (signature validation) کے لیے چیک شامل ہوتے ہیں۔ دستی BOC کمپائلیشن (manual BOC compilation) کو صرف ان انتہائی مخصوص استعمال کے کیسز کے لیے رکھا جانا چاہیے جنہیں SDK کور نہیں کر سکتا۔

  • فیلئور موڈ ٹیسٹنگ (failure-mode testing) کریں۔ سینڈ باکس میں آؤٹ آف گیس (out-of-gas) کے منظر نامے، ناکافی الاؤنس (insufficient allowance)، اور غلط فارمیٹ والے جوابات کی سمولیشن کریں۔ تصدیق کریں کہ آپ کا کانٹریکٹ صارف کو رقم واپس کرتا ہے یا ایک واضح ایرر ایونٹ (error event) جاری کرتا ہے۔ پروڈکشن میں ان بگ (bugs) کو دریافت کرنے کے لیے صارفین پر انحصار کرنا صارفین کے کھو جانے کا سبب بن سکتا ہے۔

  • ریفرل ودڈرال (referral withdrawal) کے راستوں کی تصدیق کریں۔ DEX کے دوسرے ورژن میں، ریفرل فیس والیٹ کے بجائے ایک مخصوص Vault کانٹریکٹ میں جاتی ہے۔ آپ کی انٹیگریشن کو ریفرر کے اکاؤنٹ میں رقم جمع کرنے سے پہلے Vault کے ودڈرال میتھڈ کو کال کرنا چاہیے اور موصول شدہ ٹوکنز کو سنبھالنا چاہیے۔

ڈویلپرز کس چیز پر بحث کر رہے ہیں

کچھ ڈویلپرز کا استدلال ہے کہ SDK غیر ضروری بوجھ (overhead) ڈالتا ہے اور ہاتھ سے تیار کردہ BOC پے لوڈ گیس کے لحاظ سے چھوٹا اور سستا ہو سکتا ہے۔ گائیڈ اس نقطہ نظر کو تسلیم کرتی ہے لیکن یہ بتاتی ہے کہ SDK روٹر ایڈریس اور فیس اسکیمہ (schema) کی اپ ڈیٹس کو بھی اکٹھا کرتا ہے، جس کا مطلب ہے کہ دستی طور پر بنائے گئے پے لوڈ کو ہر STON.fi اپ گریڈ کے بعد دوبارہ دیکھنا پڑے گا۔ اس لیے سودا گیس کی معمولی بچت اور خاموش خرابی کے خطرے کے درمیان ہے۔

آگے کیا نظر رکھنا ہے

  • روٹر اپ گریڈ کے اعلانات۔ STON.fi اپنے ڈویلپر چینل پر آنے والی روٹر کی تبدیلیوں کے بارے میں پوسٹ کرتا ہے۔ ان فیڈز کو سبسکرائب کرنے سے آپ مین نیٹ سوئچ سے پہلے سینڈ باکس میں نئے ایڈریس کا پیشگی ٹیسٹ کر سکتے ہیں۔
  • فیس پیرامیٹر کی نظرثانی۔ چونکہ مارکیٹ کے حالات کے مطابق فیس کے فیصد کو ایڈجسٹ کیا جا سکتا ہے، اس لیے کسی بھی مانیٹرنگ سروس میں کنفیگریشن اینڈ پوائنٹ کا وقتاً فوقتاً ڈیٹا حاصل کرنے کا عمل شامل کریں۔
  • SDK ورژن ریلیز۔ نئے SDK ریلیز میں اکثر مین نیٹ لانچ کے بعد دریافت ہونے والے ایج کیسز کے لیے بگ فکسز شامل ہوتے ہیں۔ SDK کو اپ ٹو ڈیٹ رکھنا اتنا ہی اہم ہے جتنا کہ روٹر ایڈریس کو اپ ڈیٹ کرنا۔

حاصلِ کلام واضح ہے: ایک ایسا swap جو "ٹیسٹنگ میں کام کرتا ہے" اس کا مطلب یہ نہیں کہ وہ خود بخود ایک محفوظ mainnet تجربہ فراہم کرے گا۔ ہر اہم ویلیو—router address سے لے کر fee schedule تک—کو لائیو STON.fi API سے حاصل کر کے، اور صارفین کے انٹرفیس دیکھنے سے پہلے ہی error paths کی سختی سے جانچ پڑتال کر کے، ڈویلپرز صارفین کے فنڈز کا تحفظ کر سکتے ہیں اور پروڈکشن کے آخری مرحلے تک پہنچتے وقت اعتماد کو برقرار رکھ سکتے ہیں۔

ماخذ: https://dev.to/web3kd/the-last-mile-taking-a-stonfi-integration-from-test-network-to-real-users-2ho0