Мульти-чейн казначейство, которое не теряет ключи

Клиент управлял операционными криптофондами в трёх блокчейнах — Ethereum, Tron и Bitcoin. Не трейдинг, не DeFi-фарминг, а будничная реальность: перемещать деньги между кошельками, финансировать операции и держать в поле зрения балансы по разным сетям. У них были десятки кошельков, организованных в батчи, каждый батч под свою операционную задачу, и всё это велось смесью браузерных расширений, CLI-инструментов и таблицы, которая хронически устаревала. Запрос был прост: один интерфейс, чтобы видеть всё, финансировать что угодно и знать, где находится каждый сатоши.

Стек

  • Next.js 14
  • Node.js
  • Prisma
  • PostgreSQL

кошельки и батчи

Построили систему управления казначейством, в которой кошельки — сущности первого класса. Кошельки сгруппированы в батчи, батчи принадлежат операционным категориям, а каждый кошелёк в реальном времени отслеживает балансы по всем поддерживаемым сетям. Оператор видит единый дашборд — суммарные холдинги по сетям, по батчам, по кошелькам — и может провалиться к истории конкретных транзакций. Операции пополнения работают сверху вниз: выбираем батч, указываем сумму и исходную сеть, система автоматически распределяет средства по вложенным кошелькам, рассчитывая комиссии и корректируя суммы так, чтобы запланированная величина действительно дошла.

мультичейн-операции и мосты

Кросс-чейн-операции стали ядром инженерного вызова. Клиенту нужно было регулярно перемещать средства между Ethereum и Tron и иногда мостить в Bitcoin. Интегрировали Allbridge SDK для мостов, ethers.js — для операций Ethereum, tronweb — для Tron и bitcoinjs-lib — для Bitcoin. У каждой сети свои особенности: транзакции Ethereum могут висеть в mempool часами в моменты конгестии, у Tron вместо простого gas — модель bandwidth/energy, а у Bitcoin модель UTXO означает, что «баланс кошелька» — принципиально иное понятие, чем в сетях с аккаунт-моделью. Эти различия спрятаны за единым интерфейсом операций, но абстракция намеренно «течёт»: операторы всегда видят детали конкретной сети, потому что прятать сложность в крипте — значит прятать риск.

Транзакции через мосты заслужили собственный конечный автомат. Кросс-чейн-перевод — это не одна операция, а многошаговый процесс, который может занимать от двух минут до нескольких часов, без гарантий доставки. Система ведёт каждую операцию моста по стадиям: initiated, source confirmed, bridge processing, destination pending, completed. Если мост подвисает, оператор видит, где именно остановилось движение, и получает понятные опции — повторить, эскалировать на ручное вмешательство или подождать, с оценкой уверенности по историческим данным моста. Относиться к мостам как к fire-and-forget — рецепт потерянных средств.

безопасность ключей и комиссии

Архитектура безопасности — не обсуждается и определяет каждое решение. Приватные ключи живут исключительно в переменных окружения — никогда в базе, никогда в логах, никогда в ответах API. Приложение загружает ключи при старте, держит их в памяти для подписания, и больше они нигде не существуют. В базе на кошельки ссылаются только по публичному адресу. Рассматривали HSM, но операционные накладные расходы не соответствовали сценарию: это горячие кошельки для операционных средств, а не холодное хранилище резервов. Этот компромисс задокументирован и принят клиентом.

Волатильность gas-цен в Ethereum делала прогноз стоимости ненадёжным так, что это влияло на продукт. Пополнение батча, оценённое в $50 по комиссии, могло обойтись в $200, если к моменту исполнения сеть скакнула. Добавили оракул gas-цен, который перед каждой операцией проверяет текущие условия, сравнивает их с настраиваемым потолком и ставит операцию на паузу, если стоимость превышает порог. Оператор получает оповещение: «Gas сейчас 85 gwei, твой потолок — 40. Продолжить или подождать?» Только это уже предотвратило несколько дорогих ошибок в моменты конгестии сети.

результаты

Клиент получил актуальную и точную картину операционного казначейства и может проводить мультичейн-операции без переключения между пятью разными инструментами. Ночью идёт периодическая сверка — балансы on-chain сравниваются с записями в базе, расхождения отмечаются.