← All articles

Technology

Stake 2.0: TRON's Resource Model Explained

PUBLISHED │ READ~13 min │ BYTRONORIGIN

staking resources stake-2 tip-467

TRON’s fee model is not quite like anything else in the public blockchain space. Most chains charge a single native-token fee per transaction. TRON uses two separate resource types — Bandwidth and Energy — that users can either acquire through staking or cover on the spot by burning TRX. The system sounds unusual until you understand the economics behind it, and once you do, the on-chain patterns it produces become some of the most useful signals in an investigator’s toolkit.

This article explains both resources, the staking mechanics that produce them, and the 2023 Stake 2.0 upgrade that changed how delegation, unstaking, and lock periods work. The final section ties the mechanics to what investigators can actually read from the chain.

Bandwidth and Energy — TRON’s two resources

Every transaction on TRON costs something. What it costs, and in which resource, depends on what the transaction does.

Bandwidth covers transaction byte size. One byte of serialized transaction data requires one unit of Bandwidth. Every transaction on TRON — TRX transfers, smart contract calls, staking operations, account activation — consumes Bandwidth. The amount varies with the size of the transaction payload: a simple TRX transfer is smaller and cheaper than a smart contract call with complex parameters.

Energy covers smart contract execution. When a transaction triggers code in the TRON Virtual Machine — whether a USDT transfer, a DeFi swap, or any other contract interaction — the execution of that code consumes Energy proportional to its computational complexity. Energy is the TRON equivalent of Ethereum gas, scoped specifically to smart contract work. Pure TRX transfers do not consume Energy at all.

The reason TRON uses two resources rather than one fungible “gas” is architectural. Bandwidth is cheap, predictable, and driven mainly by data volume. Energy is more variable, tied to computational load, and more expensive per unit in TRX terms when burned (Energy burns at 0.0001 TRX per unit; Bandwidth at 0.001 TRX per unit). Separating them lets high-volume smart contract users stake specifically for Energy without subsidizing byte-heavy transactions, and vice versa.

One baseline detail: every activated TRON account receives 600 free Bandwidth units per day with no staking required, covering occasional simple TRX transfers at no cost. Energy has no free daily allocation.

Why stake TRX in the first place

Staking TRX is how TRON users acquire Bandwidth and Energy in bulk. The mechanism works proportionally: the fraction of TRX you have staked against the total network-wide stake determines the fraction of the daily resource pool you receive.

  • Bandwidth pool: 43,200,000,000 units per day, distributed proportionally to all stakers who staked for Bandwidth.
  • Energy pool: 180,000,000,000 units per day, distributed proportionally to all stakers who staked for Energy.

Both resources regenerate fully over 24 hours after consumption — not in a single midnight reset, but continuously and linearly at the block level as new blocks are produced.

If a transaction exhausts the resources available to an account, TRON automatically burns TRX as a fallback fee to cover the deficit. The burn rate is 0.001 TRX per unit of Bandwidth and 0.0001 TRX per unit of Energy. For a light user sending occasional TRX transfers, the free daily 600 Bandwidth units are often enough and the fallback burn covers anything extra. For high-volume users — addresses doing dozens or hundreds of USDT transfers daily — the cumulative burn cost is substantial, making staking economically necessary.

This is why resource delegation is such a useful investigative signal. An address that consistently funds another address’s operations through delegated Energy or Bandwidth is covering real, ongoing cost. That is an active financial relationship, not an artifact of exchange infrastructure.

Stake 1.0 vs Stake 2.0

The original staking mechanism — informally called Stake 1.0, using FreezeBalanceContract — had a structural limitation: staking and resource type were coupled in a single operation. When you froze TRX under Stake 1.0, you had to declare at freeze time whether you wanted Bandwidth or Energy. Changing your mind required unfreezing first — which triggered a 3-day lock period — then re-freezing for the other resource type. You could delegate resources to one recipient only, and you could not delegate a partial amount separately from your full staked position.

In practice, Stake 1.0 also conflated two separate functions: acquiring resources and acquiring voting power (TRON Power). Both came from the same freeze operation, so users who wanted resources got votes, and users who wanted votes got resources, whether they intended to or not.

Stake 2.0, implemented via FreezeBalanceV2Contract and UnfreezeBalanceV2Contract (new contract types introduced by TIP-467), decouples these operations:

  • Staking and delegation are now independent. Freeze once, then delegate resources to multiple recipients independently, in any amounts, without re-staking.
  • Partial unstaking is supported. You can unfreeze a specific TRX amount without touching the rest of your staked position.
  • Delegation can be changed without unstaking. Resources can be re-delegated to a different recipient without first going through an unfreeze cycle.
  • Voting power is now explicitly separate. Staking for Bandwidth or Energy does not automatically grant TRON Power for voting; staking explicitly for votes is a distinct action.
  • Unstaking carries a waiting period. After initiating an unstake (UnfreezeBalanceV2Contract), the TRX enters a 14-day window before it can be withdrawn via a separate WithdrawExpireUnfreezeContract claim transaction.
  • Up to 32 unstaking operations can run concurrently. Stake 1.0 had no comparable flexibility.

One important backward-compatibility note: Stake 1.0 positions were not invalidated by the upgrade. Resources and votes obtained under Stake 1.0 remained valid after April 7, 2023. But Stake 1.0’s delegation model (which required re-staking to change recipients) could not be carried forward — only Stake 2.0 staked TRX can be delegated under the new model.

The four key TIPs

Four TRON Improvement Proposals define the Stake 2.0 system. They are worth knowing individually because they activated at different times and added distinct capabilities.

TIP-467 — Stake 2.0 design (proposed September 28, 2022; status: Final). The core proposal establishing the new staking model. TIP-467 introduced the separation of staking from delegation, partial unstaking, multi-recipient delegation, and the N-day unstaking wait window (where N is a network governance parameter). It also specified six new TVM opcodes (FREEZEBALANCEV2, UNFREEZEBALANCEV2, DELEGATERESOURCE, UNDELEGATERESOURCE, CANCELALLUNFREEZEV2, WITHDRAWEXPIREUNFREEZE) and the corresponding HTTP APIs, enabling smart contracts to interact with the staking system directly for the first time.

TIP-519 — Enable Stake 2.0 (activation proposal; status: Final). The on-chain governance proposal that actually activated Stake 2.0 on mainnet. TIP-519 set two network parameters simultaneously: parameter No. 59 (ALLOW_TVM_VOTE, set to 1) enabling contract-level vote operations, and parameter No. 70 (UNFREEZE_DELAY_DAYS, set to 14) establishing the 14-day unstaking window. The proposal was created April 4, 2023 and took effect April 7, 2023 at 17:00 UTC — the live date for Stake 2.0 on TRON mainnet.

TIP-541 — Cancel unstaking (created May 5, 2023; status: Final). Added the wallet/cancelallunfreezev2 API, allowing users to cancel all in-progress unstaking operations during the 14-day waiting period. Before TIP-541, initiating an unstake was irrevocable: if a user changed their mind or made an error, they had no option but to wait the full 14 days. Cancel-unstaking restores the TRX to its staked state and resumes resource and voting-power accrual. The feature is purely additive — it does not affect existing unstaking operations.

TIP-542 — Customizable delegation lock period (created May 12, 2023; status: Final). Added a lock_period parameter (measured in blocks) to the wallet/delegateresource API. Under Stake 1.0, delegated resources carried a fixed 3-day lock before the delegator could undelegate. TIP-542 replaced the fixed lock with a configurable block count — the delegator sets the lock at delegation time. The backward-compatible default (when lock is true and lock_period is 0) retains the original 86,400-block equivalent of the 3-day window. Custom lock periods enable bilateral resource-leasing agreements, where both parties can specify the terms on-chain at delegation time.

Delegation: when address A funds address B’s resources

Resource delegation is the single most investigator-relevant feature of Stake 2.0.

When address A stakes TRX and delegates Energy or Bandwidth to address B, address B can execute transactions as if it had staked itself — the resource consumption is drawn against A’s allowance, and the cost falls on A, not B. B pays nothing, and need not hold any staked TRX.

Several constraints bound delegation:

  • Only resources staked under Stake 2.0 (FreezeBalanceV2Contract) can be delegated. Stake 1.0 positions are ineligible.
  • Only unused resources can be delegated. Resources already being consumed by A’s own transactions are unavailable.
  • A can delegate to multiple recipients in varying amounts, independently.
  • Delegation events appear on-chain as DelegateResourceContract transactions. Undelegation appears as UnDelegateResourceContract. Both are attributable to the delegating address.

The investigative implication is direct. Exchanges serve millions of users from shared custody wallets — per-user resource delegation is economically impractical at that scale. Exchanges do not delegate Energy or Bandwidth to individual accounts. The only addresses that delegate are those with a specific operational reason to fund a particular wallet: a controller subsidizing a receiving address, a business covering a counterparty’s costs, or an operator maintaining a working address in the field.

A consistent delegation relationship — address A repeatedly delegating to address B, with B’s transactions consuming that resource — is one of the strongest ownership signals available in TRON on-chain data. It represents a sustained economic commitment to a specific address, visible and attributable for every delegation and undelegation event.

The 14-day unstaking window

The 14-day unstaking period is set by network parameter No. 70 (UNFREEZE_DELAY_DAYS). It is a governance parameter — the value can be changed through an on-chain proposal approved by the active Super Representatives — but it has remained at 14 since Stake 2.0 activation.

What the window looks like on-chain:

  1. The staker broadcasts an UnfreezeBalanceV2Contract transaction specifying the TRX amount and resource type to unstake. This transaction is the signal that unstaking has begun. The TRX is immediately removed from the staked balance and the associated resource allocation shrinks.
  2. For 14 days, the TRX sits in an intermediate state — neither staked nor freely available. During this period, TIP-541’s cancel-unstaking operation can reverse it.
  3. After 14 days, the staker broadcasts a WithdrawExpireUnfreezeContract transaction to claim the TRX back to their liquid balance. This claim transaction is the on-chain evidence that the unstaking completed.

The before/after boundary of April 7, 2023 matters when reading historical transaction records. Prior to Stake 2.0, unstaking used UnfreezeBalanceContract (Stake 1.0) with a 3-day lock and no intermediate window visible as a separate transaction. Post-Stake 2.0, the two-step pattern (UnfreezeBalanceV2Contract + later WithdrawExpireUnfreezeContract) is the standard form. When reconstructing a wallet’s staking history that spans the upgrade date, the contract types distinguish which era the transaction belongs to.

There is also a Stake 1.0 behavior that has no Stake 2.0 equivalent: under the old model, unstaking TRX immediately revoked all votes from the account, regardless of which resource type you were unstaking. Stake 2.0 proportionally removes only the votes backed by the unstaked TRX, leaving the rest intact. This distinction matters when reading vote-weight changes in wallets that transitioned through the upgrade period.

What this means for investigators

The resource model generates a specific set of on-chain signals that reward close attention.

Delegation patterns are ownership signals. A DelegateResourceContract transaction is an explicit act: the sender is choosing to fund a specific recipient’s transactions. A recurring delegation from the same source to the same target — especially Energy delegations covering USDT contract calls — is among the strongest candidate-ownership indicators on TRON. The relationship is asymmetric (A covers B’s costs), directional (attributable to A), and persistent (each re-delegation is a new on-chain event).

Fueling patterns extend the picture. Related but distinct: some wallets fund others not through resource delegation but through small TRX transfers sized to cover fallback burn costs. Identifying the address that routinely tops up a wallet’s TRX balance just before high-value USDT moves points to the same conclusion — operational control. See /learn/fueling/ for the dedicated deep-dive.

Unstaking withdrawals confirm active management. A WithdrawExpireUnfreezeContract transaction shows a wallet’s operator initiated an unstake and returned 14 days later to claim. This is deliberate behavior. A wallet that was abandoned or transferred mid-period is unlikely to complete the two-step sequence cleanly.

Contract types date the activity. FreezeBalanceContract (Stake 1.0) places activity before April 2023; FreezeBalanceV2Contract places it after. This matters when interpreting delegation events and vote-weight changes across the upgrade boundary.

The 14-day window creates a predictable delay. Large unstaking operations just before significant outbound transfers may indicate deliberate liquidity staging — the unstake is the preparatory step, and the 14-day gap is visible in the record.

The full analysis of delegation and fueling patterns — including their role in TRONORIGIN’s Phase 2 scoring — is in /learn/fueling/.

Sources

Primary documentation and data sources used for the facts in this article: