A contract owner can subsidize only a configured share of a call, up to a per-call cap and the Energy they have available. If a call is pending, wait for its execution receipt before diagnosing the charge; if it failed, check the receipt and contract settings to see whether the subsidy was absent, too small, or exhausted.
How does the contract split Energy?
The contract’s consume_user_resource_percent sets the caller’s percentage of the Energy bill, from 0 to 100. At 60, the caller is assigned 60% and the contract deployer is assigned 40%; at 100, the caller pays all of it. The setting belongs to the contract, so a caller cannot change it for one transaction.
The deployer’s actual contribution is the smallest of three amounts: its theoretical share, the contract’s origin_energy_limit, and the deployer’s currently available staked Energy. Any gap between that contribution and the promised share moves back to the caller. In other words, a percentage is a target split, not a guarantee that the deployer has reserved enough resource.
For example, suppose execution uses 80,000 Energy, the caller share is 60%, and the deployer has an origin limit of 25,000 Energy. The deployer’s theoretical share is 32,000, but its cap limits the contribution to 25,000. The caller therefore bears 55,000 Energy: their original 48,000 plus the 7,000 shortfall.
Why can a call still burn TRX or fail?
The caller first covers their share with available Energy. Any remaining amount can be paid by burning TRX, subject to the transaction’s fee_limit, which is expressed in sun. At the current 100 sun per Energy, a 40,000-Energy shortfall corresponds to 4,000,000 sun, or 4 TRX; the applicable chain price can change, so treat that conversion as an example and check the current parameter.
If the caller’s required share exceeds the Energy and TRX budget allowed by fee_limit, execution can end with OUT_OF_ENERGY. The fee limit caps the caller’s Energy budget, including Energy drawn from their stake; it does not increase the deployer’s share or force the deployer to contribute. Consumed Energy is not refunded just because execution later fails.
Energy estimates can also change with contract state, call arguments, and the contract’s dynamic Energy factor. A transfer to a new recipient, for example, may cost differently from one to an address that has already received the token. Estimate the actual call shortly before sending, then leave enough fee-limit headroom for the caller’s possible share.
What should I check while my attempt is pending?
A transaction body or broadcast acknowledgement is not an execution result. Look up the transaction ID in TRONSCAN and wait for its on-chain receipt before submitting again; the receipt is where execution status, Energy usage, fees, and the deployer’s Energy usage can be inspected. A missing receipt means the outcome has not yet been established, not that the subsidy has failed.
Once a receipt exists, compare total Energy with the caller and origin usage fields, plus the result and fee. A successful call with a TRX fee can mean the deployer hit its cap or ran short of Energy. A failed call marked OUT_OF_ENERGY points to an insufficient caller budget after the actual split; a contract revert is a different execution failure, even though it may still consume Energy.
For a call into a contract you do not control, such as a USDT TRC-20 transfer, you generally cannot ask its deployer to change the split for your transaction. If your wallet lacks enough resource for the caller’s share, obtaining TRON energy for that wallet can reduce the amount of TRX burned; TRON energy service is one way to obtain or rent that resource without staking TRX yourself.
What can a contract owner tune?
The owner can change consume_user_resource_percent with an update-setting transaction and origin_energy_limit with an update-energy-limit transaction. Those updates affect later calls; they do not rewrite an already broadcast transaction’s execution conditions. TRONSCAN’s contract information can help verify the current configuration, while the transaction receipt shows what was actually consumed.
Lowering the caller percentage improves the user experience but exposes the deployer to higher resource demand. Setting it to zero means the deployer intends to cover all Energy, yet the limit and available stake still constrain the real contribution. An origin limit is therefore a per-call risk control, while the deployer’s stake is the finite pool that supports subsidies across many callers.
When I diagnose a failed or unexpectedly costly attempt, I start with the receipt, then compare the contract split and cap with the call’s actual Energy use and the caller’s fee limit. That sequence tells you whether to wait, adjust the transaction budget, obtain resource, or recognize that only the contract owner can change the subsidy policy.
Can I set the contract subsidy on my own transaction?
No. The percentage and origin limit are contract-level settings controlled by the deployer. A caller can set their own fee limit and arrange Energy for their wallet, but cannot compel an unrelated contract to pay more of a call.
Does a 0% caller share guarantee a free call?
No. It expresses a full deployer share, but the per-call origin limit and available staked Energy still constrain payment. If either is insufficient, the uncovered amount falls to the caller and can consume their fee limit or cause OUT_OF_ENERGY.
Should I resend a transaction that has no receipt yet?
First check its transaction ID and wait for an execution receipt. The transaction body alone does not confirm success or failure. Sending a duplicate before the original outcome is clear risks making the same call twice if the first transaction later executes.
Top comments (0)