Портфельний трекер криптовалют: де ламається облік позицій
Ручний облік криптоактивів тримається рівно до того моменту, поки все лежить в одному місці й угод небагато.
Щойно з'являються дві-три біржі, апаратний гаманець, стейкінг і пара мереж, зведення позицій у таблиці починає розходитися з реальністю — і розходження зростає швидше, ніж кількість рядків.
Перше джерело — ручні вигрузки. Кожен майданчик віддає історію у своєму форматі та зі своєю гранулярністю: десь це окремі угоди, десь рухи коштів, десь агрегат за день.
Час у вигрузках іде за єдиним стандартом, а звірку людина веде у своєму часовому поясі, тому угода на стику доби потрапляє в різні періоди на двох сторонах — і в балансі з'являються розходження на рівному місці.
Другий — перекази між власними адресами. Такий переказ видно і як списання, і як зарахування, і в наївному обліку він рахується двічі; комісія мережі йде третій стороні, тому вартість активів на виході й на вході не збігається. Зведення позицій завищує оборот і викривлює підсумок.
Третій — момент оцінки. Один майданчик віддає вартість на момент угоди, інший — на момент вигрузки, а між ними ціна встигає піти. Поки облік ручний, ці розходження складаються й маскують одне одного: незрозуміло, де помилка введення, а де реальний рух коштів.
Далі розбираємо, де саме облік ламається системно і як це закривається автоматичною звіркою.
Вимірюваний ефект: точність обліку криптовалют і швидкість звірки
Раніше зведений баланс збирався вручну: вигрузки з майданчиків і гаманців зводилися в таблицю, позиції перераховувалися за курсом із відкритої вкладки. На збір ішла половина дня, а результат усе одно розходився з фактичними залишками.
Портфельний трекер криптовалют знімає цю роботу: баланс рахується з однієї моделі даних за всіма підключеними рахунками.
Свіжість котирувань тримається автоматично. Курси надходять із кількох незалежних джерел, розходження між ними позначається як аномалія, а не усереднюється мовчки.
Для рідкісних пар задається окрема політика: якщо свіжої ціни немає, позиція оцінюється за останньою підтвердженою, і це видно у звіті.
Звірка з майданчиками йде без ручного зіставлення рядків. Трекер забирає історію операцій і зіставляє записи за ідентифікатором, часом, обсягом і ціною, закриваючи збіги сам.
У розбір потрапляють лише розходження, і в кожного вказана причина — від відсутнього запису до розходження за комісією.
Звідси йде цілий клас помилок введення: задвоєні угоди, загублені комісії, переплутані знаки, обрізані періоди. Кожна операція зберігає джерело й ознаку звірки, історія операцій повна — стан портфеля піднімається на будь-яку дату, а не збирається заново із залишків.
У роботі це видно так: зведений баланс за всіма майданчиками виходить за секунди замість годин, частка автоматично звірених операцій тримається вище дев'яноста відсотків, а в ручному залишку — лише те, що потребує рішення власника.
Варіанти архітектури: власний індекс, готові агрегатори, гібрид
Схема збору цін визначає, що побачить користувач при збої майданчика чи агрегатора і скільки зусиль іде на підтримання джерела. Обирають між трьома варіантами, і в кожного свої обмеження.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Власний індекс котирувань | Потрібні пари й майданчики, яких немає в агрегаторах, або власна методика середньозваженої ціни з відсіканням викидів | Опитування десятків бірж тримаємо самі: різні формати відповідей, ліміти запитів, перейменування тикерів, делістинг — під кожне джерело потрібен окремий обробник |
| Готові агрегатори | Потрібне широке охоплення монет і швидкий запуск, рідкісні активи в портфелі не трапляються | Зовнішній постачальник — єдина точка відмови; затримка оновлення не контролюється, перерахувати ціну за своєю методикою не можна |
| Гібридна схема | Вартість портфеля рахується своєю методикою, але покриття потрібне ширше за один набір бірж | Найскладніша: логіка пріоритету джерел, зведення розходжень, вирішення конфліктів між ними |
Головний компроміс видно одразу: власний індекс дає контроль і покриття, готові агрегатори — швидкість запуску, гібрид — баланс за рахунок складності підтримки.
Окремо проєктується стійкість до збоїв: опитування зберігає останнє достовірне котирування з міткою часу, щоб в історії не з'являлися діри, а при розходженні джерел сильніше за поріг розрахунок зупиняється, а не береться перше значення, що надійшло.
CoinGecko у гібридній схемі закриває довгий хвіст монет, власний індекс — активи, де точність важливіша за покриття.
Порядок робіт: від аудиту джерел до передачі контуру
Трекер розходиться з реальністю не на графіку, а в даних: майданчик і гаманець по-різному фіксують час угоди, комісії та перекази між власними рахунками — позиція задвоюється.
Тому порядок робіт зворотний до звичного: спочатку джерела й схема нормалізації, потім збирання та інтерфейс.
- Аудит джерел даних. Дивимося, що віддає кожен майданчик і гаманець: потоки угод, вигрузки за минулі періоди, глибину історії та ліміти запитів. Там, де історія неповна, одразу плануємо резервний канал.
- Розмітка активів. Зводимо монети, мережі й тикери до єдиного довідника: один актив на різних майданчиках отримує спільний ідентифікатор, обгорнуті версії та стейкінг — окремі ознаки. Інакше вартість позиції рахується невірно.
- Схема нормалізації. Приводимо до спільного вигляду час, комісії, часткові виконання й перекази між власними рахунками, щоб внутрішнє переміщення не подвоювало позицію. Історія змін зберігається — будь-який період перераховується заднім числом.
- Збирання та перевірка розходжень. Залишки рахуються двома незалежними шляхами — за даними майданчиків і за нашою моделлю; розходження потрапляє у звіт із зазначенням джерела. Так закриваються пропущені угоди й невірний курс на дату.
- Прогін на історії. Контур проганяємо на накопичених даних за кілька ринкових циклів: вимірюємо швидкість перерахунку, поведінку при обриві каналу й коректність відновлення після збою.
- Регламенти оновлення та передача. Описуємо підключення нового майданчика чи активу, порядок правки довідника й розбору розходжень. Моніторинг показує затримку потоку й частку відмов джерел раніше, ніж їх помітить користувач.
Що залишається замовнику: конфігурації, схеми даних, регламенти
Замовнику залишається не архів вихідників, а комплект, за яким систему можна експлуатувати й розвивати без авторів. Передаємо його разом із релізом портфельного трекера: кожен артефакт закриває свій клас завдань — розгортання, розбір інциденту, підключення нового джерела.
- Файли конфігурації — джерела котирувань, інтервали опитування, ліміти звернень до бірж і параметри середовищ: розгортання відтворюється однією командою, без ручних правок на сервері.
- Схема даних — таблиці угод, переказів і знімків вартості, довідник активів, індекси під вибірки за період і версійовані міграції: перерахунок історії не ламає поточні звіти.
- Політики доступу — ролі власника, аналітика й підтримки з роздільними правами, сервісні облікові записи, ротація ключів до біржових API та журнал дій.
- Регламент супроводу — які метрики дивитися, пороги алертів (розходження балансу з біржею, застарілий курс, тиша від джерела), порядок відновлення з копії та вікно реакції на збій.
- Порядок підключення нових джерел — контракт адаптера, нормалізація тикерів, перевірка на історичних даних і викатка без зупинки сервісу: нова біржа чи мережа додаються без правок ядра.
- Документація щодо API та моделі даних — методи, коди помилок, обмеження за частотою запитів, приклади для інтеграцій на стороні замовника.
- Приймальні сценарії — перевірки імпорту історії, перерахунку дохідності й коректності курсів, які проганяються при кожному оновленні.
Комплект передається у вашому контурі з правами власника, секрети залишаються у вашому сховищі. Якщо супровід ведемо ми, працюємо за тим самим регламентом — правила однакові для обох сторін і не залежать від того, хто чергує.
Кейс: як зведений баланс за мережами замінив ручні таблиці
Клієнт — невелика керуюча команда з портфелем у кількох мережах: частина активів на біржі, частина в холодних гаманцях, частина в стейкінгу. Зведений баланс збирали вручну — вигрузка операцій за кожною мережею, зведення в таблиці, перерахунок залишків.
На звіт ішло 6–8 годин роботи аналітика на місяць, і майже в кожному прогоні знаходилися розходження за 3–5 позиціями.
Що було до впровадження
Проблемою була не швидкість, а довіра до цифр. Ручна звірка не ловила пропущені нарахування й враховувала перекази між власними адресами як окремі операції, через що вартість портфеля розходилася з реальністю.
Помилку зазвичай помічали вже після надсилання звіту, коли відновити історію руху коштів було складно.
Що змінили
Зібрали індексатор, який підтягує операції за всіма адресами й приводить їх до єдиної базової одиниці обліку.
Зведений баланс рахується на знімку стану мережі, зафіксованому на одній висоті блоку: дані за різними мережами узгоджені між собою, а внутрішні перекази розпізнаються й не подвоюються.
Курси беруться з незалежного джерела — як опорний взяли CoinGecko і звіряємо його з біржовими котируваннями.
Що стало після
Збирання зведеного балансу займає хвилини замість годин, автоматизація звірки порівнює залишки з біржовими виписками й позначає розходження вище заданого порогу.
Кількість розходжень за позиціями скоротилася з 3–5 до нуля-одного за період, і кожне розбирається як інцидент із зрозумілою причиною.
Контроль коректності побудований на перерахунку закритих періодів: історичний баланс збігся з раніше поданими звітами до останньої позиції, а розходження тепер спливають у момент звірки, а не через місяці.
Технічні сумніви: розходження, ліміти та доступи
Майданчик без програмного інтерфейсу не ставить трекер у глухий кут, але змінює спосіб забору історії. Якщо інтерфейс є — опитуємо за розкладом із урахуванням лімітів джерела, склеюючи дрібні угоди в пакети, щоб не впиратися в квоту запитів.
Якщо немає — розбираємо вигрузку операцій, а для закритих кабінетів залишаємо ручне введення з поміткою джерела, щоб він не розмивав решту розрахунків.
Кожна операція лягає в незмінну історію з джерелом, міткою часу та зліпком вихідної відповіді.
Тому розходження не «чиниться» вручну, а відтворюється: піднімаємо сиру відповідь, звіряємо з розрахунком і знаходимо причину — зазвичай це незбіг моменту угоди й моменту фіксації курсу.
Курс беремо на час угоди; для ринкових котирувань еталон — CoinGecko, але відповідь майданчика теж зберігаємо.
У одного з сервісів взагалі немає API — що з ним робити?
Пишемо адаптер під вигрузку: файл операцій фіксованого формату, розбір за колонками й та сама валідація, що й для API. Якщо й вигрузки немає — операції вводяться вручну й враховуються окремо, як «заявлені», щоб не викривлювати звірку. Пізніше джерело замінюється адаптером без переписування розрахункового ядра.
Кому належать дані і що з доступами після здачі?
Дані, історія операцій і схема залишаються у вас. Ключі до бірж видаються лише на читання, зберігаються в зашифрованому вигляді й не покидають ваш контур.
При передачі проєкту віддаємо репозиторій, міграції, опис моделі даних, регламент оновлення джерел та інструкцію з розгортання — супровід можливий, але технічно проєкт на нас не зав'язаний.
Що робити, якщо облік уже розгорнуто в таблицях і гаманцях?
Розгортати новий облік поверх старого одноразовим перемиканням — погана ідея: якщо ввечері таблиці перестануть бути джерелом правди, а звірка не зійдеться, ви втратите і цифри, і час.
Тому ми запускаємо другий контур поруч: він читає ті самі джерела, що й поточний, але рахує незалежно, а перемикання відбувається лише після того, як розходження пояснені.
Міграція обліку починається з інвентаризації: звідки надходять дані — вигрузки з торгових майданчиків, адреси гаманців, ручні рядки в таблицях. Далі все приводиться до єдиної схеми операції: актив, кількість, ціна входу, комісія, час, джерело.
Перекази між власними адресами позначаються як внутрішні — інакше обсяг задвоюється, а середня ціна входу викривлюється, і звіт показує неіснуючий прибуток.
Перенесення історії йде за операціями, а не за підсумковими сумами: підтягуємо виписки за минулі періоди, довантажуємо гаманці за адресами, перераховуємо собівартість за обраним методом — середньою ціною або черговістю партій.
Рядки в таблицях, де джерело відновити неможливо, позначаємо як неперевірені: вони видно в обліку, але не потрапляють у звітність і розрахунок бази оподаткування до підтвердження.
Паралельна робота будується на контрольних зрізах: обидва контури рахують залишки й результат на одну й ту саму дату, розходження вище заданого порогу йде в розбір — зазвичай це пропущена комісія, неврахований переказ або задвоєна угода.
Поступове впровадження йде за одним сегментом: спочатку портфель на одному майданчику, потім решта гаманців і рахунків. Старий контур залишається робочим до кінця переходу, тому відкат не потребує відновлення даних.
Термін і обсяг робіт залежать від кількості джерел і якості історії — за досвідом це найваріативніший етап. Опишіть, що вже ведете і в якому вигляді, — повернемося з оцінкою та планом переходу без зупинки обліку.
Обговоримо задачу: з чого почати і що знадобиться від вас
Щоб розмова перейшла в оцінку, а не в листування на тиждень, потрібен мінімальний набір вхідних даних. Готове технічне завдання на цьому кроці не потрібне — достатньо того, що вже є під рукою.
- які мережі та майданчики мають потрапити в перший етап: публічні адреси гаманців, ключі лише на читання, паперові угоди;
- звідки береться історія операцій — вигрузки з особистого кабінету, ручне введення, імпорт файлів;
- що вважається портфелем: один обліковий запис, кілька гаманців, заблоковані в стейкінгу активи;
- які звіти потрібні: вартість позицій, реалізований результат, рух коштів за періодами;
- на яких платформах працює клієнт — веб, мобільний, лише перегляд без торгових дій;
- вимоги до доступів: хто бачить дані, чи потрібні ролі та підтвердження входу другим фактором.
У відповідь повернемо розбитий на етапи склад робіт, схему даних і підключень, а також план першого етапу з точками перевірки.
Починаємо з ядра — облік операцій і перерахунок позицій, щоб ви побачили коректні цифри на своїх даних раніше, ніж у проєкт додадуться звітність та інтерфейс. Далі нарощуємо: підключення майданчиків, аналітика, повідомлення.
Опишіть задачу у вільній формі — повернемося з оцінкою та планом, де буде видно, що робимо на першому етапі і що знадобиться з вашого боку.
