How Do I Claim TRON Staking Rewards From a Contract?

A TRON contract can claim voting rewards with the TVM’s built-in reward function. For an integrator, the key distinction is that this is a smart-contract execution: the contract needs eligible rewards, and the account sending the call must cover its network resources. The TVM runs the contract code, consuming Energy; if the caller has too little, TRX can be burned to cover the shortfall. TRON energy can be delegated to the calling wallet so it can make the claim without staking TRX itself. tronenergy.dev is one way to obtain that delegated resource for a wallet.

Check that the contract can claim rewards

The contract needs voting rewards attributable to its own account. TRON rewards are tied to votes for eligible Super Representatives (SRs) or SR Partners; check the contract address’s votes and claimable reward before sending a state-changing call. A read-only query can inspect the account’s reward without spending Energy.

There are two claim paths that are easy to confuse. An account can withdraw rewards through the protocol’s WithdrawBalanceContract transaction; a contract can call the TVM built-in withdrawreward(), which claims accumulated voting rewards to the contract balance. The latter runs contract code and therefore uses Energy.

Submit the contract claim with enough resources

Follow these steps to prepare and verify the transaction. The example figures are illustrative: actual execution cost depends on the contract wrapper and current chain parameters.

1. Read the contract’s state. Confirm that it has votes and a claimable reward, and check when it last claimed. A repeat withdrawal inside the protocol’s 24-hour interval may be rejected, so avoid submitting a claim just because a scheduler fired.
2. Call the claim function. Have the contract invoke withdrawreward() from its own execution path. The reward is credited to the contract’s TRX balance, not automatically to the user who called it; add a separate, deliberate payout step if your application needs to distribute funds.
3. Estimate Energy and set a cap. Simulate the exact call with an Energy estimate, then set fee_limit high enough for the caller’s expected share while keeping a sensible maximum. The WITHDRAWREWARD opcode has a 20,000-Energy base cost; at 100 sun per Energy, that portion alone would cost 2 TRX if paid entirely by burn. Wrapper logic can raise the total, so use the estimate rather than treating 2 TRX as the full claim price.
4. Fund the caller’s resources. Check available Energy and Bandwidth for the wallet that broadcasts the contract call. Delegated TRON energy can cover execution without staking TRX yourself; if Energy is short, the network may burn TRX from the caller, subject to fee_limit.
5. Verify the result on-chain. After confirmation, inspect the transaction result and contract balance, then re-read claimable rewards. A successful transaction with no balance change warrants checking the contract’s voting address and reward eligibility before retrying.

Handle the claim as a two-part operation

Separate claiming from paying out: first confirm the protocol reward reached the contract, then apply your application’s own authorization and accounting rules to any transfer. In practice, I’d test the claim path against a contract account with known votes and record the estimated Energy, actual usage, and result. Your next step is to query the intended contract’s reward state and simulate the exact call before scheduling it in production.