Paymaster যোগ্য smart-account operation-এর অর্থায়ন গ্রাহকের দৃষ্টিতে কীভাবে হবে তা বদলাতে পারে। এটি network gas তুলে দেয় না: execution-এর জন্য network-এ technical gas settlement এখনও হয়, এবং সম্মত policy অনুযায়ী sponsor বা customer-fee ব্যবস্থায় সেই অর্থায়ন করতে হয়।
তিনটি সিদ্ধান্ত আলাদা করে flow নকশা করুন: কোন operation যোগ্য, অর্থনৈতিক খরচ কে বহন করবে এবং network-এর gas settlement কীভাবে অর্থায়ন ও reconcile হবে। যোগ্যতা কনফিগার করা network ও সমর্থিত settlement asset-এর ওপর নির্ভরশীল। সর্বজনীন sponsorship বা স্বয়ংক্রিয় transaction subsidy বোঝায় না।
Gas ও গ্রাহকের fee আলাদা রাখুন
Network ও account-abstraction configuration অনুযায়ী technical gas হলো network execution-এর খরচ। Customer-facing fee আলাদা policy-সংক্রান্ত সিদ্ধান্ত: প্রতিষ্ঠান যোগ্য operation sponsor করতে পারে অথবা কনফিগার করা model অনুযায়ী অনুমোদিত fee নিতে পারে। তাই গ্রাহকের কাছে fee শূন্য মনে হলেও অন্য পক্ষ খরচ বহন করছে, execution বিনামূল্যে নয়।
Protocol gas, customer-facing charge, sponsor budget, implementation বা managed-service charge এবং network reserve আলাদা item হিসেবে অনুসরণ করুন। এতে finance ও operations team-এর কাছে দায়িত্ব ও reconciliation স্পষ্ট হয়। সঠিক customer disclosure, accounting treatment এবং প্রাতিষ্ঠানিক policy ব্যাংক নির্ধারণ করে; Paymaster mechanism নিজে এগুলো স্থির করে না।
গ্রাহক অভিজ্ঞতা ও gas settlement সম্পর্কিত পৃথক পথে চলে
- গ্রাহকের পথপ্রতিষ্ঠানের নথিভুক্ত অভিজ্ঞতা অনুযায়ী operation অনুরোধ করেন।
- Policy-র পথযোগ্যতা, settlement asset, অনুমোদন ও কনফিগার করা সীমা যাচাই করে।
- Sponsor-এর পথSponsorship policy প্রযোজ্য হলে অনুমোদিত operation-এর অর্থ দেয়।
- Network-এর পথOperation execute করে এবং technical gas settle করে।
- Reconciliation-এর পথCustomer charge ও sponsor funding আলাদাভাবে নথিভুক্ত করে।
Sponsorship-এর যোগ্যতা নির্ধারণ করুন
কোন smart-account operation যোগ্য হতে পারে, কোন account বা application scope-এ আছে, কী policy condition প্রযোজ্য এবং ব্যতিক্রম কীভাবে review হবে, প্রতিষ্ঠান তা নির্ধারণ করবে। যোগ্যতা সর্বজনীন নয়। এটি কনফিগার করা settlement asset, network-এর আচরণ এবং সম্মত Paymaster policy-র ওপর নির্ভর করে; তাই শুধু application request করলেই অসমর্থিত operation যোগ্য হয়ে যায় না।
ERC-4337 Paymaster architecture-এ funding ও operation-এর শর্ত আছে, যার মধ্যে প্রযোজ্য native EntryPoint deposit ও stake অন্তর্ভুক্ত। কে funding-এর দায় নেবে, অনুমোদিত ব্যবহার কী, monitoring এবং replenishment কীভাবে হবে তা দায়িত্বপ্রাপ্ত পক্ষ নির্ধারণ করবে। Platform এগুলো স্বয়ংক্রিয়ভাবে দেয় না, network reserve থেকে আসবে এমন ইঙ্গিতও নেই, এবং প্রত্যেক গ্রাহকের জন্য নির্দিষ্ট allowance তৈরি করে না।
Settlement asset ও সীমা মূল্যায়ন করুন
কনফিগার করা policy সমর্থন করলে যোগ্য operation-এ customer-facing fee আদায়ের জন্য অনুমোদিত settlement token ব্যবহার হতে পারে। Token compatibility নির্ধারণে registration, conversion, settlement ও authorization আচরণের technical assessment দরকার। Application request-এ যেকোনো stablecoin-এর নাম দিলেই তা compatible হয় না, এবং এই নির্দেশিকা কোনো নির্দিষ্ট asset বা fee conversion rate-এর নিশ্চয়তা দেয় না।
নির্বাচিত policy-র জন্য স্পষ্ট সীমা ও exception handling ঠিক করুন, তারপর monitoring ও approval-এর role বরাদ্দ করুন। Sponsor funding অপর্যাপ্ত হলে, অনুরোধ করা asset অযোগ্য হলে, charge reconcile করা না গেলে বা application request বদলালে কী হবে বিবেচনা করুন। সম্মত environment-এ এসব ফল পরীক্ষা করুন এবং customer ও network record-এর প্রতিটি অংশের authoritative system নথিভুক্ত করুন।
Gas settlement-এর আগে যোগ্য operation policy যাচাই পেরোয়
- অপারেশনের অনুরোধএকটি smart account মূল্যায়নের জন্য operation পাঠায়।
- যোগ্যতা যাচাইকনফিগার করা asset, policy এবং সীমার শর্ত মূল্যায়ন করা হয়।
- Funding সিদ্ধান্তসম্মত sponsor বা customer-fee পথ নির্বাচন করা হয়।
- গ্যাস ফি নিষ্পত্তিNetwork execution-এ প্রয়োজনীয় technical gas settle হয়।
- Record মেলানোCustomer charge ও sponsor-এর ব্যয় আলাদা করে নথিভুক্ত হয়।
Policy পরিচালনা ও হিসাব মেলান
Operations team-কে customer fee collection ও প্রতিষ্ঠানের asset reserve থেকে আলাদাভাবে native gas funding পর্যবেক্ষণ করতে হবে। কে eligibility পরিবর্তন review করবেন, কে প্রযোজ্য deposit বা stake replenishment করবেন, service interruption কীভাবে escalate হবে এবং reconciliation-এ কোন record ব্যবহার হবে তা নির্ধারণ করুন। সম্মত operating scope-এ প্রতিষ্ঠান কী পরিচালনা করবে আর অন্য পক্ষ কী সেবা দেবে তা উল্লেখ থাকা উচিত।
Production-এর আগে অনুমোদিত test data দিয়ে সফল, প্রত্যাখ্যাত, অযোগ্য ও অপর্যাপ্ত অর্থায়নের পথগুলো পরীক্ষা করুন। Smart-account result, network record, sponsor funding movement এবং customer-facing charge reconcile করুন। কনফিগার করা সীমা ও approval যাচাই করে customer experience নির্ধারণের আগে product, finance, engineering এবং operations stakeholder-দের সঙ্গে evidence পর্যালোচনা করুন।