API docs live on docs.eopen.io

Use the external docs as the source of truth for endpoints, fields, auth, and migration notes. Open API docs →

EOPEN

TRON Energy API for Wallets

Add automated Energy rental to custodial wallets, browser wallets, and wallet service backends so users do not have to buy TRX for every USDT transfer.

Plan wallet integration

Energy Rental Built Into Wallet UX

Fewer failed transfers, fewer fee complaints

Wallet teams can use EOPEN to prepare Energy for sending addresses, abstract fee complexity, and keep TRC-20 transfers smooth for users.

Any TRON
Sending address
65K / 131K
Recommended packs
Webhook
Status updates
No custody
Keys stay yours

Wallet Integration

Fee abstraction

Let users send USDT without learning Energy, Bandwidth, burn rates, or recipient-state rules.

Address-level delegation

Delegate Energy to the actual sending address, whether the UI is custodial, MPC, or self-custody.

User support relief

Reduce tickets about missing TRX, failed transfers, and confusing fee previews.

01

Wallet users do not think in Energy

Most users only want a USDT transfer to go through. If they are forced to buy TRX or guess the right fee, the wallet experience feels broken.

  • Existing-recipient transfers typically fit a 65K Energy pack.
  • Cold-recipient transfers typically need a 131K Energy pack.
  • The wallet can decide the pack and call EOPEN behind the scenes.
02

Integration model

Your wallet backend detects a TRC-20 transfer, requests Energy for the sender, waits for confirmation, and then lets the signed transfer proceed.

  • Works for custodial hot wallets and wallet-service backends.
  • Can support user-paid, platform-paid, or bundled fee models.
  • Webhook callbacks simplify UI and customer support states.
03

Sponsoring the first transfer pays for itself

The fastest way to lose a new user is a failed first send: they fund USDT, hit send, and TRON rejects it because the wallet holds no TRX for the ~64,285 Energy a transfer needs. Covering that first transfer costs you about 1.5 TRX in rented Energy — a rounding error against an activated account's lifetime value. Every transfer that just works is also a support ticket that never opens, removing an entire category of "why did my transfer fail?" contacts and the burden of explaining staking to non-technical users.

  • Warm send: ~64,285 Energy, sponsored for ~1.5 TRX.
  • Self-custody UX as smooth as custodial, without holding keys.
  • Fewer "no TRX / transfer failed" tickets and less gas education.

Next steps

Wire rental behind your send flow so a user's first transfer just works for about 1.5 TRX — with zero Energy or gas concepts exposed.

Core API flow

  1. 1Authenticate your wallet backend with the wallet app's API key.
  2. 2On a detected TRC-20 send, request an Energy quote for the user's address (about 65,000 Energy per transfer).
  3. 3Submit the rental on the user behalf and wait for the delegation confirmation.
  4. 4Let the user signed transfer confirm with no gas concepts ever shown.
View the full API integration page

Wallet FAQ

Does rented Energy depend on the wallet app?

No. Energy is delegated to the TRON address. The wallet app controls how the user sees and signs the transfer.

Can we hide this from users?

Yes. Wallets can present a simple network fee while handling Energy rental in the backend.

Can EOPEN help with cold-address transfers?

Yes. Cold-recipient USDT transfers can use the larger 131K Energy pack when needed.

Migration & verifiability

Why do I see different field names in old docs vs new docs?

Field naming and migration details are maintained on docs.eopen.io. This page keeps only the wallet scenario overview.