जिन डेवलपर्स ने sandbox में STON.fi टोकन स्वैप को सफलतापूर्वक चला लिया है, उन्हें अब चेतावनी दी जा रही है कि यदि कोड में कुछ मामूली दिखने वाले शॉर्टकट छोड़ दिए गए, तो mainnet पर जाने से यूजर्स के फंड खत्म हो सकते हैं। एक डेवलपर ब्लॉग पर जारी की गई कम्युनिटी-लिखित चेकलिस्ट उन सटीक बिंदुओं को रेखांकित करती है जहाँ अधिकांश इंटीग्रेशन विफल हो जाते हैं और प्रोडक्शन-रेडी लॉन्च के लिए एक ठोस समाधान प्रदान करती है।

यह ट्रांज़िशन क्यों महत्वपूर्ण है

STON.fi एक राउटर प्रदान करता है जो TON ब्लॉकचेन पर कई DEXes में लिक्विडिटी को एकत्रित (aggregate) करता है। जो प्रोजेक्ट्स यूजर्स को वन-क्लिक स्वैप की सुविधा देना चाहते हैं, वे आमतौर पर फ्रंट-एंड या स्मार्ट-कॉन्ट्रैक्ट रैपर से राउटर को कॉल करते हैं। टेस्ट एनवायरनमेंट में राउटर एड्रेस स्टैटिक होता है, फीस शेड्यूल ज्ञात होता है, और sandbox गलत दिशा में भेजे गए ट्रांजेक्शन को सहन कर लेता है। हालाँकि, mainnet पर राउटर को अपग्रेड किया जा सकता है, फीस पैरामीटर्स बदल सकते हैं, और एक गलत एड्रेस वास्तविक टोकन को किसी डेड कॉन्ट्रैक्ट में भेज सकता है। इसलिए, वित्तीय जोखिम एक सुचारू यूजर एक्सपीरियंस और ऐसे नुकसान के बीच का अंतर है जो रातों-रात किसी प्रोजेक्ट की प्रतिष्ठा को नुकसान पहुँचा सकता है।

सबसे आम गलती: वैल्यूज़ को हार्ड-कोड करना

विफल लॉन्च में एक बार-बार होने वाला पैटर्न राउटर एड्रेस या फीस कांस्टेंट्स (constants) को हार्ड-कोड करना है, जो टेस्टिंग के दौरान मान्य थे। जब STON.fi अपने राउटर को अपग्रेड करता है—जो प्रदर्शन सुधारने या बग्स को ठीक करने के लिए एक नियमित प्रक्रिया है—तो हार्ड-कोडेड एड्रेस अब किसी कार्यात्मक कॉन्ट्रैक्ट की ओर इशारा नहीं करता है। इसके परिणामस्वरूप इंटीग्रेशन या तो ऐसा एरर देता है जिसे यूजर्स कभी देख नहीं पाते, या इससे भी बुरा, यह चुपचाप फंड को ऐसे एड्रेस पर भेज देता है जो उन्हें प्रोसेस नहीं कर सकता। कम्युनिटी गाइड एक ही नियम पर जोर देती है: STON.fi REST API को यह तय करने दें कि किस राउटर का उपयोग करना है।

स्टेप-बाय-स्टेप सुरक्षा चेकलिस्ट

यह चेकलिस्ट माइग्रेशन प्रक्रिया को चार तार्किक परतों में विभाजित करती है—एनवायरनमेंट, कॉन्ट्रैक्ट इंटरेक्शन, फीस कैलकुलेशन, और एज-केस हैंडलिंग।

  • एनवायरनमेंट वेरिएबल्स को जल्दी वैलिडेट करें। टेस्टिंग के दौरान WebSocket एंडपॉइंट और REST API बेस URL को sandbox पर सेट करें; लॉन्च से पहले उन्हें mainnet नोड्स पर स्विच करें। यहाँ एक टाइपो (typo) वास्तविक स्वैप को टेस्ट राउटर पर रीडायरेक्ट कर सकता है, जिससे टोकन हमेशा के लिए लॉक हो सकते हैं।

  • कॉन्ट्रैक्ट एड्रेस को कभी भी एम्बेड न करें। STON.fi API के विरुद्ध एक सिमुलेशन रिक्वेस्ट चलाएं, रिस्पॉन्स से वर्तमान राउटर एड्रेस प्राप्त करें, और उसे रनटाइम पर अपने dexFactory (या समकक्ष कॉन्ट्रैक्ट-फ़ैक्टरी) में फीड करें। यह भविष्य के किसी भी राउटर अपग्रेड के अनुसार स्वचालित रूप से ढल जाता है।

  • फीस की गणना ऑन-द-फ्लाई (on the fly) करें। API के कॉन्फ़िगरेशन पेलोड से फीस पैरामीटर्स प्राप्त करें और उन्हें अपने फीस-मैथ रूटीन में उपयोग करें। जैसे ही प्लेटफॉर्म अपनी इकोनॉमिक्स में बदलाव करता है, हार्ड-कोडेड प्रतिशत अप्रचलित हो जाते हैं।

  • आधिकारिक SDK और TonConnect को प्राथमिकता दें। SDK आपके लिए BOC (Bag of Cells) स्ट्रक्चर बनाता है और इसमें गैस लिमिट, डेटा एनकोडिंग और सिग्नेचर वैलिडेशन के लिए चेक शामिल होते हैं। मैन्युअल BOC कंपाइलेशन को केवल उन अत्यधिक विशिष्ट उपयोगों के लिए आरक्षित रखा जाना चाहिए जिन्हें SDK कवर नहीं कर सकता है।

  • फेलियर-मोड टेस्टिंग (failure-mode testing) करें। sandbox में out-of-gas परिदृश्यों, अपर्याप्त अलाउंस (insufficient allowance), और खराब रिप्लाई (malformed replies) का अनुकरण (simulate) करें। सत्यापित करें कि आपका कॉन्ट्रैक्ट यूजर को रिफंड करता है या एक स्पष्ट एरर इवेंट जारी करता है। प्रोडक्शन में इन बग्स को खोजने के लिए यूजर्स पर निर्भर रहना यूजर रिटेंशन को कम कर सकता है।

  • रेफरल विड्रॉल पाथ की पुष्टि करें। DEX के दूसरे संस्करण में, रेफरल फीस वॉलेट के बजाय एक समर्पित Vault कॉन्ट्रैक्ट में जाती है। आपके इंटीग्रेशन को रेफरर के खाते में क्रेडिट करने से पहले Vault के विड्रॉल मेथड को कॉल करना चाहिए और प्राप्त टोकन को संभालना चाहिए।

डेवलपर्स के बीच क्या बहस हो रही है

कुछ डेवलपर्स का तर्क है कि SDK अनावश्यक ओवरहेड जोड़ता है और हाथ से बनाया गया (handcrafted) BOC पेलोड छोटा और गैस में सस्ता हो सकता है। गाइड इस विचार को स्वीकार करती है लेकिन बताती है कि SDK राउटर एड्रेस और फीस स्कीमा के अपडेट को भी एक साथ लाता है, जिसका अर्थ है कि मैन्युअल रूप से बनाए गए पेलोड को हर STON.fi अपग्रेड के बाद फिर से देखना होगा। इसलिए, यह ट्रेड-ऑफ मामूली गैस बचत और साइलेंट ब्रेकएज (silent breakage) के जोखिम के बीच है।

आगे क्या ध्यान रखें

  • राउटर अपग्रेड घोषणाएं। STON.fi अपने डेवलपर चैनल पर आगामी राउटर परिवर्तनों को पोस्ट करता है। उन फीड्स को सब्सक्राइब करने से आप mainnet स्विच से पहले sandbox में नए एड्रेस का पहले से परीक्षण कर सकते हैं।
  • फीस-पैरामीटर संशोधन। चूंकि बाजार की स्थितियों के अनुसार फीस प्रतिशत को समायोजित किया जा सकता है, इसलिए किसी भी मॉनिटरिंग सर्विस में कॉन्फ़िगरेशन एंडपॉइंट का समय-समय पर डेटा प्राप्त करने (periodic pull) की सुविधा शामिल करें।
  • SDK वर्जन रिलीज़। नए SDK रिलीज़ में अक्सर mainnet लॉन्च के बाद खोजे गए एज-केस के लिए बग फिक्स शामिल होते हैं। SDK को अपडेट रखना उतना ही महत्वपूर्ण है जितना कि राउटर एड्रेस को अपडेट करना।

निष्कर्ष स्पष्ट है: एक स्वैप जो "टेस्टिंग में काम करता है", वह स्वचालित रूप से एक सुरक्षित मेननेट अनुभव में परिवर्तित नहीं हो जाता है। लाइव STON.fi API से हर महत्वपूर्ण वैल्यू—राउटर एड्रेस से लेकर फीस शेड्यूल तक—प्राप्त करके, और उपयोगकर्ताओं के इंटरफ़ेस देखने से पहले एरर पाथ्स (error paths) का कड़ाई से परीक्षण करके, डेवलपर्स उपयोगकर्ता की धनराशि की रक्षा कर सकते हैं और प्रोडक्शन के अंतिम चरण में पहुँचते समय विश्वास बनाए रख सकते हैं।

स्रोत: https://dev.to/web3kd/the-last-mile-taking-a-stonfi-integration-from-test-network-to-real-users-2ho0