پیش از انتخاب قالب، اختیارات را توصیف کنید
مشخصات توکن را با یک جدول اختیارات شروع کنید. هر اقدام حساس، شخص یا نهادی که مجاز به انجام آن است، محدودیت‌های قابل‌اعمال و نحوه تغییر آن اختیار را فهرست کنید. صدور واحدها، محدودکردن انتقال‌ها در صورت پشتیبانی، تغییر پیکربندی و ارتقای منطق در صورتی که طراحی اجازه دهد را هم بگنجانید. فرض نکنید یک برچسب آشنای توکن، این جزئیات را توضیح می‌دهد. خریدار باید در کنار رابط‌های فنی، رفتار قابل‌فهم با زبان ساده را هم دریافت کند. این جدول همچنین مبنایی برای طراحی صفحه‌های مدیریتی فراهم می‌کند: هر کنترل باید به یک مجوز واقعی متناظر باشد، نه صرفاً به دکمه‌ای که در یک دمو راحت به نظر می‌رسد.
قواعد صدور را شفاف کنید
پیش از انتخاب کنترل‌های mint، درباره رفتار موردنظرِ عرضه گفت‌وگو کنید. آیا عرضه یک‌باره ایجاد می‌شود، طبق زمان‌بندی آزاد می‌شود یا از طریق یک فرایند تجاری مستمر افزایش پیدا می‌کند؟ مشخص کنید چه کسی صدور را آغاز می‌کند، چه بررسی‌هایی اعمال می‌شود و چه رکوردی دلیل آن را توضیح می‌دهد. فرایند تأیید عملیاتی را از محدودیت‌هایی که خود قرارداد اعمال می‌کند جدا کنید. اگر سقفی وعده داده شده است، بازبینی پیاده‌سازی باید مشخص کند چه چیزی واقعاً آن را enforce می‌کند. به‌جای پذیرش یک mint موفق به‌عنوان تنها شاهد، نمونه‌هایی در مرز محدودیت بخواهید؛ از جمله درخواستی بالاتر از حد مجاز و درخواستی تکراری.
freeze، pause و محدودیت حساب را از هم تفکیک کنید
برچسب‌های مشابه در رابط کاربری می‌توانند اختیارات متفاوتی را پنهان کنند. مدل توکن Solana دارای freeze authority است، در حالی که پیاده‌سازی‌های دیگر ممکن است سازوکار سفارشی pause یا restriction ارائه کنند. این سازوکارها را قابل‌جایگزینی با یکدیگر فرض نکنید. مشخص کنید هر کنترل روی کدام حساب‌ها یا عملیات اثر می‌گذارد، چه کسی می‌تواند آن را برگرداند و مشتریان چطور وضعیت فعلی را تشخیص می‌دهند. یک تلاش برای انتقال در شرایط محدودیت مربوطه و پس از برداشتن آن را نمایش دهید. برای برنامه‌ریزی محصول، پرسش مهم رفتار دقیقی است که دارنده تجربه می‌کند؛ نه اینکه آیا صفحه فروش، یک قابلیت کلی freeze را در میان تعداد زیادی چک‌باکس فهرست کرده است یا نه.
اختیار ارتقا را مستقل بررسی کنید
طراحی مبتنی بر proxy می‌تواند منطق قرارداد را قابل‌جایگزینی کند؛ موضوعی که تصمیم حاکمیتی جداگانه‌ای نسبت به اینکه چه کسی می‌تواند توکن صادر کند ایجاد می‌کند. اختیار واقعی ارتقا و فرایندی را که برای بازبینی پیاده‌سازی پیشنهادی به کار می‌رود شناسایی کنید. در نظر بگیرید اپراتورها و مشتریان چطور متوجه تغییر رفتار می‌شوند و پیش از استقرار، چه بررسی‌های سازگاری لازم است. اگر قرار است توکن غیرقابل‌ارتقا باشد، این فرض را در معماری تحویل‌شده راستی‌آزمایی کنید، نه اینکه صرفاً به یک برچسب تکیه کنید. رکوردی از آدرس‌ها و نسخه‌های مستقرشده نگه دارید تا در بازبینی بعدی بتوان مشخص کرد در یک زمان مشخص چه چیزی در حال اجرا بوده است.
حذف اختیارات را یک تغییر عملیاتی بدانید
لغو اختیار ممکن است در سیستم انتخاب‌شده برگشت‌ناپذیر باشد؛ برای مثال، مستندات Solana حذف دائمی یک اختیار منتخب را از طریق تنظیم آن روی None توضیح می‌دهد. پیش از هر اقدام از این نوع، شبکه، آدرس، نقش دقیق و قابلیت‌هایی را که دیگر در دسترس نخواهند بود بررسی کنید. این تغییر را با افراد مسئول عملیات جاری مرور کنید. فرایند را در یک محیط آزمایشی مناسب تمرین کنید و شواهد حاصل را نگه دارید. فرض نکنید حذف یک مدیر، همه مسیرهای دارای امتیاز ویژه را از بین می‌برد: نقش‌های باقی‌مانده و کنترل‌های ارتقا باید جداگانه و بر اساس ویژگی‌های خودشان بررسی شوند.
مجوزهای مستقرشده را بپذیرید، نه فقط سورس را
هنگام تحویل، جدول اختیارات موردنظر را با پیکربندی واقعیِ مستقرشده مقایسه کنید. بررسی کنید هر نقش در اختیار چه کسی است و چرخش نقش‌ها، از دست رفتن دسترسی و تصمیم‌های اضطراری چگونه مدیریت می‌شود. مراحل نصب، سوابق استقرار، جزئیات تأیید قرارداد و تست‌های مربوط به اقدامات غیرمجاز را درخواست کنید. رابط مدیریتی باید پیش از عملیات حساس، شبکه انتخاب‌شده و هدف را کاملاً واضح نشان دهد. یک بازبینی تحویل مفید با درک مشترکی به پایان می‌رسد از اینکه امروز چه کسی می‌تواند توکن را تغییر دهد، این وضعیت فردا چگونه ممکن است تغییر کند و تیم عملیاتی و دارندگان پیش از راه‌اندازی باید کدام محدودیت‌ها را بدانند.