The Stake 2.0 Switch: How TRON Drew a Line Through Its Own Ledger

Most protocol upgrades blur the records on either side of them. Stake 2.0 drew a clean line. Every TRXThe native coin of the TRON network. TRX settles value directly (no contract call needed), is staked to obtain Energy, Bandwidth, and voting power, and is burned to pay fees when staked resources fall short. Its smallest unit is the sun: 1 TRX = 1,000,000 sun. stake created before it used one contract type and one set of rules; new stakes after it use a different contract type, decouple stakingLocking TRX (historically called freezing) to obtain network resources instead of paying fees per transaction — a stake earns either Energy or Bandwidth, chosen at stake time. Staking also grants TRON Power for Super Representative voting, at one vote per staked TRX, making a wallet's stake both its fee budget and its governance weight. from delegation, and unstake on a different clock.

That line has a precise date and a paper trail, and both matter for investigative work. When you read a wallet’sSoftware or hardware that stores private keys and uses them to sign transactions. A wallet holds keys, not coins — balances live on the ledger itself — so the same funds can be reached from any wallet loaded with the same keys, and losing the wallet loses nothing if the keys are backed up elsewhere. resource history — what it froze, what it delegated, when it unstaked — the Stake 2.0 boundary tells you whether you are looking at the old model or the new one, and the staged way the switch happened explains why some accounts straddle both. This article covers how the switch was specified and activated, and what it left on each side.

What Stake 1.0 locked together

The original staking model ran on a single contract, FreezeBalanceContract. Staking TRX and delegating the resulting resources were bound together: to change who received your delegated EnergyA TRON network resource that meters the computational cost of smart-contract execution, consumed whenever a transaction calls contract code — including TRC-20 token transfers such as USDT. An account obtains Energy by staking TRX or receiving a delegation from another account; if it holds too little, the shortfall is paid by burning TRX from its balance. or BandwidthA TRON network resource that covers the byte-size cost of putting a transaction on chain — one byte consumes one Bandwidth point. Every account receives a small free daily allowance (also called free bandwidth); heavier usage requires staking TRX, receiving a delegation, or burning TRX to cover the bytes., you had to re-stake.

It had a sharper edge for anyone reading votes. Unstaking any frozen TRX under Stake 1.0 revoked all of an account’s votes at once, even when only part of the stake was being withdrawn. Resource management and governance weight were entangled in a way that made partial moves impossible.

That rigidity was the motivation for a redesign. TIP-467, the proposal that became Stake 2.0, opens on exactly this limit: “the stake and delegating operation are bound together at present.” The fix was to pull the two apart. That required new contract types, and the new contract types created the discontinuity in the record.

A staged activation

The process ran for roughly six months.

It began as a specification. TIP-467, “Stake 2.0 — A new TRON staking model,” was created on September 28, 2022 and carried through the TRON Improvement Proposal process to Final status. A TIP is a design document; it defines what the network could do once the code ships and the network agrees to turn it on.

The code came in the java-tron client release GreatVoyage-v4.7.0.1 (Aristotle), announced January 16, 2023, which introduced the Stake 2.0 implementation. The release announcement is explicit that shipping the code did not activate the feature: “after GreatVoyage-v4.7.0.1 (Aristotle) is deployed, it is disabled by default and can be enabled by initiating a proposal vote.” For nearly three months, every node on the network could run Stake 2.0 — and none of them did, because the network had not voted to switch it on.

The final step was the vote. TIP-519, recorded as a governance proposal, requested enabling Stake 2.0 and set two network parameters: ALLOW_TVM_VOTE (No. 59) to 1, allowing smart contractsA program deployed to a blockchain that runs deterministically when called, holding its own state and balance and enforcing its rules without any operator's ongoing involvement. Because a contract executes code rather than acting on anyone's initiative, its address represents logic — funds can flow through it, but the contract itself is not a person or a controlling entity. to stake and vote, and UNFREEZE_DELAY_DAYS (No. 70) to 14, fixing the new unstaking wait at fourteen days. The proposal’s effective date is stated in the TIP-519 record itself: “the effective time of voting request: 7th April 2023.” Two follow-on proposals tuned the model the next month — TIP-541 (May 2023) added the ability to cancel an in-progress unstake, and TIP-542 (May 2023) made the delegation lock period, previously a fixed three days, customizable.

The capability sat in the code from January; the chain crossed into Stake 2.0 only at the moment the governance parameter flipped. That gap between shipping and switching is why the boundary is so clean.

The hard cutover

The date holds as a hard boundary because of what happened to the old model when TIP-519 took effect: it closed, with no gradual deprecation.

The TIP-519 record states the cutover directly: “after the proposal takes effect, the Stake 1.0 staking API will return the error message ‘freeze v2 is open, old freeze is closed’.” From that point, no new Stake 1.0 freeze could be created on the network at all. The old FreezeBalanceContract path for new stakes was shut.

The cutover was not retroactive, and that asymmetry is the part an investigator has to hold onto. Existing Stake 1.0 positions were grandfathered. As TIP-519 puts it, “the resources already staked and obtained under Stake 1.0 and the votes on the chain are still valid and will not change, and the assets can be redeemed using the unstake method of Stake 1.0.” So the boundary runs one way: after April 7, 2023, no account could create a new Stake 1.0 freeze, but accounts holding legacy 1.0 positions could — and still can — unstake and withdraw them using the old methods. A Stake 1.0 unstake event dated 2024 is a legacy position being unwound, long after new ones became impossible.

What changed underneath

The new model’s mechanics are the subject of the Stake 2.0 resource model article, and the present-day reading of delegation as an ownership signal belongs to fueling and fee provision. For the history, three structural changes matter because each one introduced a new contract type or behavior that appears only on the post-boundary side.

Staking and delegation were decoupled. Under Stake 2.0 a user freezes once and can then delegate to multiple recipients independently, and re-delegate without re-staking — the rigidity TIP-467 was written to remove. Unstaking became partial and delayed: an account can run multiple simultaneous unstaking operations and, after the fourteen-day wait, call a separate withdrawal to recover the TRX. And staking gained smart-contract access through new TVM opcodes, enabled by the ALLOW_TVM_VOTE parameter in TIP-519: contracts could now perform staking operations that had been available only to ordinary accounts.

Each of these runs on FreezeBalanceV2Contract, UnfreezeBalanceV2Contract, and the delegate/undelegate contract types — names that did not exist on-chain before the Aristotle client and were not used on the network before April 7, 2023.

The boundary an investigator reads

The payoff is a dating tool that needs no external data. The contract type a stake uses places it on a side of the line.

FreezeBalanceContract is Stake 1.0. FreezeBalanceV2Contract and UnfreezeBalanceV2Contract are Stake 2.0. A new freeze using the old contract type cannot have been created after April 7, 2023, because the network stopped accepting them. A freeze using the V2 contract type cannot have been created before the Aristotle client made it possible. The contract name carries a timestamp’s worth of information on its own. As the origin and architecture of TRON notes, the Stake 2.0 transition is a real boundary for reading older versus newer records. This is the mechanism behind that line.

Two cautions keep the boundary honest. One is the asymmetry: seeing a Stake 1.0 unstake in 2024 tells you a legacy position was being closed, not that someone created an old-style stake after the cutover. The other is the entanglement Stake 1.0 carried — unstaking revoked all votes at once — so pre-boundary governance and resource history move together in ways post-boundary records do not. Reading a wallet that staked before April 2023 and kept operating after it means reading two different rule sets in one history, with the contract types marking where one ends and the other begins.

Sources

Primary records used for facts in this article:

• TRON Improvement Proposals. “TIP-467: Stake 2.0 — A new TRON staking model” — The specification itself: the September 28, 2022 creation date, Final status, the coupled-staking limit it was written to remove, and the decoupled-delegation, partial-unstaking, and TVM-opcode design. Primary protocol record.
• TRON Improvement Proposals. “TIP-519: Proposal to enable Stake 2.0” — The on-chain activation record: the April 7, 2023 effective date, the ALLOW_TVM_VOTE (No. 59) and UNFREEZE_DELAY_DAYS (No. 70 = 14) parameters, the “freeze v2 is open, old freeze is closed” cutover, and the grandfathering of existing Stake 1.0 positions. Primary protocol record (canonical TIP-519 issue; TIP-519 has no committed .md file).
• TRON Core Devs. “Introduction of GreatVoyage-v4.7.0 (Aristotle)” (January 16, 2023) — The protocol team’s own release announcement (the Aristotle series; the specific Stake 2.0 build is v4.7.0.1): Stake 2.0 shipped in the client but “disabled by default” pending a proposal vote. Primary project record (protocol team’s release channel).
• TRON Improvement Proposals. “TIP-541” (May 2023) and “TIP-542” (May 2023) — The two post-activation refinements: cancellable in-progress unstaking, and a customizable delegation lock period replacing the fixed three-day lock. Primary protocol records.
• TRON Developer Hub. “Stake 2.0 overview” — Official protocol documentation for the persistence of Stake 1.0 after the upgrade: “TRX staked through the legacy Stake 1.0 mechanism (in use before April 2023) is still valid and can be unstaked through the Stake1.0 related API.” Primary protocol reference.
• TRON Developer Hub. “System contract types” — the contract-type identifiers and their enum numbers, naming FreezeBalanceContract, FreezeBalanceV2Contract and UnfreezeBalanceV2Contract.
• balance_contract.proto — tronprotocol/protocol — the protocol definition of FreezeBalanceContract (owner_address, frozen_balance, frozen_duration, resource, receiver_address) — the message type this chapter names. Protocol-authoritative: a contract type is either declared in core/contract/ or it does not exist.

A note on sourcing: the activation date (April 7, 2023) is taken directly from the TIP-519 proposal record rather than from any secondary recap. The exact time of day the proposal took effect is not stated in that record and is omitted here rather than asserted. Scoring weights the project assigns to each stake type are deliberately left out of this article — it documents the historical boundary, not the current heuristicA behavior-based rule used to infer facts a blockchain does not state directly — for example, that addresses spending together, or all draining into one collector, share a controller. Heuristics can be highly reliable when the pattern is strong, but they produce inferences with known failure modes, never proof, so their conclusions should carry confidence levels and survive cross-checking.; see Stake 2.0 resource model and fueling for the present-day mechanics.