How to Supply Energy to a Pool of Hot Wallets Instead of a Single Address

Short answer: in TRON you cannot "supply energy to a pool" in a single operation — delegation is always per address. A pool is served by a series of delegations from one staking account: each request carries its own receiver_address, while on your side you maintain a registry of hot wallets, idempotency keys, and confirmation of every allocation. The TRX itself stays staked with the delegator; only the right to use the resource is passed to the recipient.

Why a pool means N delegations, not one

In Stake 2.0, staking and delegation are independent operations: once TRX is frozen, you lend the resulting energy to another account without unstaking. This is exactly how exchange and DApp operators cover resource costs from a single pool.

What to build into the architecture from the start:

• the recipient must be an EOA — delegation to a contract address is rejected ("Do not allow delegate resources to contract addresses");
• the recipient account must already exist, so new pool addresses need to be activated in advance;
• the minimum amount is 1 TRX (1,000,000 sun), you cannot delegate to yourself, and TRON Power is not delegatable — only BANDWIDTH or ENERGY;
• the balance field is the TRX equivalent in sun, not an amount of energy: 100,000,000 sun grants whatever energy 100 TRX of stake produces at that moment.

The last point is the main source of billing discrepancies. Your share of the network-wide cap of 180,000,000,000 energy depends on the total volume staked for energy, so "100 TRX" today and a month from now mean different amounts of resource.

How to distribute across a pool of addresses via API

The integration loop:

1. Request per address. /wallet/delegateresource: receiver_address (Base58/HEX), balance in sun, resource: ENERGY, lock, Permission_id; revocation via /wallet/undelegateresource. With a rental provider the same thing takes the form of an order: address, volume, term → order id, status, txid.
2. Retries without double charging. Use an "address + task" key: after a timeout, query the order status first; retry only on an explicit error.
3. Errors and limits. An unactivated address, a contract recipient, a volume below the minimum lot, an exhausted /wallet/getcandelegatedmaxsize — quarantine the address; a rate limit — queue with backoff. A pool hits the orders-per-minute limit and the minimum lot before it hits the budget; energy prices drop as volume and rental term grow.
4. Reconciliation. The txid from the webhook records the allocation, while /wallet/getdelegatedresourcev2 and the delegation index catch mismatches between your registry and the chain.

Before distributing, check getcandelegatedmaxsize: you can delegate no more than "staked balance minus current consumption" within the 24-hour recovery window. If the pool has just been spending energy heavily, the available volume will be lower than expected.

Sizing: how much energy an address needs

The per-address target is the number of transfers until the next top-up, multiplied by the cost of a single transfer. There is no fixed constant for USDT TRC-20 (recipient slot, multiplier of 1×–4.4×), so measure consumption by simulation: wallet/triggerconstantcontract (returns energy_used) or wallet/estimateenergy (energy_required). The upper bound on cost is known: without energy, each unit is burned at 100 sun.

lock_period pitfalls during pool rotation

• lock_period is specified in blocks, not seconds: 86,400 blocks ≈ 3 days. An order-of-magnitude mistake freezes the pool's stake.
• The maximum is capped by chain parameter #78; pull the current value from wallet/getchainparameters.
• Re-delegating to the same address within the lock period resets the lock countdown. For hot wallets that are topped up frequently, it is better not to enable lock at all.
• The three-day lock in wallets is a UI restriction, not a protocol one: other values are available via the API.

When revoking, account for resource reclamation: along with the share of staked TRX, a proportional part of the recipient's not-yet-recovered energy is returned.

Permissions: distributing from the pool without the owner key

Grant the minimum set of rights via multi-signature and Active permissions: in the operations bitmap it is enough to enable ID 57 (DelegateResourceContract) and 58 (UnDelegateResourceContract), plus 54/55 for staking if needed; ID 46 (AccountPermissionUpdateContract) does not need to be enabled. Constraints: up to 5 keys per permission, from 1 to 8 Active permissions, Permission_id 2–9 for active. Specify the relevant Permission_id in the delegation transaction, otherwise the owner permission will be used.

Conclusion

Distributing to a pool is a matter of accounting discipline, not a special API method. What you need: a registry of activated EOA addresses, recalculation of balance in sun against the current staking yield, simulation of consumption instead of a constant, idempotency keys, and regular reconciliation with getdelegatedresourcev2. Double-check the units of lock_period separately: for rotating hot wallets, revocable delegation is usually the better deal.