TRON и TRC-20: bandwidth, energy, resources и почему USDT-переводы стоят по-разному

В TRON комиссия устроена не как единая цена gas × gas used. Сеть разделяет стоимость на два системных ресурса: **Bandwidth** оплачивает байты транзакции, а **Energy** — вычисления smart contract в TRON Virtual Machine. Оба ресурса можно получать через staking TRX или delegation. Если их не хватает, сеть сжигает TRX. Поэтому два перевода одинаковых 1000 USDT могут иметь одинаковую сумму и разные фактические расходы — в зависимости от ресурсов sender, состояния contract call и текущих chain parameters.

Resource model TRON: Bandwidth и Energy отвечают за разные вещи

Каждая записываемая в chain transaction занимает место и требует обработки. TRON не объединяет эти две величины в одну универсальную gas unit.

**Bandwidth** измеряет serialized byte size транзакции: один on-chain byte потребляет одну Bandwidth unit. **Energy** измеряет TVM computation smart-contract call: каждая инструкция имеет Energy cost, а итог зависит от выполненного кода.

Почему обычный TRX transfer и TRC-20 transfer стоят по-разному

Native TRX transfer в основном потребляет Bandwidth. TRC-20 USDT transfer — это вызов token smart contract, поэтому кроме Bandwidth требует Energy.

Именно Energy обычно определяет заметную стоимость TRC-20 transfer, если у sender нет staked или delegated resource.

Сеть имеет фиксированные дневные resource pools

Текущая TRON документация указывает network-wide daily supply **43.2 млрд Bandwidth** и **180 млрд Energy**. Staked resources распределяются пропорционально доле TRX, застейканной под соответствующий resource.

Это не фиксированное количество resources на 1 TRX

Если network-wide stake меняется, меняется и resource output одинакового amount TRX. Поэтому калькулятор «1 TRX stake всегда даёт X Energy» быстро устаревает.

Bandwidth: почему у аккаунта есть 600 бесплатных units в день

Каждый активированный external account получает **600 free Bandwidth/day**, восстанавливающихся по rolling 24-hour model. Для небольшого числа обычных transfers этого часто достаточно.

Если free allowance исчерпан, сеть сначала использует staked или delegated Bandwidth, а затем переходит к TRX burn.

Стоимость нехватки Bandwidth рассчитывается по bytes

Current docs приводят chain parameter **1000 sun за byte**, то есть 0.001 TRX/byte. Но это governance-controlled parameter, поэтому production software должен читать current value через chain parameters, а не hardcode его навсегда.

Пример native transfer

Документация приводит типичный 270-byte TRX transfer. Без доступного Bandwidth fallback burn составит 270 × 1000 sun = 270 000 sun = **0.27 TRX** при текущем documented rate.

Free Bandwidth — не «бесплатные транзакции» как маркетинговый бонус. Это protocol quota. После её исчерпания тот же transaction path начинает потреблять staked resource или TRX balance.

Energy: реальная стоимость выполнения TRC-20 contract

Energy требуется при запуске smart contract. Transfer USDT вызывает TRC-20 contract, проверяет balance, меняет storage, создаёт event и выполняет дополнительные token-specific checks.

В отличие от Bandwidth, у Energy **нет бесплатной дневной квоты**. Пользователь либо имеет Energy через staking, либо получает её delegation, либо оплачивает shortfall сжиганием TRX.

Текущая fallback price — 100 sun за Energy

Official Paying for Resources documentation сейчас указывает **100 sun/Energy = 0.0001 TRX/Energy**. Это параметр getEnergyFee и он может изменяться governance proposal.

Нельзя честно сказать «USDT transfer всегда требует N Energy»

Energy consumption зависит от code path и contract state. Разный receiver state, storage writes и Dynamic Energy Model способны менять результат. Для transaction builder правильный путь — вызвать energy estimation непосредственно перед отправкой.

Иллюстративный расчёт

Если конкретный simulation показывает **130 000 Energy**, а у sender нет ни staked, ни delegated Energy, при цене 100 sun/Energy theoretical Energy burn будет 13 000 000 sun = **13 TRX**. К нему добавляется Bandwidth shortfall, если отсутствует Bandwidth.

Это не прогноз комиссии конкретного USDT transfer — только формула, показывающая, откуда берётся стоимость.

Почему одинаковые USDT transfers могут иметь разную комиссию

Amount токена почти не влияет на TVM complexity. Transfer 10 USDT и 10 000 USDT обычно идут через одну function. Но состояние sender и receiver, доступные resources и contract dynamic-energy multiplier могут различаться.

Сумма перевода не является формулой комиссии

Комиссия 100 USDT transfer не равна проценту от 100. Network resources оплачивают computation и bytes, а не economic value token transfer.

Новый или «пустой» адрес способен изменить execution path

Token contract может выполнять storage operation иначе, когда balance slot receiver впервые становится ненулевым. Поэтому wallets не должны обещать фиксированный fee только на основании ticker.

Stake 2.0 превращает TRX в renewable network resources

Staking TRX в TRON имеет особую practical utility: пользователь выбирает resource — BANDWIDTH или ENERGY — и получает соответствующую долю network pool.

Resource восстанавливается после использования по rolling 24-hour cycle. Это делает staking похожим не на одноразовую оплату, а на приобретение возобновляемой throughput capacity.

Energy stake особенно полезен при регулярных TRC-20 transfers

Пользователь или сервис с постоянным daily flow может stake TRX вместо постоянного burn. Экономическое сравнение зависит от стоимости капитала, количества операций и network-wide stake.

Stake 2.0 отделяет resource allocation от governance power

Staking также создаёт TRON Power для voting, но resource choice относится к Bandwidth/Energy capacity. В operational analysis нужно различать network throughput benefit и governance utility.

Unstaking имеет delay

Current docs указывают **14-day unstaking delay**. Поэтому resource strategy нельзя считать мгновенно обратимым депозитом: capital временно остаётся связан с protocol rules.

Delegation: почему wallet может отправить USDT почти без TRX balance

TRON позволяет account, который застейкал TRX, делегировать полученные Bandwidth или Energy другому account. Receiver использует resource напрямую, не становясь владельцем исходного TRX stake.

Это важный payment primitive. Exchange, wallet или dApp operator может содержать большой staking pool и выдавать Energy клиентским адресам перед contract call.

Delegation меняет payer, но не отменяет resource cost

Если пользователь не сжёг TRX, это не означает, что computation стал бесплатным. Cost перенесён на capital provider, который держит staked TRX и расходует renewable Energy.

Resource rental — экономический слой поверх protocol delegation

Рынок может предлагать Energy «в аренду». Технически underlying benefit связан с delegated resource. Цена rental service уже определяется market economics и не обязана совпадать с protocol burn rate.

Делегированные resources можно отозвать

Delegation reversible согласно Stake 2.0 rules и может использовать optional lock period. Production wallet должен учитывать момент, когда promised resource фактически доступен receiver.

fee_limit: потолок caller-side Energy budget, а не «максимальная комиссия интерфейса»

Каждый smart-contract transaction содержит fee_limit. Он задаётся в sun и ограничивает total caller-side Energy budget, включая Energy из stake и TRX-burn portion.

Если execution требует больше budget, transaction завершается OUT_OF_ENERGY. Уже использованные resources при этом могут быть списаны до лимита.

fee_limit нужен как защита от runaway execution

Без budget cap bugged или неожиданно дорогой contract path мог бы сжечь значительно больше TRX. По смыслу fee_limit похож на gas limit, но charging model TRON отличается из-за staking и deployer sharing.

Максимум — chain parameter, а не вечная константа

Current docs указывают getMaxFeeLimit = **15 000 000 000 sun = 15 000 TRX**. Такое большое значение не является рекомендацией ставить 15 000 TRX на обычный transfer. Это protocol ceiling, который software должен получать из chain parameters.

Estimate сначала, fee_limit потом

Для production transaction builder последовательность должна быть такой:

1. собрать exact contract call;
2. estimate Energy;
3. учесть current energy_factor/dynamic model;
4. добавить разумный safety margin;
5. установить fee_limit;
6. подписать и broadcast.

Deployer Energy sharing: TRON позволяет контракту субсидировать пользователя

TRON имеет механику, которой нет в классической Ethereum caller-pays model. Contract deployer может установить consume_user_resource_percent и взять часть Energy cost на собственный staked Energy pool.

Если значение 100, caller оплачивает всю Energy. Если 0, deployer теоретически покрывает 100% Energy, пока его resource pool не исчерпан.

Subsidy заканчивается вместе с Energy deployer-а

Если deployer обещал 50% cost, но его Energy закончилась, shortfall переходит к caller и учитывается в том же fee_limit budget.

Для чужого token contract wallet не может просто включить subsidy

Only contract deployer управляет собственным resource-sharing parameter. Wallet, который отправляет USDT через чужой TRC-20 contract, чаще использует resource delegation/rental, а не deployer subsidy.

«Zero fee for user» — это UX statement. На protocol level кто-то всё равно предоставляет Bandwidth/Energy или принимает TRX burn.

TRC-20 USDT transaction: build, sign, broadcast, receipt

TRC-20 standard напоминает ERC-20 на уровне familiar methods: balanceOf, transfer, approve, transferFrom. Но execution и fee model — TRON-native.

Практический flow:

1. wallet кодирует transfer(destination, amount);
2. node строит TriggerSmartContract transaction;
3. wallet задаёт fee_limit;
4. sender подписывает transaction private key;
5. transaction broadcast-ится в TRON network;
6. Super Representatives включают её в block;
7. TVM выполняет contract call;
8. receipt показывает Energy/Bandwidth и execution result.

Amount учитывает token decimals, а Energy — execution code

Wallet должен корректно преобразовать human amount в integer token units. Ошибка decimals может отправить неправильную сумму, но не является причиной high Energy fee сама по себе.

OUT_OF_ENERGY не означает, что token contract обязательно сломан

Причиной может быть заниженный fee_limit, недостаточный resource budget или более дорогой code path. Debugging начинается с receipt и estimation, а не с повторной отправки с произвольным fee.

Explorer-проверка: как понять, за что реально заплатил sender

Tronscan и node APIs позволяют увидеть resource consumption transaction. Для диагностики нужно смотреть не только token amount и status.

Полезные поля

• transaction size / Bandwidth usage;
• Energy usage;
• Energy fee / net fee;
• fee_limit;
• result и contract result;
• sender/receiver;
• token contract;
• block timestamp;
• internal calls/events, если нужны для конкретного contract.

Сначала отделяйте resource consumption от TRX burn

Transaction может использовать 100 000 Energy и при этом не сжечь 10 TRX, если Energy была полностью покрыта stake/delegation. Поэтому «Energy used» и «fee paid from balance» — разные цифры.

Проверяйте официальный USDT contract

TRC-20 ecosystem допускает любой contract с символом USDT. Ticker не является identity. Для transfer/payment integration нужен exact issuer-supported contract address из официальной документации Tether/Tron explorer verification.

Главный вывод

TRON строит transaction economics не вокруг одного gas price, а вокруг renewable resources. Bandwidth оплачивает byte-size, Energy — TVM computation. Account получает 600 Bandwidth/day бесплатно, а Energy требует stake, delegation или TRX burn. Stake 2.0 позволяет превратить TRX capital в возобновляемый throughput, delegation переносит resource capacity между accounts, а fee_limit ограничивает caller-side execution budget.

Именно поэтому **у USDT TRC-20 нет одной вечной фиксированной комиссии**. Amount token transfer почти не важен для computation cost; важнее exact contract path, current Energy estimation, dynamic model, available resources и chain parameters.

Практический инженерный принцип простой: не спрашивать «сколько стоит USDT transfer в TRON вообще», а спрашивать **сколько Bandwidth и Energy потребуется этой конкретной transaction сейчас, какие resources уже доступны sender и сколько shortfall придётся покрыть TRX burn.**

FAQ

Сколько Energy нужно для USDT TRC-20 transfer?

Нет одной гарантированной цифры. Energy зависит от exact execution path и current dynamic-energy conditions. Используйте node estimation перед отправкой; затем рассчитывайте возможный TRX burn по current getEnergyFee.

Почему вчера USDT стоил дешевле отправить, чем сегодня?

Могли измениться доступные staked/delegated resources, free Bandwidth, contract dynamic Energy factor или chain parameters. Сумма USDT при этом могла быть одинаковой.

Можно ли отправлять USDT без TRX?

Иногда да, если account уже активирован и получает достаточно Bandwidth/Energy через staking, delegation или wallet/service subsidy. Но network resources всё равно кем-то предоставляются.

Что даёт staking TRX?

В Stake 2.0 пользователь выбирает Bandwidth или Energy, получает renewable resource capacity и TRON Power. Direct unstaking сейчас имеет 14-day delay согласно документации.

Что такое fee_limit?

Это caller-side cap на total Energy budget smart-contract transaction в sun. Слишком низкий limit может привести к OUT_OF_ENERGY; слишком высокий не означает, что вся сумма будет обязательно списана.

Чем Bandwidth отличается от Energy?

Bandwidth соответствует размеру transaction в bytes. Energy соответствует вычислительной работе TVM smart contract. Native TRX transfer в основном требует Bandwidth, TRC-20 transfer — и Bandwidth, и Energy.

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