টোকেন অনুমোদন ও Allowance: ERC-20 অনুমতি যাচাই ও বাতিল

সাইটে ওয়ালেট যুক্ত করলে অ্যাপ সাধারণত প্রকাশ্য ঠিকানা দেখতে এবং স্বাক্ষর চাইতে পারে। এতে সব ERC-20 টোকেন সরানোর অনুমতি নিজে থেকে যায় না। টোকেন চুক্তিতে allowance আলাদা করে থাকে। MetaMask-ও dapp বিচ্ছিন্ন করা ও টোকেন approval প্রত্যাহার আলাদা বলে ব্যাখ্যা করে।

ERC-20 allowance নির্দিষ্ট টোকেন চুক্তি, নেটওয়ার্ক, মালিকের ঠিকানা ও spender-এর ঠিকানার জন্য প্রযোজ্য। Ethereum-এ দেওয়া অনুমতি Polygon-এ একই নামের টোকেনের অনুমতি নয়, অন্য টোকেনেরও নয়। শুধু “সাইটটিকে অনুমতি দিয়েছি” মনে রাখলে কোন নেটওয়ার্কে কোন টোকেনের অনুমতি রয়ে গেছে তা বাদ পড়তে পারে।

এই লেখা Ethereum ও সামঞ্জস্যপূর্ণ নেটওয়ার্কের ERC-20 approve, allowance ও transferFrom নিয়ে। নেটিভ ETH, NFT-এর setApprovalForAll, অন্য টোকেন মান এবং ওয়ালেট লগইন সংযোগের নিয়ম আলাদা। কী ব্যাকআপ ও পুনরুদ্ধারের জন্য seed phrase ও wallet recovery guide দেখুন।

মালিক approve(spender, amount) দিয়ে নির্দিষ্ট spender-কে নির্দিষ্ট পরিমাণ পর্যন্ত টোকেন ব্যবহারের অনুমতি দিতে পারেন। transferFrom সেই spender-কে মালিকের হয়ে টোকেন সরাতে দেয়। তাই approve সাধারণত সঙ্গে সঙ্গে ব্যালান্স বদলায় না; পরে চুক্তির কল allowance ব্যবহার করতে পারে। ERC-20 standard-এ এই ব্যবস্থাই নির্ধারিত।

উদাহরণ: ওয়ালেটে 300 টোকেন আছে, একটি router-কে allowance 80 দেওয়া হলো। সাধারণ ERC-20-তে বাকি allowance ও ব্যালান্সের মধ্যে ছোট সংখ্যাটিই ব্যবহারের সীমা। অনুমতি এক লেনদেনেই সীমাবদ্ধ নাও থাকতে পারে—চুক্তি একাধিকবার transferFrom ডাকতে পারে। অনুমোদিত চুক্তি বা নির্দিষ্ট কল-পথ অপব্যবহার হলে প্রত্যাশার বাইরে টোকেন সরতে পারে। টোকেনের অমানক আচরণও যাচাই করুন।

Approval সাধারণত টোকেন চুক্তিতে পাঠানো অন-চেইন লেনদেন, যাতে নেটওয়ার্ক ফি লাগতে পারে। কিছু অ্যাপ approval ও swap আলাদা করে; অন্যগুলো স্বাক্ষরকে পরের লেনদেনের সঙ্গে ব্যবহার করে। শুধু “Approve” বোতাম দেখে নয়, ওয়ালেট কী স্বাক্ষর করাতে চাইছে ও কোন নেটওয়ার্ক নির্বাচিত তা পড়ুন।

“Unlimited” সাধারণত টোকেনের সর্বোচ্চ পূর্ণসংখ্যার কাছাকাছি allowance বোঝায়। এতে অসীম টোকেন তৈরি হয় না এবং approval দেওয়ার সময় ব্যালান্স চলে যায় না। তবে একই নেটওয়ার্কে একই টোকেন পরে এই ওয়ালেটে এলে spender বাকি অনুমতি ব্যবহার করতে পারে। কিছু বাস্তবায়নে সর্বোচ্চ allowance খরচ হলেও তা কমে না; টোকেনের আচরণ যাচাই করুন।

বারবার approval এড়াতে অ্যাপ বড় সীমা চাইতে পারে, কিন্তু সুবিধা ও ঝুঁকি দুটোই বিবেচ্য। spender চুক্তির দুর্বলতা বা নিয়ন্ত্রণের অপব্যবহার হলে পুরোনো অনুমতি পরে কাজে লাগতে পারে। Ethereum.org-এর revoke guide ব্যাখ্যা করে, টোকেন ওয়ালেটে ফিরিয়ে আনলেও বড় allowance ঝুঁকি তৈরি করতে পারে।

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

স্বাক্ষরের আগে চারটি জিনিস মিলিয়ে দেখুন: নির্বাচিত নেটওয়ার্ক অ্যাপের নির্দেশনার সঙ্গে মেলে কি না; শুধু টিকার নয়, টোকেন চুক্তির ঠিকানা সঠিক কি না; spender ঠিকানা প্রকল্পের সরকারি নথি বা যাচাইযোগ্য চুক্তির সঙ্গে মেলে কি না; আর সীমা পরিকল্পিত কাজের জন্য যথেষ্ট নাকি অপ্রয়োজনীয়ভাবে বড়।

ব্যক্তিগত বার্তা, QR কোড, সাপোর্ট চ্যাট বা অযাচাইকৃত বিজ্ঞাপনের লিংক থেকে ওয়ালেট যুক্ত করবেন না। ফিশিং সাইট আসল অ্যাপের মতো দেখাতে পারে। সংরক্ষিত সরকারি ঠিকানা বা প্রকল্পের নথি থেকে শুরু করুন। পরিচিত চুক্তির নাম ঠিকানার নিরাপত্তা প্রমাণ করে না; block explorer-এর verified চিহ্নও নিরাপত্তার নিশ্চয়তা নয়।

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

কিছু ERC-20 ERC-2612 permit সমর্থন করে। সাধারণ approve লেনদেনের বদলে মালিক typed data-তে স্বাক্ষর করেন; অন্য কেউ সেই স্বাক্ষর জমা দিয়ে allowance সেট করতে পারে। মানক বার্তায় মালিক, spender, পরিমাণ, nonce ও deadline থাকে এবং domain স্বাক্ষরকে নেটওয়ার্ক ও চুক্তির সঙ্গে যুক্ত করে।

ERC-2612-এর deadline হলো স্বাক্ষরিত permit জমা দেওয়ার শেষ সময়। সফলভাবে সেট হওয়া allowance ওই সময়ে নিজে থেকে শেষ হবে—এমন নয়। ব্যবহৃত, পরিবর্তিত বা বাতিল না হওয়া পর্যন্ত তা থাকতে পারে। কিছু টোকেনে আলাদা permit পদ্ধতি বা অতিরিক্ত মেয়াদ থাকে; “permit” লেখা প্রতিটি অনুরোধকে ERC-2612 ভাববেন না।

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

লগআউট বা ওয়ালেট বিচ্ছিন্ন করলে ব্রাউজার সেশন বা সংযোগের অনুমতি বদলায়। টোকেন চুক্তিতে থাকা ERC-20 allowance থেকে যেতে পারে। উল্টো দিকে, allowance বাতিল করলেও সাইটের জানা প্রকাশ্য ঠিকানা বা পুরোনো অন-চেইন ইতিহাস মুছে যায় না। MetaMask-এর disconnect guide এই পার্থক্য ব্যাখ্যা করে।

বাতিল করতে সাধারণত অন-চেইন লেনদেনে নির্দিষ্ট টোকেন ও spender-এর allowance শূন্য করতে হয়। এতে নেটওয়ার্ক ফি লাগে; নিশ্চিত হওয়ার আগে পুরোনো অনুমতি কার্যকর থাকতে পারে। পরে approval তালিকা আপডেট করে বা চুক্তি আবার দেখে একই ওয়ালেট, নেটওয়ার্ক, টোকেন ও spender-এর মান শূন্য হয়েছে কি না নিশ্চিত করুন। MetaMask-এর approval guide এবং Ethereum.org নেটওয়ার্কভিত্তিক যাচাইয়ের কথা বলে; যে টুলই ব্যবহার করুন সরকারি domain ও নেটওয়ার্ক মিলিয়ে নিন।

প্রতিটি নেটওয়ার্ক আলাদা অবস্থা রাখে। Ethereum-এ শূন্য করলে অন্য নেটওয়ার্কের একই টোকেনের অনুমতি বদলায় না। প্রাসঙ্গিক প্রতিটি অ্যাকাউন্ট, টোকেন চুক্তি, spender ও নেটওয়ার্ক দেখুন, লেনদেন নিশ্চিত হওয়ার পরে ফল যাচাই করুন। কোনো revoke tool-এর seed phrase বা private key লাগার কথা নয়।

শূন্য allowance নিশ্চিত হলে সেই অনুমতি দিয়ে নতুন transferFrom করা যায় না। কিন্তু সম্পন্ন স্থানান্তর বাতিল, প্রাপকের কাছ থেকে টোকেন ফেরত বা অন্য চুক্তির অনুমতি মুছে দেয় না। সন্দেহজনক spender ইতিমধ্যে টোকেন সরিয়ে ফেললে শুধু revoke করে সেগুলো ফিরে পাওয়া নিশ্চিত নয়।

ওয়ালেটের private key ফাঁস হলে আক্রমণকারী অন্যভাবে লেনদেন স্বাক্ষর করতে পারে। অন্য spender বা টোকেনের approval, NFT operator permission, permit signature এবং চুক্তি-নির্দিষ্ট ক্ষমতাও থাকতে পারে। ফলাফল কেবল যে ওয়ালেট ও নেটওয়ার্ক পরীক্ষা করেছেন তার মধ্যে বুঝুন।

বাতিলের পরে পরের swap, deposit বা redemption-এ আবার অনুমতি দিতে হতে পারে। কোনো pending transaction বা active position ওই permission ব্যবহার করছে কি না দেখুন; দরকার হলে protocol-এর সরকারি সহায়তা নিন। পরিবর্তনের পরের ধাপ কী হবে, তা আগে জানুন।

ERC-20 মান বলে, একটি nonzero allowance আরেকটি nonzero মানে বদলানোর আগে UI-তে শূন্য করার পরামর্শ দেওয়া উচিত। পুরোনো ও নতুন approval-এর মাঝখানে spender-এর লেনদেন ঢুকলে প্রত্যাশার চেয়ে বেশি ব্যবহার হতে পারে। যেমন 100 থেকে 25 করলে, নতুন 25 রেকর্ড হওয়ার আগে spender পুরোনো 100 ব্যবহার করে পরে নতুন 25-ও ব্যবহার করতে পারে।

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

বর্তমান allowance না জানলে বদলানোর আগে নির্বাচিত নেটওয়ার্কে টোকেন চুক্তি দেখুন। মান ফাঁকা বা অপ্রত্যাশিত হলে অন্য নেটওয়ার্ক বা ঠিকানা দেখছেন কি না মিলিয়ে নিন। মালিকের ঠিকানা ও টোকেন চুক্তি দুটিই সঠিক হওয়া দরকার।

1. প্রকল্পের সরকারি domain ও নির্বাচিত নেটওয়ার্ক নিশ্চিত করুন।
2. টোকেন চুক্তি ও spender ঠিকানা যাচাই করে সীমাটি পরিকল্পিত পরিমাণের সঙ্গে তুলনা করুন।
3. ওয়ালেটের আসল transaction বা typed data পড়ুন। না বুঝলে স্বাক্ষর করবেন না।
4. যে spender আর ব্যবহার করেন না বা বিশ্বাস করেন না, তার allowance সঠিক নেটওয়ার্কে দেখুন; প্রয়োজন হলে শূন্য করে ফল যাচাই করুন।
5. ওয়ালেট তুলনা করার সময় নেটওয়ার্ক সমর্থনের পাশাপাশি approval কত পরিষ্কার দেখায় এবং update/recovery নির্দেশনা কতটা বোধগম্য তাও দেখুন।

Hardware wallet কী সংরক্ষণ ও স্বাক্ষর যাচাইয়ের একটি উপায়; এটি চুক্তির নিরাপত্তার গ্যারান্টি নয় বা বড় allowance অনুমোদন ঠেকায় না। spender, token, network ও amount নিজে যাচাই করুন। সাইট সংযোগের বাইরে allowance থেকে যেতে পারে বুঝলে ওয়ালেট নিরাপত্তা ফিচার ও সীমা তুলনা করাও সহজ হয়।