যে সকল ডেভেলপাররা একটি স্যান্ডবক্সে (sandbox) STON.fi টোকেন সোয়াপ সফলভাবে চালাতে পেরেছেন, তাদের এখন সতর্ক করা হচ্ছে যে কোডে যদি কিছু আপাতদৃষ্টিতে ক্ষতিকর নয় এমন শর্টকাট রেখে দেওয়া হয়, তবে মেইননেটে (mainnet) যাওয়ার সময় ব্যবহারকারীর ফান্ড হারিয়ে যেতে পারে। একটি ডেভেলপার ব্লগে প্রকাশিত কমিউনিটি-প্রস্তুত একটি চেকলিস্ট সেই সুনির্দিষ্ট পয়েন্টগুলো তুলে ধরেছে যেখানে বেশিরভাগ ইন্টিগ্রেশন ব্যর্থ হয় এবং একটি প্রোডাকশন-রেডি লঞ্চের জন্য একটি সুনির্দিষ্ট নির্দেশিকা প্রদান করে।

কেন এই পরিবর্তনটি গুরুত্বপূর্ণ

STON.fi এমন একটি রাউটার প্রদান করে যা TON ব্লকচেইনের একাধিক DEX-এর লিকুইডিটি একত্রিত করে। যে প্রজেক্টগুলো ব্যবহারকারীদের ওয়ান-ক্লিক সোয়াপ সুবিধা দিতে চায়, তারা সাধারণত ফ্রন্ট-এন্ড বা একটি স্মার্ট-কন্ট্রাক্ট র‍্যাপার থেকে রাউটারটি কল করে। একটি টেস্ট এনভায়রনমেন্টে রাউটার অ্যাড্রেসটি স্ট্যাটিক থাকে, ফি শিডিউল জানা থাকে এবং স্যান্ডবক্স ভুলভাবে পরিচালিত ট্রানজ্যাকশনগুলো সহ্য করে নেয়। তবে মেইননেটে রাউটার আপগ্রেড করা যেতে পারে, ফি প্যারামিটার পরিবর্তিত হতে পারে এবং একটি ভুল অ্যাড্রেস আসল টোকেনগুলোকে একটি মৃত কন্ট্রাক্টে পাঠিয়ে দিতে পারে। তাই আর্থিক ঝুঁকির বিষয়টি একটি মসৃণ ইউজার এক্সপেরিয়েন্স এবং এমন একটি ক্ষতির মধ্যে পার্থক্য তৈরি করে যা রাতারাতি একটি প্রজেক্টের সুনাম নষ্ট করে দিতে পারে।

সবচেয়ে সাধারণ ভুল: ভ্যালু হার্ড-কোড করা

ব্যর্থ লঞ্চগুলোর একটি পুনরাবৃত্তিমূলক প্যাটার্ন হলো রাউটার অ্যাড্রেস বা ফি কনস্ট্যান্টগুলো হার্ড-কোড করা, যা শুধুমাত্র টেস্টিংয়ের সময় কার্যকর ছিল। যখন STON.fi তাদের রাউটার আপগ্রেড করে—পারফরম্যান্স উন্নত করতে বা বাগ ফিক্স করার জন্য এটি একটি রুটিন ঘটনা—তখন হার্ড-কোড করা অ্যাড্রেসটি আর কোনো কার্যকরী কন্ট্রাক্টকে নির্দেশ করে না। এর ফলে ইন্টিগ্রেশনটি হয় এমন একটি এরর (error) দেয় যা ব্যবহারকারীরা দেখতে পান না, অথবা আরও খারাপভাবে, এটি নীরবে ফান্ডগুলোকে এমন একটি অ্যাড্রেসে পাঠিয়ে দেয় যা সেগুলো প্রসেস করতে পারে না। কমিউনিটি গাইড একটি মাত্র নিয়মের ওপর জোর দেয়: কোন রাউটার ব্যবহার করতে হবে তা STON.fi REST API-কে সিদ্ধান্ত নিতে দিন।

ধাপে ধাপে নিরাপত্তা চেকলিস্ট

এই চেকলিস্টটি মাইগ্রেশন প্রক্রিয়াটিকে চারটি যৌক্তিক স্তরে বিভক্ত করেছে—এনভায়রনমেন্ট, কন্ট্রাক্ট ইন্টারঅ্যাকশন, ফি ক্যালকুলেশন এবং এজ-কেস হ্যান্ডলিং।

  • এনভায়রনমেন্ট ভেরিয়েবলগুলো দ্রুত যাচাই করুন। টেস্টিং করার সময় WebSocket এন্ডপয়েন্ট এবং REST API বেস URL-কে স্যান্ডবক্সের দিকে নির্দেশ করুন; লঞ্চ করার আগে সেগুলোকে মেইননেট নোডে পরিবর্তন করুন। এখানে একটি টাইপো (typo) আসল সোয়াপকে টেস্ট রাউটারে রিডাইরেক্ট করতে পারে, যা টোকেনগুলোকে চিরতরে আটকে ফেলবে।

  • কখনও কন্ট্রাক্ট অ্যাড্রেস এমবেড করবেন না। STON.fi API-তে একটি সিমুলেশন রিকোয়েস্ট চালান, রেসপন্স থেকে বর্তমান রাউটার অ্যাড্রেসটি সংগ্রহ করুন এবং রানটাইমে সেটি আপনার dexFactory (বা সমতুল্য কন্ট্রাক্ট-ফ্যাক্টরি)-তে প্রদান করুন। এটি স্বয়ংক্রিয়ভাবে ভবিষ্যতের যেকোনো রাউটার আপগ্রেডের সাথে মানিয়ে নেবে।

  • ফি তাৎক্ষণিকভাবে গণনা করুন। API-এর কনফিগারেশন পেলোড থেকে ফি প্যারামিটারগুলো সংগ্রহ করুন এবং আপনার ফি-ম্যাথ রুটিনে সেগুলো ব্যবহার করুন। প্ল্যাটফর্মটি তাদের ইকোনমিক্স পরিবর্তন করার সাথে সাথেই হার্ড-কোড করা পার্সেন্টেজগুলো অকেজো হয়ে যায়।

  • অফিসিয়াল SDK এবং TonConnect ব্যবহার করা শ্রেয়। SDK আপনার জন্য BOC (Bag of Cells) স্ট্রাকচার তৈরি করে এবং এতে গ্যাস লিমিট, ডেটা এনকোডিং এবং সিগনেচার ভ্যালিডেশনের জন্য চেক অন্তর্ভুক্ত থাকে। ম্যানুয়াল BOC কম্পাইলেশন শুধুমাত্র অত্যন্ত বিশেষায়িত ব্যবহারের জন্য রাখা উচিত যা SDK দিয়ে সম্পন্ন করা সম্ভব নয়।

  • ফেইলর-মোড টেস্টিং করুন। স্যান্ডবক্সে out-of-gas সিনারিও, অপর্যাপ্ত অ্যালাউন্স (insufficient allowance) এবং ত্রুটিপূর্ণ রিপ্লাই সিমুলেট করুন। আপনার কন্ট্রাক্ট ব্যবহারকারীকে রিফান্ড করছে কি না বা একটি স্পষ্ট এরর ইভেন্ট দিচ্ছে কি না তা যাচাই করুন। প্রোডাকশনে এই বাগগুলো খুঁজে বের করার জন্য ব্যবহারকারীদের ওপর নির্ভর করা মানে হলো গ্রাহক হারানোর ঝুঁকি নেওয়া।

  • রেফারেল উইথড্রয়াল পাথ নিশ্চিত করুন। DEX-এর দ্বিতীয় সংস্করণে, রেফারেল ফি কোনো ওয়ালেটের পরিবর্তে একটি ডেডিকেটেড Vault কন্ট্রাক্টে জমা হয়। আপনার ইন্টিগ্রেশনকে অবশ্যই Vault-এর উইথড্রয়াল মেথড কল করতে হবে এবং রেফারারের অ্যাকাউন্টে ক্রেডিট করার আগে প্রাপ্ত টোকেনগুলো হ্যান্ডেল করতে হবে।

ডেভেলপাররা কী নিয়ে বিতর্ক করছেন

কিছু ডেভেলপার যুক্তি দেন যে SDK অপ্রয়োজনীয় ওভারহেড যোগ করে এবং হাতে তৈরি (handcrafted) BOC পেলোড আকারে ছোট এবং গ্যাস খরচেও সাশ্রয়ী হতে পারে। গাইডটি এই মতটি স্বীকার করে কিন্তু উল্লেখ করে যে SDK রাউটার অ্যাড্রেস এবং ফি স্কিমার আপডেটগুলোকেও একসাথে যুক্ত করে, যার অর্থ হলো প্রতিটি STON.fi আপগ্রেডের পরে ম্যানুয়ালি তৈরি করা পেলোডটি পুনরায় পরীক্ষা করতে হবে। তাই মূল বিষয়টি হলো সামান্য গ্যাস সাশ্রয় এবং একটি নীরব সিস্টেম বিপর্যয়ের ঝুঁকির মধ্যে ভারসাম্য বজায় রাখা।

পরবর্তীতে যা খেয়াল রাখতে হবে

  • রাউটার আপগ্রেড সংক্রান্ত ঘোষণা। STON.fi তাদের ডেভেলপার চ্যানেলে আসন্ন রাউটার পরিবর্তনগুলো পোস্ট করে। সেই ফিডগুলোতে সাবস্ক্রাইব করলে আপনি মেইননেটে পরিবর্তনের আগেই স্যান্ডবক্সে নতুন অ্যাড্রেসটি আগেভাগেই পরীক্ষা করে নিতে পারবেন।
  • ফি প্যারামিটার সংশোধন। যেহেতু বাজারের অবস্থার সাথে তাল মেলাতে ফি পার্সেন্টেজ পরিবর্তন করা হতে পারে, তাই যেকোনো মনিটরিং সার্ভিসে কনফিগারেশন এন্ডপয়েন্ট থেকে পর্যায়ক্রমিক ডেটা সংগ্রহের ব্যবস্থা রাখুন।
  • SDK ভার্সন রিলিজ। নতুন SDK রিলিজগুলোতে প্রায়শই মেইননেট লঞ্চের পর আবিষ্কৃত এজ-কেসগুলোর জন্য বাগ ফিক্স অন্তর্ভুক্ত থাকে। রাউটার অ্যাড্রেস আপডেট করার মতোই SDK আপ-টু-ডেট রাখা গুরুত্বপূর্ণ।

মূল শিক্ষাটি স্পষ্ট: একটি সোয়াপ (swap) যা "টেস্টিংয়ে কাজ করে" তা স্বয়ংক্রিয়ভাবে একটি নিরাপদ মেইননেট (mainnet) অভিজ্ঞতায় রূপান্তরিত হয় না। রাউটার অ্যাড্রেস থেকে শুরু করে ফি শিডিউল পর্যন্ত প্রতিটি গুরুত্বপূর্ণ মান লাইভ STON.fi API থেকে গ্রহণ করার মাধ্যমে এবং ব্যবহারকারীরা ইন্টারফেস দেখার আগেই ত্রুটিপূর্ণ পথগুলো (error paths) কঠোরভাবে পরীক্ষা করার মাধ্যমে, ডেভেলপাররা প্রোডাকশনে পৌঁছানোর শেষ ধাপে ব্যবহারকারীর তহবিল রক্ষা করতে পারেন এবং আস্থা বজায় রাখতে পারেন।

উৎস: https://dev.to/web3kd/the-last-mile-taking-a-stonfi-integration-from-test-network-to-real-users-2ho0