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