Чому розрахунок NAV криптофонду ламається на масштабі
Розрахунок NAV криптофонду ламається не на формулі, а на узгодженості даних. Поки портфель уміщується в таблицю, розрахунок вартості активів сходиться вручну.
На масштабі в гру вступають десятки бірж, позабіржові угоди, стейкінг і заблоковані залишки — і кожна позиція тягне свою котирування зі свого джерела.
Перший збій — розсинхрон котирувань. Біржовий стакан, індекс провайдера і ціна останньої угоди дають три різні числа на один і той самий момент часу.
Якщо розрахунок бере ціну з різних джерел для різних позицій, підсумок перестає бути відтворюваним: два прогони на одних даних дають різний NAV, і аудит такий результат не приймає.
Другий — ручні звірки. Позиції, яких немає в API біржі (позабіржові угоди, позики, нарахування за стейкінгом), заводяться вручну і живуть в окремій таблиці.
Чим більше таких рядків, тим вища ймовірність, що розрахунок і облік розійдуться, а розбіжність спливе вже у звітності перед інвесторами.
Третій — затримка публікації. Поки дані збираються по частинах і звіряються очима, NAV фіксується із лагом. Фонд не може показати вартість на закриття торгів, а інвестор бачить застарілу цифру.
Усі три збої — про одне: розрахунок має спиратися на єдиний зріз даних із зафіксованим часом. Розбираємо, як це закривається.
Що дає автоматизований розрахунок NAV
Автоматизація розрахунку NAV прибирає ручне перенесення позицій між біржовими вивантаженнями, кастодіальними звітами та таблицею.
Дані щодо токенів, стейкінгу, невиведених винагород і позабіржових угод підтягуються за розкладом, звіряються з ончейн-станом гаманців і потрапляють до єдиного реєстру.
Інженер налаштовує правила мапінгу один раз — далі система сама приводить активи до єдиної структури та позначає розбіжності до того, як вони дійдуть до підсумкової цифри.
Закриття періоду перестає бути рутиною на кілька днів. Коли котирування, курси та правила оцінки зашиті в розрахунковий контур, NAV рахується за розкладом, а не за запитом — звітність щодо фонду формується того самого дня, коли закрився період.
Помилки ручного введення зникають як клас: немає копіювання між таблицями — немає одруків у кількості токенів, переплутаних десяткових розрядів і задвоєних рядків.
Точність NAV тримається на відтворюваності. Кожен розрахунок зберігає знімок вхідних даних і версію методики оцінки, тому будь-яку цифру можна перерахувати й пояснити — що важливо і для інвесторів, і для аудиту.
Якщо методика змінюється, перерахунок іде за історичними знімками, а не переписує минулі звіти. Швидкість звітності зростає не за рахунок спрощення моделі, а за рахунок того, що важка частина — збір і звірка даних — виконується автоматично.
Окремий ефект — контроль на вході. Система перевіряє повноту вивантажень, збіжність балансів і аномалії в рухах за гаманцями до розрахунку, тому проблема випливає на етапі даних, а не в готовому звіті перед інвестором. Це знімає основну причину перерахунків NAV заднім числом.
Підходи до розрахунку: від ручних таблиць до розподіленого реєстру
Розрахунок NAV криптофонду майже ніколи не починається з блокчейну. Спочатку це таблиця, яку веде операційний аналітик: ціни підтягуються вручну з бірж, частки партнерів рахуються формулами, а звірка з кастодіаном іде поштою.
Такий контур працює, поки активів десятки і угод одиниці на день — далі розходження в 0,1% на округленні перетворюється на спір про те, чий це збиток.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ручний розрахунок | 1-2 фонди, до 10 інструментів, угоди раз на тиждень | Немає відтворюваності: результат залежить від того, хто рахував. Помилку знаходять через місяць, аудит неможливий |
| Напівавтоматичний | Портфель до сотні позицій, щоденний NAV | Ціни та курси все ще вводяться вручну, історія правок живе в листуванні. Звірка займає години |
| Автоматизований з розподіленим реєстром | Багато рахунків, стейкінг, позабіржові угоди, кілька юрисдикцій | Потребує описаних правил оцінки та доступу до джерел цін; окупається лише на потоці операцій |
Різниця між підходами не в швидкості рахунку, а в доказовості. Ручний і напівавтоматичний контур відповідають на питання «скільки коштує портфель зараз», але не на питання «чому цифра змінилася і хто її підтвердив».
Розподілений реєстр закриває другу частину: кожна переоцінка, нарахування та рух між рахунками фіксуються як подія з підписом, і NAV збирається з цих подій, а не з підсумкової комірки.
Обмеження є у всіх трьох варіантів, і чесніше назвати їх до старту.
Ручний не масштабується за людьми, напівавтоматичний упирається в якість джерел цін, а автоматизований потребує дисципліни в правилах оцінки — якщо методика не описана формально, реєстр просто зафіксує помилку швидше.
Тому перехід між контурами роблять поетапно: спочатку фіксують правила, потім переносять розрахунок, і лише згодом прибирають ручні операції.
Як ми вибудовуємо процес впровадження
Розрахунок NAV — це конвеєр, де помилка на вході множиться на весь портфель. Тому ми ведемо впровадження як інженерний проєкт із фіксованими етапами: кожен наступний крок спирається на перевірений попередній, а не на припущення.
- Аудит джерел даних. Інвентаризуємо біржі, кастодіальні гаманці, позабіржові угоди та стейкінг-позиції, звіряємо формати вивантажень, частоту оновлення та розбіжності між ними. На виході — карта джерел із зазначенням, яке з них вважається еталонним для кожного типу активу.
- Проєктування схеми розрахунку. Визначаємо методику оцінки неліквідних позицій, правила конвертації в базову валюту фонду, порядок обліку нарахувань і комісій. Схема фіксується письмово до початку налаштування — це знімає спір «а ми думали інакше» на етапі приймання.
- Налаштування конвеєра. Збираємо забір даних, нормалізацію, розрахунок і запис результату в облікову систему. Ключові контрольні точки — ідемпотентність перерахунку та відтворюваність цифри за будь-яку минулу дату.
- Перевірка на історичних даних. Проганяємо схему на минулих періодах і звіряємо з уже опублікованими значеннями NAV. Розбіжність вище заданого порогу — сигнал повернутися до проєктування, а не «підкрутити» результат.
- Контроль доступу та журналювання. Розмежовуємо права, вмикаємо незмінний журнал змін і фіксуємо, хто і коли коригував вхідні дані.
- Передача та супровід. Віддаємо документацію щодо схеми, регламент перерахунку та інструкції для чергової зміни; окремо проговорюємо порядок дій у разі збою джерела.
Така послідовність дає головне: цифру NAV можна пояснити й повторити. Якщо аудитор або інвестор запитає, звідки взялося значення, відповідь лежить у журналі та схемі, а не в листуванні.
Що замовник отримує на руки
Розрахунок NAV криптофонду — це не один скрипт, а набір артефактів, які живуть після здачі проєкту: їх читають аудитори, ними користуються чергові інженери, на них спирається бухгалтерія під час звірки.
Тому передаємо не «працюючий код», а систему, яку команда замовника може супроводжувати й розвивати самостійно.
- Конфігурації всіх сервісів розрахунку та джерел ринкових даних — з описом параметрів, значень за замовчуванням і меж, за які виходити не можна.
- Схеми потоків даних: звідки надходять котирування та баланси, як вони нормалізуються, де сходяться в єдиний снапшот на звітну дату.
- Політики доступу: ролі, права на запуск перерахунку, на зміну методики та на вивантаження звітів, журнал дій за кожною зміною.
- Документація з методики: формули оцінки позицій, правила обробки завислих транзакцій і активів без ліквідного котирування.
- Регламенти експлуатації: порядок щоденного розрахунку, точки звірки, дії чергового в разі розбіжності з еталоном.
- Набір тестових сценаріїв з еталонними значеннями — щоб після будь-якої зміни можна було перевірити, що цифри не поїхали.
- Інструкція з розгортання та відновлення: як підняти розрахунок з нуля і як відкотитися на попередню версію методики.
До кожного артефакту додаємо коротке пояснення «навіщо це потрібно і що буде, якщо цим знехтувати» — щоб новий інженер у команді замовника входив у контекст без листування з нами.
Окремо фіксуємо відкриті питання та припущення, прийняті на етапі проєктування: вони найчастіше спливають під час аудиту або зміни провайдера даних.
Опишіть вашу методику розрахунку та джерела даних — повернемося з оцінкою та планом за кожним з артефактів.
Кейс: як ми скоротили час розрахунку NAV утричі
Фондовий облік у криптофонді починається з однієї проблеми: активи лежать на десятках адрес і біржових рахунків, а вартість портфеля потрібна на фіксований час.
У клієнта розрахунок NAV займав майже повний робочий день: аналітик вручну зводив баланси, курси підтягував із таблиць, а звірку позицій робив за вивантаженнями з кастодіана.
Помилки в цінах і пропущені нарахування знаходили вже після публікації, і доводилося випускати коригувальний звіт.
Ми перебудували контур розрахунку: позиції та рухи підтягуються з джерел автоматично, ціни беруться з кількох котирувальних стрічок із правилом вибору при розходженні, а нарахування за стейкінгом і відсотками рахуються за розкладом.
Кожне значення проходить перевірку на повноту — якщо за інструментом немає ціни або не зійшовся баланс, розрахунок зупиняється до з'ясування, а не публікує неправильну цифру.
Chainalysis у частині ринкових даних тут не єдине джерело, тому логіка звірки цін винесена в окремий шар: при розходженні між стрічками більше заданого порогу система позначає інструмент і вимагає підтвердження.
Що змінилося в метриках
| Показник | До | Після |
|---|---|---|
| Час повного розрахунку NAV | ~7 годин | ~2,5 години |
| Помилки в опублікованих значеннях | 3-5 за квартал | поодинокі, ловляться до публікації |
| Затримка публікації звіту | 1-2 дні | того ж дня |
| Ручні операції аналітика | більша частина зміни | лише розбір винятків |
Окремо закрили питання відтворюваності: будь-який минулий розрахунок можна перезібрати на тих самих вхідних даних і отримати ту саму цифру — це знімає суперечки з аудитором і керуючим.
Помилки перестали бути «людським фактором» і стали сигналом про проблему в джерелі даних, який видно одразу.
Чим відрізняється NAV криптофонду від традиційного розрахунку?
Ключова відмінність — ринок не закривається. У традиційного фонду є точка відсікання: біржа зупинилася, брокер зафіксував ціни закриття, далі рахуєш спокійно.
У криптофонду такої точки немає: активи торгуються цілодобово, і ціна, знята в момент розрахунку, застаріває на момент публікації. Тому NAV криптофонду — це завжди знімок на конкретну мітку часу, і мітка має бути зафіксована в самому розрахунку, а не матися на увазі.
Волатильність змінює вимоги до частоти. Якщо портфель за годину може піти на кілька відсотків, розрахунок раз на добу перестає відображати реальність — інвестор бачить цифру, якої вже немає.
На практиці NAV рахують частіше і за розкладом, а не за фактом закриття сесії, і кожен розрахунок має бути відтворюваним: ті самі вхідні дані та та сама мітка часу дають той самий результат.
Друга відмінність — активи лежать не в одному місці. Позиції розподілені по кількох біржах, плюс частина в холодному зберіганні, плюс стейкінг і заблоковані під забезпечення суми.
Жодна біржа не дає повної картини, тому розрахунок починається з консолідації: зібрати баланси з усіх майданчиків, привести до єдиної мітки часу, звести дублі та виключити активи, які вже не належать фонду.
Звідси третє — ціна береться не з одного джерела. Для ліквідних пар достатньо біржового стакана, для тонких ринків потрібне запасне джерело і правило вибору, якщо майданчики розходяться.
Без цього NAV починає залежати від того, яку біржу опитали першою, і розходження між розрахунками стає не помилкою округлення, а системною проблемою.
І останнє: результат має бути перевірюваним. Кожна цифра у звіті — це посилання на джерело ціни, на баланс і на правило перерахунку. Тоді розходження з розрахунком керуючого розбирається за хвилини, а не перетворюється на суперечку про те, чиї дані вірніші.
Часті технічні сумніви
Розрахунок NAV криптофонду — це не «взяти ціну з біржі та помножити на кількість». Нижче — сумніви, які найчастіше виникають на етапі оцінки, і те, як вони закриваються інженерно.
Наскільки точним виходить NAV, якщо активи торгуються на різних майданчиках?
Ціна береться не з однієї біржі, а як консенсус за кількома джерелами з відсіканням викидів: медіана замість середнього, відкидання котирувань, що відхилилися від кластера. Для неліквідних позицій додається модель оцінки — остання угода, порядок стакана, дисконт за ліквідність.
Підсумок фіксується снапшотом із хешем вхідних даних: будь-яку цифру можна відтворити й пояснити аудитору.
Яка затримка між угодою та оновленням NAV?
Позиції підтягуються з джерел виконання майже в реальному часі, але опублікований NAV рахується за розкладом — зазвичай раз на добу на фіксований момент. Це усвідомлений вибір: внутрішньоденний перерахунок на волатильному ринку дає стрибучі цифри, які неможливо звіряти. Котирування кешуються, щоб сплеск запитів не гальмував розрахунок.
Як система вбудовується в наш облік і звітність?
Ми не замінюємо наявні системи, а надбудовуємося над ними: забираємо позиції з облікового контуру, віддаємо готовий NAV назад через програмний інтерфейс і вивантаження.
Формати узгоджуємо на старті, щоб бухгалтерія та комплаєнс отримували ті самі дані, що й раніше, — без ручного перенесення та розбіжностей між звітами.
Що буде, якщо джерело цін відвалиться або віддасть сміття?
Кожне джерело перевіряється на живучість і адекватність: різкий стрибок, нульова ціна або застаріла мітка часу відкидаються, розрахунок іде за резервними.
Якщо даних не вистачає для коректної оцінки, система позначає позицію як таку, що потребує ручного підтвердження, а не підставляє мовчки неправильне число. Відмова одного джерела не валить розрахунок.
Чи можна перерахувати NAV заднім числом?
Так. Усі вхідні дані та версії моделей оцінки зберігаються, тому будь-який минулий розрахунок відтворюється на ту саму дату.
Це потрібно для звірок, виправлення помилкових котирувань і розбору розбіжностей із контрагентами — перерахунок дає ту саму цифру, що й у момент публікації, або явно показує, що змінилося.
Обговоримо ваше завдання розрахунку NAV
Щоб розрахунок NAV криптофонду був відтворюваним, а не «зійшлося в таблиці в аналітика», потрібен контур, де джерела цін, правила оцінки неліквідних позицій і облік часток пайовиків описані формально й перевіряються автоматично.
Збираємо такий контур під ваш портфель: від протоколів і бірж до звітності перед інвесторами та аудиторами.
Що закриваємо в межах завдання:
- джерело цін і правила фолбеку: основна біржа, резервне джерело, обробка розходження котирувань і «залиплих» пар;
- оцінка неліквідних і заблокованих позицій: моделі дисконтів, розклад переоцінки, фіксація припущень;
- облік стейкінгу, нагород, комісій і розблокувань — так, щоб дохідність не задвоювалася в NAV;
- розрахунок частки пайовика під час введення та виведення коштів, включно з датами відсічки та спірними транзакціями;
- звірка on-chain залишків з обліковою системою та розбір розходжень до публікації цифри;
- звітність: зріз NAV на дату, рух за період, журнал коригувань і слід правок;
- доступи та ролі: хто бачить чернетку, хто затверджує фінальний NAV, хто лише читає.
Опишіть завдання: які активи та майданчики в портфелі, як зараз рахується NAV, де найчастіше виникають розходження. Повернемося з оцінкою термінів, складом робіт і планом впровадження — з етапами, на яких ви бачите проміжний результат, а не лише фінал.
