Автоматический сбор средств с пользовательских TON-кошельков: пороги, батчи и казначейство

У биржи или обменника обычно не один кошелёк, а сотни — каждому пользователю может выдаваться свой TON-адрес. Держать деньги «размазанными» по ним небезопасно.

Нужен процесс, который регулярно и предсказуемо переводит средства на ограниченный набор казначейских (collector) кошельков, которыми удобно управлять и проще защищать. Разберём, из чего на практике состоит такой процесс — collection, — если делать его не «руками через консоль», а как встроенную автоматику.

Не просто «перевести всё», а посчитать, что можно перевести

Прежде чем инициировать перевод, сервис отвечает сразу для всех кандидатов на сбор: сколько реально доступно за вычетом зарезервированного баланса; хватит ли остатка на сетевую комиссию, чтобы операция не съела саму себя; не превысит ли пополнение лимит максимального баланса collector-кошелька; не участвует ли этот же кошелёк уже в другой активной операции сбора.

Каждая проверка — отдельная причина «пропустить» кандидата, и система обязана явно фиксировать причину (недостаточно средств, кошелёк занят, collector переполнен, лимит батча), а не молча его игнорировать — это важно и для отладки, и для финансовой отчётности.

Батчи, а не поток одиночных переводов

Сбор выполняется ограниченными батчами с заранее посчитанной ёмкостью: сколько кошельков войдёт, какая суммарная сумма ожидается, какая комиссия сети закладывается заранее. Оператор видит предпросмотр операции до её запуска — это защищает от ситуации, когда одна гигантская фоновая задача пытается обработать тысячи кошельков одновременно и упирается в лимиты RPC-провайдера TON-сети.

Автоматический триггер по порогу, а не только по расписанию

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

Ротация collector-кошельков и устойчивость к сбоям сети

Казначейские кошельки не статичны: предусмотрена ротация — новый активный collector подключается автоматически, без остановки процесса сбора. А TON-провайдер (нода/индексатор) может быть перегружен — на этот случай есть cooldown-механизм: при рейт-лимите сервис не долбит провайдера повторными запросами, а выдерживает нарастающую паузу для всей сети, а не только для одной операции.