Налаштування Nansen: чому звіти розходяться з мережею
Мітка адреси — це твердження про власника, а не факт з мережі. Коли налаштування Nansen робиться «на око» — за назвою біржі з листування, за першою великою транзакцією контрагента — у систему потрапляють чужі депозитні гаманці та внутрішні каси проєкту.
Після цього аналітика гаманців вважає їх зовнішніми потоками, і картина руху коштів перестає збігатися з тим, що видно в мережі.
Друге джерело розходження звітів із мережею — групи адрес. Якщо зібрати їх за ознакою «схожі суми та час», в одну сутність потрапляють різні власники: казначейство, маркетмейкер, службові адреси команди.
Внутрішній переказ між своїми гаманцями починає враховуватися як приплив ззовні: оборот зростає вдвічі, частка зовнішніх надходжень спотворюється, а рішення щодо стейкінгу та звітності ухвалюються за неправильними числами.
Лікується це не заміною сервісу, а порядком у мітках адрес. У кожної мітки має бути джерело — сторінка біржі, офіційний документ, підтверджена транзакція, — а в кожної групи правило включення та виключення адрес.
Верифікація транзакцій іде за першоджерелом: сума, контрагент, призначення та комісія звіряються з журналом мережі, а агрегат у звіті — порядково з цими записами.
Поки такої звірки немає, звіт виглядає переконливо та розходиться з мережею на десятки відсотків. Розбираємо, як це закривається.
Що дає вивірена аналітика потоків і гаманців
Аналітика починається не з підключення сервісу, а з розмітки адрес: казначейство, контракти, вестинг, пули ліквідності, гаманці команди. Поки ці адреси не позначені, відстеження транзакцій тоне в шумі — вхідні перекази змішуються з транзитними.
Nansen дає готову базу розмічених адрес, але проєктні сутності описуються вручну, під конкретну схему розподілу токенів.
Далі — профілювання гаманців. Адреси групуються за поведінкою: хто тримає позицію місяцями, хто заходить перед оголошенням і виходить на зростанні, хто пов'язаний спільним джерелом коштів.
Список адрес перетворюється на карту учасників, і поява в ній нового великого власника стає подією, а не рядком у вивантаженні.
Третій шар — правила оповіщень: поріг на відтік із пулу, різка зміна частки однієї адреси, переказ із гаманця команди, сплеск активності навколо контракту. Кожна умова задається з вікном і кратністю, інакше сигнал спрацьовує на нормальному обсязі операцій.
Раннє оповіщення про ризики працює рівно настільки, наскільки точно виставлені пороги: вузькі дають хибні спрацювання, широкі пропускають виведення коштів.
Моніторинг ліквідності та звітність для керівництва збираються з тих самих даних. Вивантаження метрик — обсяг у пулах, розподіл власників, активність великих адрес — іде за розкладом у таблицю або панель, де періоди зіставні між собою.
Режими роботи: разовий аудит, постійний доступ, закритий контур
Три режими відрізняються не набором метрик, а моделлю доступу та маршрутом, яким дані потрапляють у внутрішні системи.
Один і той самий набір міток за адресами можна зняти разово, поставити на постійне спостереження або розгорнути всередині свого контуру — і обмеження в цих варіантів принципово різні. Аналітику за блокчейнами ми збираємо в Nansen і зіставляємо її з даними самого проєкту.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Разовий аудит гаманців | Перевірка контрагента, розбір інциденту, вихід на новий ринок | Зріз на дату: історію зв'язків заднім числом не відновити, оповіщень немає |
| Постійний доступ до аналітики | Моніторинг потоку коштів, спостереження за адресами проєкту та великими власниками | Потрібен регламент розбору спрацювань і власне сховище історії |
| Закритий контур даних | Вимоги до ізоляції, змішування зовнішніх міток із внутрішньою звітністю, розмежування доступів | Окрема інфраструктура, супровід і оновлення міток на нашій стороні |
Вивантаження даних у звітність і спільний доступ команд налаштовуються в будь-якому з трьох режимів — різниться регулярність.
Разовий аудит віддає статичний зріз, постійний доступ формує потік, який складається у вітрину, а закритий контур дозволяє пов'язати зовнішні мітки з власними транзакційними даними та не випускати їх назовні.
Обирати варто за горизонтом задачі. Моніторинг без регламенту розбору спрацювань перетворюється на потік повідомлень, який ніхто не читає, — тому режим постійного доступу має сенс лише разом із правилами ескалації. Розберіться, як це закривається під ваш сценарій — опишіть задачу, повернемося з оцінкою та планом.
Налаштування Nansen: етапи роботи від аудиту до передачі
Спостереження за блокчейн-активністю починається не з відкриття панелі, а з інвентаризації того, за чим потрібно стежити.
Розбираємо задачу з командою замовника, фіксуємо список адрес і критерії значущої події — інакше спостереження перетворюється на потік повідомлень, який швидко перестають читати.
Далі порядок впровадження однаковий для будь-якого проєкту — налаштовуємо його в Nansen, де мітки та правила прив'язані до адрес і оновлюються разом із ними.
- Розбір задачі та інвентаризація адрес. Збираємо контракти, казначейські, операційні та біржові гаманці, уточнюємо, які потоки важливі: приплив і відтік, рух великих власників, взаємодії з протоколами.
- Схема міток. Заводимо єдиний словник «адреса — власник — роль — тип», щоб той самий гаманець читався однаково в усіх звітах і його не доводилося розшифровувати заново.
- Налаштування спостереження. Ставимо алерти на рухи вище порогу, зміну структури власників і сплески активності. Пороги рахуємо від історичної волатильності адреси, а не «на око».
- Перевірка на історичних даних. Проганяємо правила за минулими періодами: рахуємо частку хибних спрацювань і події, які система пропустила. Пороги правимо до передачі, а не після першого інциденту.
- Розмежування доступу. Ролі видаємо за принципом мінімальної необхідності: повний доступ, лише перегляд, лише повідомлення. Дії в панелі логуються, доступ відкликається при зміні складу команди.
- Регламент спостереження. Фіксуємо, хто і як реагує на спрацювання: канал повідомлень, вікно реакції, порядок ескалації та періодичність звірки міток.
- Передача. Віддаємо документацію, схеми міток і навчання команди, залишаємося на зв'язку, поки регламент не запрацює самостійно.
На виході спостереження відтворюване: зміна аналітика не скидає налаштування, а реакція на рух коштів вимірюється хвилинами, а не днями.
Політики доступу, мітки адрес і документація
Після налаштування Nansen у замовника залишається не набір разових звітів, а робоча система: розмічені простори під різні команди, довідник міток адрес і правила, за якими до них допускають людей. Нижче — перелік того, що передаємо разом із конфігурацією та володінням на вашій стороні.
- Робочі простори під задачі: окремі простори для казначейства, продукту та контролю ризиків — потоки даних не змішуються, доступ видається за принципом мінімальної необхідності.
- Довідник міток адрес: біржі, кастодіани, власні гаманці, контракти та казначейські адреси — з власником мітки та датою останньої перевірки; нові адреси вносяться за єдиним шаблоном.
- Ролі користувачів і матриця прав: аналітик, спостерігач, режим лише читання — з розмежуванням на зміну міток, вивантаження даних і керування оповіщеннями.
- Політики доступу: порядок видачі та відкликання прав при виході співробітника, вхід через єдиний вхід і двофакторну автентифікацію, журнал дій для розбору інцидентів.
- Регламент реагування: пороги спрацювання, відповідальний черговий, порядок ескалації та строки реакції на аномальне виведення коштів.
- Інструкції для команди: короткі пам'ятки — як внести адресу в довідник, зібрати звіт, оновити оповіщення після зміни контракту.
- Передача налаштувань: схеми просторів, шаблони міток і протоколи розбору залишаються у вашому репозиторії — система працює без нашої участі.
Кейс: мітки адрес виявили виведення коштів за добу
Як було
Проєкт випустив токен і тримав казначейство на кількох адресах, але стежив за ними вручну: аналітик раз на день звіряв вивантаження переказів.
Велике виведення в стейблкоїнах помітили лише наступного дня — частина коштів уже пройшла через проміжні гаманці та обмінні сервіси, і повернути їх було нічим.
Що налаштували
Ми розмітили адреси проєкту — казначейство, гаманці команди, контракти, адреси бірж — і закріпили правила оповіщення в Nansen. Сторожові умови спрацьовують на нетиповий потік: переказ вище звичайного для адреси, новий контрагент, ланцюжок проміжних гаманців за коротке вікно.
Що змінилося
| Метрика | До | Після |
|---|---|---|
| Час виявлення аномалії | близько доби | 15-20 хвилин |
| Частка транзакцій із зрозумілим контрагентом | менше половини | 96% |
| Хибні спрацювання | десятки на тиждень | 2-3 на місяць |
Правила дали про себе знати через одинадцять днів: сторож спрацював на виведення, яке перевищувало звичайний оборот адреси в кілька разів.
Розбір інциденту зайняв сорок хвилин замість доби пошуку — ланцюжок промаркували, мітку отримувача доклали до звернення в біржовий сервіс, частину переказу встигли зупинити.
Хибні спрацювання прибрали порогами під профіль конкретних адрес: оповіщення приходить тоді, коли є що розбирати.
Чим відрізняється разове вивантаження від постійного спостереження?
Разове вивантаження — знімок даних на конкретний момент: баланси, розподіл власників, рух коштів за період. Режим виправданий, коли рішення ухвалюється один раз: оцінка проєкту перед входом, перевірка контрагента, підготовка звіту. Таблиця після вивантаження статична — вона описує стан, а не поведінку.
Обмеження знімка в тому, що між двома вивантаженнями не видно нічого. Виведення великої суми, зміна власника контракту, сплеск активності спливають лише в наступному вивантаженні — із затримкою в дні. Якщо ціна помилки зростає з часом реакції, знімка недостатньо.
Безперервне спостереження — набір умов, за якими Nansen опитує мережу за розкладом і надсилає оповіщення при відхиленні: поріг за обсягом, нова адреса у списку, зміна частки власників.
Режим моніторингу витрачає ліміти запитів і потребує калібрування порогів: широкі дають шум, вузькі пропускають події.
На практиці підходи поєднують. Разове вивантаження задає базову лінію та список адрес під спостереження, далі працює безперервний режим з оповіщеннями на відхилення, а контрольний знімок раз на тиждень звіряє картину та оновлює лінію. Проєкт бачить і поточний стан, і динаміку, а потік оповіщень залишається читабельним.
Вибір підходу визначається горизонтом рішення: відповідь потрібна один раз — досить знімка, реагувати потрібно в моменті — вмикаємо режим спостереження. Частоту опитування добираємо під ліміти, щоб зростання кількості адрес не вперлося в обмеження.
Технічні сумніви, які знімаємо до старту
Частина питань повторюється майже в кожній оцінці — відповідаємо на них до старту, щоб не з'ясовувати деталі вже на етапі складання правил.
У нас уже розгорнута аналітика — чи не отримаємо ми другий контур заради другого контуру?
Спочатку робимо інвентаризацію: які мережі та адреси вже покриті, які звіти хто читає, де дані розходяться. Новий шар підключаємо лише там, де він закриває те, чого в поточному контурі немає, — наприклад, рух коштів між мережами та зв'язки адрес. Решта залишається як є, дублювання прибираємо, а не нарощуємо.
Чи можна обмежити видимість адрес усередині команди?
Так, і це налаштовується на старті. Робочі простори розділяємо за напрямами, доступ до адрес і міток видаємо за списком, а чутливі гаманці виносимо в окремий закритий контур, куди дивиться лише вузьке коло. Права відкликаються централізовано — людина пішла, доступ закрився разом із нею.
Наскільки повні мітки і чи можна їм довіряти?
Повних міток не буває: великі сервіси, біржі та відомі контракти розмічені, а нові адреси з'являються швидше, ніж їх встигають описати. Тому ми ведемо власні словники адрес і правила розмітки, а в кожної мітки зберігаємо джерело та дату — видно, де факт, а де припущення. Це знімає головну проблему: рішення ухвалюються на даних із зрозумілим ступенем достовірності.
Як швидко приходять оповіщення?
Швидкість задається частотою звернення до мережі та способом доставки. Для критичних адрес ставимо частий опитування та доставку в кілька каналів, для решти — рідше, щоб не випалювати ліміти та не топити команду в шумі.
Сигнал за значущою операцією приходить у межах хвилин, а не годин; пріоритети та правила придушення дублів налаштовуємо окремо.
Що буде з налаштуваннями, якщо ми вирішимо вести контур самі?
Конфігурація не залишається всередині чужого кабінету. Правила оповіщень, словники міток і шаблони повідомлень вивантажуються файлами та зберігаються в системі контролю версій — їх можна перенести й відтворити на вашій стороні.
Доступи власника залишаються у вас, передача налаштувань Nansen — частина робіт, а не окрема домовленість.
Обговоримо задачу та повернемося з оцінкою і планом
Щоб повернутися з планом, а не із загальними словами, нам потрібен мінімум ввідних. Зберіть їх в одному повідомленні — цього вистачить, щоб розібрати задачу та оцінити обсяг робіт з аналітики без уточнювальних листів на тиждень.
- Постановка задачі: які рішення ухвалюються на даних — перевірка контрагентів, спостереження за гаманцями команди, контроль руху коштів за портфелем.
- Мережі та активи в пріоритеті: де живе основна ліквідність проєкту, які мережі покриваємо першими, а які можна відкласти.
- Джерела адрес: списки гаманців, реєстри контрагентів, готові мітки — у якому вигляді вони у вас є та хто відповідає за їхню актуальність.
- Користувачі та формат виводу: хто дивиться дані та як — вебпанель, регулярні вивантаження у вашу звітність, оповіщення в корпоративний месенджер.
- Обмеження: рівень доступу та ліміти запитів, вимоги служби безпеки до ключів і зберігання вивантажень.
- Ознака готовності: який звіт або сигнал ви вважаєте доказом, що задачу вирішено.
Із цього збирається план робіт: склад робіт за блоками — доступи, джерела, правила аналізу, вивід даних, — оцінка строків за кожним блоком і порядок старту проєкту. Окремо фіксуємо, що залишається у вас після здачі: конфігурації, схеми, інструкції для команди.
Опишіть задачу — повернемося з планом і переліком результатів, які ви отримаєте на виході.
