Я писав про це багато в минулому, тому не буду писати сьогодні великий трактат, але коли йдеться про стейблкоіни (включаючи ті, що розраховані на ETH або інші еталонні активи), жорстко закодовані оракули мають крихкість. Вони працюють, поки раптово не перестають працювати.

Натомість живі оракули дозволяють здійснювати оцінку ризиків в реальному часі, але за ціну покарання користувачів за хибні спрацьовування, якщо ліквідність висихає.

Обидва підходи є законною конструкцією дизайну, але потребують дотримання різних процесів андерайтингу. Жорстко кодируйте лише якщо ви перевірили базовий актив і впевнені у його здатності забезпечити погашення в передбаченому обсязі.

І технічні, і фінансові основи мають бути міцними, та призначте премію за ризик для ставок або дисконт до LTV відповідно.

Живі оракули дозволяють вам бути відносно байдужим щодо якості активу (крім технічної безпеки смарт-контрактів) та сконцентруватися на доступності ліквідності.

Давайте також пам'ятатимемо, що можливі й більш складні налаштування оракулів. Я особисто виступав за те, щоб стейблкоіни мали жорстке кодування, коли n ліквідність є життєздатною в контракті погашення, а потім переходили на оракули ринкової ціни в момент, коли ліквідність падає нижче n.

Зрештою, це знову виявляє давню проблему «міграції кредиту», де DeFi покладається на кураторів та консультантів з ризиків, щоб вручну позначити, коли актив переходить від відмінного до хорошого до справедливого до поганого як забезпечення. Це набагато занадто повільно, навіть у випадку з USR, навіть якби це було на 100% точно.

DeFi автоматизує, прискорює та спрощує (навіть якщо це іноді видається інакше) фінанси у порівнянні з традиційними альтернативами. Ми в кінцевому рахунку будуємо фінансові торговельні автомати, і це просто факт, що дійсно важко зробити машину, яка б працювала так, як задумано, за будь-яких умов.

Але є ясні способи вдосконалення як дизайну оракулів, так і їхнього використання, і розчаровує бачити повільні інновації на цьому фронті.