Как покупать энергию TRON программно, без ручного подтверждения

Короткий ответ: энергия TRON покупается программно по той же схеме «сборка → подпись → отправка», что и обычный перевод. Ваш сервис собирает неподписанную транзакцию HTTP-методом (wallet/freezebalancev2 — стейкинг под энергию, DelegateResource — передача ресурса конкретному адресу), подписывает её локально приватным ключом пула и отправляет в wallet/broadcasttransaction. Ручное подтверждение появляется только там, где ключ находится в кошельке пользователя (TronLink, MCP-серверы экосистемы). Если ключ держит ваш код, подтверждать нечего, и автоматическая закупка становится просто ещё одним шагом в конвейере выплат.

Откуда берётся энергия

В отличие от Bandwidth, у Energy нет бесплатной дневной квоты (у Bandwidth она есть — 600 единиц в сутки для внешнего аккаунта). Чтобы выполнить перевод TRC-20, аккаунту нужно либо иметь застейканную или делегированную энергию, либо покрыть недостаток сжиганием TRX по текущей цене getEnergyFee — в документации указано 100 sun (0,0001 TRX) за единицу. Это параметр цепи, который меняется голосованием SR, поэтому в продакшене его нужно читать из сети, а не хардкодить.

Есть два стандартных способа получить энергию:

• стейкинг TRX (Stake 2.0) — вы замораживаете TRX и получаете долю общего лимита сети по формуле застейканные TRX / всего TRX сети, застейканных под Energy × 180 000 000 000;
• аренда на Energy Rental Market от JustLend DAO — доступ к энергии без заморозки собственных активов.

Примитив, на котором строятся пулы и сервисы аренды, — DelegateResourceContract: держатель стейка делегирует энергию другому аккаунту, и получатель тратит её напрямую, ничего не стейкая сам. Именно так биржи и операторы DApp покрывают расходы пользователей из единого стейкинг-пула.

Архитектура «пул + делегирование»

1. Выделенный аккаунт пула с TRX, застейканными под ENERGY (минимум для одной операции FreezeBalanceV2 — 1 TRX, то есть 1 000 000 sun; меньшая сумма отклоняется с ContractValidateException).
2. Перед каждой выплатой — запрос wallet/getaccountresource для горячего адреса: сколько энергии доступно прямо сейчас.
3. Если не хватает — DelegateResource из пула на нужный объём, подпись, отправка.
4. После пачки выплат — UnDelegateResource, возврат ресурса в пул.

Поле resource принимает строки ENERGY или BANDWIDTH. Делегирование обратимо, но поддерживает необязательную блокировку: пока она не истекла, забрать ресурс нельзя — в бэкенде это нужно учитывать как «пул временно меньше», иначе планировщик будет раз за разом упираться в балансы, которые не может вывести.

Если логика распределения ресурсов у вас уже ончейн, то же самое можно сделать и без сервера: Stake 2.0 доступен из Solidity — freezebalancev2(1000000, 1), receiver.delegateResource(1000000, 0), receiver.unDelegateResource(...), плюс view-метод target.delegatableResource(1) для мониторинга объёма, доступного для делегирования. Подробности — в разделе Bandwidth and Energy.

Если вы планируете поручить закупку ИИ-агенту, учтите одно ограничение: MCP-инструменты TronScan пока доступны только для чтения, TronGrid умеет собирать неподписанные транзакции и отправлять уже подписанные, но не подписывает и не хранит приватные ключи, а остальные серверы экосистемы требуют явного разрешения пользователя. Полностью «автономный» сценарий через MCP из коробки не поддерживается — подпись должна оставаться внутри вашего собственного кода.

Сколько покупать: расчёт в рантайме

Не хардкодьте объём энергии на перевод.

Шаг	Метод	Что даёт
Оценка	/wallet/triggerconstantcontract	локальное выполнение без транзакции и без расхода ресурсов
Уточнение	estimateenergy	energy_used; точнее для конкретных контрактов, требует включённых на ноде vm.estimateEnergy и vm.supportConstant
Цена	getEnergyFee (параметр №11)	sun за единицу Energy
Потолок	getMaxFeeLimit (параметр №47)	сейчас 15 000 TRX

Математика проста: fee_limit (sun) = energy_required × getEnergyFee. Оценка отражает состояние ноды на момент запроса и не гарантирует, что последующая ончейн-транзакция пройдёт успешно.

Главный риск по стоимости — динамическая модель энергии (DEM). Параметр №75 getDynamicEnergyMaxFactor возвращает в мейннете 34 000, то есть max_factor = 3,4, а суммарный множитель энергии может достигать 4,4. Коэффициент меняется после смены цикла обслуживания, поэтому любой кэш оценок, переживающий цикл, нужно инвалидировать. Стратегия «всегда считать по max_factor» безопасна для прохождения транзакций, но приводит к завышенному бюджету. Разбор — в FeeLimit & Energy.

Перевод USDT не активирует получателя и лишней Energy за это не стоит: дополнительные 25 000 Energy списываются, только когда смарт-контракт отправляет TRX или TRC-10 на неактивированный адрес. На расход влияет другое — баланс USDT получателя: около 65 000 Energy, если USDT у него есть, и около 131 000, если баланс нулевой.

Что ломается под нагрузкой

• TTL транзакции — 60 секунд после сборки. Бывает, что отправка «успешна», но транзакция так и не доходит до ноды SR; повторять имеет смысл только после истечения срока действия.
• OUT_OF_TIME: глобальный лимит времени выполнения транзакции контракта — 80 мс (меняется голосованием SR). При превышении списывается весь fee_limit.
• Energy не возвращается — ни из стейка, ни от сжигания — даже если транзакция откатилась или упала на другой проверке.
• Восстановление занимает 24 часа, линейно. Если за этот период вы снова тратите ресурс или отзываете делегирование, система пропорционально объединяет прогресс восстановления с новым циклом: «отозвано» не значит «сразу доступно».
• Анстейк занимает 14 дней: UnfreezeBalanceV2Contract, ожидание, затем WithdrawExpireUnfreezeContract. Это не инструмент быстрой ребалансировки.
• Stake 1.0 в скопированном коде: старые примеры содержат frozen_duration: 3 и FreezeBalanceContract — скопируете их, и соберёте транзакцию для старого механизма.
• API-ключ: заголовок TRON-PRO-API-KEY нужен только для мейннета; Shasta и Nile работают без него, и Stake 2.0 там ведёт себя так же, как в мейннете, — поэтому это подходящее место для отладки автоматической закупки.

Вывод: ручное подтверждение исчезает не благодаря какому-то особому «API аренды», а потому, что подпись остаётся на вашей стороне. Всё остальное — дисциплина: оценивать энергию в рантайме, читать параметры цепи из сети (wallet/getchainparameters) и помнить, что стейкинг, делегирование и восстановление ресурсов живут каждое по своему таймеру.

Материал носит исключительно информационный характер и не является инвестиционной рекомендацией.