Коллектив Aave Labs випустив документ ARFC, в якому пропонують новий стандартизований Technical Asset Listing Framework (TALF) для Aave V3, V4 і Aave Horizon.
Ціль ця документа — встановити єдині технічні вимоги для нових активів, які будуть розміщені в мережах Aave. Це допоможе зробити оцінку активів більш прозорою і знизити ризики для користувачів мережі.
🚀💰
Документ не заміне аналіз ризиків ринку, ликвідності, законодавчої експертизи тощо. Він лише встановлює базовий технічний фільтр, який має бути застосований разом із висновками ризик-провайдерів та інших учасників екосистеми.
📊🐋
Фреймворк охоплює три сценарії: зміни параметрів активу, періодичні технічні перевірки та інший випадок відсутності технічних змін.
Під час перевірки актив має відповідати вимогам окремо для кожної мережі, в якій він присутній. Ці вимоги стосуються реалізації контрактів, мостів, оракулов, прав доступу і залежностей.
Актив має бути розгорнутий і затверджений для цілевказової мережі, а також бути класифікованим згідно з Aave Asset Classification Framework. Ніколи не можна розміщувати заборонені або санкційні категорії активів.
Якщо вже існуючий актив схожий на той, який бажають розмістити, необхідно використовувати його як орієнтир при налаштуванні оракулів, коэфціентів залога, порогів ликвідності та інших параметрів.
Для актива, який розміщується в мережі ERC-20, необхідно дотримуватися певних вимог щодо роботи з цим стандартом. Для цього потрібно підтвердити, що функції transfer() і transferFrom() працюють передбачувано, відсутні механізми комісій при переказу тощо.
Додаткової емісії через флаш-мінт можна робити, але її необхідно розкривати і підтверджувати, щоб вона не порушувала облік у протоколі.
Для доходних активів допускається використання механізму CAPO, який обмежує припущення щодо зростання обміну або вартості активу.
Якщо відсутні стабільні механізми котування цін, застарілені дані або високий інфраструктурний ризик оракулів, ці ризики повинні бути відображені в рекомендаціях щодо розміщення, ризикових параметрах і моніторингу.
Для актива також необхідно розкривати всі привілеговані ролі як у контракті ERC-20, так і в зовнішніх модулях, які можуть впливати на пропозицію, баланс тощо.
Для кожного привілегійного ролі встановлюються рівень безпеки від Level 0 до Level 5. Наївно не надійні рівні вважаються Level 0–1, які можуть мати лише одне ключове слово, яке не видаляє виконання або мультисиг за відсутності більшості.
Для випуску і знищення актива необхідно розкривати функції випуску, список авторизованих адрес, обмеження тощо.
Ризики паузи, чорних списків і оновлюваних контрактів повинні бути відображені окремо у технічному звіті.
Для LST, LRT, оберток і токенів хранилищ необхідно додатково дотримуватися вимог щодо механізму зміни цін.
За матеріалами ForkLog