Сьогодні оракул Solana припиняє підтримку. Хто досі покладається на його ціни?

Крайній термін підтримки Switchboard 25 вересня перетворив шестиденне попередження про міграцію на випробування цінових потоків Solana. Поточна публічна документація показує, де її дані залишаються частиною дизайну застосунку, але ці сторінки не можуть довести, що живий ринок досі використовує цей потік. Jito та marginfi пропонують два різко різні погляди на експозицію.

Switchboard досягла заявленого завершення технічної підтримки 25 вересня, залишивши застосункам Solana перевірити джерела цін, налаштовані в їхніх живих програмах.

Заява оракул-проєкту від 19 вересня, відтворена в матеріалах про оголошення, повідомила, що його основний контриб'ютор розробки Switchboard Technology Labs згортається, а всі реалізації негайно застарівають. Команда закликала інтеграторів перейти до інших постачальників, назвавши Pyth і RedStone. 25 вересня було описано як останній день існуючої підтримки. Припинення підтримки компанією є реальною операційною віхою. Це саме по собі не доводить, що кожен ончейн-потік припинив оновлюватися опівночі або що кожен застосунок, колись пов'язаний зі Switchboard, залишався залежним від нього.

Власна документація Switchboard називала Kamino, Jito, marginfi та Drift користувачами. Це історичні твердження про інтеграцію від постачальника, який продавав послугу оракула, а не інвентаризація активних потоків у реальному часі станом на 25 вересня. Перевірка поточної документації кожного проєкту виявляє складнішу картину. Сторінки Jito Tip Router досі описують Switchboard у своєму потоці ціноутворення; вересневе технічне оновлення marginfi додає шляхи, розроблені для уникнення цієї залежності. Один документ може бути застарілим, тоді як інший передбачає міграцію. Жоден не замінює перевірку конфігурації живого акаунта.

Раніший раунд фінансування Switchboard становив 7,5 мільйона доларів у травні 2024 року. Сума є корисною довідкою про історію венчуру, але вона не дає міри поточної експозиції протоколу. Відповідний підрахунок — це кількість і вартість живих ринків, чиї розрахунки ризику досі беруть дані з потоку, який не може бути надійно оновлений, і цей підрахунок не можна вивести з логотипа клієнта.

Зазначена інтеграція — це не активний потік

Публічний вступ Switchboard описує потоки на вимогу: застосунки створюють або викликають потрібні їм дані, і ціна стає доступною через акаунти Solana. Документація може вказати, де протокол знає, як читати потік Switchboard. Вона може не вказувати, який варіант обирає конкретний ринок наразі. Набір для розробки програмного забезпечення може підтримувати тип оракула ще довго після того, як останній банк перейде на інший. І навпаки, вебсайт може змінитися, тоді як живий резерв зберігає свій старіший акаунт оракула.

Три рівні доказів потрібно тримати окремо. Перший — це маркетингова сторінка або сторінка інтеграції, яка показує, що зв'язок існував. Другий — це підтримувана конфігурація програми, видима в технічній документації або коді. Третій — це жива конфігурація та нещодавня історія оновлень фактичного ринку. Лише третій може підтвердити твердження, що названий ринок досі покладався на Switchboard у певний час. Навіть тоді може бути налаштоване резервне джерело, тому вплив зупиненого основного потоку потрібно перевіряти відповідно до відповідного резервного правила та правила свіжості.

Розгляньте документацію протоколу marginfi. Її таблиця оракулів зберігає SwitchboardPull та варіанти майданчиків серед доступних налаштувань. Вона каже, що викликач повинен прокрутити потік Switchboard pull безпосередньо перед використанням. Та сама таблиця перелічує потоки Pyth push та акаунти Scope як інші налаштування. Читач міг би помилково сприйняти збережений рядок Switchboard як доказ того, що кожен банк marginfi досі його використовує. Таблиця описує підтримувані типи, а не повний список того, який банк використовує який потік сьогодні.

Окрема примітка Marginfi щодо Program 0.1.11 є актуальнішою та конкретнішою. У ній розробникам було наказано оновити SDK щонайменше до версії 2.8.0 до 4 вересня, зазначаючи, що банки почнуть переходити на нові налаштування оракулів із цієї дати. У випуску було додано дев'ять варіантів, які не залежать від Switchboard, зокрема фіди Kamino Scope та ціноутворення на основі обмінного курсу для певних токенів ліквідного стейкінгу та основних токенів. У примітці не сказано, що кожен банк мігрував до 25 вересня. Вона показує, що проєкт публічно задокументував шлях від загрозливої залежності до оголошення про припинення підтримки.

Міграція несе несподіваний другий режим відмови. Marginfi зазначає, що старіші SDK не можуть декодувати банк, налаштований з одним із нових значень переліку оракулів. Один банк із непідтримуваним значенням може перешкодити Project0Client.initialize та читанню банків, а не лише дії, що стосується цього банку. Іншими словами, зміна оракула може виправити одну інфраструктурну залежність, водночас зламавши інтегратора, який не оновив своє програмне забезпечення. Документ Marginfi розповідає інтеграторам, як уникнути проблеми з SDK; це не є доказом того, що якийсь конкретний користувач постраждав від неї.

Project 0 описав уніфіковану маржу між майданчиками Solana, зокрема Kamino та Drift. Міжпротокольні інтерфейси створюють ще один рівень, на якому міграція оракула має бути прочитана правильно. Примітка про старіші версії SDK є конкретним доказом інтеграційної небезпеки, не доводячи збою в Project 0 чи будь-якому іншому названому застосунку. Відповідальний аудит перевірив би версії програмного забезпечення та поточні конфігурації активних кредитних банків, перш ніж заявляти про збій.

Tip Router від Jito досі документує Switchboard

Огляд Tip Router від Jito Foundation зазначає, що Switchboard визначає відносну вагу таких активів, як JitoSOL та JTO, що зберігаються в сховищах, пов'язаних із Tip Router. В огляді визначено ончейн-програму Tip Router, клієнт оператора вузла та дозвільно-вільний cranker. Його документація з ціноутворення називає Switchboard поточним фідом оракула та описує резервні ваги, коли фіди недоступні.

Документи відводять Switchboard конкретну роль: ціноутворення активів сховища для розрахунку ваг у системі розподілу чайових та рестейкінгу. Вони не стверджують, що недоступний фід Switchboard автоматично ліквідує кредитну позицію на Solana. Сторінка ціноутворення Jito описує механізм відкату, що послаблює спрощене твердження, ніби припинення підтримки обов'язково зупиняє всі операції Tip Router. Точні резервні значення, умови активації та поточні активні рахунки оракулів все ще потребують перевірки поточного стану програми.

Огляд Tip Router показував позначку останнього оновлення дев'ять місяців тому на момент перевірки 25 вересня. Цей вік змінює спосіб його використання. Він встановлює задокументований дизайн і визначає, де поставити технічне питання. Він не може встановити, що поточна програма має ту саму конфігурацію фідів. Jito могла оновити ончейн-рахунки, не переглядаючи сторінку, або все ще використовувати Switchboard із відкатом. Без нещодавньої перевірки транзакцій або поточної заяви від Jito названа жива залежність залишається непідтвердженою.

Публічні примітки до випусків Jito на GitHub для Tip Router згадують повторні спроби шлюзів оракула Switchboard в операціях кіпера. Кодова база, що містить таку логіку, так само демонструє технічну інтеграцію, а не обов'язково залежність кожного сховища на момент публікації. Код може зберігати шлях сумісності протягом місяців. Живе питання полягає в тому, чи нещодавні транзакції оновлення цін націлені на рахунок Switchboard, який використовується сховищем, що все ще несе вартість, і чи просувається цей рахунок після кінцевого терміну підтримки.

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

Scope від Kamino — це агрегатор, а не мітка постачальника

Публічний репозиторій Scope від Kamino Finance описує ончейн-агрегатор, який копіює значення з кількох оракул-акаунтів в один ціновий фід і перевіряє оновлення за заздалегідь визначеними правилами. У його README зазначено, що фід підтримує до 512 цін, а зв'язок між індексом і токен-парою не повністю зберігається ончейн. Нижчий за рівнем програма може вказувати на Scope, тоді як сам Scope покладається на інші фіди для вибраного активу. Таким чином, побачити Scope в конфігурації банку — це відправна точка для відстеження фактичного джерела даних, а не кінцева.

Вереснева нотатка marginfi перелічує Scope як опцію, яка не залежить від Switchboard для нової конфігурації, яку вона описує. Це не означає, що кожне розгортання Scope на кожну дату виключає кожне джерело Switchboard. Агрегатор може змінювати свої базові вхідні дані. Повна перевірка залежностей потребує як вибраного акаунта Scope у споживача, так і зіставлення джерел, яке використовується для заповнення його запису. Репозиторій Kamino надає архітектуру, а не інвентаризацію з часовими мітками поточних джерел у mainnet для кожного застосунку.

Kamino продовжує залучати інституції до своєї екосистеми кредитування. Galaxy відкрила два сховища стейблкоїнів на платформі у вересні. Існування нових сховищ показує, чому називати цілий протокол схильним до ризику без перевірки його окремих активів було б необґрунтовано. Сховище USDC, резерв ліквідного стейкінг-токена та токенізований ринок акцій можуть використовувати різні шляхи оракулів. Ми не перевіряли, чи використовують сховища Galaxy Switchboard, тому вони не включені до підрахунку постраждалих позицій.

Аналогічно, старіший список Kamino, Jito, marginfi та Drift у вступних матеріалах Switchboard не повідомляє нам розподіл схильності до ризику між ними. Проєкт може використовувати оракул лише для одного ринку, використовувати його як резервний або зберігати код після переходу на живі фіди. Єдина захищена одиниця аналізу — це конкретний ринок або сховище та його налаштований фід на визначений момент часу. Без цієї одиниці твердження про кошти під ризиком — це маркетингова арифметика, запущена у зворотному напрямку.

Застарілий фід має більше ніж один можливий ефект

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

Marginfi прямо зазначає, що pull-фіди Switchboard потрібно прокручувати перед використанням. Тому інтегратор повинен надати свіже оновлення як частину свого шляху транзакції. Push-фіди Pyth, навпаки, описуються як такі, що підтримуються свіжими через інфраструктуру Pyth. Scope використовує агреговане значення акаунта, вибране за налаштованим індексом запису. Перехід між цими типами змінює акаунти, потрібні для транзакції, та код, який їх перевіряє. Вересневе попередження SDK — це один видимий приклад того, як ці зміни доходять до прикладного програмного забезпечення.

Для Jito Tip Router публічна документація описує резервні ваги для недоступних фідів. Чи зберігають ці резерви точний розподіл винагород під час тривалого збою — це питання для живої конфігурації та операторів Jito, а не те, що вирішує речення в документації. Якщо фід продовжує оновлюватися через незалежних операторів вузлів після того, як компанія припиняє підтримку, резерв може не спрацювати негайно. Якщо оновлення припиняються, але резерв активний, операції можуть продовжуватися з іншим методом ціноутворення. Це умовні шляхи, а не прогноз поточного стану системи.

Не пов'язаний з цим інцидент з оракулом призвів до ліквідацій на Vesu раніше у вересні. Він ілюструє, що неправильне ціноутворення може мати економічні наслідки, але це не є доказом інциденту в Switchboard, Jito або marginfi. Повідомлення про вимкнення не слід перетворювати на твердження про ліквідацію за аналогією. Ознакою фактичної події були б застарілі часові мітки акаунтів, невдалі транзакції, пауза протоколу або ідентифіковані збитки, жодного з яких тут не показано для дедлайну 25 вересня.

Перехід Solana до слотів у 250 мілісекунд змінив темп, з яким виробляються блоки, але він не гарантував, що зовнішнє джерело цін оновлюється. Швидші слоти можуть донести нову ціну раніше, коли вона існує. Вони не можуть створити ціну, коли вузол, що її постачає, зупиняється. Тест протоколу на свіжість може вимірюватися слотом, часом або іншим правилом, тому зміна мережевого годинника може змінити те, як розробники інтерпретують старі конфігурації фідів.

Хто несе тягар міграції?

Оператор оракула публікує або координує дані, але протокол-споживач обирає акаунт, який читає його програма, та обмеження, які він накладає на цю ціну. Протокол кредитування може вимагати від управління або адміністратора змінити адреси оракула для своїх ринків. Його фронтенд і сторонні інтегратори потім мають сконструювати транзакції з правильними додатковими акаунтами. Користувачі можуть помітити лише відхилену позику або призупинений ринок, значно пізніше після того, як оператор і протокол ухвалили свої технічні рішення.

Оператор, який припиняє підтримку, не обов'язково має повноваження переписувати конфігурацію програми клієнта. Повідомлення Switchboard закликало користувачів мігрувати, оскільки власники інтеграцій повинні діяти. Проєкти слід оцінювати за адресами та оновленнями акаунтів, які вони контролюють. Якщо застосунок уже перейшов на Pyth до 19 вересня, пізніший дедлайн підтримки не має прямого впливу на цей ринок. Якщо він досі обирає стрічку Switchboard і не має робочого резервного варіанта, поведінка стрічки після 25 вересня є конкретною проблемою.

Найсильніше протилежне прочитання тривоги щодо відключення випливає з власної вересневої нотатки marginfi та задокументованого резервного варіанта Jito. Застосунки можуть проєктувати надлишковість або рухатися попереду виходу постачальника; код і документи показують механізми для цього. Модель на вимогу Switchboard може залишити частину інфраструктури стрічок працювати незалежно, навіть якщо основний контриб'ютор припинив підтримку. Повідомлення не опублікувало перевіреного графіка, за яким кожен акаунт зупинився б, і ми не знайшли первинних доказів, що встановлюють таке універсальне відсікання.

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

Згортання постачальника може мати відкладені наслідки. Код, написаний для запиту цін на вимогу, може успішно працювати, поки відповідає незалежний шлюз, а потім зазнати невдачі, коли цей шлюз буде виведено з експлуатації або його оператори припинять оновлювати конкретний актив. Спостерігачеві потрібно кілька часових позначок після дедлайну, а не одна успішна транзакція, щоб зробити висновок про продовження обслуговування. Та сама дисципліна застосовується до невдалої транзакції: помилка одного користувача може виникнути через застарілий SDK або недостатній ввід акаунта, а не через недоступний оракул. Документ про міграцію marginfi надає явний приклад збою декодування програмного забезпечення, який інакше міг би бути помилково позначений як збій оракула.

Існує межа цьому заспокоєнню. Резервний варіант, описаний дев'ять місяців раніше, потребує перевірки на відповідність поточному стану, а варіант міграції, описаний у вересні, не є доказом того, що кожен банк його обрав. Два документи надають достовірні причини не припускати катастрофу, залишаючи вимірюваний розрив. Справедливий висновок вужчий за обидві версії — рекламну та панікерську: публічні документи визначають кандидатні залежності та шляхи відходу; потрібен поточний аудит конфігурації за кожним ринком, щоб встановити будь-яку залишкову експозицію.

Живий інвентар все ще залишається відсутнім документом

Оригінальний звіт тут порівнює список Switchboard із чотирьох відомих інтеграторів із поточними первинними документами від Jito, marginfi та Kamino. Це дає два підтверджені документальні висновки. Старіша документація Jito Tip Router називає Switchboard для ціноутворення сховища та резервний варіант для недоступних потоків даних. Примітка marginfi за вересень 0.1.11 описує дев'ять нових налаштувань, незалежних від Switchboard, і попереджає про окрему поломку SDK, якщо інтегратори не оновляться. Репозиторій Kamino Scope пояснює, чому сама лише мітка агрегатора не може ідентифікувати кожне джерело даних вищого рівня.

Робота не дає підрахунку живих не мігрованих потоків даних, схильних до ризику коштів користувачів або збою в будь-якому названому протоколі. Доступні публічні сторінки не містять синхронізованого знімка станом на 25 вересня всіх оракул-акаунтів, останніх успішних оновлень, налаштувань резервування та сум, підтримуваних кожним ринком. Заявляти конкретну суму в доларах із TVL протоколу було б необґрунтовано, оскільки активи всього протоколу не обов'язково використовують той самий оракул. Точне питання заголовка залишається відкритим на рівні живих акаунтів.

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

Цей метод пояснює, чому навіть правдиве твердження, як-от протокол підтримував 550 потоків даних у минулому, є недостатнім для поточного питання. Потік даних може існувати без активного позичальника, може мати оновлення ціни без споживчого ринку або може згадуватися лише в неактивному коді. Підрахунок акаунтів потоків даних вимірює інфраструктуру. Підрахунок налаштованих ринків вимірює залежність. Підрахунок позицій і застави, які фактично торкаються цих ринків, вимірює економічну експозицію. Жоден із них не є взаємозамінним із загальними активами, депонованими в усіх продуктах, якими керує проєкт.

Існує додатковий крок перевірки, коли джерелом є агрегатор. Споживач може ідентифікувати акаунт Scope та індекс запису, тоді як відображення Scope вказує далі на одного або кількох постачальників. Оновлення в акаунті Scope після 25 вересня доводить, що агрегатор створив значення, але це саме по собі не доводить, що Switchboard продовжував постачати базову ціну. Досліднику потрібен вибраний запис і конфігурація джерела для цього оновлення. Репозиторій Kamino зазначає, що мітки токен-пар не повністю зберігаються ончейн, тому може знадобитися зовнішня конфігурація або документація супроводжувача, щоб зіставити індекс із його активом. Якщо це зіставлення недоступне, результат слід записати як невідомий, а не мовчки приписувати Pyth або Switchboard.

За чим стежити

• Адреси оракулів ринку: Порівняйте налаштований потік даних кожного активного банку або сховища з задокументованими акаунтами Switchboard.
• Часові мітки оновлення цін: Перевірте, чи ідентифікований потік даних продовжує публікувати свіжі значення після 25 вересня.
• Конфігурація резервування: Шукайте джерело та ліміт свіжості, які використовуються, якщо основний потік даних відстає.
• Недавні транзакції програми: Перевірте, чи все ще завершуються позичання, розрахунок або розподіл чайових для відповідного ринку.
• Датовані оновлення супроводжувача: Шукайте названу міграцію, паузу ринку або залишкову залежність, підтверджену акаунтом або адресою програми.

Записуйте час спостереження для кожної перевірки; скріншот без блоку або часової мітки може швидко застаріти.

Примітка про оновлення marginfi зазначає, що банк, який використовує нове значення переліку оракулів, може змусити старіший SDK не ініціалізувати свій клієнт, навіть якщо користувач не взаємодіє з цим конкретним банком. Інструкція використовувати SDK версії 2.8.0 або новішої була опублікована до початку міграції 4 вересня, за три тижні до кінцевого терміну підтримки Switchboard.

FAQ