چهار موجودی را نام‌گذاری کنید
داشبورد وستینگ زمانی گیج‌کننده می‌شود که از «در دسترس» برای چند مبلغ متفاوت استفاده کند. تخصیصی را که طبق برنامه وعده داده شده، توکن‌هایی را که واقعاً تأمین شده‌اند، مبلغی را که تا زمان محاسبه وست شده و مبلغی را که قبلاً مطالبه شده است از هم جدا کنید. مبلغ قابل مطالبه را فقط پس از تطبیق این مفاهیم با پیاده‌سازی نمایش دهید. هرگونه کسری تأمین مالی را صریح توضیح دهید. ذی‌نفع نباید مجبور باشد حدس بزند دکمه صفر یعنی چیزی وست نشده، همه‌چیز مطالبه شده یا قرارداد توکن کافی ندارد. همین تعریف‌ها را در اختیار تیم پشتیبانی نیز قرار دهید.
زبان تقویمی را به مثال تبدیل کنید
زمان شروع، کلیف، مدت و الگوی آزادسازی را به شکلی بنویسید که هم توسعه‌دهندگان و هم ذی‌نفعان آن را بفهمند. مشخص کنید کلیف مبلغ انباشته‌شده را آزاد می‌کند یا دوره انباشت تازه‌ای را آغاز می‌کند. یک لحظه پیش از مرز، خود مرز و یک لحظه پس از آن را تست کنید. تخصیصی را وارد کنید که به‌طور مساوی در برنامه تقسیم نمی‌شود تا رفتار گرد کردن آشکار شود. زمان‌ها را به‌صورت سازگار ذخیره کنید و منطقه زمانی آن‌ها را نمایش دهید. عبارت‌های بازاریابی مانند «آزادسازی ماهانه» بدون توضیح دقیق تاریخ‌ها و قاعده محاسبه کافی نیستند.
مشخص کنید تأمین مالی بعدی چه معنایی دارد
مستندات VestingWallet در OpenZeppelin اشاره می‌کند که واریزهای بعدی از برنامه موجود پیروی می‌کنند و ممکن است از قبل بخشی از آن‌ها قابل آزادسازی باشد. هنگام استفاده از این پیاده‌سازی، این موضوع را به‌عنوان یک انتخاب عمدی محصولی در نظر بگیرید. شارژی که قرار است یک اعطای جدید باشد، ممکن است به برنامه‌ای جداگانه نیاز داشته باشد، نه افزوده شدن به موجودی قبلی. پیش از تأمین مالی، هدف، ذی‌نفع، هویت توکن و برنامه مورد انتظار را ثبت کنید. اثر فوری بر مبلغ قابل مطالبه را برای اپراتور پیش‌نمایش دهید. هم واریزهای زودهنگام و هم دیرهنگام را تست کنید تا یک اقدام عادی خزانه‌داری باعث آزادسازی غیرمنتظره نشود.
تغییرات و اختیار را توضیح دهید
مستند کنید آیا ذی‌نفع قابل تغییر است، آیا حقوق قابل انتقال‌اند و آیا امکان لغو یا اصلاح وجود دارد یا نه. این‌ها انتخاب‌های پیاده‌سازی‌اند، نه قابلیت‌هایی که از روی یک صفحه باید فرض شوند. نشان دهید چه کسی می‌تواند درخواست تغییر بدهد و چه کسی می‌تواند آن را مجاز کند. برنامه اولیه و دلیل هر تغییر تأییدشده را حفظ کنید. آدرس‌ها را با یک گردش کار کنترل‌شده تأیید کنید، نه با کپی کردن یک پیام چت بازبینی‌نشده. فرایند بازیابی باید محدودیت‌های خود را مشخص کند، از جمله مواردی که قرارداد مستقرشده نمی‌تواند اقدام قبلی را برگرداند.
سوابق مطالبه را قابل حسابرسی کنید
برای هر مطالبه، شناسه‌ی زمان‌بندی، شبکه، دارایی، دریافت‌کننده، مبلغ، مرجع تراکنش و وضعیت مشاهده‌شده را نگه دارید. تراکنش در انتظار باید تا زمانی که قاعده‌ی تأیید پیکربندی‌شده برآورده شود، در همان وضعیت بماند. تلاش دوباره‌ی یک درخواست کاربر نباید یک تلاش دومِ بی‌توضیح برای مطالبه ایجاد کند. زمان آخرین تطبیق را کنار موجودی‌های محاسبه‌شده نمایش دهید، به‌ویژه وقتی ایندکسر با تأخیر کار می‌کند. اپراتورها به نمایی از مغایرت‌ها و مشاهده‌های ناموفق نیاز دارند؛ ذی‌نفعان هم به توضیحی ساده و اقدام بعدیِ مفید نیاز دارند. این نماها را به همان شواهد زیربنایی متصل نگه دارید.
برای روز انتشار، دستورالعمل عملیاتی آماده کنید
پیش از نخستین آزادسازی، بررسی‌های تأمین موجودی، پرسش‌های ذی‌نفعان، قطعی ارائه‌دهندگان و مطالبه‌ای را که نزدیک یک مرز زمانی ثبت می‌شود، تمرین کنید. مستند کنید چه کسی می‌تواند هر مسئله را بررسی کند و کدام سوابق را خواهد دید. سازگاری کیف‌پول، برچسب‌ها در صفحه‌نمایش کوچک، دقت اعداد و قالب‌بندی ترجمه‌شده‌ی تاریخ را آزمایش کنید. تقویم انتشار را از هر وعده‌ای درباره‌ی ارزش بازار یا نقدشوندگی جدا نگه دارید. بسته‌ی پذیرش نهایی باید شامل نمونه‌های محاسبه، قواعد دسترسی، گزارش‌های تطبیق و محدودیت‌های بازیابی باشد. یک محصول واگذاری مرحله‌ایِ قابل اتکا توضیح می‌دهد چه چیزهایی ممکن است رخ دهد، ثابت می‌کند چه چیزی رخ داده و برای اپراتورها فرایندی تکرارپذیر فراهم می‌کند.