Блог · 7 ноября 2026 г.

Поддержание энергии на кошельке выплат: стейк, аренда под каждый перевод или пополнение после каждого

Кошелёк выплат в TRON тратит энергию на каждый отправляемый перевод USDT: около 65,000 единиц, когда у получателя USDT уже есть, и около 131,000, когда нет. Когда энергии не хватает, сеть берёт вместо неё TRX по 100 sun за единицу — это 6.5 TRX или 13.1 TRX за перевод, — и выплата всё равно подтверждается, пока на кошельке есть эти TRX и fee_limit транзакции разрешает сжигание (весь расчёт). Так что задача горячего кошелька — иметь энергию на месте перед каждой отправкой, чтобы никто не заказывал её вручную. С этой задачей справляются три схемы, и каждая ломается по-своему.

Стейк рассчитывают под самый загруженный день, а платят за него каждый день

Стейкинг TRX под энергию покупает долю фиксированного суточного пула. Суточная норма кошелька — это его стейк, умноженный на TotalEnergyLimit сети и делённый на TotalEnergyWeight, и 3 сентября 2026 года это отношение стояло на 180,000,000,000 к 18,770,236,993: чуть меньше десяти единиц энергии в сутки на каждый застейканный TRX. Делитель — весь стейк сети под энергию, включая ваш, поэтому цифра дрейфует от блока к блоку (разобранная формула).

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

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

Аренда под каждый перевод ставит ожидание перед каждой отправкой

Вторая схема покупает энергию под каждый перевод по мере его появления. Заказ называет кошелёк-отправитель и получателя. API отвечает 202, с собственным адресом заказа в Location и интервалом опроса в Retry-After, а мы покупаем энергию и следим, когда она появится на кошельке. Как только делегация подтверждена, в заказе появляется send_before — это сигнал вашему коду отправлять. Окно — это срок аренды без трёх секунд: 297 секунд на пятиминутной аренде и 3,597 на часовой.

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

Тринадцать заказов — малая выборка, и большая её часть ранняя. Семь пришлись на первую неделю боевых заказов, и самые медленные — среди них, а последующие недели шли за три–четыре секунды. На большей выборке мы замер не повторяли.

Перевод, отправленный до прихода энергии, сжигает по полной ставке, а отправленный после send_before может найти энергию уже ушедшей и сжечь так же. Сожжённые TRX не возвращаются. Энергия, которая была доставлена и не использована внутри окна, закрывается как expired и оплачивается, потому что была доставлена (трое часов аренды). Очередь выплат, отправляющая по собственному расписанию, должна быть перестроена вокруг этого сигнала. Для прогона выплат, известного заранее, один пакетный заказ до 500 переводов собирает ожидание в одном месте: энергия на весь прогон покупается первой, и все переводы в нём делят один send_before (как пакет выглядит изнутри).

Правило, которое пополняет кошелёк после каждого перевода

Третья схема — правило на кошельке, которое мы продаём как Auto-refill: горячий кошелёк как частный случай отправки USDT без TRX на кошельке. Оно принимает два поля, address и daily_budget_trx, одним вызовом POST /v1/auto-refill-rules. С этого момента кошелёк после каждого своего перевода доводится обратно примерно до 131,000 единиц энергии. Этого хватает на любой один следующий перевод, в том числе на адрес без USDT. Правило не создаёт заказов: GET /v1/orders перечисляет только те, что разместили вы.

Пополнение оценивается по тому, сколько потратил предшествующий ему перевод. Если тот потратил около 65,000 единиц, пополнение считается по ставке single; если около 131,000 — по double. Обе ставки лежат в GET /v1/tariff под maintenance_price_trx. Это отдельная цена, и движется она отдельно от цен аренды, а применяется та ставка, что действует в момент подтверждения пополнения. Первое пополнение нового правила — всегда double: предыдущего перевода, по которому его можно оценить, нет, и кошелёк сразу получает полные 131,000.

Списание ждёт, пока энергия не станет видна на кошельке в сети; слов поставщика о доставке недостаточно. Каждое списание приходит событием maintenance.topup с rule_id, address, units и charged_trx и строкой charge в GET /v1/ledger. Кошелёк, который ничего не отправляет, не получает пополнений и не платит ни за одно.

Как пополнение останавливается и что тогда делает кошелёк

Суточный лимит, daily_budget_trx, резервируется из вашего доступного баланса, когда правило запускается, и снова в начале каждых суток по UTC, и это самое большее, что правило может потратить за эти сутки. Пополнения списываются из этого резерва, а то, что от него остаётся, возвращается на баланс в полночь UTC. Поле правила spent_today_trx показывает, сколько из суточного лимита уже ушло. Повышение лимита в середине дня добавляет разницу в резерв и вторых суток не открывает.

Когда лимит потрачен, пополнения останавливаются до следующих суток по UTC. Вы получаете одно событие maintenance.budget_exhausted с spent_today_trx и daily_budget_trx внутри, а правило остаётся active. С этого момента и до полуночи каждый перевод, который кошелёк не может оплатить энергией, сжигает TRX на недостачу по 100 sun за единицу. Лимит, рассчитанный на средний день, на загруженном кончается.

Когда ваш баланс не может покрыть резерв следующих суток, правило останавливается. Его status становится paused, paused_reason — insufficient_balance, и уходит событие maintenance.paused. Поставленное на паузу правило само не возобновляется, и депозит его не запускает: оно ждёт PATCH /v1/auto-refill-rules/{rule_id} с {"status": "active"}, а возобновление, которое баланс всё ещё не покрывает, отвечает 402. Пауза, которую вы поставили сами, причины не несёт, поэтому paused_reason отличает правило, ждущее денег, от правила, ждущего вашего решения.

Суточный лимит ниже ставки double отклоняется ответом 422, с details.reason, равным budget_below_topup_price, и минимумом в details.min_daily_budget_trx: первое пополнение — double, и правило с меньшим лимитом запустилось бы и ни разу не смогло бы его оплатить.

Примерно 131,000 единиц на кошельке покрывают два перевода на адреса с USDT или один на адрес без него. Перевод, отправленный раньше, чем дошло пополнение за предыдущий, может найти меньше нужного и оплатить часть пути, а то и почти весь, в TRX. Как скоро после перевода приходит пополнение, мы не измеряли. Удаление правила до того, как его пополнения покроют то, что мы предоплатили под этот кошелёк, стоит непокрытой части — с учётом предоплат и списаний начиная с 6 ноября 2026 года; пауза за это не списывает никогда.

Один пример дня, тремя способами

Чтобы поставить три схемы рядом, возьмём один кошелёк и один день: тридцать выплат на адреса, где USDT уже есть, и десять на адреса, где его нет. Сжигание и стейк — арифметика сети. Цена заказа и ставки пополнения — наши, прочитаны из GET /v1/tariff в 21:46 UTC 27 октября 2026 года; сегодняшние — на странице цен.

В тот час заказы вышли дешевле пополнений, и так бывало обычно. За тридцать дней почасовой истории до того же вечера ставки пополнений не менялись ни разу, а пятиминутный заказ на тот же перевод стоил меньше его пополнения в большинстве часов.

То, что пополнение стоит сверх заказа, покупает кошелёк, у которого энергия уже есть к моменту отправки каждого перевода, и жёсткий потолок на то, сколько он может потратить за сутки. Лимит, как и стейк, должен покрывать загруженный день, но то, что от него оставляет тихий день, возвращается на баланс в полночь UTC. Боевой цифры того, сколько пополнений правило делает за сутки, у нас нет.

Настройте кошелёк выплат так, чтобы он пополнял себя сам, одним запросом и суточным лимитом на ваш выбор: POST /v1/auto-refill-rules в справочнике API →