Aave Labs представила документ ARFC з пропозицією нового уніфікованого фреймворку для додавання активів (Technical Asset Listing Framework – TALF) до Aave V3, V4 та Aave Horizon.
Aave Labs опублікували ARFC із пропозицією нового стандартизованого Technical Asset Listing Framework для Aave V3, V4 та Aave Horizon.
Фреймворк встановлює послідовні технічні вимоги для лістингу активів, розширення параметрів і постійного моніторингу. pic.twitter.com/OO9hwJK80T
— Aave (@aave) May 28, 2026
Цей фреймворк визначає уніфіковані технічні критерії для включення активів, модифікації їх параметрів та безперервного відстеження.
Команда пропонує запровадити мінімальний поріг для відбору. Мета полягає у зменшенні розбіжностей в оцінках, підвищенні прозорості критеріїв та запуску постійного моніторингу вже доданих токенів.
Документ не скасовує необхідність аналізу ринкових ризиків, ліквідності, проведення юридичної експертизи та прийняття рішень DAO. Він слугує як базовий технічний фільтр, який має застосовуватися поряд з висновками від постачальників ризик-менеджменту та інших учасників екосистеми.
Фреймворк охоплює три сценарії:
- додавання нових активів;
- активи зі значними змінами параметрів;
- регулярна та позапланова технічна переоцінка.
Якщо токен функціонує в кількох мережах, він повинен відповідати вимогам для кожної мережі окремо, враховуючи реалізацію смарт-контрактів, міжмережевих мостів, оракулів, прав доступу та залежностей.
На початковому етапі актив повинен бути розгорнутий та перевірений у цільовій мережі, класифікований згідно з Aave Asset Classification Framework та не належати до заборонених або підсанкційних категорій.
Якщо в протоколі вже існує подібний інструмент, його пропонується використовувати як орієнтир при налаштуванні оракулів, коефіцієнтів співвідношення вартості застави до суми позики (LTV), порогів ліквідації та лімітів.
Суворі вимоги до ERC-20
Один з ключових розділів присвячений сумісності токенів зі стандартом ERC-20.
Aave Labs пропонує встановити наступні вимоги:
- передбачувана робота функцій `transfer()` та `transferFrom()`;
- відсутність механіки комісій за переказ (fee-on-transfer);
- заборона на ребейзинг без окремої обгортки;
- відмова від хуків ERC777 та зворотних викликів ERC1363;
- коректна підтримка десяткових знаків.
Можливість додаткової емісії через flash mint не забороняється, проте вона має бути розкрита та підтверджено, що вона не порушує внутрішній облік протоколу.
Контракт також не повинен містити обмежень щодо списків дозволених адрес для зберігання та переказів.
Chainlink як основне джерело цін
Як основне джерело котирувань у цільовій мережі пропонується використовувати Chainlink. Будь-яка альтернативна схема повинна бути окремо обґрунтована.
Для прибуткових активів допускається використання CAPO, який обмежує припущення щодо зростання обмінного курсу або вартості.
Відсутність надійного механізму ціноутворення, застарілі дані або високий інфраструктурний ризик оракулів повинні безпосередньо відображатися в рекомендаціях щодо лістингу, ризик-параметрів та моніторингу.
Контроль емісії та привілейованих ролей
Окремий розділ присвячено правам доступу та випуску токенів.
Aave Labs пропонує розкривати всі привілейовані ролі як у контракті ERC-20, так і у зовнішніх модулях, що можуть впливати на пропозицію, баланси, переказ або погашення активу.
До них відносяться:
- власник (owner);
- адміністратор (admin);
- емітент (minter);
- спалювач (burner);
- оператор паузи (pauser);
- оператор чорного списку (blacklister);
- ролі, пов’язані з мостами та адаптерами.
Для цих ролей запроваджується шкала безпеки від Level 0 до Level 5. Найменш надійними вважаються Level 0–1 — одиночний ключ без затримки виконання або мультипідпис без чесної більшості.
У розділі випуску та спалення вимагається документувати функції емісії, перелік авторизованих адрес, ліміти та часові обмеження. Окремо оцінюється worst-case mint exposure у доларах — відносно потенційної заставної експозиції Aave.
Серед небажаних сценаріїв:
- необмежена емісія;
- можливість одночасного збільшення ліміту випуску та його використання однією адресою;
- довільне спалення токенів з гаманців користувачів.
Ризики паузи, чорних списків та оновлюваних контрактів
Функції паузи та чорних списків виділено в окрему зону ризику. Вони можуть безпосередньо впливати на ліквідації та виведення коштів. Управління має розуміти, хто контролює ці повноваження та чи може механізм блокування адрес перешкодити ліквідаціям у протоколі.
Для оновлюваних контрактів необхідно розкривати тип проксі, адміністратора оновлень, наявність таймлоку та історію оновлень. Слабкий механізм оновлення прямо визнається таким, що не відповідає стандарту лістингу.
Додаткові вимоги для LST та LRT
Для LST, LRT, обгорток та токенів сховищ запроваджуються додаткові вимоги до механіки обмінного курсу.
Пропонується перевіряти:
- можливість маніпуляції курсом через донати, флеш‑кредити або особливості обліку;
- наявність зрозумілого механізму погашення;
- достатність вторинної ліквідності для ліквідацій.
Актив без прозорого механізму погашення та достатньої ліквідності може зіткнутися зі значними обмеженнями щодо лістингу та ризик-параметрів або вимагатиме доопрацювання.
Ця ініціатива продовжує курс, заявлений після інциденту з KelpDAO. На початку травня протокол повідомив про намір переглянути стандарти оцінки застави та лістингу, розширивши фокус з волатильності й ліквідності на кібербезпеку, сумісність та технічну архітектуру.
Водночас ARFC не запроваджує автоматичну систему оцінок і не містить універсального переліку стоп-факторів. Технічні звіти можуть включати якісні оцінки та маркування ризиків, проте чітких порогів для автоматичної відмови у лістингу не передбачено.
Нагадаємо, у травні лендинговий протокол Aave відновив параметри забезпечення для wETH у шести мережах.