How to integrate gasless transactions on Tron with 0xkey

This is a DIY orchestration guide, not a managed sponsorship product. 0xkey provides the secure keys, in-enclave Tron transaction parsing, and tron.tx.* policy control you need to build this yourself — it does not (yet) auto-insert resource delegation into a user’s signing path. See 0xkey and Tron for baseline Tron support.

Why Tron gasless is different from EVM Gas Station

Tron has no EIP-7702-style paymaster and no native sponsor: true fee-payer switch like Solana sponsorship. Tron’s fee model runs on Bandwidth and Energy, which accounts obtain by staking (freezing) TRX. Gasless UX on Tron is achieved by: Sponsor account stakes TRX for Bandwidth/Energy → delegates that resource to the end-user’s address → the end-user signs and broadcasts their own transaction, which consumes the delegated resource first.

	EVM Gas Station (`sponsor: true`)	Solana fee sponsorship (`sponsor: true`)	Tron resource delegation (this guide)
Who pays	Platform paymaster pays gas	Platform fee-payer signs as `account_keys[0]`	Sponsor wallet stakes TRX; user consumes delegated resource
Does the platform co-sign the user’s tx	Depends on flow	Yes, dual-sign	No — user signs alone
Managed by 0xkey today	Yes (Gas Station)	Yes	No — you orchestrate staking/delegation calls yourself
Consumption order	N/A	N/A	Fixed by the Tron protocol — cannot be customized

Because the mechanisms are fundamentally different, 0xkey does not (and will not) extend EIP-7702 Gas Station to Tron.

Setup guide

Fund a 0xkey-managed wallet (your organization’s own address, or a dedicated sponsor sub-wallet) with TRX, then freeze it for Bandwidth or Energy via FreezeBalanceV2:

{
  "resource": "BANDWIDTH",
  "frozen_balance": 10000000,
  "owner_address": "<SPONSOR_ADDRESS>"
}

Build this with TronWeb (or any Tron transaction builder) client-side, then sign it through 0xkey with signTransaction({ type: "TRANSACTION_TYPE_TRON" }) — see Client-side construction and signing.

TRC-20 transfers consume both Bandwidth and Energy. If your users interact with smart contracts, freeze for both resource types — freezing only Bandwidth still leaves users burning TRX for Energy.

2. Delegate the resource to end-user wallets

Once the sponsor wallet has a resource pool, delegate it to a specific user address with DelegateResource:

{
  "owner_address": "<SPONSOR_ADDRESS>",
  "receiver_address": "<END_USER_ADDRESS>",
  "balance": 1000000,
  "resource": "BANDWIDTH",
  "lock": false
}

owner_address: the sponsor wallet that staked TRX (step 1)
receiver_address: the end user’s wallet
balance: sun-denominated stake backing the delegated resource
lock / lock_period: set lock: true with a lock_period (in blocks, ~3s/block) if you want the delegation to be non-revocable for a period — otherwise you can UnDelegateResource at any time

You can delegate ahead of time (right after a user’s wallet is created) or just-in-time (query wallet/getaccountresource for the user before their first send, and only delegate if their available resource is insufficient). See the trade-offs table below.

	Pre-provisioned	Just-in-time
UX	Business transaction has no extra hop	One extra on-chain delegation + confirmation before the user’s send
Resource usage	Higher — every user holds a standing allocation	Lower — only allocated when needed
Failure surface	Concentrated in the business transaction	Delegation failure/timeout adds a new failure mode
Best for	High-activity users, small per-user caps	Long-tail users, tight pool budgets

3. End-user transaction flow

After delegation, the end user’s experience is unchanged from a normal 0xkey Tron signing flow — they sign and broadcast their own business transaction (see Client-side construction and signing). The Tron protocol automatically consumes their available resource (own stake + delegated-in resource + daily free Bandwidth) before falling back to burning TRX; this consumption order cannot be customized by 0xkey, Turnkey, or any application.

4. Reclaiming resources

The sponsor wallet can reclaim delegated resources at any time with UnDelegateResource — the end user does not need to sign or approve this:

{
  "owner_address": "<SPONSOR_ADDRESS>",
  "receiver_address": "<END_USER_ADDRESS>",
  "balance": 1000000,
  "resource": "BANDWIDTH"
}

lock: true delegations cannot be reclaimed until lock_period elapses. Resources the user has already consumed (or that are inside Tron’s 24h usage-recovery window) may not be reclaimable in full immediately — query wallet/getdelegatedresourcev2 and wallet/getaccountresource and reconcile before assuming a full recall. Split policies across the sponsor wallet and end-user wallets so a compromised user credential cannot touch the resource pool, and the sponsor role cannot sign arbitrary user business transactions: Sponsor wallet policy — allow only delegation/staking operations, capped and allowlisted:

{
  "policyName": "Sponsor: allow delegation only to allowlisted receivers, capped balance",
  "effect": "EFFECT_ALLOW",
  "condition": "tron.tx.contract[0].type in ['DelegateResourceContract', 'FreezeBalanceV2Contract'] && (tron.tx.contract[0].type != 'DelegateResourceContract' || (tron.tx.contract[0].receiver_address in ['<END_USER_ADDRESS_1>', '<END_USER_ADDRESS_2>'] && tron.tx.contract[0].balance <= 5000000))"
}

End-user wallet policy — allow only business transactions, never resource operations:

{
  "policyName": "User: allow TRX and USDT transfers only",
  "effect": "EFFECT_ALLOW",
  "condition": "tron.tx.contract[0].type == 'TransferContract' || (tron.tx.contract[0].type == 'TriggerSmartContract' && tron.tx.contract[0].contract_address == '<USDT_CONTRACT_ADDRESS>' && tron.tx.contract[0].data.startsWith('a9059cbb'))"
}

See Tron policy examples for more sponsor/user policy patterns, and the policy language reference for the full TronContract field list (resource, receiver_address, balance, lock, lock_period, frozen_balance, unfreeze_balance).

Operational notes

fee_limit still matters. Even with Energy sponsored, set a sane fee_limit on smart-contract calls — it bounds how much TRX a transaction is allowed to burn if delegated Energy runs out mid-execution. Estimate it with triggerconstantcontract before building the real transaction.
Security blast radius. A leaked end-user key lets an attacker drain the user’s delegated resource (or force TRX burn) — it cannot touch the sponsor wallet’s staked principal. Mitigate with per-user delegation caps, anomaly alerting on resource burn, and auto-UnDelegateResource for dormant accounts.
Consumption order is fixed. You cannot configure “spend the sponsor’s delegation before the user’s own stake” — Tron’s protocol always resolves available resource as one pool.
This is orthogonal to custodial send. This guide is entirely client-side resource orchestration (freeze/delegate/undelegate) — it works whether the business transaction itself is broadcast client-side or through 0xkey’s custodial tronSendTransaction. Custodial send does not yet auto-check or auto-delegate resources before broadcasting; you’re still responsible for keeping the end-user’s delegated balance sufficient.

Using a third-party paymaster instead

If you’d rather not operate a resource pool at all, some third-party services (e.g. Transatron) offer Tron fee sponsorship via their own broadcast RPC — your client signs the same way described in Client-side construction and signing, then submits the signed transaction to the third party’s endpoint instead of a standard Tron full node. This requires no 0xkey-side changes, but introduces a third-party availability, commercial, and privacy dependency that the sponsor-wallet approach above avoids. Evaluate this trade-off against your own requirements before adopting it.

Questions?

If you have questions about Tron gasless transactions on 0xkey, reach out through your usual support channel.

Get started

Products

Crypto ecosystems

Developers

How to integrate gasless transactions on Tron with 0xkey

Why Tron gasless is different from EVM Gas Station

Setup guide

2. Delegate the resource to end-user wallets

3. End-user transaction flow

4. Reclaiming resources

Operational notes

Using a third-party paymaster instead

Questions?

​Why Tron gasless is different from EVM Gas Station

​Setup guide

​1. Stake TRX for resources (sponsor wallet)

​2. Delegate the resource to end-user wallets

​3. End-user transaction flow

​4. Reclaiming resources

​Policy: separate sponsor and user permissions

​Operational notes

​Using a third-party paymaster instead

​Questions?

Why Tron gasless is different from EVM Gas Station

Setup guide

1. Stake TRX for resources (sponsor wallet)

2. Delegate the resource to end-user wallets

3. End-user transaction flow

4. Reclaiming resources

Policy: separate sponsor and user permissions

Operational notes

Using a third-party paymaster instead

Questions?