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