با مسئله کاربر شروع کنید، نه نشان استاندارد
اصطکاکی را انتخاب کنید که می‌خواهید حذف شود: اولین تراکنشی که نیاز به تهیه گس دارد، تأییدهای تکراری در یک فعالیت آشنا، یا فرایند بازیابی‌ای که مشتریان نمی‌توانند آن را کامل کنند. پیش از انتخاب زیرساخت حساب، مسیر مطلوب کاربر را توصیف کنید. ERC-4337 عملیات حساب هوشمند را حول UserOperationها و سرویس‌های پشتیبان سامان می‌دهد. اما به‌تنهایی همه قابلیت‌های بازیابی یا مجوزدهی موردنیاز محصول شما را تعریف نمی‌کند. از تأمین‌کننده بخواهید هر مزیت پیشنهادی را به یک قابلیت پیاده‌سازی‌شده، یک تصمیم پیکربندی یا کار تکمیلی نگاشت کند. برچسب استاندارد زمینه مفیدی می‌دهد، اما مشخصات کامل محصول نیست.
نشان دهید مشتری چه چیزی را مجاز می‌کند
صفحه آنبوردینگ ساده‌تر همچنان باید اختیار و دسترسی را قابل‌فهم کند. امضاکننده، حسابی که کنترل می‌شود و دامنه عملی که تأیید می‌گردد را مشخص کنید. اگر چند فراخوانی در یک تعامل گروه‌بندی شده‌اند، اثر ترکیبی آن‌ها را خلاصه کنید و جزئیات مفید را در دسترس بگذارید. توضیح دهید وقتی فقط بخشی از جریان کاری تجاریِ موردنظر بیرون از مرز تراکنش حساب قرار دارد چه اتفاقی می‌افتد. هنگام بازبینی، از کاربری ناآشنا بخواهید توضیح دهد فکر می‌کند چه چیزی را تأیید کرده است. این تمرین اغلب فاصله میان یک درخواست فنیِ درست و توضیحی واقعاً مفید برای مشتری را آشکار می‌کند.
کارمزدهای اسپانسرشده را به‌عنوان سرویسی محدود مدیریت کنید
Paymasterها می‌توانند در جریان ERC-4337 از اسپانسرکردن گس پشتیبانی کنند، اما محصول همچنان باید تصمیم بگیرد چه کسی واجد شرایط است و چه کسی هزینه را می‌پردازد. بودجه‌ها، اقدام‌های پشتیبانی‌شده، کنترل‌های سوءاستفاده و واکنش در زمان در دسترس نبودن اسپانسرشیپ را مشخص کنید. نگذارید یک تعامل اول رایگان، استفاده رایگان نامحدود را القا کند. هر پرداخت لازم از سوی مشتری را پیش از تأیید نشان دهید، به‌ویژه وقتی مسیر جایگزین هزینه را تغییر می‌دهد. تجربه اپراتور را هم لحاظ کنید: کسی باید هزینه‌کرد را ببیند، مصرف غیرمنتظره را بررسی کند و یک سیاست را بدون اینکه ناخواسته مشتریان را از اقدام‌های نامرتبطی که حسابشان باید همچنان پشتیبانی کند محروم سازد، تعلیق کند.
مجوزهای محدود را ملموس تعریف کنید
اگر حساب انتخاب‌شده از مجوزهای نشست پشتیبانی می‌کند، آن‌ها را با مفاهیمی تعریف کنید که مشتری بتواند بررسی کند: مقصدهای مجاز، عملیات مجاز، سقف هزینه، مدت‌زمان و امکان لغو. صرفاً چون نشست تعداد درخواست‌های تأیید را کاهش می‌دهد، آن را بی‌خطر توصیف نکنید. نمونه‌ای از یک اقدام مجاز را کنار یک اقدام مسدودشده بنویسید، سپس هر دو را در برابر قواعد پیاده‌سازی‌شده آزمایش کنید. به کاربران نشان دهید مجوزهای فعال را کجا می‌توانند مرور کنند. برای حالتی که نشست در میانه یک کار منقضی می‌شود برنامه داشته باشید و فقط برای حفظ ظاهر روان رابط کاربری در دمو، بی‌سروصدا اختیار گسترده‌تری درخواست نکنید.
بازیابی را جدا از دسترسی عادی مشخص کنید
طراحی بازیابی باید طرف‌های درگیر، شرایط تغییر امضاکننده و هر اعلان یا دوره انتظار را نام ببرد. یک صفحه ایمیل آشنا به‌تنهایی اختیار زیربنایی را توضیح نمی‌دهد. سناریوهای دستگاه گم‌شده و دستگاه در معرض نفوذ را جداگانه بررسی کنید، از جمله اینکه اگر طراحی اجازه می‌دهد، مشتری مشروع چگونه می‌تواند به یک تغییر در انتظار اعتراض کند یا آن را متوقف سازد. به‌جای وعده بازیابی همگانی، محدودیت‌ها را مستند کنید. تحویل باید شامل ران‌بوک اپراتور و توضیح مشتری باشد که با قراردادها و سرویس‌های واقعی مطابقت دارد. کل فرایند را آزمایش کنید، نه فقط دکمه‌ای را که آن را شروع می‌کند.
وابستگی‌ها را به‌عنوان بخشی از محصول ارزیابی کنید
برای شبکه‌های پشتیبانی‌شده و اجزا، یک ماتریس بخواهید که پیاده‌سازی حساب، سازگاری با EntryPoint، bundler، paymaster و سرویس‌های لازمِ اپلیکیشن را پوشش دهد. ثبت کنید کدام نسخه‌ها مستقر شده‌اند و ارزیابی ارتقاها با چه کسی است. در یک محیط کنترل‌شده، ازکارافتادن ارائه‌دهنده، ردشدن اسپانسرینگ، منقضی‌شدن مجوزها، رد عملیات و شکست در استقرار حساب را تمرین کنید. مطمئن شوید تاریخچه مشتری، درخواست داخل اپلیکیشن را به نتیجه نهایی آن روی زنجیره وصل می‌کند. محصول smart-wallet با دامنه‌گذاری درست، لزوماً محصولی نیست که در همه وضعیت‌ها کمترین گامِ قابل‌مشاهده را داشته باشد؛ محصولی است که مسیر ساده‌شده‌اش وقتی سرویس‌های پشتیبان از حالت عادی خارج می‌شوند، همچنان قابل‌فهم بماند.