> ## Documentation Index
> Fetch the complete documentation index at: https://docs.0xkey.io/llms.txt
> Use this file to discover all available pages before exploring further.

# How to integrate gasless transactions on Tron with 0xkey

> Fund a sponsor wallet, delegate Bandwidth/Energy to end-user wallets, and let users transact without holding TRX.

<Note>
  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](/networks/tron) for baseline Tron support.
</Note>

## 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](/embedded-wallets/code-examples/sending-sponsored-solana-transactions). 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](/embedded-wallets/code-examples/sending-sponsored-transactions)) | 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

### 1. Stake TRX for resources (sponsor wallet)

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`](https://developers.tron.network/reference/freezebalancev2):

```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
{
  "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](/networks/tron#client-side-construction-and-signing).

<Note>
  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.
</Note>

### 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`](https://developers.tron.network/reference/delegateresource):

```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
{
  "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](/networks/tron#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`](https://developers.tron.network/reference/undelegateresource) — the end user does **not** need to sign or approve this:

```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
{
  "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.

## Policy: separate sponsor and user permissions

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:

```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
{
  "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:

```json theme={"theme":{"light":"github-light","dark":"github-dark"}}
{
  "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](/concepts/policies/examples/tron) for more sponsor/user policy patterns, and the [policy language reference](/concepts/policies/language#tron) 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`](/networks/tron#custodial-send). 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](/networks/tron#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.