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: какие вызовы читаем, что агрегируем, что исключаем;
- конфигурация индексатора и адаптера, развёрнутая отдельно от вашего продуктивного контура;
- регламент сопровождения: как проверяются расхождения после релиза и апгрейдов.
Опишите задачу в двух-трёх абзацах и приложите то, что уже собрано, — вернёмся с оценкой, планом работ и составом этапов.
