USDT কোট ও হাতে পাওয়া অর্থের হিসাব

হালনাগাদ: ১১ আগস্ট ২০২৬

ক্লায়েন্ট বললেন, “আমি USDT-তে পেমেন্ট করব—আপনি কত নেবেন?” প্রশ্নটি শুনতে সহজ, কিন্তু উত্তরটি শুধু ডলারের অঙ্ক লিখে দেওয়া নয়। কোন নেটওয়ার্কে টাকা আসবে, প্ল্যাটফর্ম কত শতাংশ কাটবে, নেটওয়ার্ক খরচ কার অংশ থেকে যাবে, পরে মূল্য ব্যবধান কত ধরা হবে এবং সব কাটার পরে আপনার লক্ষ্য পূরণ হবে কি না—এই পাঁচটি বিষয় আগে আলাদা করতে হয়। এই লেখায় সেই হিসাবটি কাগজে, স্প্রেডশিটে বা একটি সাধারণ ক্যালকুলেটরে করার পদ্ধতি দেখানো হয়েছে। এখানে কোনো হার, ফি বা USDT মূল্য সরাসরি বাজার থেকে নেওয়া হয় না। উদাহরণের প্রতিটি সংখ্যা ব্যবহারকারীর দেওয়া কাল্পনিক ইনপুট; এগুলো বর্তমান বাজারদর, কোনো প্ল্যাটফর্মের চলতি চার্জ বা ভবিষ্যৎ ফলের প্রতিশ্রুতি নয়।

আরও গুরুত্বপূর্ণ একটি সীমা আছে। অঙ্ক মিলে গেলেই লেনদেন অনুমোদিত হয়ে যায় না। বাংলাদেশ ব্যাংকের FE Circular No. 24 বাংলাদেশ থেকে, বাংলাদেশে বা বাংলাদেশের ভেতরে ভার্চুয়াল অ্যাসেট বা ভার্চুয়াল কারেন্সি অর্জনের উদ্দেশ্যে লেনদেন অনুমোদিত নয় বলে সতর্ক করেছে। উৎস যাচাইয়ের সময়: 2026-08-10T18:21:00+08:00। তাই নিচের হিসাব একটি কোট ও রেকর্ড তৈরির কাঠামো, কোনো আইনি অনুমতি বা বৈদেশিক মুদ্রা লেনদেনের পথনির্দেশ নয়। এই লেখা আইনি বা কর পরামর্শও নয়। নিজের পরিস্থিতি, কাজের ধরন ও অর্থ গ্রহণের বৈধ পথ সম্পর্কে বাংলাদেশ ব্যাংকের বর্তমান নির্দেশনা এবং আপনার অনুমোদিত ডিলার ব্যাংক বা উপযুক্ত পেশাদারের পরামর্শ যাচাই করুন।

কোন প্রশ্নের উত্তর আগে খুঁজবেন?

• কোট করার আগে কোন পাঁচটি ইনপুট লিখবেন?
• মোট পেমেন্ট থেকে প্রকৃত প্রাপ্তি কীভাবে বের হবে?
• হাতে ৫০০ ডলার রাখতে ক্লায়েন্টকে কত বলবেন?
• নেটওয়ার্ক ফি ক্লায়েন্ট দিলে সূত্র কীভাবে বদলাবে?
• শতাংশ ফি ও স্প্রেড কেন শুধু যোগ করা যাবে না?
• একবারে ও ভাগ করে পেমেন্টের খরচ কীভাবে তুলনা করবেন?
• ভুল, অসম্পূর্ণ বা ঋণাত্মক ইনপুট কীভাবে আটকাবেন?
• কোন নেটওয়ার্কে USDT আসবে তা কোটে কেন লিখবেন?
• পেমেন্টের সময়কার ফিয়াট মূল্য ও প্রমাণ কীভাবে রাখবেন?
• ক্লায়েন্টকে পাঠানোর কোটে কোন ভাষা ব্যবহার করবেন?
• এই হিসাব কোথায় থামে এবং পেশাদার যাচাই কোথায় শুরু হয়?

USDT কোট বলতে এখানে ঠিক কী বোঝানো হচ্ছে?

USDT কোট হলো কাজের মূল্য, সম্ভাব্য কর্তন ও প্রাপ্তির একটি লিখিত পূর্বহিসাব। এটি ইনভয়েসের বিকল্প নয়, বিনিময় হারের নিশ্চয়তা নয় এবং কোনো নির্দিষ্ট সেবার অনুমোদনও নয়। ভালো কোটে ক্লায়েন্ট বুঝবেন তিনি কত পাঠাবেন; ফ্রিল্যান্সার বুঝবেন কোন শর্ত সত্য হলে কত অবশিষ্ট থাকবে। অঙ্কের সঙ্গে সম্পদ, নেটওয়ার্ক, ফি বহনকারী পক্ষ, সময় ও ব্যবহৃত রেফারেন্স রেটও লেখা থাকে।

“৫০০ USDT চাই” বলা এবং “সব খরচের পরে ৫০০ ডলারের সমমূল্য রাখতে চাই” বলা একই কথা নয়। প্রথম বাক্যে পাঠানো টোকেনের পরিমাণ বোঝায়। দ্বিতীয় বাক্যে একটি লক্ষ্য প্রাপ্তি আছে, যার জন্য বিপরীত হিসাব দরকার। USDT সাধারণত ডলারের কাছাকাছি মূল্য ধরে রাখার উদ্দেশ্যে তৈরি হলেও একটি কোটে ১ USDT-কে বিনা যাচাইয়ে ঠিক ১ USD ধরে নেওয়া উচিত নয়। পেমেন্টের সময় আপনি যে মূল্য বা হিসাবরক্ষণের রেট দেখেছেন সেটিকে আলাদা ইনপুট হিসেবে লিখুন। এতে পরে কেউ “কোন দরে হিসাব করেছিলেন?” জিজ্ঞেস করলে উত্তরটি অনুমাননির্ভর থাকে না।

কোটের কাজ মূলত অনিশ্চয়তা প্রকাশ করা। কোনো চার্জ এখনও জানা না থাকলে শূন্য বসিয়ে লুকিয়ে রাখবেন না; “নিশ্চিত নয়” লিখুন এবং হিসাবকে খসড়া রাখুন। একটি অজানা নেটওয়ার্ক ফি কিংবা অনির্ধারিত প্ল্যাটফর্ম হার ফলকে এতটাই বদলাতে পারে যে সুন্দর একটি দশমিক সংখ্যা মিথ্যা নিশ্চয়তা তৈরি করে। তাই কোটের মান শুধু সূত্রে নয়, ইনপুটের অবস্থা পরিষ্কার রাখায়।

কোট করার আগে কোন ছয়টি মূল চলক লিখবেন?

লক্ষ্য, ফি ও মূল্যকে একই সূত্রে স্পষ্ট রাখতে ছয়টি চলক আলাদা লিখুন। এই লেখার প্রতিটি হিসাব নিচের সংজ্ঞাই মেনে চলে:

প্রতীক	অর্থ	বৈধ মান ও একক
G	ক্লায়েন্টের মোট পেমেন্ট	শূন্যের বেশি USDT
P	মোট পেমেন্টের ওপর প্ল্যাটফর্মের আনুপাতিক ফি	দশমিক; 0 ≤ P < 1
N	প্রাপকের USDT থেকে কাটা স্থির নেটওয়ার্ক ফি	USDT; N ≥ 0
R	প্রতি ১ USDT-এর ব্যবহারকারী-দেওয়া USD রেফারেন্স মূল্য	USD/USDT; R > 0
S	রেফারেন্স মূল্য থেকে মূল্য ব্যবধানের হার	দশমিক; 0 ≤ S < 1
T	সব কর্তনের পরে লক্ষ্য নিট প্রাপ্তি	USD; T > 0

এককগুলো আর বদলাবে না: G ও N USDT, R হলো USD/USDT, আর T USD। ফলে G থেকে আনুপাতিক ফি ও N বাদ দিলে USDT থাকে; সেটিকে R দিয়ে গুণ করলে USD হয়; তারপর S প্রয়োগ করলে প্রত্যাশিত নিট প্রাপ্তি USD-তে আসে। N কোনো নিট ফলের প্রতীক নয়—এটি কেবল স্থির নেটওয়ার্ক ফি।

P শুধু মোট পেমেন্টের অনুপাতে কাটা প্ল্যাটফর্ম ফি। স্থির চার্জ এতে ঢুকবে না। N একবার কাটে নাকি প্রতিটি ট্রান্সফারে কাটে, তা লিখুন। R ও S ব্যবহারকারী হাতে লিখবেন; সাইট কোনো লাইভ মূল্য বা ফি টানে না। প্রতিটি মানের পাশে উৎস, দেখা সময় এবং “আনুমানিক” বা “নিশ্চিত” অবস্থা থাকলে পরে কোটটি পুনরায় পরীক্ষা করা যায়।

মোট পেমেন্ট থেকে প্রকৃত প্রাপ্তি কীভাবে বের করবেন?

নেটওয়ার্ক খরচ প্রাপকের অঙ্ক থেকে কাটা হলে সামনের সূত্রটি হলো:

প্রত্যাশিত নিট প্রাপ্তি (USD) = ((G × (1 − P)) − N) × R × (1 − S)

একক দিয়েও সূত্রটি পরীক্ষা করা যায়। প্রথম বন্ধনীর ফল USDT, R দিয়ে গুণের পর ফল USD, আর (1 − S) এককহীন গুণক। কোনো ধাপে USD থেকে N বাদ পড়লে বা T-কে USDT বলা হলে বুঝবেন সংজ্ঞা ভেঙেছে। কাগজ, স্প্রেডশিট ও ক্যালকুলেটর—তিন জায়গাতেই এই একক-পরীক্ষা একই থাকবে।

ধাপগুলো ইচ্ছাকৃতভাবে আলাদা:

1. মোট পেমেন্ট G থেকে আনুপাতিক ফি কেটে G × (1 − P) USDT বের করুন।
2. সেই অবশিষ্ট থেকে স্থির নেটওয়ার্ক ফি N USDT বাদ দিন।
3. অবশিষ্ট USDT-কে R USD/USDT দিয়ে গুণ করুন।
4. মূল্য ব্যবধান ধরতে USD ফলকে (1 − S) দিয়ে গুণ করুন।

ধরা যাক ব্যবহারকারী পরীক্ষামূলক ইনপুট দিলেন: G = 600 USDT, P = 0.08, N = 1 USDT, R = 0.998 USD/USDT, S = 0.012। প্রথমে 600 × 0.92 = 552 USDT, তারপর 552 − 1 = 551 USDT। এরপর 551 × 0.998 = 549.898 USD; সবশেষে 549.898 × 0.988 = 543.299224 USD। এটি কোনো চলতি মূল্য বা ফি নয়; পাঁচটি ব্যবহারকারী-দেওয়া পরীক্ষামূলক ইনপুটের ফল।

এই মডেলে N USDT রূপান্তরের আগে কাটা হয় এবং S USD রেফারেন্স মূল্যের ওপর প্রয়োগ হয়। বাস্তব প্ল্যাটফর্মে কাটার ভিত্তি আলাদা হলে আগে সেই প্রবাহ বুঝে নিন; অজানা নিয়মকে এই সূত্রের সঙ্গে জোর করে মেলাবেন না। এই নিবন্ধের সব পরবর্তী উদাহরণ একই সংজ্ঞা ব্যবহার করে, ফলে কোথাও N-কে ফল বা T-কে USDT ধরা হবে না।

হাতে নির্দিষ্ট অঙ্ক রাখতে বিপরীত কোট কীভাবে করবেন?

লক্ষ্য নিট প্রাপ্তি T USD জানা থাকলে বিপরীত কোটের সূত্র:

G = (T ÷ (R × (1 − S)) + N) ÷ (1 − P)

প্রথমে T ÷ (R × (1 − S)) করে লক্ষ্য পূরণের জন্য দরকারি ফি-পরবর্তী USDT বের হয়। তার সঙ্গে N USDT যোগ করে স্থির কর্তন ফিরিয়ে দেওয়া হয়; শেষে (1 − P) দিয়ে ভাগ করে ক্লায়েন্টের মোট পেমেন্ট G পাওয়া যায়।

সামনের সূত্র যে ক্রমে অঙ্ককে বদলায়, বিপরীত সূত্র সেই ক্রম উল্টো পথে ফেরায়। মাঝখানে গোল করবেন না এবং P + S একসঙ্গে বাদ দেবেন না। হিসাবের ভেতরে পূর্ণ নির্ভুলতা রাখুন। চূড়ান্ত G সর্বোচ্চ ছয় দশমিক USDT পর্যন্ত দেখানো যায়; গ্রহণকারী প্ল্যাটফর্ম যত দশমিক সমর্থন করে, লক্ষ্য থেকে কম না পড়তে সেই ক্ষুদ্রতম এককে ওপরে গোল করে কোট দিন। ফিয়াট ফল সাধারণত দুই দশমিকে দেখালেও মিল যাচাইয়ের জন্য কাঁচা মান রেখে দিন।

সূত্রটি কেবল তখনই অর্থপূর্ণ, যখন 0 ≤ P < 1, N ≥ 0, R > 0, 0 ≤ S < 1, T > 0 এবং R × (1 − S) > 0। (1 − P) বা R × (1 − S) শূন্য কিংবা ঋণাত্মক হলে ভাগ করা যায় না। কেউ ১০% বোঝাতে 10 লিখলে ক্যালকুলেটর সেটিকে ১০০০% ধরে ফেলতে পারে; তাই ইনপুট ঘর দশমিক নেয় নাকি শতাংশ নেয়, সেটি স্পষ্ট লেবেলে জানান।

“আমি হাতে ৫০০ ডলার রাখতে চাই” উদাহরণটি কীভাবে কাজ করে?

ব্যবহারকারীর দেওয়া উদাহরণমূলক হার দিয়ে বিপরীত সূত্র চালালে লক্ষ্য ৫০০-এর জন্য মোট কোট বের হয়; এটি কোনো লাইভ দর নয়। ধরুন, শুধু পদ্ধতি বোঝাতে ব্যবহারকারী লিখলেন:

• লক্ষ্য T = 500 USD
• প্ল্যাটফর্ম ফি P = 0.10
• প্রাপকের অঙ্ক থেকে স্থির নেটওয়ার্ক ফি N = 1 USDT
• হাতে দেওয়া রেফারেন্স মূল্য R = 1 USD/USDT
• মূল্য ব্যবধান S = 0.015

তাহলে G = (500 ÷ (1 × 0.985) + 1) ÷ 0.90। 500 ÷ 0.985 = 507.614213... USDT; N যোগ করলে 508.614213... USDT; (1 − P) দিয়ে ভাগ করলে 565.126903... USDT। অভ্যন্তরীণ হিসাবে পূর্ণ নির্ভুলতা থাকবে। ছয় দশমিক পর্যন্ত ফল 565.126904 USDT করে ওপরে গোল করা যায়; প্ল্যাটফর্ম দুই দশমিক নিলে লক্ষ্য থেকে কম না পড়তে কোট হবে 565.13 USDT।

সামনের সূত্রে যাচাই: ((565.13 × 0.90) − 1) × 1 × 0.985 = 500.002745 USD। প্রদর্শিত ফিয়াট ফল দুই দশমিকে 500.00 USD, আর কাঁচা মানটি মিল পরীক্ষায় থাকবে। R = 1 এখানে সম্পূর্ণ ইনপুটের একটি ব্যবহারকারী-দেওয়া প্রদর্শনী মান, USDT সব সময় ১ USD—এমন দাবি নয়। বাস্তবে R, P, N বা S বদলালে ফলও বদলাবে। শুধু 565.13 পাঠাবেন না; P, N, R, S ও T-এর মানও সঙ্গে দিন।

T সব সময় USD, তাই আলাদা “USDT লক্ষ্য” বানানোর দরকার নেই। R-ই USD লক্ষ্যকে সূত্রের ভেতরে USDT-তে ফিরিয়ে আনে। R কখন, কোথা থেকে এবং কোন দিকের মূল্য হিসেবে নেওয়া হয়েছে লিখুন। কেনার দর, বিক্রির দর ও মধ্যমূল্য এক নয়; আপনার প্রাপ্তির সঙ্গে সম্পর্কিত ব্যবহারকারী-দেওয়া মূল্যটিই দরকার।

শতাংশ ফি ও স্প্রেড শুধু যোগ করলে ভুল কোথায় হয়?

P ও S ভিন্ন ভিত্তির ওপর ধারাবাহিকভাবে কাজ করে, তাই সাধারণভাবে মোট প্রভাব P + S নয়। N বাদ দিলে USDT থেকে USD ফলের গুণক (1 − P) × R × (1 − S)। P = 0.10, R = 1 এবং S = 0.015 হলে গুণক 0.90 × 1 × 0.985 = 0.8865। শতাংশ অংশের যৌগিক প্রভাব ১১.৩৫%, সরল যোগে ১১.৫% নয়।

স্থির নেটওয়ার্ক ফি এই গুণকের অংশ নয়। N = 1 USDT ছোট পেমেন্টে তুলনামূলক বড়, বড় পেমেন্টে ছোট প্রভাব ফেলে। ২০ USDT-তে ১ USDT হলো ৫%, কিন্তু ৫০০ USDT-তে ০.২%। তাই আনুপাতিক ফি ও স্থির অঙ্ক দুই সারিতে দেখান।

আরও একটি ভুল হলো স্প্রেডকে আলাদা চার্জ না ভেবে “USDT তো ডলার” বলে বাদ দেওয়া। স্প্রেড এখানে কোনো নির্দিষ্ট প্রতিষ্ঠানের ফি দাবি করছে না; এটি আপনার নির্বাচিত রেফারেন্স মূল্য এবং বাস্তবে যে মূল্য ধরে হিসাব করছেন তার ব্যবধান প্রকাশের ঘর। ব্যবধান জানা না থাকলে 0 বসানোর আগে লিখুন যে ফলটি স্প্রেড বাদ দেওয়া প্রাথমিক হিসাব। পরে প্রকৃত রেকর্ড এলে আগের কোট মুছবেন না; কোট ও বাস্তব ফল পাশাপাশি রাখুন।

নেটওয়ার্ক ফি ক্লায়েন্ট আলাদা দিলে সূত্র কীভাবে বদলায়?

প্রেরক নেটওয়ার্ক খরচ মোটের বাইরে বহন করলে এবং প্রাপকের USDT থেকে কিছু না কাটলে এই মডেলে N = 0। তখন প্রত্যাশিত নিট প্রাপ্তি (USD) = G × (1 − P) × R × (1 − S) এবং G = T ÷ (R × (1 − S)) ÷ (1 − P)। প্রেরকের আলাদা খরচ কোটে লিখবেন, কিন্তু প্রাপকের সূত্রে আবার কাটবেন না।

কখনও প্রেরণপর্দায় ৫০০ পাঠানো দেখালেও প্রাপক ৪৯৯ পান; আবার কখনও প্রেরকের ব্যালেন্স থেকে ৫০১ কেটে প্রাপক ৫০০ পান। প্রথম ক্ষেত্রে প্রাপকের কর্তন N হতে পারে, দ্বিতীয় ক্ষেত্রে N = 0 এবং প্রেরকের আলাদা খরচ আছে। কোট চূড়ান্ত করার আগে “প্রাপক পাবেন” ও “মোট কাটা হবে” অঙ্ক দুটি আলাদা করে দেখুন।

খরচ ভাগ হলে শুধু প্রাপকের USDT থেকে কাটা অংশ N-এ বসবে। প্রেরকের অতিরিক্ত খরচ কোটের আলাদা সারিতে থাকবে। একই ফি দুইবার গণনা ঠেকাতে “প্রাপকের কর্তন” এবং “প্রেরকের অতিরিক্ত খরচ” আলাদা লিখুন।

কোটের একক কীভাবে একই রাখবেন?

একক স্থির রাখলেই ভুল ধরা সহজ: G ও N USDT, R USD/USDT, T ও সূত্রের ফল USD। G = 600 USDT, N = 1 USDT, R = 0.998 USD/USDT এবং T = 500 USD একই সূত্রে অর্থপূর্ণ। কোনো ঘরে BDT বসালে সেটি আর এই USD মডেল থাকে না।

BDT-তে আলাদা হিসাবরক্ষণ মূল্য চাইলে USD ফলকে নথিভুক্ত USD/BDT রেট দিয়ে পরে রূপান্তর করুন; সেই দ্বিতীয় রেটকে R বলবেন না। R কেবল প্রতি USDT-এর USD মূল্য। এটি ব্যবহারকারী প্রবেশ করাবেন, সাইট কোনো API থেকে টানে না। উৎসের নাম, মূল্য দেখার সময়, কেনা বা বিক্রির দিক এবং একক নোট করুন। শুধু “ডলার রেট” লিখলে পরে সেটি USDT/USD নাকি USD/BDT বোঝা যায় না।

ফিয়াট মূল্য রাখা মানে ব্যক্তিগতভাবে মুদ্রা বদলের নির্দেশ নয়। এটি আয়ের মুহূর্তের একটি হিসাবরক্ষণ রেকর্ড। কোন মূল্য স্থানীয় কর, ব্যাংক বা আইনি নথিতে গ্রহণযোগ্য হবে তা সংশ্লিষ্ট কর্তৃপক্ষ বা পেশাদার নির্ধারণ করবেন। ক্যালকুলেটরের ব্যবহারকারী ইনপুট কেবল তার নিজের নথির একটি উপাদান; সরকারি গ্রহণযোগ্যতার সনদ নয়।

প্ল্যাটফর্মের শতাংশ ফি কোন ভিত্তিতে বসাবেন?

P মোট পেমেন্ট G-এর ওপর কাটা কার্যকর আনুপাতিক প্ল্যাটফর্ম ফি। কোনো সেবা অন্য ভিত্তিতে চার্জ নিলে আগে তার নিয়ম অনুযায়ী কার্যকর হার নির্ধারণ করুন; অনুমান করে সব চার্জ P-তে গুঁজবেন না। স্থির চার্জ N-এ বা কোটের বাইরে আলাদা থাকবে।

একাধিক আনুপাতিক চার্জ ধারাবাহিকভাবে কাটলে তাদের যৌগিক প্রভাব থেকে একটি কার্যকর P বের করে এই সূত্রে দিন। চার্জগুলো সরলভাবে যোগ করার আগে তারা একই ভিত্তির ওপর স্বাধীনভাবে কাটা কি না দেখুন। প্ল্যাটফর্মের বর্ণনা অস্পষ্ট হলে P অনুপস্থিত রাখুন এবং কোটকে খসড়া বলুন।

হার অনিশ্চিত হলে P-এর কম, মাঝারি ও বেশি ব্যবহারকারী-দেওয়া মান দিয়ে আলাদা দৃশ্য চালাতে পারেন। এগুলো পূর্বাভাস নয়, সংবেদনশীলতা পরীক্ষা। কোনো প্রতিষ্ঠানের নামের পাশে প্রমাণ ছাড়া হার বসাবেন না; চূড়ান্ত কোটে লিখিতভাবে যাচাই করা ইনপুটই থাকবে।

মূল্য ব্যবধান S কীভাবে বুঝবেন এবং লিখবেন?

মূল্য ব্যবধান হলো R থেকে কার্যকর মূল্য কমে যাওয়ার আনুপাতিক হার। ধরা যাক ব্যবহারকারী R = 1 USD/USDT দিয়েছেন, কিন্তু তার পরীক্ষামূলক কার্যকর মূল্য 0.98 USD/USDT; তখন S = 1 − (0.98 ÷ 1) = 0.02, অর্থাৎ ২%। এটি কোনো বাজারের চলতি ব্যবধান নয়।

স্প্রেডের দিক উল্টো করলে ভুল হতে পারে। আপনি যা পাবেন সেটির দর ব্যবহার করতে হবে, অন্য পক্ষ যে দরে কিনছেন সেটি নয়। কোনো পর্দায় buy ও sell দুটি দর থাকলে আপনার প্রবাহের সঙ্গে মিলিয়ে সঠিক দিক বাছুন। পর্দা থেকে একটি সংখ্যা কপি করলেই তার অর্থ পরিষ্কার হয় না। কোট নোটে “প্রাপ্তি/বিক্রয় দিকের ব্যবহারকারী-প্রদত্ত রেফারেন্স” এর মতো সংক্ষিপ্ত ব্যাখ্যা দিন।

মূল্য ব্যবধান নিশ্চিত না হলে S-এর একটি কম মান ও একটি বেশি মান দিয়ে দুইটি আলাদা ফল বের করুন। বেশি S-এ নিট প্রাপ্তি কম হবে। প্রতিটি ফলের পাশে ব্যবহৃত S লিখুন; অজানা হারকে শূন্য ধরে নির্ভুলতার ভান করবেন না।

নেটওয়ার্ক খরচ স্থির ধরা হলেও কেন যাচাই দরকার?

সূত্রে N একটি স্থির USDT ইনপুট, কিন্তু বাস্তব নেটওয়ার্ক খরচ সব সময় স্থির নয়। Ethereum-এর সরকারি ডকুমেন্টেশন অনুযায়ী গ্যাস ফি ব্যবহৃত গ্যাস ও প্রতি গ্যাস ইউনিটের মূল্যের ওপর নির্ভর করে; তাই ERC20 পাঠানোর খরচকে চিরস্থায়ী একটি সংখ্যায় বেঁধে রাখা ঠিক নয়। বিস্তারিত ধারণার জন্য Ethereum gas documentation দেখা যায়।

TRON-এর নথিতে লেনদেনে Bandwidth এবং স্মার্ট-কন্ট্রাক্ট কলে Energy ব্যবহারের কথা আছে; পর্যাপ্ত রিসোর্স না থাকলে TRX বার্ন হতে পারে। ফলে TRC20-সংক্রান্ত খরচও “সব সময় শূন্য” বা “সব সময় একই” ধরে নেওয়া নিরাপদ নয়। TRON transaction documentation খরচের পেছনের রিসোর্স মডেলটি ব্যাখ্যা করে।

কোটের জন্য N হলো নির্দিষ্ট সময়ে ব্যবহারকারী বা প্ল্যাটফর্মে দেখা সম্ভাব্য প্রাপক-পক্ষের কর্তন। তার পাশে দেখা সময় লিখুন এবং পেমেন্টের আগে আবার যাচাইয়ের শর্ত রাখুন। ক্লায়েন্ট দেরি করলে পুরোনো N দিয়ে ফলের নিশ্চয়তা দেবেন না। কোটে লেখা থাকতে পারে “ফি ইনপুট পুনরায় যাচাই না হওয়া পর্যন্ত খসড়া”; বাজারের ভবিষ্যৎ মান নিশ্চিত করে এমন ভাষা থাকবে না।

USDT নামের সঙ্গে নেটওয়ার্ক লেখা কেন বাধ্যতামূলক?

USDT একটি টোকেনের নাম; কোন ব্লকচেইনে সেটি পাঠানো হবে, সেটি আলাদা তথ্য। Tether-এর USDT পরিচিতি টোকেনটি একাধিক ব্লকচেইনে বিদ্যমান থাকার বিষয়টি ব্যাখ্যা করে। তাই কোটে শুধু “USDT” লিখলে পেমেন্ট নির্দেশ অসম্পূর্ণ থাকে। “USDT—সম্মত নেটওয়ার্ক: ___” লিখে উভয় পক্ষের নিশ্চিতকরণ নিন।

ইস্যুয়ারের supported protocols page Ethereum-এর ERC20 ও TRON-এর TRC20 সম্পর্কিত প্রোটোকল তথ্য দেয়। তবে কোনো গ্রহণকারী প্ল্যাটফর্মে BEP20 লেখা অপশন দেখলেই সেটিকে ওই পৃষ্ঠায় তালিকাভুক্ত Tether deployment-এর সমার্থক ধরে নেওয়া যাবে না। BNB Smart Chain বা BEP20 গ্রহণের সক্ষমতা সরাসরি গ্রহণকারী প্ল্যাটফর্মে সম্পদ ও নেটওয়ার্ক জোড়া হিসেবে নিশ্চিত করতে হবে।

নেটওয়ার্ক ভুল হলে শুধু ফি হিসাব ভুল হয় না; অর্থ দৃশ্যমান না-ও হতে পারে বা পুনরুদ্ধার কঠিন হতে পারে। BNB Chain-এর tokens not showing FAQ সফল লেনদেন, প্রাপক, টোকেন এবং নেটওয়ার্ক যাচাই করতে বলে এবং BNB Smart Chain-এ পাঠানো টোকেন Ethereum Mainnet বা opBNB-এর নিচে না-ও দেখা যেতে পারে বলে ব্যাখ্যা করে। তাই নেটওয়ার্ক নিশ্চিত না হলে কোটের গাণিতিক অংশ প্রস্তুত রাখা যায়, কিন্তু ঠিকানা পাঠানো বা পেমেন্ট শুরু করা উচিত নয়।

ঠিকানা ও নেটওয়ার্ক নিশ্চিত না হলে কোটের অবস্থা কী হবে?

নেটওয়ার্ক বা গ্রহণ সমর্থন নিশ্চিত না হলে কোটকে “খসড়া—পেমেন্টের জন্য নয়” রাখুন। ক্লায়েন্টের কাছে চারটি আলাদা প্রশ্ন পাঠান: টোকেন কি USDT, পাঠানোর নেটওয়ার্ক কী, গ্রহণকারী সেবায় সেই একই নেটওয়ার্কে USDT deposit সমর্থিত কি না, এবং নেটওয়ার্ক খরচ কে বহন করবেন। চারটির একটি উত্তর অনিশ্চিত হলে অঙ্ক চূড়ান্ত করবেন না।

ঠিকানা মিলানোর সময় প্রথম ও শেষ কয়েকটি অক্ষর চোখে দেখে মিলিয়ে নেওয়া সহায়ক, কিন্তু এটি সম্পূর্ণ প্রযুক্তিগত বৈধতা বা মালিকানা প্রমাণ করে না। ঠিকানার ফরম্যাট দেখতে ঠিক হলেই নেটওয়ার্ক সমর্থিত—এমন নয়। কপি করার পরে অপ্রত্যাশিত পরিবর্তন হয়েছে কি না আবার দেখুন, কিন্তু কোনো ক্যালকুলেটরকে “অর্থ ফেরত আসবেই” ধরনের নিশ্চয়তা দিতে দেবেন না।

গ্রহণকারী প্ল্যাটফর্মে যদি deposit বন্ধ, maintenance, memo/tag প্রয়োজন বা সর্বনিম্ন জমার শর্ত দেখায়, কোটের কাজ থামান। এই লেখার সূত্র এসব অপারেশনাল শর্ত পরীক্ষা করে না। প্ল্যাটফর্মের প্রকাশ্য নির্দেশনা ও পেমেন্ট পর্দায় তথ্য মিললে তবেই পরবর্তী ধাপ বিবেচনা করুন। অনিশ্চয়তা থাকলে ছোট অঙ্ক পাঠিয়েও মূল অসামঞ্জস্য দূর হয় না; প্রথমে সমর্থন নিশ্চিত করাই দরকার।

একবারে পেমেন্ট আর ভাগ করে পেমেন্ট কীভাবে তুলনা করবেন?

প্রতিটি ট্রান্সফারে প্রাপকের স্থির ফি কাটলে ভাগ করা পেমেন্টে N বারবার প্রযোজ্য হয়। মোট পেমেন্ট G, অংশের সংখ্যা K, আনুপাতিক ফি P, প্রতি অংশের স্থির নেটওয়ার্ক ফি N, হাতে দেওয়া USD রেফারেন্স মূল্য R এবং মূল্য ব্যবধান S অপরিবর্তিত হলে:

ভাগ করলে প্রত্যাশিত নিট প্রাপ্তি (USD) = [G × (1 − P) − K × N] × R × (1 − S)

একবারে পাঠালে:

একবারে প্রত্যাশিত নিট প্রাপ্তি (USD) = [G × (1 − P) − N] × R × (1 − S)

দুইটির USD পার্থক্য [(K − 1) × N] × R × (1 − S)। আনুপাতিক ফি একই ভিত্তিতে থাকলে স্থির ফি পুনরাবৃত্তিই প্রধান পার্থক্য। কোনো প্ল্যাটফর্মে প্রতি অংশে ন্যূনতম চার্জ, স্তরভিত্তিক ফি বা ভিন্ন হার থাকলে এই সরল সূত্র যথেষ্ট নয়; প্রতিটি অংশের বাস্তব নিয়ম আলাদাভাবে পরীক্ষা করতে হবে।

ধরা যাক পরীক্ষামূলক ইনপুট G = 600 USDT, K = 3, P = 0.05, N = 1 USDT, R = 1 USD/USDT, S = 0.01। একবারে ফল [600 × 0.95 − 1] × 1 × 0.99 = 563.31 USD। তিন ভাগে ফল [600 × 0.95 − 3] × 1 × 0.99 = 561.33 USD। পার্থক্য [(3 − 1) × 1] × 1 × 0.99 = 1.98 USD। সব সংখ্যা ব্যবহারকারীর প্রদর্শনী ইনপুট, লাইভ ফি নয়।

ভাগ করার সিদ্ধান্ত শুধু খরচের নয়। নতুন ক্লায়েন্টের সঙ্গে কাজের মাইলস্টোন, বিতর্কের ঝুঁকি ও ডেলিভারির পর্যায়ও বিবেচ্য। প্রথমে ছোট পরীক্ষামূলক পেমেন্ট করলে ঠিকানা ও নেটওয়ার্ক প্রবাহ যাচাইয়ের সুযোগ মিলতে পারে, তবে সেই পরীক্ষার স্থির খরচ আলাদা থাকবে। “টেস্ট সফল” মানে ভবিষ্যতের প্রতিটি পেমেন্ট নিশ্চিত নয়; পরেরবারও সম্পদ, নেটওয়ার্ক, ঠিকানা ও গ্রহণ অবস্থা মিলিয়ে নিন।

ভাগ করা পেমেন্টে বিপরীত কোট কীভাবে করবেন?

প্রতি অংশে একই N কাটলে মোট লক্ষ্য T USD-এর বিপরীত সূত্র হলো G = [T ÷ (R × (1 − S)) + K × N] ÷ (1 − P)। তারপর কাজের মাইলস্টোন অনুযায়ী মোট পেমেন্ট ভাগ করুন। অংশভেদে P, N, R বা S আলাদা হলে প্রতিটি অংশের USD লক্ষ্য ধরে মূল বিপরীত সূত্র আলাদাভাবে চালিয়ে ফলগুলো যোগ করুন।

সমান তিন ভাগের ক্ষেত্রে মোট কোটকে সরাসরি তিন দিয়ে ভাগ করার আগে প্ল্যাটফর্মের পরিমাণ নির্ভুলতা দেখুন। প্রতিটি অংশ দুই দশমিকে গোল করলে তিনটির যোগ মোট কোট থেকে এক বা দুই সেন্ট আলাদা হতে পারে। একটি অংশকে সমন্বয়কারী অংশ হিসেবে রাখুন, যাতে সব অংশের যোগ লিখিত মোটের সঙ্গে মেলে। ক্লায়েন্টকে প্রতিটি কিস্তির অঙ্ক, মাইলস্টোন, সম্ভাব্য নেটওয়ার্ক খরচ এবং কার দায় সেটি দিন।

কোনো কিস্তি দেরি হলে পুরোনো স্প্রেড বা নেটওয়ার্ক ইনপুট অন্ধভাবে পুনর্ব্যবহার করবেন না। মূল কাজের মূল্য অপরিবর্তিত থাকতে পারে, কিন্তু কোটের ফি-সংক্রান্ত অংশ পুনরায় হিসাবের শর্ত আগে লিখে রাখুন। এতে পরে “চুক্তির দাম বদলেছে” ও “পরিবহন খরচ বদলেছে”—দুই বিষয় গুলিয়ে যায় না।

চার দশমিক, দুই দশমিক নাকি পূর্ণ সংখ্যা—কখন গোল করবেন?

সব মধ্যবর্তী ধাপ পূর্ণ নির্ভুলতায় রাখুন। চূড়ান্ত USDT কোট সর্বোচ্চ ছয় দশমিক পর্যন্ত দেখান এবং গ্রহণকারী প্ল্যাটফর্মের সমর্থিত নির্ভুলতায় ওপরে গোল করুন, যাতে T থেকে কম না পড়ে। USD বা অন্য ফিয়াট প্রদর্শন সাধারণভাবে দুই দশমিক হবে; মিল পরীক্ষার কাঁচা মান আলাদাভাবে থাকবে। ওপরে গোল করার ক্ষুদ্র পার্থক্যটিও কোটে দেখাতে পারেন।

উদাহরণে কাঁচা 565.126903... USDT মাঝপথে 565.12 করলে লক্ষ্য ৫০০ USD-এর নিচে যেতে পারে। ছয় দশমিকে ওপরে গোল করলে 565.126904 USDT; প্ল্যাটফর্ম দুই দশমিক নিলে 565.13 USDT; এক দশমিক নিলে 565.2 USDT। আট বা দশ দশমিক দেখিয়ে কৃত্রিম নির্ভুলতা তৈরি করবেন না।

ফিয়াট মূল্য রেকর্ডে ভিন্ন রাউন্ডিং নিয়ম থাকতে পারে। হিসাবের কাঁচা ফল, প্রদর্শিত ফল এবং কোট করা ফল—তিনটি আলাদা কলাম উপকারী। কাঁচা ফল সূত্র পুনরায় যাচাই করতে সাহায্য করে; প্রদর্শিত ফল পড়তে সহজ; কোট করা ফল ক্লায়েন্টের সম্মত অঙ্ক। পরে মিল না হলে কোন পর্যায়ে পার্থক্য হয়েছে বোঝা যায়।

ভুল ইনপুট কীভাবে শুরুতেই আটকাবেন?

শূন্য, ঋণাত্মক, শতকরা সীমার বাইরে বা সংখ্যায় রূপান্তর করা যায় না—এমন ইনপুটে ফল না দেখিয়ে স্পষ্ট ত্রুটি দিন। ন্যূনতম যাচাই তালিকা:

• G > 0 এবং T > 0;
• 0 ≤ P < 1 ও 0 ≤ S < 1;
• N ≥ 0 এবং R > 0;
• বিপরীত হিসাবের হর R × (1 − S) > 0;
• প্রতিটি মান সসীম সংখ্যা, ফাঁকা ঘর নয়;
• G ও N USDT, R USD/USDT, T USD;
• শতাংশ ও দশমিকের লেবেল দ্ব্যর্থহীন;
• নেটওয়ার্ক ফি কার দিক থেকে কাটবে তা নির্বাচিত।

ব্যবহারকারী P = 10 লিখলে ইন্টারফেসকে জিজ্ঞেস করতে হবে এটি ১০% নাকি দশমিক ১০। চুপচাপ 10 দিয়ে হিসাব করলে (1 − P) ঋণাত্মক হয়। একইভাবে কমা-সহ 1,000 কোন অঞ্চলে হাজার, কোন অঞ্চলে দশমিক—লোকেল অনুযায়ী পার্সিং না করলে ভুল হতে পারে। গ্রহণযোগ্য ফরম্যাট দেখান এবং ফলের আগে স্বাভাবিক করা ইনপুট পুনরায় প্রদর্শন করুন।

ত্রুটি বার্তা “Invalid” না লিখে কারণ বলুক: “প্ল্যাটফর্ম ফি ০% থেকে ১০০%-এর কম হতে হবে”, “নেটওয়ার্ক ফি ঋণাত্মক হতে পারে না”, অথবা “USDT ও BDT একই সূত্রে মেশানো হয়েছে”। এতে ব্যবহারকারী শুধু সংখ্যা পাল্টান না, ভুলের উৎসও বুঝতে পারেন।

কখন সামনের হিসাব ঋণাত্মক বা শূন্য হয়ে যায়?

G × (1 − P) − N ≤ 0 হলে USD-তে রূপান্তরের আগেই প্রাপ্তিযোগ্য USDT শূন্য বা ঋণাত্মক; ফল দেখানোর বদলে হিসাব থামান। এর মানে N আনুপাতিক ফি-পরবর্তী অঙ্কের সমান বা বেশি। বাস্তবে কোনো সেবা ঋণাত্মক টোকেন দেবে এমন দাবি নয়; ইনপুট বা ছোট পেমেন্টটি এই মডেলে অকার্যকর।

ধরা যাক পূর্ণ পরীক্ষামূলক ইনপুট G = 1 USDT, P = 0.10, N = 1 USDT, R = 1 USD/USDT, S = 0.015, T = 1 USD। ফি-পরবর্তী অঙ্ক 0.90 USDT, যা N-এর চেয়ে কম; মধ্যবর্তী ফল −0.10 USDT। ক্যালকুলেটর কোনো ঋণাত্মক নিট ফল দেখাবে না, বরং বলবে: “ফি-পরবর্তী অঙ্ক স্থির নেটওয়ার্ক ফি মেটায় না; মোট পেমেন্ট বা ইনপুট যাচাই করুন।”

একই যুক্তিতে P ≥ 1, R ≤ 0 বা S ≥ 1 হলে বিপরীত সূত্রের হর শূন্য বা ঋণাত্মক হয়। G অসীম বা ঋণাত্মক দেখানো যাবে না। (1 − P) > 0 এবং R × (1 − S) > 0—দুটি শর্তই না মেলা পর্যন্ত কোট বন্ধ থাকবে।

অজানা ফি থাকলে কি শূন্য বসানো যায়?

অজানা ইনপুট ও সত্যিকারের শূন্য আলাদা অবস্থা। N = 0 অর্থ প্রাপকের USDT থেকে নেটওয়ার্ক ফি কাটবে না বলে নিশ্চিত হওয়া; “জানি না” তার সমান নয়। S = 0 অর্থ ব্যবহারকারীর ইনপুটে মূল্য ব্যবধান নেই, মূল্য দেখা হয়নি—এমন নয়। R কখনও অজানা রেখে শূন্য বসানো যাবে না, কারণ R > 0 বাধ্যতামূলক।

একটি ব্যবহারযোগ্য কোটে প্রতিটি ইনপুটের পাশে তিনটি অবস্থা রাখা যায়: নিশ্চিত, আনুমানিক, অনুপস্থিত। অনুপস্থিত ইনপুট থাকলে “চূড়ান্ত কোট” বোতাম নিষ্ক্রিয় রাখা উচিত; শুধু একটি খসড়া পরিসর দেখানো যায়। আনুমানিক মানের ক্ষেত্রে সংবেদনশীলতা দেখান—মান সামান্য বদলালে ফল কত বদলে যায়।

জরুরি কাজের চাপেও অজানা মান লুকিয়ে নির্ভুল সংখ্যা পাঠাবেন না। বরং ক্লায়েন্টকে বলুন কাজের মূল্য স্থির, কিন্তু নেটওয়ার্ক ও গ্রহণের শর্ত নিশ্চিত হলে মোট পেমেন্ট চূড়ান্ত হবে। এতে দর-কষাকষি ও প্রযুক্তিগত খরচ আলাদা থাকে।

ফি কে বহন করবে তা লিখিত না থাকলে কী সমস্যা হয়?

“ক্লায়েন্ট ফি দেবেন” বাক্যটি অস্পষ্ট, কারণ কোন ফি এবং কোন পর্যায়ে—সেটি বলা নেই। প্ল্যাটফর্ম কমিশন, প্রেরণ ফি, গ্রহণকারী কর্তন, নেটওয়ার্ক ফি এবং মূল্য ব্যবধান আলাদা করে লিখুন। প্রত্যেকটির পাশে তিনটির একটি লিখুন: ক্লায়েন্ট বহন করবেন, ফ্রিল্যান্সারের প্রাপ্তি থেকে কাটা হবে, অথবা এখনও অনির্ধারিত।

ক্লায়েন্টের মোট ব্যয় ও সম্মত মোট পেমেন্ট G এক নাও হতে পারে। ক্লায়েন্ট G পাঠিয়ে প্রেরণ ফি আলাদা দিলে সেই অতিরিক্ত ফি প্রাপকের সূত্রে N হিসেবে আবার কাটা হবে না। প্রাপক কম USDT পেলে শুধু সেই স্থির কর্তন N-এ যাবে। এই পার্থক্য লিখিত না থাকলে উভয় পক্ষই ভিন্ন অর্থে “৫০০ পাঠানো” বলতে পারেন।

কোটে একটি ছোট বাক্য যথেষ্ট: “ক্লায়েন্টের সম্মত মোট USDT পেমেন্ট: ___; প্রেরকের নেটওয়ার্ক খরচ: মোটের বাইরে/মোট থেকে; প্রাপকের সম্ভাব্য কর্তন: ___।” ফি বদলালে কার অনুমোদন লাগবে তাও লিখুন। এতে কোট কোনো পক্ষের ওপর অদৃশ্য খরচ চাপানোর কৌশল হয় না।

কোট পাঠানোর আগে কোন ক্রমে যাচাই করবেন?

প্রথমে কাজের মূল্য, তারপর সম্পদ ও নেটওয়ার্ক, তারপর ফি, সবশেষে গাণিতিক ফল যাচাই করুন। একটি কার্যকর ক্রম হতে পারে:

1. ইনভয়েসের কাজ, মুদ্রা ও লক্ষ্য প্রাপ্তি T নিশ্চিত করুন।
2. পেমেন্ট সম্পদ USDT কি না এবং গ্রহণকারী স্থানে সেটি সমর্থিত কি না দেখুন।
3. সুনির্দিষ্ট নেটওয়ার্ক লিখে উভয় পক্ষের সম্মতি নিন।
4. প্ল্যাটফর্মের আনুপাতিক ফি P মোট পেমেন্টের ওপর কাটে কি না লিখুন।
5. স্থির নেটওয়ার্ক ফি N প্রাপকের USDT থেকে কাটবে কি না ঠিক করুন।
6. হাতে দেওয়া USD রেফারেন্স মূল্য R ও মূল্য ব্যবধান S নথিভুক্ত করুন।
7. বিপরীত সূত্রে G বের করুন এবং সামনের সূত্রে আবার মিলিয়ে নিন।
8. শেষ ধাপে অনুমোদিত নির্ভুলতায় গোল করুন।
9. তারিখ, সময়, ইনপুট উৎস ও কোটের মেয়াদ লিখুন।
10. ক্লায়েন্টের লিখিত সম্মতি রাখুন; নেটওয়ার্ক অস্পষ্ট হলে পেমেন্ট থামান।

এই ক্রমে গাণিতিক ফল শেষের দিকে আসে। কারণ ভুল নেটওয়ার্কে নিখুঁত অঙ্ক পাঠানোও ভুল পেমেন্ট। আবার আইনি বা ব্যাংকিং সীমা অমীমাংসিত থাকলে সঠিক সূত্র সেই সীমা সরায় না। ক্যালকুলেটর সিদ্ধান্তের সহায়ক, সিদ্ধান্তদাতা নয়।

ক্লায়েন্টকে পাঠানোর কোটে কী কী লিখবেন?

একটি ভালো কোটে অঙ্কের পাশাপাশি শর্ত পড়ে বোঝা যায় এবং পরে পুনরায় হিসাব করা যায়। নিচের কাঠামো নিজের ভাষায় ব্যবহার করতে পারেন:

কাজ/ইনভয়েস: ___ লক্ষ্য নিট প্রাপ্তি T: ___ USD সম্মত সম্পদ: USDT সম্মত নেটওয়ার্ক: ___ প্ল্যাটফর্মের আনুপাতিক ফি P: ___% — ভিত্তি: মোট পেমেন্ট প্রাপকের স্থির নেটওয়ার্ক ফি N: ___ USDT প্রতি USDT-এর হাতে দেওয়া USD রেফারেন্স মূল্য R: ___ USD/USDT ব্যবহারকারী-প্রদত্ত মূল্য ব্যবধান S: ___% হিসাব করা মোট পেমেন্ট G: ___ USDT প্রেরকের আলাদা খরচ: প্রযোজ্য/প্রযোজ্য নয়/অনির্ধারিত প্রত্যাশিত নিট প্রাপ্তি: ___ USD ইনপুট দেখার সময় ও উৎস: ___ কোটের অবস্থা: খসড়া/সম্মত নোট: পেমেন্টের আগে সম্পদ, নেটওয়ার্ক ও ঠিকানা আবার মিলবে।

এই বার্তায় “আপনি ঠিক এই পরিমাণ পাবেন” না লিখে “উপরের ইনপুট অপরিবর্তিত থাকলে হিসাব অনুযায়ী আনুমানিক প্রাপ্তি” লিখুন। কোনো হার লাইভ নয় এবং ক্যালকুলেটর বাজার বা প্ল্যাটফর্মের সঙ্গে যুক্ত নয়—এটিও উল্লেখ করুন। ক্লায়েন্ট কোনো ইনপুট বদলালে নতুন সংস্করণ নম্বর দিন; পুরোনো বার্তা সম্পাদনা করে ইতিহাস মুছবেন না।

কোটের সঙ্গে ইনভয়েসের সম্পর্ক কী?

ইনভয়েস কাজের পাওনা প্রমাণ করে, আর কোট সম্ভাব্য পেমেন্ট প্রবাহ ও কর্তন ব্যাখ্যা করে; দুটিকে একই রেকর্ডে যুক্ত করুন। ইনভয়েস নম্বর, ক্লায়েন্টের নাম বা ব্যবসায়িক পরিচয়, সেবার বিবরণ, কাজের সময়কাল, মূল চুক্তির মুদ্রা এবং পরিশোধের তারিখ আলাদা ক্ষেত্র। কোটে সেই ইনভয়েস নম্বর উল্লেখ করলে পরে একটি অন-চেইন পেমেন্ট কোন কাজের জন্য ছিল তা বোঝা সহজ হয়।

সরকারি Freelancer ID পোর্টাল আয়ের প্রমাণ হিসেবে marketplace statement, bank statement এবং অন্য বৈধ income document-এর উদাহরণ দেয়; Freelancers.gov.bd মূল পৃষ্ঠা থেকে বর্তমান প্রয়োজন দেখা যায়। তাদের কীভাবে Freelancer ID কাজ করে নির্দেশনা আর্থিক প্রতিষ্ঠান বৈধ আর্থিক নথি বা আয়ের প্রমাণ চাইতে পারে বলে জানায়। এই তথ্য থেকে ব্যবহারিক শিক্ষা হলো: কেবল একটি transaction hash রেখে পুরো আয়ের গল্প সম্পূর্ণ হয় না।

কোট, ইনভয়েস, কাজের চুক্তি, ডেলিভারির প্রমাণ, পেমেন্ট তারিখ, লেনদেন হ্যাশ এবং সেই সময়ের মূল্য রেকর্ড একে অন্যকে সমর্থন করে। তবে এই নথিগুলো রাখা মানেই কোনো কর্তৃপক্ষ সেগুলো গ্রহণ করবে—এমন নিশ্চয়তা নেই। কোন নথি গ্রহণযোগ্য তা সংশ্লিষ্ট প্রতিষ্ঠান ঠিক করে। তাই নথি তৈরির সময় সত্য তথ্য লিখুন, পরে মানানসই করার জন্য তারিখ বা মূল্য বদলাবেন না।

পেমেন্টের সময়কার ফিয়াট মূল্য কীভাবে রেকর্ড করবেন?

লেনদেন নিশ্চিত হওয়ার সময় ব্যবহারকারী যে রেফারেন্স মূল্য দেখেছেন, তার উৎস ও সময়সহ অপরিবর্তনীয় রেকর্ড রাখুন। ন্যূনতম ক্ষেত্র হতে পারে: UTC বা স্পষ্ট সময় অঞ্চলসহ তারিখ, প্রাপ্ত USDT, ব্যবহারকারী-প্রদত্ত R USD/USDT, S, হিসাব করা USD নিট মূল্য, পরে আলাদাভাবে নথিভুক্ত USD/BDT রূপান্তর, মূল্য দিক, উৎসের নাম এবং প্রমাণ ফাইলের অবস্থান।

কোটের সময়ের R ও পেমেন্টের সময়কার মূল্য আলাদা হতে পারে। “কোটের রেফারেন্স মূল্য” এবং “পেমেন্টের সময়কার রেফারেন্স মূল্য” নামে দুইটি সারি রাখুন। প্রথমটি মোট পেমেন্ট ঠিক করতে সাহায্য করেছে; দ্বিতীয়টি আয়ের সময়কার মূল্য নথিভুক্ত করে। পুরোনো কোটের মান নতুন মান দিয়ে প্রতিস্থাপন করলে পরে পার্থক্যের কারণ বোঝা যাবে না।

একটি CSV-তে সংখ্যার পাশাপাশি একক রাখুন। 500 একা অর্থহীন; 500 USD-equivalent বা 500 USDT স্পষ্ট। দশমিক বিভাজক, সময় অঞ্চল ও ফাইলের তারিখ বিন্যাস পুরো মাসে একই রাখুন। মাসশেষে যোগ করার আগে একই মুদ্রায় রূপান্তরের নীতি লিখুন। এই নীতি কর বা আইন নির্ধারণ করে না; এটি আপনার নিজের রেকর্ডকে পুনরুৎপাদনযোগ্য করে।

transaction hash কি একাই আয়ের প্রমাণ?

লেনদেন হ্যাশ একটি অন-চেইন লেনদেন শনাক্ত করে, কিন্তু কাজ, ক্লায়েন্ট, ইনভয়েস বা মূল্য নিজে ব্যাখ্যা করে না। তাই hash-এর সঙ্গে নেটওয়ার্ক, সম্পদ, প্রেরক ও প্রাপক ঠিকানা, প্রাপ্ত অঙ্ক, ব্লক সময়, ইনভয়েস নম্বর এবং ক্লায়েন্টের সম্মতির রেফারেন্স যুক্ত করুন। যে explorer ব্যবহার করবেন সেটি সংশ্লিষ্ট নেটওয়ার্কের কি না নিশ্চিত করুন।

কোনো hash বানিয়ে উদাহরণ দেখানোর দরকার নেই। টেমপ্লেটে transaction_hash নামে খালি ক্ষেত্র রাখুন; বাস্তব পেমেন্ট হলে আসল মান লিখুন। স্ক্রিনশট থাকলে সেটি সহায়ক নথি, মূল ডেটার বিকল্প নয়। স্ক্রিনশট কাটা বা পুরোনো হলে তথ্য হারাতে পারে, অথচ hash ও নেটওয়ার্ক দিয়ে প্রকাশ্য লেনদেন পুনরায় দেখা সম্ভব হতে পারে।

ব্যক্তিগত তথ্যের সীমাও রাখুন। আয়ের নথিতে যতটুকু ব্যবসায়িক প্রমাণ দরকার ততটুকুই সংরক্ষণ করুন। কোনো ব্যক্তির পরিচয়, ইমেইল বা চুক্তির সংবেদনশীল অংশ অপ্রয়োজনীয়ভাবে প্রকাশ করবেন না। ক্লায়েন্টকে কীভাবে নথি ব্যবহার হবে জানানো এবং স্থানীয় তথ্য-সুরক্ষার বাধ্যবাধকতা বোঝা আপনার দায়িত্ব।

একটি মাসিক লেজারে কোন কলামগুলো রাখবেন?

মাসিক লেজারে কোট, ইনভয়েস, পেমেন্ট ও মূল্য রেকর্ডকে একটি স্থায়ী আইডি দিয়ে যুক্ত করুন। ব্যবহারযোগ্য কলাম:

• রেকর্ড পরিচিতি
• ক্লায়েন্ট রেফারেন্স
• ইনভয়েস নম্বর ও কাজের বিবরণ
• কোট সংস্করণ
• মোট পেমেন্ট G—USDT
• আনুপাতিক ফি P
• প্রাপকের স্থির নেটওয়ার্ক ফি N—USDT
• USD রেফারেন্স মূল্য R—USD/USDT
• মূল্য ব্যবধান S
• লক্ষ্য নিট প্রাপ্তি T—USD
• প্রত্যাশিত নিট প্রাপ্তি—USD
• বাস্তবে পাওয়া অঙ্ক—USDT এবং USD
• নেটওয়ার্ক ও লেনদেন হ্যাশ
• পেমেন্টের তারিখ, সময় ও সময় অঞ্চল
• প্রমাণ ফাইলের নাম ও নোট

প্রত্যাশিত ও বাস্তব অঙ্ক আলাদা কলাম হওয়া উচিত। USD পার্থক্য হবে বাস্তবে পাওয়া USD − প্রত্যাশিত নিট প্রাপ্তি USD। কারণ হিসেবে ফি বদল, রাউন্ডিং, কিস্তি, মূল্য দেখার সময়ের পার্থক্য অথবা ভুল ইনপুট লিখুন। কারণ না জানলে “অজানা—যাচাই বাকি” লিখুন; মনগড়া ব্যাখ্যার চেয়ে এটি সৎ। একই স্থায়ী রেকর্ড পরিচিতি কোট, ইনভয়েস, লেনদেন সারি ও প্রমাণ ফোল্ডারে দিন। কিস্তি হলে একই ইনভয়েস নম্বরের সঙ্গে আলাদা কিস্তি নম্বর থাকবে; এতে পরে নথি খুঁজতে শুধু নাম বা অঙ্কের ওপর নির্ভর করতে হয় না।

CSV export করলে UTF-8, তারিখ বিন্যাস এবং দশমিক বিভাজক পরীক্ষা করুন। স্প্রেডশিট কোনো দীর্ঘ transaction hash-কে বৈজ্ঞানিক সংখ্যায় বদলে দিচ্ছে কি না দেখুন; hash কলামকে text হিসেবে রাখা যায়। ফাইল খোলার পরে প্রথম ও শেষ সারি, মোট এবং কয়েকটি এলোমেলো রেকর্ড মিলিয়ে নিন।

কোটের স্থির প্রতিলিপি কেন রাখবেন?

হিসাবের স্থির প্রতিলিপি রাখলে কোন ইনপুট দিয়ে কোন ফল বের হয়েছিল তা পরে পুনর্গঠন করা যায়। কেবল 565.13 USDT রাখলে P, N, R, S, T, রাউন্ডিং ও ফি বহনের নিয়ম হারিয়ে যায়। প্রতিলিপিতে ছয়টি চলকের মান, সূত্র সংস্করণ, কাঁচা USDT ফল, ওপরে গোল করা USDT কোট, কাঁচা ও দুই দশমিকে দেখানো USD ফল, তারিখ, সময় অঞ্চল, কোটের অবস্থা এবং ব্যবহারকারীর নোট থাকা দরকার।

সংস্করণ নম্বর সহজ হতে পারে: Q-2026-08-11-01-v1। ক্লায়েন্ট নেটওয়ার্ক ফি বহনের সিদ্ধান্ত বদলালে v2 করুন এবং পরিবর্তনের কারণ লিখুন। পুরোনো সংস্করণ মুছবেন না। একই ইনভয়েসের বহু কোট থাকলে কোনটি ক্লায়েন্ট সম্মত করেছেন সেটি আলাদা ক্ষেত্র দিয়ে চিহ্নিত করুন।

এই প্রতিলিপিতে কোনো প্রাইভেট কি, সিড ফ্রেজ বা ওয়ালেট অ্যাক্সেস দরকার নেই। এই হিসাবের জন্য ওয়ালেট সংযোগও লাগে না। ঠিকানা ও লেনদেন হ্যাশ প্রকাশ্য নেটওয়ার্ক ডেটা হতে পারে, তবু ব্যবসায়িক পরিচয়ের সঙ্গে যুক্ত হলে সেগুলো সংবেদনশীল হয়ে ওঠে। ফাইলের প্রবেশাধিকার ও সংরক্ষণকাল সচেতনভাবে ঠিক করুন। কোনো প্রতিষ্ঠান পরে ভিন্ন বিন্যাস চাইলে মূল সত্য তথ্য থেকে নতুন রপ্তানি করুন; মূল তারিখ, মূল্য বা ঘটনাক্রম বদলাবেন না।

কোটের মেয়াদ কীভাবে লিখবেন?

কোটের মেয়াদ কাজের মূল্য বদলানোর অজুহাত নয়; পরিবর্তনশীল ফি ও রেফারেন্স ইনপুট পুনরায় যাচাইয়ের সময়সীমা। “এই কোট ২৪ ঘণ্টা বৈধ” লেখা যেতে পারে শুধু যদি আপনি সত্যিই সেই সময়ের মধ্যে একই ইনপুট সম্মান করবেন। আরও নির্ভুল ভাষা হতে পারে: “কাজের মূল্য স্থির; নেটওয়ার্ক ফি ও মূল্য ইনপুট পেমেন্ট শুরু করার আগে পুনরায় যাচাই হবে।”

ক্লায়েন্ট মেয়াদের পরে পেমেন্ট করতে চাইলে নতুন স্থির প্রতিলিপি তৈরি করুন। পুরোনো ইনভয়েস নম্বর রাখা যায়, কিন্তু কোট সংস্করণ ও ইনপুটের সময় বদলান। পরিবর্তন খুব ছোট হলেও ইতিহাস রাখুন। এতে ক্লায়েন্ট বুঝবেন মূল সেবার মূল্য নয়, প্রযুক্তিগত বা মূল্য ইনপুট পুনরায় গণনা হয়েছে।

কোনো সময়সীমা বাজারের ভবিষ্যৎ মূল্য নিশ্চিত করে না। “আগামীকালও একই থাকবে” বা “USDT সব সময় ১ ডলার” ধরনের নিশ্চয়তা দেবেন না। আপনার কোট একটি শর্তযুক্ত গণনা; বাজার আদেশ বা মূল্য গ্যারান্টি নয়।

একাধিক মুদ্রায় চুক্তি হলে কী করবেন?

চুক্তির মূল মুদ্রা একটি রাখুন এবং অন্য মুদ্রাগুলোকে তারিখযুক্ত রেফারেন্স রূপান্তর হিসেবে দেখান। ইনভয়েস USD-তে ও পেমেন্ট USDT-তে হলে T USD এবং ব্যবহারকারী-দেওয়া R USD/USDT সরাসরি বিপরীত সূত্রে যাবে। লেজারে BDT দরকার হলে সূত্রে পাওয়া USD ফলকে পেমেন্টের সময় নথিভুক্ত USD/BDT রেট দিয়ে আলাদাভাবে রূপান্তর করুন।

প্রতিটি রূপান্তরের দিক লিখুন। 1 USDT = x USD এবং 1 USD = y USDT পারস্পরিক বিপরীত হলেও রাউন্ডিং ও মূল্য ব্যবধানের কারণে পর্দায় একই নাও হতে পারে। একটি দিক দেখে অন্য দিক অন্ধভাবে উল্টাবেন না। কোটের স্থির প্রতিলিপিতে পর্দায় দেখা মূল উদ্ধৃতি রাখুন।

ক্লায়েন্টকে একাধিক মোট দেখালে কোনটি পরিশোধযোগ্য তা বাংলায় স্পষ্ট করুন: “ইনভয়েস মূল্য: ৫০০ USD; এই প্রদর্শনী ইনপুটে পরিশোধযোগ্য মোট: ৫৬৫.১৩ USDT।” বাস্তব কোটে “প্রদর্শনী” থাকবে না; সেখানে যাচাই করা P, N, R, S, T এবং তাদের উৎস থাকবে।

একটি সংবেদনশীলতা পরীক্ষা কীভাবে করবেন?

একটি ইনপুট সামান্য বদলে ফল কত বদলায় তা দেখা কোটের দুর্বল স্থান বোঝায়। লক্ষ্য T = 500 USD, N = 1 USDT ও একটি হাতে দেওয়া R অপরিবর্তিত রেখে P ও S-এর তিনটি ব্যবহারকারী-দেওয়া মান দিয়ে বিপরীত সূত্র চালাতে পারেন। ফল বাজার পূর্বাভাস নয়; এটি “যদি–তবে” পরীক্ষা।

P এক শতাংশ পয়েন্ট বাড়লে মোট পেমেন্ট G কত বাড়ে দেখুন। N দ্বিগুণ হলে ছোট কিস্তির ওপর প্রভাব দেখুন। R কমলে বা S ১% থেকে ২% হলে লক্ষ্য পূরণে G কত বাড়ে দেখুন। এই তুলনা কোন ইনপুট লিখিতভাবে নিশ্চিত করা সবচেয়ে জরুরি তা জানায়।

সংবেদনশীলতা সারণিতে প্রতিটি কলামের ওপরে “ব্যবহারকারীর পরীক্ষামূলক ইনপুট” লিখুন। কোনো প্রতিষ্ঠানের নাম বা চলতি হার বসাবেন না। ফল গোল করার আগে পূর্ণ নির্ভুলতায় হিসাব করুন। সবচেয়ে খারাপ দৃশ্যকেও নিশ্চয়তা না বলে উচ্চ-কর্তন অনুমান বলুন। বাস্তব ইনপুট যাচাই হলে আবার মূল সূত্র চালান।

ক্যালকুলেটরের ফল কীভাবে হাতে যাচাই করবেন?

বিপরীত কোটের G সামনের সূত্রে ফিরিয়ে বসিয়ে প্রত্যাশিত নিট প্রাপ্তি T-এর সমান বা ওপরে আছে কি না দেখুন। G বের করার পরে “আনুপাতিক ফি-পরবর্তী USDT”, “স্থির নেটওয়ার্ক ফি-পরবর্তী USDT”, “রেফারেন্স মূল্যে USD” এবং “মূল্য ব্যবধান-পরবর্তী নিট USD”—এই চারটি মধ্যবর্তী অঙ্ক লিখুন।

স্প্রেডশিটে আলাদা ঘর রাখুন। বিপরীত কোট =((T/(R*(1-S))+N)/(1-P)); সামনের যাচাই =(((G*(1-P))-N)*R*(1-S))। শতাংশ বিন্যাসের ঘরে 10% নিজেই 0.10, কিন্তু সাধারণ সংখ্যার ঘরে 10 ভুল। একটি পরীক্ষার সারিতে P=0, N=0, R=1, S=0 দিলে G=T হওয়া উচিত, কারণ তখন ১ USDT-এর রেফারেন্স মূল্য ১ USD।

আরেক পরীক্ষায় P=0, R=1, S=0 এবং N>0 হলে G=T+N। N=0, R=1, S=0 হলে G=T/(1-P)। P=0, N=0, R=1 হলে G=T/(1-S)। R এক না হলে শূন্য-ফি অবস্থাতেও G=T/R। কোনো ফল সংখ্যায় রূপান্তরযোগ্য না হলে, অসীম বা ঋণাত্মক হলে কোট দেখাবেন না।

বাস্তব প্রাপ্তি কোটের চেয়ে কম হলে কীভাবে মিল করবেন?

প্রথমে প্রত্যাশিত ও বাস্তব প্রবাহের প্রতিটি ধাপ পাশাপাশি বসান; অনুমান করে ঘাটতিকে “মূল্য ব্যবধান” বলবেন না। মোট পেমেন্ট, প্রেরকের আলাদা ফি, প্রাপকের USDT, P, N, পেমেন্টের সময়কার রেফারেন্স মূল্য এবং বাস্তব USD মূল্য আলাদা সারিতে তুলনা করুন।

পার্থক্যের কারণ হতে পারে: ক্লায়েন্ট মোটের ভেতর থেকে নেটওয়ার্ক ফি দিয়েছেন, প্ল্যাটফর্মের হার অন্য ভিত্তিতে কেটেছে, কিস্তি সংখ্যার কারণে স্থির চার্জ বেড়েছে, রাউন্ডিং নিচের দিকে হয়েছে, কিংবা reference rate-এর দিক ভুল নেওয়া হয়েছে। প্রতিটি কারণ প্রমাণ ছাড়া নির্বাচন করবেন না। “Unreconciled” অবস্থা রেখে সংশ্লিষ্ট রেকর্ড যাচাই করুন।

ঘাটতি নিয়ে ক্লায়েন্টের সঙ্গে কথা বলার সময় মূল কাজের মূল্য ও প্রযুক্তিগত কর্তন আলাদা দেখান। কোটের সম্মত version সংযুক্ত করুন। অন-চেইন তথ্যের অখণ্ডতা বজায় রাখুন এবং প্রতিটি লেনদেন সত্যভাবে নথিভুক্ত করুন। প্রয়োজন হলে পেশাদার হিসাবরক্ষক বা অনুমোদিত আর্থিক প্রতিষ্ঠানের সহায়তা নিন।

বেশি এসে গেলে কীভাবে নথিভুক্ত করবেন?

বাস্তব প্রাপ্তি প্রত্যাশার চেয়ে বেশি হলে পার্থক্যটিও লেজারে লিখুন এবং ক্লায়েন্টের সঙ্গে সমাধান নথিভুক্ত করুন। এটি স্বয়ংক্রিয়ভাবে টিপ, লাভ বা পরের ইনভয়েসের অগ্রিম নয়। ক্লায়েন্ট ভুল পরিমাণ পাঠিয়েছেন কি না, রাউন্ডিং বাফার ছিল কি না বা কোনো ফি প্রত্যাশার চেয়ে কম হয়েছে কি না দেখুন।

প্রত্যাশিত নিট USD, বাস্তব নিট USD এবং তাদের পার্থক্য রাখুন। ক্লায়েন্ট ফেরত বা পরের ইনভয়েসে সমন্বয় চান কি না লিখিতভাবে ঠিক করুন। কোনো ফেরত পাঠানোর আগে নতুন লেনদেনের নেটওয়ার্ক, ঠিকানা, ফি ও প্রযোজ্য নিয়ম আবার যাচাই দরকার; পুরোনো ঠিকানা অন্ধভাবে ব্যবহার করা নিরাপদ ধরে নেওয়া যায় না।

অতিরিক্ত অঙ্কের ফিয়াট মূল্যও payment-time reference দিয়ে নথিভুক্ত করুন। পরে সমন্বয় হলে দ্বিতীয় transaction hash ও তারিখ যুক্ত করুন। পুরোনো সারি বদলে শুধু শেষ ফল রাখবেন না; ঘটনাগুলোর ক্রম অক্ষুণ্ণ থাকলে হিসাব পরীক্ষা করা সহজ।

আইনি ও নিয়ন্ত্রক সীমাটি কোটে কোথায় লিখবেন?

কোটের শুরু ও সম্মতির ঠিক আগে সংক্ষিপ্ত নিয়ন্ত্রক সতর্কতা রাখুন, কিন্তু সেটিকে ভয় দেখানো বা অনুমতির সিল হিসেবে ব্যবহার করবেন না। বাংলাদেশ ব্যাংকের FE Circular No. 24 ভার্চুয়াল অ্যাসেট বা ভার্চুয়াল কারেন্সি অর্জনের উদ্দেশ্যে বাংলাদেশ-সম্পর্কিত লেনদেন অনুমোদিত নয় বলে যে অবস্থান দিয়েছে, তা USDT কোটের আগে প্রাসঙ্গিক সীমা। এই সূত্র সেই সীমা বাতিল করে না।

ফ্রিল্যান্স সেবা রপ্তানি, বৈদেশিক মুদ্রা গ্রহণ, ব্যাংকিং নথি এবং ভার্চুয়াল অ্যাসেট—এগুলো আলাদা নিয়ন্ত্রক প্রশ্ন হতে পারে। কোনো ফিয়াট সেবা-রপ্তানি নিয়মকে USDT গ্রহণের অনুমতি হিসেবে ব্যাখ্যা করবেন না। আবার আয়ের নথি রাখা লেনদেনকে বৈধ ঘোষণা করে না। আপনার AD bank, বাংলাদেশ ব্যাংকের হালনাগাদ প্রকাশনা এবং যোগ্য আইন বা কর পেশাদারের কাছ থেকে নির্দিষ্ট পরিস্থিতির উত্তর নিন।

ব্যক্তিগত মুদ্রা বিনিময় বা লাইসেন্সবিহীন মানি চেঞ্জারের সেবা এই লেখার আওতায় নেই। VPN-নির্ভর পথও এখানে নেই; পরিচয় ও লেনদেনের তথ্য সত্য ও স্বচ্ছ রাখা আবশ্যক, এবং KYC/AML মানতে হবে। এটি কোনো ওয়ালেটে স্বয়ংক্রিয়ভাবে যুক্ত হয় না এবং প্রাইভেট কি বা সিড ফ্রেজের প্রয়োজন নেই। হিসাব ও নথি তৈরির কাজের বাইরে পেমেন্টের বৈধতা, কর ও রিপোর্টিং নিয়ে পেশাদার যাচাই জরুরি।

ঠিকানা বা পরীক্ষামূলক পেমেন্টের আগে কোথায় থামবেন?

ঠিকানা পাঠানোর আগে USDT, সুনির্দিষ্ট নেটওয়ার্ক, গ্রহণকারী সেবার সমর্থন এবং ফি বহনের নিয়ম লিখিতভাবে মিলিয়ে নিন। ক্লায়েন্ট নেটওয়ার্কের নাম বলতে না পারলে থামুন; “সস্তা নেটওয়ার্ক” যথেষ্ট নয়। সমর্থন নিশ্চিত হওয়ার পরে ছোট পরীক্ষামূলক পেমেন্ট ঝুঁকি সীমিত করতে পারে, কিন্তু সেটি আইনি সীমা, ভবিষ্যৎ ফি বা পরের পেমেন্টের নিশ্চয়তা নয়। পরীক্ষা ও মূল পেমেন্ট দুইটি ট্রান্সফার হলে ভাগ-পেমেন্ট সূত্রে K = 2 এবং প্রাপকের প্রতিবারের স্থির ফি N দুইবার ধরুন; প্রতিটি লেনদেনের হ্যাশ, অঙ্ক, সময় ও ফল একই ইনভয়েস রেকর্ডে রাখুন।

কোন তথ্য ক্লায়েন্টের সঙ্গে ভাগ করবেন, আর কোনটি নয়?

ক্লায়েন্টকে পেমেন্টের জন্য প্রয়োজনীয় ব্যবসায়িক তথ্য দিন, কিন্তু সংবেদনশীল wallet credential কখনও দরকার হয় না। কোটে গ্রহণকারী asset, network, address বা প্রযোজ্য memo, invoice number, amount ও timing terms থাকতে পারে। কোনো password, private key, seed phrase, recovery phrase বা account security code কোটের অংশ নয়।

প্রকাশ্য ঠিকানা পাঠালেও সেটি কোন ইনভয়েসের সঙ্গে যুক্ত তা ক্লায়েন্টকে স্পষ্ট করুন। ঠিকানা পরিবর্তন হলে নতুন বার্তায় পুরো asset–network–address ত্রয়ী আবার দিন। শুধু “আগের ঠিকানায় পাঠান” লিখলে পুরোনো কথোপকথনের ভুল অংশ ব্যবহারের ঝুঁকি থাকে।

নথির কপি কোথায় রাখা হবে, কে দেখতে পারবেন এবং কতদিন থাকবে—নিজস্ব data policy অনুযায়ী ঠিক করুন। আয়ের প্রমাণের নামে অপ্রয়োজনীয় পরিচয়পত্র বা ব্যক্তিগত কথোপকথন সংগ্রহ করবেন না। প্রমাণের পরিমাণ নয়, ঘটনার সঙ্গে প্রাসঙ্গিকতা ও সত্যতা মুখ্য।

কোট চূড়ান্ত করার আগে নয় লাইনের পরীক্ষাটি কী?

1. G ও N USDT, R USD/USDT এবং T USD কি না দেখুন।
2. 0 ≤ P < 1, N ≥ 0, R > 0, 0 ≤ S < 1, T > 0 এবং R × (1 − S) > 0 মিলিয়ে নিন।
3. P মোট পেমেন্টের ওপর প্রযোজ্য কি না এবং প্রেরকের আলাদা ফি N-এ ঢোকেনি কি না দেখুন।
4. বিপরীত সূত্রে G বের করে সামনের সূত্রে বসান; প্রত্যাশিত নিট USD যেন T-এর নিচে না যায়।
5. ভেতরের হিসাব পূর্ণ নির্ভুলতায় রেখে USDT সর্বোচ্চ ছয় দশমিকে ও গ্রহণ-নির্ভুলতায় ওপরে গোল করুন; ফিয়াট দুই দশমিকে দেখান।
6. USDT, সুনির্দিষ্ট নেটওয়ার্ক, গ্রহণ সমর্থন, ঠিকানা এবং ফি বহনকারী পক্ষ লিখিতভাবে মিলিয়ে নিন।
7. P, N, R ও S-এর উৎস, দেখা সময় ও অনুমান-অবস্থা লিখুন; কোনো প্রদর্শনী মানকে চলতি হার বলবেন না।
8. কোট সংস্করণকে ইনভয়েস, ক্লায়েন্ট, লেনদেন হ্যাশ, পেমেন্ট তারিখ ও মূল্য রেকর্ডের সঙ্গে যুক্ত করুন।
9. বাংলাদেশ ব্যাংকের বর্তমান নির্দেশনা, AD bank এবং প্রয়োজনমতো আইন বা কর পেশাদারের যাচাই অসম্পূর্ণ থাকলে কোট খসড়া রাখুন ও পেমেন্ট থামান।

এই পদ্ধতির সীমা কোথায়?

এই পদ্ধতি অঙ্ক, শর্ত ও রেকর্ড গুছিয়ে দেয়; পেমেন্টের বৈধতা, করের ফল, প্ল্যাটফর্ম যোগ্যতা বা অর্থ ফেরত পাওয়ার নিশ্চয়তা দেয় না। এটি কোনো API-সংযুক্ত live quote নয়, কোনো wallet connector নয় এবং কোনো exchange service নয়। এখানে ব্যক্তিগত মুদ্রা বদলের ব্যবস্থা বা লাইসেন্সবিহীন মধ্যস্থতাকারীর পরিচয় নেই। প্রযোজ্য আইন, বিধিনিষেধ, KYC ও AML অনুসরণ করাই এই হিসাবের অপরিবর্তনীয় সীমা; পরিচয় ও লেনদেনের তথ্য সত্যভাবে নথিভুক্ত হওয়া চাই।

বাংলাদেশ-সম্পর্কিত ভার্চুয়াল অ্যাসেট লেনদেনের ক্ষেত্রে বাংলাদেশ ব্যাংকের বর্তমান অবস্থান প্রথম সীমা। ফ্রিল্যান্সার আয়ের নথি দরকার হওয়া আর USDT গ্রহণ অনুমোদিত হওয়া এক কথা নয়। নিজের কাজের চুক্তি, বাসস্থান, পেমেন্টের উৎস ও ব্যাংকিং পথ অনুযায়ী বাংলাদেশ ব্যাংক, আপনার AD bank এবং যোগ্য আইন ও কর পেশাদারের কাছ থেকে লিখিত বা নথিভুক্ত ব্যাখ্যা নিন।

অঙ্ক ব্যবহার করতে হলে ধীর পদ্ধতিই নিরাপদ: ইনপুটের অর্থ লিখুন, সূত্র চালান, উল্টো সূত্রে মিলান, শেষ ধাপে গোল করুন, স্থির প্রতিলিপি রাখুন এবং নেটওয়ার্ক বা নিয়ন্ত্রক প্রশ্ন অনিশ্চিত হলে থামুন। এতে কোটটি শুধু একটি সংখ্যা থাকে না; কোন শর্তে সেই সংখ্যা তৈরি হয়েছে তার পরীক্ষাযোগ্য রেকর্ড হয়ে ওঠে।