নেটওয়ার্ক নিরাপত্তা
TRC20, BEP20 নাকি ERC20: নেটওয়ার্ক বাছাই
TRC20, BEP20 ও ERC20-এর ঠিকানা, ফি ও গ্রহণকারী প্ল্যাটফর্ম মিলিয়ে নিরাপদ নেটওয়ার্ক বাছাইয়ের ব্যাখ্যা।
সর্বশেষ হালনাগাদ: 2026-08-11
ক্লায়েন্ট বললেন, “USDT পাঠাব—নেটওয়ার্ক কোনটি?” এই ছোট প্রশ্নের উত্তর শুধু TRC20, BEP20 বা ERC20-এর একটি নাম বলে দেওয়া নয়। সঠিক উত্তর পেতে চারটি জিনিস একসঙ্গে মিলতে হবে: যে সম্পদ পাঠানো হবে, পাঠানোর নেটওয়ার্ক, গ্রহণকারী সেবা সেই নেটওয়ার্কে জমা নেয় কি না, আর দেখানো ঠিকানাটি সেই জমার নির্দেশনারই কি না। একটি জিনিসও অস্পষ্ট থাকলে পেমেন্ট থামিয়ে আবার নিশ্চিত করাই বুদ্ধিমানের কাজ।
USDT একই নামের টোকেন হলেও একাধিক ব্লকচেইনে চলতে পারে। নেটওয়ার্ক বদলালে লেনদেনের পথ, ফি দেওয়ার সম্পদ, লেনদেন শনাক্ত করার স্থান এবং জমা শনাক্ত করার নিয়মও বদলে যায়। তাই “USDT তো USDT-ই” ধরে কোনো ঠিকানায় পাঠানো নিরাপদ যুক্তি নয়। এই লেখার লক্ষ্য কোনো নেটওয়ার্ককে সবার জন্য সেরা বলা নয়; বরং ক্লায়েন্ট ও ফ্রিল্যান্সার যেন একই সম্পদ, একই নেটওয়ার্ক এবং একই ঠিকানায় সম্মত হতে পারেন, সেই সিদ্ধান্তপদ্ধতি তৈরি করা।
এই লেখায় কোন প্রশ্নগুলোর উত্তর আছে?
- সম্পদ ও নেটওয়ার্কের পার্থক্য কী?
- ERC20, TRC20 ও BEP20 নামগুলো আসলে কী বোঝায়?
- Tether-এর সরকারি তথ্য থেকে কোন দাবি করা যায়, আর কোনটি যায় না?
- একই রকম ঠিকানা দেখালেও কেন নেটওয়ার্ক নিশ্চিত করতে হয়?
- পাঠানোর আগে ক্লায়েন্ট ও প্রাপক কী কী লিখিতভাবে মিলবেন?
- ফি কীভাবে তৈরি হয়, এবং কেন স্থির অঙ্ক ধরে নেওয়া ঠিক নয়?
- ছোট পরীক্ষামূলক পেমেন্ট (test payment) কখন সহায়ক, আর কখন উল্টো খরচ ও ভুল বাড়ায়?
- লেনদেনের পরে হ্যাশ ও ব্লকচেইন রেকর্ড কীভাবে পড়তে হয়?
- ভুল বা অস্পষ্টতা দেখা দিলে কোথায় থামতে হবে?
এক বাক্যে নিরাপদ সিদ্ধান্ত কী?
প্রাপক যে প্ল্যাটফর্ম বা ওয়ালেটে USDT নেবেন, তার বর্তমান জমা পাতায় দেখানো সম্পদ, নেটওয়ার্ক ও ঠিকানা হুবহু মিলিয়ে তারপরই ক্লায়েন্টকে পেমেন্ট নির্দেশনা দিন। পুরোনো স্ক্রিনশট, আগের ক্লায়েন্টের ঠিকানা, মেসেজে অনুমান করে লেখা নেটওয়ার্কের নাম বা শুধু ঠিকানার চেহারা—কোনোটিই বর্তমান জমা পাতার বিকল্প নয়।
এই নিয়মে “কম ফি” প্রথম সিদ্ধান্ত নয়। গ্রহণকারী সেবার সমর্থনই প্রথম দরজা। সেই দরজা পেরোনোর পরে পাঠানোর সেবায় একই নেটওয়ার্ক আছে কি না দেখতে হবে। তারপর ফি, গতি, পরীক্ষামূলক পেমেন্ট ও রেকর্ড রাখার সুবিধা তুলনা করা যায়। যে নেটওয়ার্ক দুই প্রান্তে একই নামে পাওয়া যাচ্ছে না, তার ফি কম হলেও সেটি এই পেমেন্টের বিকল্প নয়।
সম্পদ আর নেটওয়ার্ক কি একই জিনিস?
না। সম্পদ হলো আপনি কী পাঠাচ্ছেন; নেটওয়ার্ক হলো সেটি কোন ব্লকচেইন পথ দিয়ে যাচ্ছে। USDT সম্পদের নাম। Ethereum, TRON ও BNB Smart Chain আলাদা নেটওয়ার্কের নাম। ERC20, TRC20 ও BEP20 নামগুলো সাধারণত সংশ্লিষ্ট নেটওয়ার্কে টোকেনের মান বা জমার পথ বোঝাতে ব্যবহৃত হয়।
একটি সহজ তুলনা হলো টাকা ও ব্যাংকিং চ্যানেল। টাকার অঙ্ক একই থাকতে পারে, কিন্তু কোন ব্যাংক, কোন হিসাব এবং কোন চ্যানেলে পাঠানো হচ্ছে তা ভুল হলে প্রাপক স্বাভাবিকভাবে অর্থ দেখতে নাও পারেন। ব্লকচেইনে একই “USDT” লেবেল দেখেও নেটওয়ার্ক আলাদা হলে অনুরূপ সমস্যা হতে পারে। পার্থক্যটি আরও কঠিন, কারণ ব্লকচেইন লেনদেন নিশ্চিত হওয়ার পরে সাধারণত প্রেরক নিজে সেটি বাতিল করতে পারেন না।
Tether-এর USDT পরিচিতি বলছে, টোকেনটি একাধিক ব্লকচেইনে পরিবাহিত হয় এবং Ethereum-এ USDT একটি ERC20 টোকেন। এই তথ্য থেকে দুটি কাজের সিদ্ধান্ত আসে। এক, USDT নাম দেখাই যথেষ্ট নয়। দুই, যে ব্লকচেইন সংস্করণ গ্রহণ করা হবে সেটি আলাদাভাবে বলতে হবে। কিন্তু এই তথ্য কোনো নির্দিষ্ট এক্সচেঞ্জ, কাস্টডিয়াল অ্যাকাউন্ট বা ওয়ালেট আজ কোন নেটওয়ার্কে জমা নিচ্ছে—সেটি প্রমাণ করে না। সেই উত্তর গ্রহণকারী সেবার বর্তমান জমা পাতায় আছে।
একটি পেমেন্ট নির্দেশনায় কোন চারটি পরিচয় থাকবে?
একটি সম্পূর্ণ নির্দেশনা অন্তত এই চারটি পরিচয় আলাদা লাইনে রাখে:
- সম্পদ: USDT
- নেটওয়ার্ক: প্রাপকের জমা পাতায় যে সঠিক নাম দেখায়, যেমন Ethereum (ERC20) বা TRON (TRC20)
- জমা ঠিকানা: বর্তমান জমা পাতা থেকে কপি করা পূর্ণ ঠিকানা
- Memo বা tag: জমা পাতায় চাইলে হুবহু; না চাইলে নিজের থেকে কিছু যোগ নয়
এর সঙ্গে অঙ্ক, কে নেটওয়ার্ক ফি বহন করবেন এবং পাঠানোর আগে পুনরায় নিশ্চিত করার সময় লিখলে বিরোধ কমে। “USDT ঠিকানা” নামে শুধু একটি অক্ষরমালা পাঠালে ক্লায়েন্টকে অনুমান করতে হয়। অনুমানই এখানে সবচেয়ে ব্যয়বহুল দুর্বলতা।
কোন তথ্য সম্পদ–নেটওয়ার্ক যাচাইয়ের বিকল্প নয়?
স্ক্রিনশটে USDT লেখা, ঠিকানার প্রথম কয়েক অক্ষর, আগেরবার একই পথে টাকা আসা, সামাজিক মাধ্যমে কারও পরামর্শ, বা “সাধারণত এই নেটওয়ার্ক সস্তা”—এগুলোর কোনোটিই বর্তমান সমর্থনের প্রমাণ নয়। প্ল্যাটফর্ম রক্ষণাবেক্ষণ, অঞ্চল, অ্যাকাউন্টের অবস্থা বা টোকেন সমর্থনের কারণে জমার বিকল্প বদলাতে পারে। পাঠানোর মুহূর্তে দুই পক্ষকে নিজেদের স্ক্রিনে একই সম্পদ ও একই নেটওয়ার্ক দেখতে হবে।
Tether-এর সরকারি তালিকা থেকে ঠিক কী জানা যায়?
Tether-এর সমর্থিত প্রোটোকলের তালিকা থেকে Ethereum/ERC20 ও TRON/TRC20 সম্পর্কে সরাসরি প্রোটোকল তথ্য পাওয়া যায়; এই লেখায় BEP20-কে Tether-এর তালিকাভুক্ত নেটওয়ার্ক সংস্করণ বলা হচ্ছে না। Tether-এর সমর্থিত প্রোটোকল পাতা বিভিন্ন ব্লকচেইনে USDT-র প্রোটোকল আলাদা করে দেখায় এবং সমর্থিত প্রোটোকল স্পষ্ট করার গুরুত্ব বোঝায়। সেখানে Ethereum/ERC20 ও TRON/TRC20-এর তথ্য এই তুলনার ভিত্তি।
BEP20 নামে কোনো USDT জমার বিকল্প যদি কোনো গ্রহণকারী প্ল্যাটফর্মে দেখা যায়, সেই নির্দিষ্ট বিকল্পের সত্যতা ও শর্ত ওই প্ল্যাটফর্মের বর্তমান জমা পাতাতেই যাচাই করতে হবে। “BEP20” লেখা দেখেই এটিকে Tether-এর তালিকাভুক্ত নেটওয়ার্ক সংস্করণ ধরে নেওয়া যাবে না। প্ল্যাটফর্মটি কোন টোকেন কনট্র্যাক্ট গ্রহণ করছে, জমা চালু আছে কি না, ন্যূনতম জমা বা নিশ্চিতকরণের শর্ত কী—এসবও একই পর্দায় দেখতে হবে। তথ্য অনুপস্থিত হলে সেখানে থামুন; অন্য নেটওয়ার্ক অনুমান করবেন না।
কেন এই সীমা এত গুরুত্বপূর্ণ?
একটি টোকেনের নাম, ইস্যুকারীর তালিকাভুক্ত নেটওয়ার্ক সংস্করণ এবং কোনো প্ল্যাটফর্মে একই প্রতীকে দেখানো জমার পথ—তিনটি আলাদা দাবি। এগুলো এক করে লিখলে ব্যবহারকারী মনে করতে পারেন সব জায়গায় একই সমর্থন আছে। অথচ প্ল্যাটফর্মভেদে সম্পদের তালিকা, টোকেন কনট্র্যাক্ট ও জমার ব্যবস্থা আলাদা হতে পারে। নির্দিষ্ট দাবির নির্দিষ্ট প্রমাণ রাখা তাই শুধু লেখার সততা নয়, পেমেন্ট নিরাপত্তার অংশ।
এই নিবন্ধে BEP20 নিয়ে আলোচনা হচ্ছে কারণ ব্যবহারকারীর জমা বা উত্তোলন পর্দায় নামটি দেখা যেতে পারে এবং ভুল নেটওয়ার্কের ঝুঁকি বোঝা দরকার। আলোচনা মানেই অনুমোদন, উপলভ্যতা বা Tether-এর তালিকাভুক্ত নেটওয়ার্ক সংস্করণ নিশ্চিত করা নয়। সিদ্ধান্তের ভাষা হবে: “আমার গ্রহণকারী প্ল্যাটফর্মের বর্তমান USDT জমা পাতায় BNB Smart Chain (BEP20) দেখা যাচ্ছে”—শুধু সত্য হলে। “USDT সবখানে BEP20-এ চলে”—এমন বাক্য গ্রহণযোগ্য নয়।
ERC20 বলতে কী বোঝায়?
ERC20 হলো Ethereum-এ সমজাতীয় টোকেনের বহুল ব্যবহৃত মান; USDT-এর Ethereum সংস্করণ এই পথে স্থানান্তর হতে পারে। Ethereum অ্যাকাউন্টে টোকেন ধারণ ও পাঠানো যায়। Ethereum অ্যাকাউন্টবিষয়ক নথি বাহ্যিকভাবে নিয়ন্ত্রিত অ্যাকাউন্টের ঠিকানাকে 0x দিয়ে শুরু হওয়া ৪২ অক্ষরের রূপে ব্যাখ্যা করে। এই রূপ চিনতে পারা একটি প্রাথমিক পরীক্ষা, চূড়ান্ত নেটওয়ার্ক প্রমাণ নয়।
Ethereum-এর লেনদেনে প্রেরক, প্রাপক, স্বাক্ষর, মূল্য বা ইনপুট তথ্য এবং gas-সম্পর্কিত ক্ষেত্র থাকে। জমা পাঠালে সাধারণত টোকেন কনট্র্যাক্টের একটি কল হয়; ব্যবহারকারীর চোখে এটি “USDT স্থানান্তর” হলেও নেটওয়ার্কে gas লাগে। Ethereum transactions নথি লেনদেন জমা পড়ার পরে লেনদেনের হ্যাশ তৈরি হওয়া এবং প্রাথমিক ক্ষেত্রগুলো বোঝায়। এই হ্যাশ পরে লেনদেনের অবস্থা, ঠিকানা ও ব্লক রেকর্ডের সঙ্গে মিলানোর চাবি।
ERC20 ঠিকানা দেখে কী জানা যায়?
0x দিয়ে শুরু এবং মোট ৪২ অক্ষর হওয়া Ethereum ঠিকানার সরকারি বর্ণনার সঙ্গে মেলে। এতে অসম্পূর্ণ কপি বা দৃশ্যমান কিছু ভুল ধরা পড়তে পারে। কিন্তু এই গঠন দেখে প্রাপকের প্ল্যাটফর্মে Ethereum জমা সক্রিয় আছে, ঠিকানাটি বর্তমান, অথবা এটি কাঙ্ক্ষিত ব্যক্তির—এসব প্রমাণ হয় না। প্রাপকের জমা পাতায় নির্বাচিত নেটওয়ার্কের নামই আসল নির্দেশনা।
ফরম্যাট পরীক্ষা আরও একটি জিনিস প্রমাণ করে না: ঠিকানাটি কাঙ্ক্ষিত ব্যক্তির নিয়ন্ত্রণে আছে কি না। ক্লায়েন্টের চ্যাটে একটি ঠিকানা দেখা এবং প্রাপকের নিজস্ব জমা পাতা থেকে ঠিকানাটি নেওয়া এক কথা নয়। পেমেন্টের আগে গ্রহণকারী নিজে বর্তমান জমা পাতা খুলবেন, নেটওয়ার্ক বাছবেন, ঠিকানা কপি করবেন এবং পাঠানো বার্তায় সেই নেটওয়ার্কের নাম লিখবেন।
ERC20 ফি কোথা থেকে আসে?
Ethereum-এ gas ফি ETH-এ দেওয়া হয় এবং কাজের পরিমাণ ও নেটওয়ার্ক চাহিদার সঙ্গে বদলায়; এটি স্থির USDT কর্তন নয়। Ethereum gas ব্যাখ্যা অনুযায়ী gas কম্পিউটেশনাল কাজের মূল্য এবং নেটওয়ার্কের চাহিদা ফি-কে প্রভাবিত করে। প্ল্যাটফর্ম নিজস্ব উত্তোলন ফি আলাদা করে দেখাতে পারে, তাই প্রোটোকল gas আর প্ল্যাটফর্মের দেখানো মোট ফিকে একই জিনিস ভাবা উচিত নয়।
ক্লায়েন্ট কোনো এক্সচেঞ্জ থেকে পাঠালে তার পর্দায় একটি উত্তোলন ফি দেখা যেতে পারে। নিজস্ব ওয়ালেট থেকে পাঠালে gas-এর আনুমানিক হিসাব দেখা যেতে পারে এবং পর্যাপ্ত ETH দরকার হতে পারে। ফ্রিল্যান্সারের জন্য আসল তথ্য হলো পাঠানোর ঠিক আগে প্রেরকের চূড়ান্ত নিশ্চিতকরণ পাতায় দেখানো প্রাপ্য অঙ্ক। সংখ্যাটি পুরোনো কোটের চেয়ে কম হলে পাঠানোর আগে ফি কে বহন করবেন তা আবার মেলাতে হবে।
TRC20 বলতে কী বোঝায়?
TRC20 হলো TRON নেটওয়ার্কে সমজাতীয় টোকেন তৈরির একটি মান। TRON-এর টোকেন মানের সরকারি নথি TRC20-কে TRON Virtual Machine-এ চলা টোকেন মান হিসেবে ব্যাখ্যা করে এবং এর প্রোগ্রামিং ইন্টারফেসের সঙ্গে ERC20-এর মিল উল্লেখ করে। ইন্টারফেসে মিল থাকলেও Ethereum ও TRON আলাদা নেটওয়ার্ক। একটি নেটওয়ার্কের জমা নির্দেশনা অন্যটিতে ব্যবহার করা যাবে—এমন সিদ্ধান্ত এই মিল থেকে আসে না।
প্রাপক যদি TRC20 নিতে চান, তার USDT জমা পাতায় TRON বা TRC20 নামটি সক্রিয় থাকতে হবে। ঠিকানার প্রথম অক্ষর একটি প্রাথমিক অসঙ্গতি ধরতে সাহায্য করতে পারে, কিন্তু শুধু সেটি দেখে সমর্থন নিশ্চিত হয় না। জমা পাতায় সম্পদ, নেটওয়ার্ক, পূর্ণ ঠিকানা এবং memo বা tag-এর নির্দেশনা একসঙ্গে পড়তে হবে। নেটওয়ার্কের নাম না দেখা গেলে বা জমা সাময়িক বন্ধ থাকলে প্রাপক নতুন নির্দেশনা না দেওয়া পর্যন্ত অপেক্ষা করুন।
TRC20 ফি কীভাবে তৈরি হয়?
TRON লেনদেনে Bandwidth ব্যবহৃত হয়; স্মার্ট কনট্র্যাক্টের কাজে Energy-ও লাগে, আর পর্যাপ্ত রিসোর্স না থাকলে TRX পুড়ে ফি মেটাতে পারে। TRON লেনদেনের সরকারি নথি এই ব্যবস্থা ব্যাখ্যা করে। ফলে “TRC20-এ সব সময় ফি নেই” বলা সঠিক নয়। প্রেরকের রিসোর্স, পাঠানোর পদ্ধতি এবং সেবার নিজস্ব উত্তোলন ফি—সবকিছু মিলিয়ে প্রকৃত খরচ তৈরি হয়।
এক্সচেঞ্জ থেকে পাঠালে ক্লায়েন্ট Bandwidth বা Energy-এর আলাদা হিসাব নাও দেখতে পারেন; তার বদলে উত্তোলন পাতায় একটিমাত্র ফি দেখা যেতে পারে। নিজের নিয়ন্ত্রণে থাকা ওয়ালেট থেকে পাঠালে রিসোর্স ও TRX-এর অবস্থা প্রাসঙ্গিক হতে পারে। দুই ধরনের পাঠানোকে একই পুরোনো সংখ্যায় তুলনা না করে, পাঠানোর মুহূর্তে প্রেরকের পর্দায় মোট কর্তন ও প্রাপ্য অঙ্ক দেখুন।
BEP20 সম্পর্কে কোন সীমার মধ্যে কথা বলা যায়?
BEP20 বিকল্প গ্রহণযোগ্য কি না, তার উত্তর শুধু প্রাপকের বর্তমান USDT জমা পাতা ও পাঠানোর সেবার বর্তমান উত্তোলন পাতায় মিলবে। এই লেখার Tether উৎসগুলো BEP20-কে ইস্যুকারীর তালিকাভুক্ত নেটওয়ার্ক সংস্করণ হিসেবে প্রতিষ্ঠা করে না। তাই কোনো প্ল্যাটফর্মে BEP20 লেখা দেখলে সেটিকে Tether-এর সর্বত্র সমর্থিত সরকারি পথ বলা যাবে না। নির্দিষ্ট প্ল্যাটফর্ম কোন টোকেন ও কোন নেটওয়ার্ক গ্রহণ করছে—দাবিটি সেখানেই সীমিত থাকবে।
BNB Chain-এর সরকারি প্রশ্নোত্তর বলছে, সঠিক টোকেন ও সঠিক নেটওয়ার্ক নিশ্চিত করতে হবে; BNB Smart Chain-এ থাকা টোকেন Ethereum Mainnet বা opBNB নেটওয়ার্কে স্বয়ংক্রিয়ভাবে দেখা যায় না। এই উৎস ভুল নেটওয়ার্কের ঝুঁকি বোঝায়। এটি কোনো নির্দিষ্ট প্ল্যাটফর্মে USDT জমা সক্রিয় আছে, ফি কত, বা ভুল জমা উদ্ধার হবেই—এসব প্রমাণ করে না।
BEP20 বিকল্প দেখা গেলে কোন প্রশ্ন করবেন?
প্রাপকের জমা পাতায় USDT বেছে BNB Smart Chain বা BEP20 নামটি সত্যিই দেখা যাচ্ছে কি না দেখুন। তারপর ক্লায়েন্ট তার উত্তোলন পাতায় একই অর্থের নেটওয়ার্ক দেখবেন। জমা বন্ধ, রক্ষণাবেক্ষণ, ন্যূনতম অঙ্ক বা নিশ্চিতকরণের সতর্কতা থাকলে তা পড়বেন। টোকেন কনট্র্যাক্ট দেখানো হলে প্ল্যাটফর্মের নিজস্ব সরকারি তথ্যের সঙ্গে মিলবে। কোনো ঘর অস্পষ্ট থাকলে সেখানেই থামুন।
“ঠিকানাটি দেখতে পরিচিত” বা “আগেও BEP20 ব্যবহার করেছি”—এগুলো বর্তমান সমর্থনের বিকল্প নয়। একটি সেবায় যে বিকল্প আছে, অন্য সেবায় একই নামে তা নাও থাকতে পারে। দুই পক্ষ একই নেটওয়ার্ক বুঝছেন কি না লিখিতভাবে নিশ্চিত করুন। নামের অর্থ পরিষ্কার না হলে দুই প্ল্যাটফর্মের সরকারি সহায়তা নিন; ক্লায়েন্টের অনুমানকে প্রযুক্তিগত প্রমাণ হিসেবে নেবেন না।
ERC20, TRC20 ও BEP20 তুলনা কীভাবে পড়বেন?
তুলনার প্রথম প্রশ্ন হলো দুই প্রান্তের সমর্থন; তার পরে ঠিকানা, ফি, পরীক্ষামূলক পেমেন্ট ও নথি। নিচের সারণি কোনো স্থির ফি বা সবার জন্য সেরা পথ ঘোষণা করে না। এটি কোথায় কোন তথ্য যাচাই করতে হবে তা দেখায়।
| যাচাইয়ের বিষয় | ERC20 | TRC20 | BEP20 |
|---|---|---|---|
| মূল নেটওয়ার্ক | Ethereum | TRON | BNB Smart Chain |
| এই লেখায় USDT-র প্রমাণসীমা | Tether-এর তালিকাভুক্ত Ethereum সংস্করণ | Tether-এর তালিকাভুক্ত TRON সংস্করণ | প্রাপকের বর্তমান প্ল্যাটফর্ম সমর্থন; Tether-এর তালিকাভুক্ত সংস্করণ দাবি নয় |
| ফি বোঝার ভিত্তি | gas ETH-এ; প্ল্যাটফর্মের উত্তোলন ফি আলাদা হতে পারে | Bandwidth, Energy ও TRX-এর শর্ত; প্ল্যাটফর্মের ফি আলাদা হতে পারে | পাঠানো ও গ্রহণকারী প্ল্যাটফর্মের বর্তমান পাতার তথ্য |
| প্রথমে কোথায় দেখবেন | প্রাপকের USDT জমা পাতা | প্রাপকের USDT জমা পাতা | প্রাপকের USDT জমা পাতা ও টোকেনের সতর্কতা |
| পাঠানোর আগে কী মিলবে | সম্পদ, নেটওয়ার্ক, ঠিকানা, অঙ্ক | সম্পদ, নেটওয়ার্ক, ঠিকানা, অঙ্ক | সম্পদ, নেটওয়ার্ক, ঠিকানা, অঙ্ক ও প্ল্যাটফর্মের নির্দিষ্ট সমর্থন |
সারণির কোনো সারি একা সিদ্ধান্ত দেয় না। ERC20-এ gas ব্যবস্থার সরকারি ব্যাখ্যা আছে বলেই কোনো এক্সচেঞ্জের আজকের উত্তোলন ফি জানা যায় না। TRC20-এ রিসোর্সের নিয়ম জানা থাকলেও প্রেরকের প্ল্যাটফর্ম কত কাটবে তা আলাদা। BEP20 নাম দেখা গেলেও প্রাপক সেটি গ্রহণ করছেন কি না নিশ্চিত না হলে পেমেন্ট করা যাবে না।
কোন নেটওয়ার্ককে সেরা বলা যায়?
সবার জন্য একটি সেরা বা সব সময় সবচেয়ে সস্তা নেটওয়ার্ক নেই। যে পথ পাঠানো ও গ্রহণ—দুই প্রান্তে স্পষ্টভাবে সমর্থিত, যার ঠিকানা বর্তমান জমা পাতা থেকে নেওয়া, এবং যার মোট খরচ চূড়ান্ত নিশ্চিতকরণ পাতায় গ্রহণযোগ্য—সেই পেমেন্টে সেটিই ব্যবহারযোগ্য পথ। সমর্থন না থাকলে কম ফি কোনো সুবিধা নয়।
সিদ্ধান্তে তিনটি প্রশ্ন ধারাবাহিকভাবে করুন। ভুল হলে অর্থ ফেরত পাওয়ার স্পষ্ট ব্যবস্থা আছে কি না দেখুন, তবে পুনরুদ্ধার নিশ্চিত ধরে নেবেন না। দুই পক্ষ একই সম্পদ ও নেটওয়ার্ক বুঝছেন কি না নিশ্চিত করুন। শেষে মোট ফি ও প্রাপ্য অঙ্ক দেখুন। গতি ও সুবিধা বিবেচ্য, কিন্তু এগুলো অস্পষ্ট সমর্থনকে ঠিক করে না।
কম ফি কি একাই সিদ্ধান্ত নিতে পারে?
না। প্রেরকের উত্তোলন ফি, নেটওয়ার্কের খরচ, ন্যূনতম উত্তোলন এবং প্রাপকের ন্যূনতম জমা—চারটি আলাদা বিষয় হতে পারে। কিছু সেবা পাঠানো অঙ্ক থেকে ফি কাটে; অন্য ক্ষেত্রে আলাদা সম্পদে ফি লাগে। ক্লায়েন্টের চূড়ান্ত নিশ্চিতকরণ পাতায় প্রাপক কত পাবেন তা না দেখে কোটের অঙ্ককে নিট প্রাপ্তি ধরে নেওয়া যাবে না।
পুরোনো নিবন্ধ, স্ক্রিনশট বা বন্ধুর দেওয়া একটি ফি বর্তমান পেমেন্টের প্রমাণ নয়। ফি বদলালে ইনভয়েসে কার দায় সেটি আগে লেখা থাকা দরকার। প্রাপক যদি নির্দিষ্ট নিট অঙ্ক চান, ক্লায়েন্টকে এমন মোট অঙ্ক দিতে হবে যাতে উত্তোলনের পরে সেই নিট অঙ্ক পৌঁছায়। হিসাব পরিষ্কার না হলে পেমেন্টের আগে নতুন কোট দিন।
দুই প্ল্যাটফর্মে নেটওয়ার্কের নাম আলাদা দেখালে কী করবেন?
নামের বানান আলাদা হলে একই নেটওয়ার্ক ধরে নেবেন না; দুই সেবার সরকারি ব্যাখ্যা মিলিয়ে অর্থ পরিষ্কার করুন। একটি সেবা পূর্ণ নাম দেখাতে পারে, অন্যটি সংক্ষিপ্ত রূপ দেখাতে পারে। শুধু TRC20, ERC20 বা BEP20 লেখা থাকলেও সঙ্গে কোন মূল নেটওয়ার্কের নাম আছে তা পড়ুন। একই শব্দের পাশে ভিন্ন সতর্কতা থাকলে সেটিও সিদ্ধান্তের অংশ।
প্রাপক প্রথমে নিজের জমা পাতার পুরো নাম ও সতর্কতা লিখে রাখবেন। ক্লায়েন্ট তার উত্তোলন পাতায় দেখা পুরো নাম পাঠাবেন। দুই নামের অর্থ একই কি না বোঝা না গেলে সংশ্লিষ্ট সেবার সরকারি সহায়তা পাতায় ব্যাখ্যা খুঁজুন। সহায়তা লেখা অস্পষ্ট হলে টিকিট খুলে নির্দিষ্টভাবে জিজ্ঞেস করুন: “এই USDT উত্তোলন বিকল্পটি কি প্রাপকের দেখানো অমুক নেটওয়ার্ক জমার সঙ্গে সামঞ্জস্যপূর্ণ?” উত্তর না আসা পর্যন্ত পাঠানো বন্ধ থাকবে।
কোনো সহায়তাকর্মীর উত্তর নথি হিসেবে রাখলে প্রশ্ন, তারিখ ও টিকিট নম্বর সংরক্ষণ করুন। উত্তরের শুধু একটি সুবিধাজনক বাক্য কেটে রেখে বাকি শর্ত বাদ দেবেন না। পরের পেমেন্টে একই উত্তর স্থায়ীভাবে প্রযোজ্য ধরে নেবেন না, কারণ জমা ও উত্তোলনের অবস্থা বদলাতে পারে। নতুন লেনদেনের আগে বর্তমান পর্দা আবার দেখা দরকার।
নেটওয়ার্কের নাম মিললেও আর কী দেখবেন?
নাম মেলার পরে সম্পদটি USDT কি না, জমা ও উত্তোলন চালু কি না, ন্যূনতম অঙ্ক কত, memo বা tag লাগে কি না এবং চূড়ান্ত প্রাপ্য অঙ্ক কত—এসব দেখুন। নেটওয়ার্কের নাম একটি গুরুত্বপূর্ণ ঘর, কিন্তু পুরো নির্দেশনা নয়। একই নামের নিচে ভুল টোকেন বাছাই হলে বা প্রাপকের ঠিকানা পুরোনো হলে লেনদেন তবুও সমস্যায় পড়তে পারে।
প্রাপকের জমা পাতায় কোনো লাল বা হলুদ সতর্কতা থাকলে তার অর্থ বুঝে নিন। “শুধু এই নেটওয়ার্কে পাঠান”, “অন্য টোকেন পাঠাবেন না” বা “জমা সাময়িক বন্ধ”—এ ধরনের নির্দেশনা ফি-র চেয়ে বেশি গুরুত্বপূর্ণ। সতর্কতা পড়া শেষ না হলে শুধু কপি বোতাম দেখা গেছে বলে ঠিকানা পাঠাবেন না।
পুরোনো ঠিকানা আবার ব্যবহার করার আগে কী যাচাই করবেন?
আগের পেমেন্ট সফল হলেও পুরোনো ঠিকানাকে স্থায়ী নির্দেশনা ধরে নেবেন না। প্রাপক নতুন করে USDT জমা পাতা খুলবেন, একই নেটওয়ার্ক বাছবেন এবং বর্তমান ঠিকানা আগের নথির সঙ্গে মিলাবেন। ঠিকানা একই থাকলে সেটি বর্তমান পর্দা থেকে পুনরায় নিশ্চিত হলো; আলাদা হলে নতুন ঠিকানাই ব্যবহার করতে হবে।
ক্লায়েন্টের ঠিকানার তালিকায় পুরোনো তথ্য থাকলে নামের সঙ্গে সম্পদ, নেটওয়ার্ক ও শেষ যাচাইয়ের তারিখ লিখে রাখা ভালো। তবে তালিকার নাম ভুলও হতে পারে। পাঠানোর আগে তালিকায় রাখা পূর্ণ ঠিকানা এবং প্রাপকের বর্তমান জমা পাতা পাশাপাশি মিলবে। শুধু “ফ্রিল্যান্সার USDT” নামে সংরক্ষিত তথ্য দেখে নেটওয়ার্ক বোঝা যায় না।
প্রাপক যদি প্ল্যাটফর্ম বদলান, একই নেটওয়ার্ক হলেও নতুন জমা নির্দেশনা লাগবে। ক্লায়েন্ট যদি পাঠানোর প্ল্যাটফর্ম বদলান, সেখানে নেটওয়ার্কের নাম ও ফি নতুন করে দেখতে হবে। অর্থাৎ পরিচিত ক্লায়েন্ট বা পরিচিত সম্পদ—কোনোটিই নতুন পর্দার যাচাই বাদ দেয় না। অভ্যাসের কারণে হওয়া ভুল ঠেকাতে প্রতিবার একই সাত ধাপ ব্যবহার করুন।
পেমেন্টের প্রমাণকে তিন স্তরে রাখবেন কেন?
পেমেন্টের আগে নির্দেশনা, ব্লকচেইনে লেনদেন এবং প্ল্যাটফর্মে জমা—এই তিন স্তর আলাদা রাখলে কোথায় সমস্যা হয়েছে তা বোঝা যায়। শুধু হ্যাশ থাকলে ক্লায়েন্ট কোন নেটওয়ার্কে সম্মত হয়েছিলেন তা নাও বোঝা যেতে পারে। শুধু ইনভয়েস থাকলে ব্লকচেইনে কী ঘটেছে জানা যায় না। শুধু ব্যালান্সের স্ক্রিনশট থাকলে কোন ইনভয়েসের অর্থ তা অস্পষ্ট হতে পারে।
প্রথম স্তরে ইনভয়েস, সম্পদ, সম্মত নেটওয়ার্ক, নিট বা মোট অঙ্ক, ফি বহনের নিয়ম এবং প্রাপক পাঠানো ঠিকানা রাখুন। তারিখসহ ক্লায়েন্টের নিশ্চিতকরণ বার্তাও রাখুন। এটি দেখায় লেনদেনের আগে দুই পক্ষ কী বুঝেছিলেন। কোনো ঘর পরে বদলালে আগের বার্তা মুছে না দিয়ে সংশোধিত নির্দেশনা আলাদাভাবে রাখুন।
দ্বিতীয় স্তরে পূর্ণ হ্যাশ, ব্লকচেইনের নাম, প্রেরক ও প্রাপক ঠিকানা, টোকেন, অঙ্ক, সময় এবং লেনদেনের অবস্থা রাখুন। সঠিক এক্সপ্লোরারে দেখা তথ্যের সঙ্গে ক্লায়েন্টের রসিদ মিলান। অপেক্ষমাণ অবস্থার স্ক্রিনশটকে চূড়ান্ত প্রমাণ বানাবেন না; পরে সফল বা ব্যর্থ অবস্থা আবার নথিভুক্ত করুন।
তৃতীয় স্তরে প্রাপকের জমার ইতিহাস, ব্যবহারযোগ্য প্রাপ্ত অঙ্ক, জমা হওয়ার সময় এবং ইনভয়েসের সঙ্গে মিল রাখুন। ব্লকচেইনে সফল অথচ প্ল্যাটফর্মে জমা না হলে এই স্তর আলাদাভাবে অপেক্ষমাণ থাকবে। ফলে “ক্লায়েন্ট পাঠিয়েছেন” এবং “ফ্রিল্যান্সার ব্যবহারযোগ্য অর্থ পেয়েছেন”—দুটি ঘটনার পার্থক্য পরিষ্কার থাকে।
তিন স্তরের নথি বিরোধ মেটাতে কীভাবে সাহায্য করে?
প্রাপ্ত অঙ্ক কম হলে প্রথম স্তরের ফি-সমঝোতা এবং তৃতীয় স্তরের অঙ্ক তুলনা করা যায়। ভুল নেটওয়ার্ক হলে প্রথম স্তরের নির্দেশনা ও দ্বিতীয় স্তরের বাস্তব ব্লকচেইন তুলনা করা যায়। হ্যাশ সঠিক কিন্তু জমা দেরি হলে দ্বিতীয় স্তরের সফল অবস্থা ও তৃতীয় স্তরের অপেক্ষমাণ অবস্থা সরকারি সহায়তাকে দেখানো যায়। এতে অভিযোগের বদলে নির্দিষ্ট তথ্য দেওয়া সম্ভব হয়।
নথি রাখার উদ্দেশ্য কাউকে দোষী প্রমাণ করা নয়; একই ঘটনার পুনরায় যাচাইযোগ্য ধারাবাহিকতা রাখা। ক্লায়েন্টের প্রয়োজনের অতিরিক্ত ব্যক্তিগত তথ্য সংগ্রহ করবেন না। নিজের আয়ের খাতায় প্রয়োজনীয় তথ্য রাখুন, আর বাইরে ভাগ করার সময় ব্যালান্স, পরিচয় ও অন্য লেনদেনের তথ্য বাদ দিন। মূল হ্যাশ ও ইনভয়েস নম্বর যেন বদলে না যায়।
একটি বিরোধ ধরা পড়লে সিদ্ধান্ত কীভাবে নেবেন?
যে ঘরে বিরোধ, ঠিক সেই ঘর পরিষ্কার না হওয়া পর্যন্ত পাঠানো থামান। ধরুন, প্রাপক TRC20 জমা নির্দেশনা দিয়েছেন কিন্তু ক্লায়েন্টের পাতায় শুধু ERC20 আছে। এখানে ফি তুলনা করার দরকার নেই; দুই প্রান্তে একই নেটওয়ার্ক নেই। প্রাপক অন্য সমর্থিত পথ দিতে পারেন, অথবা দুই পক্ষ অন্য পেমেন্ট পদ্ধতিতে নতুন করে সম্মত হতে পারেন।
আবার দুই প্রান্তে ERC20 দেখা গেলেও প্রাপ্য অঙ্ক ইনভয়েসের চেয়ে কম হলে সমস্যাটি নেটওয়ার্ক নয়, ফি-সমঝোতা। ক্লায়েন্ট মোট অঙ্ক বাড়াবেন, নাকি ফ্রিল্যান্সার কম অঙ্ক গ্রহণ করবেন—এটি ব্যবসায়িক সিদ্ধান্ত। প্রযুক্তিগত যাচাই সেই সিদ্ধান্ত নিজে নেয় না; শুধু প্রকৃত কর্তন দৃশ্যমান করে।
আরেক ক্ষেত্রে দুই প্রান্তে একই নেটওয়ার্ক ও অঙ্ক মেলে, কিন্তু জমা পাতা রক্ষণাবেক্ষণ দেখায়। তখনও অপেক্ষা করতে হবে। সক্রিয় না থাকা জমা পথে পাঠিয়ে পরে উদ্ধারের আশা করা ভালো সিদ্ধান্ত নয়। অবস্থাটি সক্রিয় হলে ঠিকানা ও অঙ্ক আবার মিলিয়ে তারপর এগোন।
পেমেন্টের আগে সাত ধাপে কী মিলাবেন?
সাতটি ধাপ শেষ না হলে ক্লায়েন্টকে পাঠানোর অনুমতি দেবেন না। প্রতিবার একই ক্রম ব্যবহার করলে ভুল বাদ পড়ার সম্ভাবনা কমে এবং পরে নথি তৈরি সহজ হয়।
- সম্পদ লিখুন। ইনভয়েসে USDT এবং কোটের মুদ্রা আলাদা ঘরে রাখুন।
- প্রাপক জমা পাতা খুলুন। নিজের অ্যাকাউন্টের বর্তমান জমার ধাপ ব্যবহার করুন; পুরোনো স্ক্রিনশট নয়।
- নেটওয়ার্ক বাছুন। পাতায় দেখানো পুরো নাম লিখুন এবং জমা সক্রিয় কি না দেখুন।
- ঠিকানা কপি করুন। হাতে টাইপ করবেন না। memo বা tag চাইলে আলাদা ঘরে নিন।
- ক্লায়েন্টের দিক মিলান। তার উত্তোলন পাতায় একই সম্পদ ও একই নেটওয়ার্ক থাকতে হবে।
- অঙ্ক ও ফি পড়ুন। চূড়ান্ত নিশ্চিতকরণ পাতায় প্রাপ্য অঙ্ক ইনভয়েসের সঙ্গে মিলান।
- শেষ পুনরীক্ষণ করুন। সম্পদ, নেটওয়ার্ক, ঠিকানা, memo বা tag এবং অঙ্ক—পাঁচটি তথ্য আবার পড়ুন।
একটি ধাপের উত্তর অস্পষ্ট হলে পরের ধাপে যাবেন না। প্রাপকের জমা পাতায় নেটওয়ার্ক নেই অথচ ক্লায়েন্টের উত্তোলন পাতায় আছে—এটি মিল নয়। একইভাবে প্রাপকের নির্দেশনা পুরোনো হলে বর্তমান জমা পাতা আবার খুলতে হবে। থামা মানে ক্লায়েন্টকে প্রত্যাখ্যান করা নয়; তথ্য পরিষ্কার না হওয়া পর্যন্ত অর্থ না পাঠানো।
ক্লায়েন্টকে কীভাবে নির্দেশনা লিখবেন?
লম্বা ব্যাখ্যার বদলে ছোট ঘরভিত্তিক বার্তা দিন। উদাহরণ:
সম্পদ: USDT নেটওয়ার্ক: প্রাপকের জমা পাতায় দেখানো পুরো নাম ঠিকানা: বর্তমান জমা পাতা থেকে কপি করা পূর্ণ ঠিকানা memo/tag: জমা পাতার নির্দেশনা অনুযায়ী প্রাপ্য অঙ্ক: ইনভয়েস অনুযায়ী; উত্তোলন ফি কে বহন করবেন আগে নিশ্চিত শেষ যাচাই: পাঠানোর আগে নেটওয়ার্ক ও ঠিকানা আবার মিলিয়ে নিন
এটি কেবল নমুনা; এখানে কোনো বাস্তব ঠিকানা বা অঙ্ক নেই। প্রতিটি পেমেন্টে নতুন করে জমা পাতা দেখে তথ্য বসাতে হবে। ক্লায়েন্ট নেটওয়ার্ক বদলাতে চাইলে পুরোনো ঠিকানা পুনর্ব্যবহার করবেন না। প্রাপক নতুন নেটওয়ার্ক বেছে নতুন নির্দেশনা দেবেন, তারপর সাতটি ধাপ আবার শুরু হবে।
ঠিকানা কপি করার পরে কীভাবে মিলাবেন?
কপি করা ঠিকানার শুরু, মাঝের অন্তত একটি অংশ, শেষ এবং মোট দৈর্ঘ্য মূল জমা পাতার সঙ্গে মিলিয়ে দেখুন। শুধু প্রথম ও শেষ কয়েকটি অক্ষর দেখা দুর্বল পরীক্ষা। ক্লিপবোর্ডে ভুল লেখা থাকা, ভুল আলাপ থেকে ঠিকানা নেওয়া বা কপি করার সময় বাড়তি অক্ষর ঢুকে যাওয়া—সব ক্ষেত্রেই পূর্ণ তুলনা দরকার।
ঠিকানাটি সাধারণ লেখার ঘরে পেস্ট করে বাড়তি ফাঁক, নতুন লাইন বা বিরামচিহ্ন আছে কি না দেখুন। কোনো অচেনা ওয়েবসাইটে “নিরাপদ কি না” জানতে ঠিকানা দেওয়ার দরকার নেই। বিন্যাস পরীক্ষা কেবল অক্ষর ও গঠনের অসঙ্গতি ধরতে পারে; ঠিকানার মালিক, বর্তমান জমা সমর্থন বা টোকেন কনট্র্যাক্ট প্রমাণ করতে পারে না।
QR কোড কি লেখা যাচাই বাদ দিতে পারে?
না। QR কোড হাতে টাইপ করার ভুল কমাতে পারে, কিন্তু স্ক্যানের পরে অ্যাপ যে সম্পদ, নেটওয়ার্ক, ঠিকানা ও অঙ্ক দেখায় তা লিখিত নির্দেশনার সঙ্গে মিলতে হবে। পুরোনো QR কোডে পুরোনো ঠিকানা থাকতে পারে। প্রেরক স্ক্যান করলেই প্রাপক নিরাপদে অর্থ পাবেন—এমন নিশ্চয়তা নেই। চূড়ান্ত নিশ্চিতকরণ পাতা পড়াই শেষ পরীক্ষা।
অ্যাকাউন্টের পর্দা অন্যকে দেখানো দরকার নেই। ক্লায়েন্ট ও প্রাপক লিখিত ঘরগুলো মিলিয়ে নিতে পারেন। স্ক্রিনশট পাঠালে ব্যালান্স, পরিচয় বা অপ্রাসঙ্গিক অ্যাকাউন্ট তথ্য বাদ দিন। নিরাপত্তা মানে নেটওয়ার্ক ভুল এড়ানো এবং ব্যক্তিগত তথ্য অযথা প্রকাশ না করা—দুটিই।
পরীক্ষামূলক পেমেন্ট কখন কাজে লাগে?
নতুন বা বড় পেমেন্ট পথে ছোট পরীক্ষামূলক পেমেন্ট অতিরিক্ত যাচাই দিতে পারে, কিন্তু এটি কোনো বাঁধাধরা নিয়ম নয়। প্রথম অঙ্ক পাঠানোর আগে ন্যূনতম উত্তোলন, ন্যূনতম জমা এবং দুই দফা ফি হিসাব করুন। পরীক্ষার অঙ্ক ন্যূনতমের নিচে হলে ফল উল্টো বিভ্রান্তিকর হতে পারে।
পরীক্ষামূলক অঙ্কে ব্লকচেইনে সফল লেনদেন এবং প্রাপকের প্ল্যাটফর্মে ব্যবহারযোগ্য জমা—দুটি পর্যায়ই দেখতে হবে। শুধু এক্সপ্লোরারে সফল দেখলে পরীক্ষা শেষ নয়। প্রাপকের জমার ইতিহাসে অঙ্ক দেখা গেলে একই সম্পদ ও একই নেটওয়ার্কের পথটি কাজ করেছে বলে সীমিত প্রমাণ পাওয়া যায়। পরের লেনদেনের আগে তবুও ঠিকানা, নেটওয়ার্ক ও জমার অবস্থা আবার মিলবে।
পরীক্ষামূলক পেমেন্টের লাভ ও খরচ কী?
লাভ হলো ভুল কপি, ভুল নেটওয়ার্কের বোঝাপড়া বা জমা শনাক্তকরণের সমস্যা সীমিত অঙ্কে ধরা পড়তে পারে। ক্লায়েন্ট উত্তোলন পাতায় কী দেখেন এবং প্রাপক কোন নথি রাখবেন, সেটিও বোঝা যায়। নতুন সেবা বা নতুন ক্লায়েন্টের ক্ষেত্রে এটি কথা ও বাস্তব পর্দার মিল যাচাই করতে সাহায্য করে।
খরচও আছে। দুইবার উত্তোলন ফি লাগতে পারে, দুইটি হ্যাশ নথিভুক্ত করতে হয় এবং দ্বিতীয়বার তথ্য বসানোর সময় নতুন ভুল হতে পারে। খুব ছোট অঙ্কে ফি তুলনামূলকভাবে বড় হয়। তাই পরীক্ষামূলক পেমেন্টের সিদ্ধান্ত পেমেন্টের আকার, নতুনত্ব, ন্যূনতম সীমা এবং মোট খরচ দেখে নিন। সফল পরীক্ষা পরের লেনদেনের নিশ্চয়তা নয়।
নেটওয়ার্ক ফি নিয়ে কীভাবে লিখিত সমঝোতা করবেন?
ইনভয়েসে ক্লায়েন্ট মোট কত পাঠাবেন এবং ফ্রিল্যান্সার নিট কত পাবেন—দুটি অঙ্ক আলাদা হলে তা স্পষ্ট লিখুন। “ক্লায়েন্ট সব উত্তোলন ফি বহন করবেন” অথবা “পাঠানো অঙ্ক থেকে ফি কাটা হতে পারে”—যে নিয়মে সম্মতি হয়েছে সেটি পেমেন্টের আগে নথিভুক্ত করুন। পরে কম অঙ্ক পৌঁছালে কারণ খোঁজা সহজ হবে।
আনুমানিক ফি লিখলে কোন পর্দা বা সরকারি নথি দেখে হিসাব করা হয়েছে এবং কোন তারিখে দেখা হয়েছে তা রাখুন। প্রকৃত ফি জানার শেষ স্থান প্রেরকের চূড়ান্ত নিশ্চিতকরণ পাতা। প্রেরকের ফি জানা না গেলে খাতায় অজানা লিখুন; অনুমান করে সংখ্যা বসাবেন না। প্রাপকের কাছে আসা অঙ্ক এবং ইনভয়েসের পার্থক্য থাকলে আলাদা ব্যাখ্যা রাখুন।
লেনদেনের হ্যাশ কী প্রমাণ করে?
হ্যাশ নির্দিষ্ট ব্লকচেইন লেনদেন খুঁজে পেতে সাহায্য করে; এটি কাজের চুক্তি, ইনভয়েসের কারণ বা ক্লায়েন্টের আইনগত পরিচয় নিজে প্রমাণ করে না। সঠিক নেটওয়ার্কের প্রকাশ্য এক্সপ্লোরারে হ্যাশ খুঁজে অবস্থা, প্রেরক, প্রাপক, টোকেন, অঙ্ক ও ব্লকের তথ্য দেখা যায়। ভুল নেটওয়ার্কের এক্সপ্লোরারে না পাওয়া মানেই লেনদেন নেই—এমন সিদ্ধান্ত নেবেন না; আগে নেটওয়ার্কের নাম মিলান।
এক্সপ্লোরারে অন্তত পাঁচটি তথ্য দেখুন: সঠিক ব্লকচেইন, সফল বা অপেক্ষমাণ অবস্থা, প্রত্যাশিত টোকেন, প্রাপকের ঠিকানা এবং অঙ্ক। এরপর প্রাপকের জমার ইতিহাসে ক্রেডিট দেখা গেছে কি না দেখুন। ব্লকচেইনে সফল হলেও প্ল্যাটফর্মের প্রয়োজনীয় নিশ্চিতকরণ বা পর্যালোচনার কারণে ব্যালান্সে দেখাতে সময় লাগতে পারে।
হ্যাশ কি আয়ের পূর্ণ প্রমাণ?
না। আয়ের পূর্ণ ধারায় ইনভয়েস নম্বর, ক্লায়েন্ট, কাজের বিবরণ, সম্মত অঙ্ক, পেমেন্টের তারিখ, সম্পদ, নেটওয়ার্ক, প্রাপ্ত অঙ্ক ও হ্যাশ একসঙ্গে লাগে। হ্যাশ লেনদেনের প্রযুক্তিগত প্রমাণ; ব্যবসায়িক কারণের প্রমাণ নয়। খাতায় পূর্ণ হ্যাশ লিখুন এবং প্রয়োজনে সংশ্লিষ্ট এক্সপ্লোরারের লিংক রাখুন।
হ্যাশের সঙ্গে প্ল্যাটফর্মে জমার রসিদও সংরক্ষণ করুন। প্রকাশ্য প্রতিবেদনে ক্লায়েন্টের অপ্রয়োজনীয় তথ্য দেখাবেন না, কিন্তু নিজের নথিতে মূল তথ্য অপরিবর্তিত রাখুন। পরে কোনো বিরোধ হলে ইনভয়েস, ক্লায়েন্টের বার্তা, হ্যাশ ও জমার রসিদ মিলিয়ে ধারাবাহিক ঘটনা বোঝা যাবে।
নিজের নিয়ন্ত্রণে থাকা ওয়ালেটের আলাদা সীমা কী?
নিজের নিয়ন্ত্রণে থাকা ওয়ালেটে নেটওয়ার্ক ও টোকেন নিজে সামলাতে হয়; seed phrase বা private key কখনো ক্লায়েন্ট, সহায়তাকর্মী বা যাচাইকারী ওয়েবসাইটকে দেওয়া লাগে না। পেমেন্ট গ্রহণের জন্য প্রকাশ্য ঠিকানাই যথেষ্ট। কোনো ব্যক্তি পুনরুদ্ধারের নামে ব্যক্তিগত চাবি চাইলে কাজ থামান। এই নিবন্ধে ওয়ালেট সংযোগের কোনো ধাপ নেই।
অজানা টোকেন কনট্র্যাক্ট শুধু ticker হিসেবে USDT দেখালেই সেটি প্রত্যাশিত সম্পদ হয় না। নিজের ওয়ালেটে টোকেন যোগ করার আগে সংশ্লিষ্ট নেটওয়ার্ক ও সরকারি তথ্য বুঝতে হবে। নতুন ব্যবহারকারী যদি তা নিশ্চিত করতে না পারেন, সমর্থন স্পষ্ট এমন গ্রহণের পদ্ধতি বেছে নিন।
ভুল নেটওয়ার্কে পাঠানো হলে প্রথম কাজ কী?
আরেকটি লেনদেন পাঠাবেন না; আগে হ্যাশ, বাছাই করা নেটওয়ার্ক, টোকেন, ঠিকানা, অঙ্ক ও সময় সংরক্ষণ করুন। সঠিক ব্লকচেইনের এক্সপ্লোরারে অবস্থা দেখুন এবং প্রাপক প্ল্যাটফর্মের বর্তমান জমা সমর্থন পড়ুন। এরপর পাঠানো ও গ্রহণকারী সেবার সরকারি সহায়তায় তথ্য দিন। উদ্ধার সম্ভব, দ্রুত বা বিনা ফিতে হবে—এমন প্রতিশ্রুতি দেওয়া যায় না।
ভুলটি ক্লায়েন্টকে তথ্যভিত্তিকভাবে জানান। “ব্লকচেইনে সফল, প্ল্যাটফর্মে জমা অপেক্ষমাণ” অথবা “অসমর্থিত নেটওয়ার্ক; সরকারি সহায়তার উত্তর অপেক্ষায়”—যে অবস্থা সত্য সেটিই লিখুন। সামাজিক যোগাযোগমাধ্যমের অচেনা উদ্ধারকারীকে অর্থ বা নিরাপত্তা তথ্য দেবেন না। সহায়তার উত্তর না আসা পর্যন্ত ইনভয়েস সম্পূর্ণ পরিশোধিত হিসেবে চিহ্নিত করবেন না।
ঠিকানার বিন্যাস যাচাইকারী কতটুকু সাহায্য করে?
বিন্যাস যাচাইকারী অসম্পূর্ণ বা স্পষ্টত বেমানান ঠিকানা ধরতে পারে; এটি মালিকানা, টোকেন কনট্র্যাক্ট, বর্তমান জমা সমর্থন বা বাছাই করা নেটওয়ার্ক নিশ্চিত করতে পারে না। দেখতে সঠিক একটি ঠিকানাও ভুল ব্যক্তি বা পুরোনো জমা নির্দেশনার হতে পারে। তাই ফলের ভাষা হবে “গঠনটি প্রত্যাশিত নিয়মের সঙ্গে মেলে”, “ঠিকানাটি নিরাপদ” নয়।
যাচাইকারী অক্ষরের ধরন, দৈর্ঘ্য বা checksum পরীক্ষা করলেও সেটি কেবল লেখার অখণ্ডতার সীমিত পরীক্ষা। প্রাপক কে, প্ল্যাটফর্ম আজ ওই নেটওয়ার্ক নিচ্ছে কি না, বা টোকেনটি প্রত্যাশিত কি না—এসব জানতে বর্তমান জমা পাতা দরকার। কোনো সরঞ্জাম চলতি প্ল্যাটফর্ম সমর্থন না পড়লে সেটি সমর্থনের দাবি করতে পারে না। এই সীমা ফলের পাশে স্পষ্ট লেখা উচিত।
কপি-পেস্ট যাচাইয়ের একটি বাস্তব পদ্ধতি কী?
ঠিকানাকে চার ভাগে পড়ুন: প্রথম অংশ, মাঝের দুটি ছোট অংশ এবং শেষ অংশ। মোট দৈর্ঘ্যও দেখুন। তারপর বাছাই করা নেটওয়ার্কের নাম আবার পড়ুন। তুলনার স্ক্রিনশট রাখলে ব্যক্তিগত ব্যালান্স বা অ্যাকাউন্টের নাম বাদ দিন; শুধু পেমেন্টের জন্য প্রয়োজনীয় ঘর রাখুন। স্ক্রিনশটের সঙ্গে পূর্ণ ঠিকানা লেখা হিসেবেও রাখুন, যাতে ছবির মান কমলেও যাচাই করা যায়।
ক্লায়েন্টের চূড়ান্ত নিশ্চিতকরণ পাতায় প্রাপকের ঠিকানা সংক্ষিপ্ত দেখা যেতে পারে। বিস্তারিত দেখার ব্যবস্থা থাকলে পূর্ণ অক্ষরমালা খুলুন। পূর্ণ ঠিকানা দেখা না গেলে ঠিকানার তালিকায় রাখা তথ্য ও মূল নির্দেশনা মিলিয়ে নিন। তবুও নিশ্চিত হওয়া না গেলে পাঠাবেন না।
নেটওয়ার্ক সমর্থন কখন আবার যাচাই করতে হবে?
প্রতিটি নতুন পেমেন্টের আগে, দীর্ঘ বিরতির পরে এবং প্ল্যাটফর্মে রক্ষণাবেক্ষণের বিজ্ঞপ্তি দেখা গেলে সমর্থন আবার যাচাই করুন। “একবার সেট করেছি” স্থায়ী নিয়ম নয়। জমা বা উত্তোলন সাময়িকভাবে বন্ধ থাকতে পারে। টোকেন কনট্র্যাক্ট, প্ল্যাটফর্মের নীতি বা প্রয়োজনীয় নিশ্চিতকরণের সংখ্যা বদলাতে পারে।
একই দিনে পরীক্ষামূলক ও চূড়ান্ত পেমেন্ট হলেও শেষ স্থানান্তরের আগে জমার অবস্থা আবার দেখুন। ক্লায়েন্ট কয়েক দিন পরে পেমেন্ট করলে নতুন করে ঠিকানা নিন। ইনভয়েসে নেটওয়ার্ক আগে লেখা থাকলেও পাঠানোর দিনে বর্তমান সমর্থন না মিললে সংশোধিত শর্তে দুজনের সম্মতি নিন। লিখিত শর্ত বাস্তব প্ল্যাটফর্ম অবস্থাকে সক্রিয় করতে পারে না।
স্ক্রিনশট কত দিন বিশ্বাস করা যায়?
স্ক্রিনশট একটি নির্দিষ্ট সময়ের প্রমাণ, চলতি নির্দেশনা নয়। এতে তোলার তারিখ, প্ল্যাটফর্ম ও দৃশ্যমান নেটওয়ার্কের নাম রাখুন। পরের পেমেন্টে পুরোনো স্ক্রিনশট দেখে পাঠানো উচিত নয়। প্রক্রিয়া বোঝাতে স্ক্রিনশট কাজে লাগে; ঠিকানার উৎস হবে বর্তমান জমা পাতা। ছবিতে ঠিকানা থাকলে অন্যকে দেওয়ার আগে গোপনীয়তা বিবেচনা করুন।
সরকারি নথিও বদলাতে পারে। এই লেখার হালনাগাদের তারিখ 2026-08-11; পাঠানোর দিনের প্ল্যাটফর্ম পর্দা ও সরকারি সহায়তা লেখা আরও নতুন হতে পারে। কোনো বিরোধ দেখা গেলে বর্তমান সরকারি নির্দেশনা অনুসরণ করুন এবং বিরোধ পরিষ্কার না হওয়া পর্যন্ত অর্থ পাঠানো বন্ধ রাখুন।
ফ্রিল্যান্সারের আয়ের নথিতে নেটওয়ার্ক কেন লিখবেন?
নেটওয়ার্কের ঘর ছাড়া লেনদেনের হ্যাশ পুনরায় খোঁজা ও ফি ব্যাখ্যা করা কঠিন হয়। একই টোকেন প্রতীক একাধিক ব্লকচেইনে দেখা গেলে “USDT পেয়েছি” অসম্পূর্ণ বর্ণনা। আয়ের খাতায় সম্পদ, নেটওয়ার্ক, মোট অঙ্ক, জানা থাকলে প্রেরকের ফি, প্রাপ্ত অঙ্ক, হ্যাশ, ব্লকচেইনের সময়, প্ল্যাটফর্মে জমার সময় এবং ইনভয়েস নম্বর রাখুন।
এর সঙ্গে পেমেন্টের সময়কার রেফারেন্স মুদ্রা, মূল্য, বিনিময় হারের উৎস ও সময় আলাদা ঘরে রাখা যায়। নেটওয়ার্ক ফি USDT অঙ্ক থেকে কাটা হলে ইনভয়েস নিষ্পত্তির পার্থক্য ব্যাখ্যা করুন। ফি অন্য সম্পদে হলে সেই সম্পদ ও অঙ্ক জানা থাকলে আলাদা লিখুন। অজানা ফি আন্দাজ করবেন না। পরে ক্লায়েন্ট, প্ল্যাটফর্ম বা আয়ের নথি নিয়ে প্রশ্ন এলে মূল প্রমাণ থেকে উত্তর দেওয়া সহজ হবে।
নথির একটি নমুনা কেমন?
| ক্ষেত্র | কী লিখবেন |
|---|---|
| ইনভয়েস | নিজের ধারাবাহিক ইনভয়েস নম্বর |
| ক্লায়েন্ট | চুক্তি বা ক্লায়েন্ট নথির নাম |
| সম্পদ | USDT |
| নেটওয়ার্ক | পাঠানোর পর্দায় দেখা নির্দিষ্ট নাম |
| চাওয়া অঙ্ক | ইনভয়েস অনুযায়ী |
| প্রাপ্ত অঙ্ক | অ্যাকাউন্টে জমা অনুযায়ী |
| ফি বহনের নিয়ম | ক্লায়েন্ট বহন করেছেন / অঙ্ক থেকে কাটা / অজানা |
| লেনদেনের হ্যাশ | পূর্ণ হ্যাশ |
| ব্লকচেইন অবস্থা | অপেক্ষমাণ / সফল / ব্যর্থ, যাচাইয়ের সময়সহ |
| প্ল্যাটফর্ম অবস্থা | জমা হয়েছে / অপেক্ষমাণ / পর্যালোচনাধীন |
| ফিয়াট রেফারেন্স | মুদ্রা, হার, উৎস ও সময় |
এটি ব্যক্তিগত হিসাবের নথি। প্রকাশ্য পোস্ট বা সামাজিক মাধ্যমে পূর্ণ ক্লায়েন্ট পরিচয় ও ঠিকানা ছড়ানোর দরকার নেই। কিন্তু নিজের প্রমাণভান্ডারে মূল ইনভয়েস, বার্তা ও প্ল্যাটফর্মের রসিদ অপরিবর্তিত রাখুন। CSV রপ্তানি করলে হ্যাশের ঘর যেন বৈজ্ঞানিক সংখ্যা বিন্যাসে বদলে না যায়, সেটিও পরীক্ষা করুন।
ক্লায়েন্ট ও ফ্রিল্যান্সারের দায়িত্ব কীভাবে ভাগ করবেন?
প্রাপক সঠিক জমা নির্দেশনা দেবেন; প্রেরক সেই নির্দেশনা অনুযায়ী নিজের উত্তোলন পাতায় একই সম্পদ ও নেটওয়ার্ক বেছে চূড়ান্ত অঙ্ক যাচাই করবেন। দুজনেই শেষ নিশ্চিতকরণের দায় ভাগ করেন। “আপনি ঠিকানা দিয়েছেন, তাই সব দায় আপনার” বা “আমি পাঠিয়েছি, তাই পেমেন্ট সম্পূর্ণ”—দুটি বাক্যই বাস্তব পর্যায়গুলোকে অতিরিক্ত সরল করে।
কাজের চুক্তিতে নেটওয়ার্ক ফি, ভুল নেটওয়ার্ক, পরীক্ষামূলক পেমেন্ট এবং পাওনা নিষ্পত্তির সংজ্ঞা লেখা যায়। নিষ্পত্তি কি ব্লকচেইন নিশ্চিতকরণে, নাকি প্রাপকের প্ল্যাটফর্মে ব্যবহারযোগ্য জমা হওয়ার পরে সম্পন্ন হবে? বিরোধ কমাতে প্রশ্নটি আগে ঠিক করুন। ক্লায়েন্ট অন্য নেটওয়ার্ক চাইলে প্রাপক নতুন নির্দেশনা দেবেন; ক্লায়েন্ট নিজের সুবিধায় নেটওয়ার্ক বদলে পুরোনো ঠিকানা ব্যবহার করবেন না।
পেমেন্ট সম্পূর্ণ কখন বলবেন?
সবচেয়ে পরিষ্কার সংজ্ঞা হলো: সম্মত নেটওয়ার্কে লেনদেন সফল, প্রাপকের প্ল্যাটফর্মে ব্যবহারযোগ্য ব্যালান্স জমা হয়েছে এবং ইনভয়েস অনুযায়ী নিট অঙ্ক মিলেছে। ব্যবসায়িক চুক্তি অন্য সংজ্ঞা নিতে পারে, তবে তা আগে লেখা দরকার। অপেক্ষমাণ জমাকে পরিশোধিত বললে খাতা ও ক্লায়েন্টের হিসাব মেলে না।
প্রাপ্ত অঙ্ক কম হলে ফি বহনের নিয়ম দেখুন। ভুল অঙ্ক আর ভুল নেটওয়ার্ক আলাদা সমস্যা। প্রথমটি অতিরিক্ত পেমেন্ট বা ইনভয়েস সংশোধনে মিটতে পারে; দ্বিতীয়টি প্রযুক্তিগত পুনরুদ্ধারের বিষয়। দুটি একসঙ্গে মিশিয়ে ক্লায়েন্টের কাছে অস্পষ্ট অভিযোগ পাঠাবেন না।
কোন পরিস্থিতিতে সঙ্গে সঙ্গে থামবেন?
নেটওয়ার্ক, টোকেন, ঠিকানা বা সমর্থনের যেকোনো একটি অস্পষ্ট হলে পেমেন্ট থামান। নিচের কোনো সংকেত দেখলে পাঠানোর বোতাম চাপবেন না:
- প্রাপক TRC20 বলেছেন, কিন্তু ঠিকানা 0x দিয়ে শুরু এবং ব্যাখ্যা নেই।
- ERC20 নির্দেশনার ঠিকানা ক্লায়েন্ট BEP20 হিসেবে ব্যবহার করতে চাইছেন।
- জমা পাতায় নেটওয়ার্ক স্থগিত বা অনুপলভ্য।
- প্ল্যাটফর্ম নির্দিষ্ট টোকেন বা কনট্র্যাক্ট নিয়ে সতর্ক করছে।
- চূড়ান্ত নিশ্চিতকরণ পাতার প্রাপক ঠিকানা মূল নির্দেশনার সঙ্গে মিলছে না।
- Memo/tag চাওয়া হয়েছে, কিন্তু কী বসবে স্পষ্ট নয়।
- পরীক্ষামূলক অঙ্ক ন্যূনতম জমার নিচে হতে পারে।
- ক্লায়েন্ট তাড়াহুড়ো করাচ্ছেন এবং যাচাই বাদ দিতে বলছেন।
- কেউ ব্যক্তিগত নিরাপত্তা তথ্য বা দূরবর্তী প্রবেশাধিকার চাইছেন।
- সরকারি সহায়তা ও পর্দার তথ্য পরস্পর বিরোধী।
থামা মানে পেমেন্ট বাতিল করা নয়। এটি তথ্যের ঘাটতি পূরণ করা। জমা পাতা আবার খুলুন, সরকারি সহায়তা লেখা পড়ুন, সহায়তার উত্তর নিন এবং ক্লায়েন্টের সঙ্গে সংশোধিত নির্দেশনা লিখিতভাবে মিলান। অস্পষ্টতা না কাটলে অন্য সমর্থিত পেমেন্ট পদ্ধতি নিয়ে ক্লায়েন্টের সঙ্গে নতুনভাবে সম্মত হন। এই সিদ্ধান্ত কেবল সমর্থিত, স্বচ্ছ ও নথিবদ্ধ পেমেন্টের জন্য।
দ্রুত ব্যবহারযোগ্য পেমেন্ট-পূর্ব নিশ্চিতকরণ কার্ড কী?
নিচের কার্ড পূর্ণ হলে তবেই পেমেন্ট নির্দেশনা প্রস্তুত। এটিকে ইনভয়েসের নোট বা ক্লায়েন্টের বার্তায় পেস্ট করে প্রতিটি ঘর নিজেরা যাচাই করতে পারেন।
- সম্পদ দুপক্ষে USDT
- প্রাপক জমা পাতা আজ খোলা হয়েছে
- প্রাপকের নেটওয়ার্কের নির্দিষ্ট নাম লেখা হয়েছে
- প্রেরকের উত্তোলন পাতায় একই নেটওয়ার্ক আছে
- পূর্ণ ঠিকানা কপি করে অংশে অংশে মিলেছে
- Memo/tag-এর প্রয়োজন দেখা হয়েছে
- টোকেন কনট্র্যাক্টের সতর্কতা থাকলে যাচাই হয়েছে
- জমা ও উত্তোলন অবস্থা সক্রিয়
- ন্যূনতম অঙ্ক ও নিশ্চিতকরণের বিজ্ঞপ্তি পড়া হয়েছে
- ফি কে বহন করবেন লেখা আছে
- চূড়ান্ত প্রাপ্য অঙ্ক ইনভয়েসের সঙ্গে মেলে
- পরীক্ষামূলক পেমেন্ট হবে কি না সিদ্ধান্ত লেখা আছে
- হ্যাশ ও রসিদ কোথায় রাখা হবে ঠিক আছে
- কোনো অস্পষ্টতা নেই; থাকলে পেমেন্ট স্থগিত
কার্ড পূরণ মানেই ব্লকচেইন লেনদেন ফিরিয়ে আনার নিশ্চয়তা নয়। এর কাজ ভুল বোঝাবুঝি ও বাদ পড়া ঘর কমানো। প্রতিটি ঘরে টিক দেওয়ার আগে সত্যিই পর্দা দেখুন; পরে যাচাইয়ের তারিখ ও দুই পক্ষের নিশ্চিতকরণ বার্তা রাখুন।
সাধারণ ভুল ধারণার সরাসরি উত্তর কী?
| প্রশ্ন | সংক্ষিপ্ত উত্তর |
|---|---|
| USDT ঠিকানা দিলেই কি যেকোনো নেটওয়ার্ক নেওয়া যায়? | না। ঠিকানার সঙ্গে প্রাপকের বর্তমান জমা পাতায় দেখানো নির্দিষ্ট নেটওয়ার্ক লাগবে। |
| 0x গঠন মিললেই কি ERC20 জমা নিশ্চিত? | না। গঠন মেলা শুধু প্রাথমিক পরীক্ষা; বর্তমান জমা সমর্থনের প্রমাণ নয়। |
| TRC20 কি সব সময় সবচেয়ে সস্তা? | না। রিসোর্স, পাঠানোর পদ্ধতি ও প্ল্যাটফর্মের উত্তোলন ফি বদলাতে পারে। |
| BEP20 কি Tether-এর তালিকাভুক্ত নেটওয়ার্ক সংস্করণ? | এই লেখার উৎস তা প্রমাণ করে না; নির্দিষ্ট প্ল্যাটফর্মের বর্তমান সমর্থন যাচাই করুন। |
| পরীক্ষামূলক পেমেন্ট সফল হলেই কি পরের অঙ্ক নিশ্চিত? | না। পরের লেনদেনের আগে সব ঘর আবার মিলবে। |
| এক্সপ্লোরারে সফল মানেই কি অর্থ ব্যবহারযোগ্য? | না। প্রাপকের প্ল্যাটফর্মে ব্যবহারযোগ্য জমা হওয়াও দেখতে হবে। |
| বিন্যাস যাচাই পাস করলেই কি ঠিকানা নিরাপদ? | না। এটি মালিকানা, টোকেন বা প্ল্যাটফর্ম সমর্থন প্রমাণ করে না। |
নেটওয়ার্ক বাছাইয়ের একটি সিদ্ধান্তগাছ কেমন?
প্রথম প্রশ্ন ফি নয়, প্রাপক সমর্থন। সিদ্ধান্তগাছটি এভাবে পড়ুন:
- প্রাপক কি USDT জমা নিচ্ছে?
- না বা অনিশ্চিত → থামুন।
- হ্যাঁ → নেটওয়ার্কের তালিকা দেখুন।
- প্রাপকের গ্রহণযোগ্য নেটওয়ার্ক কি প্রেরকের উত্তোলন পাতায়ও আছে?
- না → অন্য দুই-পক্ষ-সমর্থিত পদ্ধতি নিয়ে সম্মত হন।
- হ্যাঁ → নির্দিষ্ট নাম ও ঠিকানা নিন।
- টোকেন, ঠিকানা এবং memo বা tag-এর প্রয়োজন কি স্পষ্ট?
- না → সরকারি সহায়তা দিয়ে পরিষ্কার করুন।
- হ্যাঁ → ফি ও প্রাপকের অঙ্ক দেখুন।
- নতুন বা বড় পথ কি?
- হ্যাঁ → ন্যূনতম ও দুই দফা ফি দেখে পরীক্ষামূলক পেমেন্ট বিবেচনা করুন।
- না → চূড়ান্ত ঘরগুলো যাচাই করুন।
- চূড়ান্ত নিশ্চিতকরণ পাতার সব ঘর কি নির্দেশনার সঙ্গে মেলে?
- না → পাঠাবেন না।
- হ্যাঁ → পাঠিয়ে হ্যাশ ও প্ল্যাটফর্মে জমার তথ্য নথিভুক্ত করুন।
এই গাছ কোনো নেটওয়ার্কের বিজ্ঞাপন নয়। ERC20, TRC20 বা BEP20—যে শাখাই হোক, একই প্রমাণের মান প্রযোজ্য। প্ল্যাটফর্মের তালিকায় নেটওয়ার্ক নেই অথচ ক্লায়েন্ট বলেন “আমার দিক থেকে যায়”—এটি প্রাপকের সমর্থনের ঘাটতি পূরণ করে না।
শেষবার মনে রাখার নিয়ম কী?
এখন করণীয় হলো বর্তমান জমা পাতা খুলে USDT, নির্দিষ্ট নেটওয়ার্ক, পূর্ণ ঠিকানা, memo বা tag এবং প্রাপ্য অঙ্ক একবারে মিলিয়ে ক্লায়েন্টকে লিখিত নির্দেশনা দেওয়া; ERC20-এ gas, TRC20-এ Bandwidth–Energy–TRX এবং BEP20-এ নির্দিষ্ট প্ল্যাটফর্মের বর্তমান সমর্থন দেখে ফি বোঝা; প্রয়োজনে পরীক্ষামূলক পেমেন্টের দুই দফা খরচ বিবেচনা করা; তারপর হ্যাশ ও প্ল্যাটফর্মে জমার রসিদ রাখা। একটি ঘরও অস্পষ্ট থাকলে পাঠাবেন না—সরকারি তথ্য নিয়ে আবার মিলিয়ে তবেই এগোন।
