> For the complete documentation index, see [llms.txt](https://tron-energy-doc.crypto-chief.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://tron-energy-doc.crypto-chief.com/getting-started/how-energy-works.md).

# How Energy Works

## How Energy Works

Read this before you build. It is short, and it prevents the two failures that cost real money.

### Energy is what the chain charges for computation

A TRC-20 transfer is a smart contract call, and TRON charges **energy** to execute it. An account holding energy spends the energy. An account holding none pays by **burning TRX** at a rate set by network governance — currently **100 SUN per energy unit**, or 0.0001 TRX.

That rate is a chain parameter and it has changed before: it was 420 SUN, then 210, now 100. We read the live value rather than hard-coding it, which is why every quote carries `burn_price_sun` alongside the price — the comparison you see is the one in force at that moment.

### The amount depends on the recipient, not on you

This is the part that catches people out.

| The recipient          | Energy needed | Burned if you do nothing |
| ---------------------- | ------------- | ------------------------ |
| **Already holds USDT** | \~64,285      | \~6.43 TRX               |
| **Holds no USDT yet**  | \~130,285     | \~13.03 TRX              |

Sending USDT to an address that already holds some **updates** a storage slot. Sending to an address that holds none has to **create** that slot first, and creating costs roughly twice what updating does.

{% hint style="success" %}
**Leave `energy` out of your request and we work it out.** We read the recipient's token balance and size the order for the transfer you are actually about to make. Every other service on the market shows you a 65k / 131k switch and leaves the choice to you.
{% endhint %}

The response tells you which case it was:

```json
{
  "energy": 130285,
  "recipient_state": "cold"
}
```

| `recipient_state` | Meaning                                                                         |
| ----------------- | ------------------------------------------------------------------------------- |
| `warm`            | The recipient already holds the token. The smaller figure applies.              |
| `cold`            | The recipient holds none. The transfer must create the slot, so roughly double. |
| `unknown`         | You supplied `energy` yourself, so we did not look.                             |

### When you should name the amount yourself

Automatic sizing is built for a plain USDT transfer, which is most traffic but not all of it. Supply `energy` explicitly when:

* the transaction is **not a simple transfer** — a contract call, a multi-send, an approval;
* you are moving **a different TRC-20 token** whose contract costs more than USDT's;
* you have **metered your own usage** and know better than our estimate.

A figure you supply is trusted and used as-is. We stop reading the recipient, and `recipient_state` comes back `unknown`.

### `FAILED-OUT_OF_ENERGY`

The transaction started, ran out of energy part-way through, and reverted. **The fee is still consumed.** This is the failure mode that costs money and delivers nothing, and it is almost always one of two things:

1. **The wallet had some energy, but not enough.** Partial energy is worse than none: TRON starts the transfer, spends what is there and reverts. Rent the whole amount, not the shortfall you estimated.
2. **The recipient turned out to be new to the token.** You budgeted 64,285 and it needed 130,285. This is exactly what leaving the sizing to us prevents.

### Bandwidth is a separate resource

Energy pays for computation. **Bandwidth** pays for the number of bytes the transaction occupies in a block. A transfer consumes both — roughly 345 bandwidth alongside its energy.

This API rents **energy only**.

Bandwidth is cheap, and every TRON account gets a free daily allowance that covers a handful of transfers, so most callers never think about it. But a wallet with **no allowance left and no TRX** will still fail even with energy delegated to it. A fraction of a TRX on the sending wallet clears that permanently.

{% hint style="warning" %}
If a transfer fails with energy delegated and plenty of it unused, check bandwidth before you check anything else.
{% endhint %}

### The address must be activated

Energy cannot be delegated to an account the chain has never seen. An address that has never received anything is not yet activated, and we refuse the order with `ADDRESS_NOT_ACTIVATED` **before charging you** rather than selling a delivery that cannot happen.

[`POST /v1/activate`](/api-reference/activate.md) does it for you, or send the address about 1 TRX yourself.

### Rentals expire

Energy is delegated for the window you asked for and returns to us at the end of it. There is no carry-over and nothing to cancel; anything unused is simply reclaimed.

Rent for the window you actually need. A longer one costs more and buys time you will not use — for a single transfer, one hour is generous.

| `duration_sec`   | Typical use                     |
| ---------------- | ------------------------------- |
| `3600` (default) | One transfer                    |
| `86400`          | A day's batch                   |
| `259200`         | A steady flow over several days |

### When renting is not worth it

Renting is only worth anything while it is cheaper than burning. If the energy market moves far enough that our price would reach what the chain charges, we **refuse the sale** with `NOT_WORTH_RENTING` rather than take your money to leave you no better off.

Treat it as a signal, not an error: let the transfer burn TRX this time and try again later. The market moves through the day.