DefiLlama листинг: чому TVL проєкту рахують неправильно
Публічні агрегатори рахують заблоковану вартість не за вашим обліком, а за подіями в мережі: адаптер обходить адреси контрактів, розбирає виклики й сумує баланси пулів.
Якщо адаптер не знає частину пулів, не розуміє похідні інструменти або складає їх за номіналом разом з базовим активом, цифра розходиться з фактичним станом контрактів. Ззовні це виглядає як неправильний TVL, хоча контракти працюють штатно.
Типові причини розходження метрик — неверифікований код, відсутність публічного опису інтерфейсу й адрес у репозиторії, мультичейн-конфігурація, де частина ліквідності живе в іншій мережі й у суму не потрапляє.
Окрема історія — подвійний облік: LP-токени й стейкінг-розписки враховуються і як самостійний актив, і як застава, через що показник роздувається, а після правки адаптера різко падає.
Ціна такої помилки — не косметика. Проєкт не проходить верифікацію протоколу, випадає з порівнянь і рейтингів, а інтегратори та аналітики будують рішення за викривленою картиною. Падіння TVL на графіку читається як відтік коштів, навіть коли ліквідність на місці.
Далі розбираємо, як влаштований листинг DefiLlama: що агрегатору потрібно від контрактів, як проходить верифікація і якими звірками закривають розходження метрик.
Що дає налаштування аналітики: звірюваний TVL і потоки
Коректний TVL — це не одне число з кабінету, а відтворюваний розрахунок.
До нього входять вартість заблокованих активів по всіх мережах, єдине джерело цін на момент знімка, облік десяткових знаків і виключення подвійного обліку — коли ті самі кошти потрапляють і в пул, і в похідний інструмент на його основі.
Ми описуємо формулу й фіксуємо її в конфігурації адаптера: DefiLlama рахує метрики протоколу вже за нею, а не за своєю внутрішньою евристикою.
Далі — індексація. Субграф збирає події контрактів, розрахунок перезбирається за розкладом, вивантаження в Dune наздоганяють той самий знімок даних.
Ручні таблиці відходять: значення оновлюється само, а не наприкінці місяця силами аналітика, і однаково виглядає у нас у кабінеті, в Dune і на агрегаторах.
Потоки капіталу видно як окрему метрику: добовий приплив і відтік, нетто за пулами й мережами, розбивка за когортами адрес. За нею відрізняють органічне зростання від разових заливок під програму винагород — і заздалегідь бачать відтік, поки він не перетворився на обвал.
Звірка даних закриває останнє: якщо розходження між джерелами перевищує поріг, спрацьовує перевірка й видно, де загубився облік. Клас помилок ручного зведення — задвоєні пули, застарілі ціни, пропущені події — просто перестає виникати.
Способи подачі даних: субграф, панель, ручний звіт
Спосіб подачі даних обирають за споживачем метрики й частотою оновлення: від цього залежать і точність, і обсяг супроводу. Нижче — три робочі варіанти з їхніми межами.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Субграф | Потрібна програмна видача: своя логіка агрегації, запити з інтерфейсу, бота, розрахункового скрипта | Індекс відстає від ланцюга, після реорганізації потребує переперевірки; схему й мапінги супроводжують за кожної зміни контрактів |
| Публічна панель | Потрібне зовнішнє охоплення й швидкий старт: агрегати за протоколом без своєї інфраструктури | Методика розрахунку задана платформою, нестандартні метрики виражаються погано, глибина історії обмежена джерелом |
| Ручна звітність | Метрика унікальна або рахується разово за закритими даними | Відтворюваність падає, оновлення залежить від людини, методику доводиться фіксувати регламентом |
На практиці методи комбінують: субграф закриває регулярні метрики, панель працює як зовнішня вітрина, ручний звіт — для рідкісних зрізів.
Для листингу на DefiLlama потрібне перевірюване джерело з відкритою методикою — частіше це субграф, що віддає обсяг заблокованих коштів за адресами протоколу.
Етапи роботи: від аудиту контрактів до передачі схем
Публічний дашборд — це вітрина, за якою стоїть вивірена схема обліку. Помилка в розмітці подій дає гарне число, яке розсипається за першої ж зовнішньої перевірки. Тому йдемо послідовно: від розбору контрактів до документації, за якою команда супроводжує аналітику без нас.
- Аудит даних. Розбираємо контракти, пули й події, фіксуємо, які величини витягуються з ланцюга напряму, а які рахуються похідними від кількох джерел.
- Схема обліку. Описуємо сутності, поля й зв'язки: як рахуємо TVL, де виключаємо подвійний облік, за якими ключами агрегуємо адреси й токени.
- Налаштування збору. Піднімаємо індексацію подій і перерахунок за розкладом, окремо закладаємо пропуски блоків і відкати стану.
- Перевірка метрик. Звіряємо розрахунок на історичних даних і з незалежними джерелами; розходження пояснюємо до нуля, а не списуємо на затримку індексації.
- Публікація. Оформлюємо листинг у DefiLlama і сторінки дашборда так, щоб методика розрахунку була видна користувачеві.
- Регламент оновлення. Фіксуємо періодичність перерахунку, пороги оповіщень і порядок дій при розсинхроні даних.
- Передача документації. Віддаємо схеми, доступи, запити та інструкції — супровід не зав'язаний на нас.
Що ви отримуєте на руки: схеми, правила, регламенти
Аналітика закінчується не гарною панеллю, а набором артефактів, за якими команда працює далі без нас. Усе передаємо в репозиторій проєкту: у кожного документа є власник, версія й прив'язка до конкретного джерела даних.
- Схема джерел і сутностей — які контракти, пули й токени потрапляють у розрахунок, як пов'язані між собою й звідки береться кожне число.
- Конфігурації збору — параметри індексації, списки адрес, фільтри подій; конфіги лежать у репозиторії й розгортаються однією командою.
- Правила розмежування доступу — хто бачить сирі дані, хто змінює конфігурації, хто підтверджує публікацію метрик назовні.
- Опис метрик — формула кожного показника, включно з TVL: що рахуємо (заблоковані активи, стейкінг, позикові позиції) і як враховуємо ціни.
- Інструкція для команди — як підключити новий пул або мережу, де дивитися логи перезбирання, що робити при розходженні із зовнішньою панеллю.
- Регламент оновлення — періодичність перезбирання, вікно перевірки, порядок відкату до попереднього зрізу при збої.
- Чек-ліст публікації — набір перевірок перед відправленням даних на DefiLlama: свіжість, повнота, збіг із даними з мережі.
Через місяць після здачі команда закриває типові задачі сама: додати мережу, перерахувати метрику, розширити доступ — без звернення до нас.
Кейс: як привели метрики проєкту до єдиного значення
Що було до
Проєкт показував три різні значення заблокованих коштів: внутрішня панель рахувала за своїми знімками, запити в Dune — за власними вибірками, а в листингу DefiLlama цифра відставала на добу.
Аналітик зводив розходження вручну раз на тиждень, частина операцій не потрапляла у вибірку взагалі — великі депозити й виводи через мультисиг губилися на проміжному кроці. Динаміка TVL виглядала рваною, і за нею не можна було відрізнити реальний відтік від затримки індексації.
Що змінили
Субграф став єдиним джерелом: події контрактів індексуються з прив'язкою до номера блоку, а перерахунок балансів іде за однією формулою для панелі, Dune і зовнішнього листингу.
Додали звірку сум на кожному оновленні й окрему перевірку операцій, які раніше пропускалися — транзитні перекази й перекази з кількома токенами в одній транзакції. Впровадження зайняло шість тижнів з моменту доступу до контрактів.
Результат проєкту
Розходження між внутрішніми панелями й листингом зникло: значення збігаються до останнього знака, оновлення автоматичне. Динаміка TVL уперше дала картину, за якою видно причину відтоку — не «цифра впала», а який пул і в який період вивів кошти.
Ручна звірка зникла із задач аналітика: час, який витрачався на зведення звітів, пішов на розбір метрик.
Чи потрібен DefiLlama листинг, якщо у проєкту своя панель?
Своя панель відповідає на внутрішні питання: де просів обсяг, який пул тягне ліквідність, що з емісією та заставою. Зовнішнього зіставлення вона не дає — цифри із закритого дашборда нема з чим звірити, і в галузевих оглядах проєкт просто не з'являється.
Листинг на DefiLlama — це незалежна точка звірки, а не другий дашборд. Платформа рахує TVL за єдиною методологією, розбиває його за мережами й пулами, зберігає історію зрізів стану, яку не можна переписати заднім числом.
Аналітики, інтегратори й агрегатори беруть цифри звідти — для них ваша панель джерело без підтвердження.
Розходження зазвичай не на користь проєкту: своя панель нерідко враховує застейкані позиції та LP-токени двічі або не бачить частину контрактів. Публічна метрика тоді читається як спростування ваших же звітів, хоча помилка — в методиці обліку.
Тому адаптер і субграф описують контракти явно: який виклик читаємо, як рахуємо частку пулу, що робимо при оновленні контракту.
Не все потрібно виводити назовні. Утримання, воронка, розподіл позицій публічного сенсу не мають. Пріоритети впровадження такі: спочатку коректний облік TVL та історія, потім дашборди в Dune під конкретні питання, і тільки потім публічні метрики навколо них.
Якщо сумніваєтеся, чи потрібен листинг при живій панелі, — опишіть задачу: подивимося, де ваша методика розходиться з публічною, і повернемося з оцінкою та планом.
Часті технічні питання щодо обліку метрик
Метрики на блокчейн-даних майже завжди розходяться між майданчиками: різний момент знімка, різне трактування активів, різний список адрес у вибірці. Нижче — часті питання, які ставлять на прийманні контуру аналітики, і відповіді по суті.
Чому наш TVL не збігається з даними DefiLlama?
Зазвичай справа в методиці: момент знімка, трактування заблокованих і застейканих активів, перелік контрактів. Ми фіксуємо методику документом і сходимося за кожним розходженням.
У нас уже розгорнутий свій контур — він сумісний?
Підключаємося до наявного сховища та індексатора, не ламаючи їх: уже зібрані дані перевикористовуємо, дописуємо відсутні метрики та звірку.
Що робити після оновлення контрактів?
Перезбирання даних — штатна операція: змінюється адреса або сигнатура події, індексація порушеного діапазону блоків іде заново. Історію зберігаємо, значення до й після оновлення порівнянні.
Чи можна рахувати метрики за закритими даними?
Так: контур розгортається у вашому периметрі, назовні йдуть тільки ті агрегати, які ви самі вирішите показувати.
Що входить у підтримку після здачі?
Стежимо за працездатністю індексації, оновлюємо методики при змінах протоколу, додаємо нові метрики. Перезбирання й розбір розходжень — частина регулярної роботи.
Обговоримо задачу: звіримо метрики й запропонуємо план робіт
Щоб оцінка була предметною, а не «за відчуттями», на вході потрібні вихідні дані: адреси контрактів і мережа, опис того, як зараз рахується вартість заблокованих коштів, і посилання на наявні дашборди або субграф, якщо вони вже є.
Цього достатньо, щоб зрозуміти обсяг індексації й заздалегідь побачити, де цифри у вашій звітності розходяться з тим, що читається з блокчейну.
На розборі уточнюємо те, що не можна вичитати з коду: які активи включати в TVL, як обходити подвійний облік LP-позицій, чи потрібна розбивка за мережами й пулами, як враховувати стейкінг і заблоковані токени.
Окремо проговорюємо вимоги до публікації в DeFiLlama і те, хто відповідає за підтримувальні правки після листингу — адаптер доведеться оновлювати при апгрейді контрактів.
За підсумками розбору повертаємося з конкретикою:
- оцінка — склад робіт і трудовитрати, розкладені за етапами;
- план робіт — від аудиту контрактів і моделі обліку до подання заявки та верифікації метрик;
- строки з контрольними точками й списком залежностей від вашої сторони;
- перелік доступів і даних, без яких старт неможливий;
- схема розрахунку TVL: які виклики читаємо, що агрегуємо, що виключаємо;
- конфігурація індексатора й адаптера, розгорнута окремо від вашого продуктивного контуру;
- регламент супроводу: як перевіряються розходження після релізу й апгрейдів.
Опишіть задачу в двох-трьох абзацах і додайте те, що вже зібрано, — повернемося з оцінкою, планом робіт і складом етапів.
