Track and Introduce ERC-3009 Transfer With Authorization to TRON

[yanghang8612]

Background

ERC-3009 lets a token holder authorize a transfer with an off-chain EIP-712 signature that any third party (a relayer) can submit on-chain and pay fees for — enabling gasless token transfers. It defines transferWithAuthorization, receiveWithAuthorization, and cancelAuthorization. transferWithAuthorization and receiveWithAuthorization use distinct EIP-712 primary types: a transferWithAuthorization signature can be submitted by anyone, while receiveWithAuthorization binds the payee path and additionally requires to == msg.sender (mitigating front-running of the relayed call). Transfer/receive authorizations carry validAfter/validBefore time bounds and use random 32-byte nonces (not sequential), so they can be created and redeemed out of order / in parallel; cancelAuthorization signs only authorizer + nonce (no time window). It is the mechanism behind Circle's USDC gasless transfers.

It differs from the permit pattern (TIP-2612): permit sets an allowance (still needing a later transferFrom) with sequential nonces, whereas ERC-3009 performs the transfer itself by signature with random nonces. Stablecoin transfers dominate TRON usage and "holds tokens but no TRX for fees" is a common friction point, so we propose to track ERC-3009 and introduce it to TRON as a TIP (proposed TIP-3009), as an extension for TIP-20 tokens — a token-level building block for gasless transfers that complements TIP-2612 (permit) and TRC-2771 (#852) (meta-transaction forwarding).

Scope

• Follow ERC-3009's functions and EIP-712 typed-data definitions as closely as possible.
• Apply to TIP-20 tokens (not native TRX or TRC-10).
• Provide TRON-specific guidance only where TIP-712, address encoding, or the resource model requires clarification.

Compatibility Topics for Discussion

• Positioning within TRON's gasless stack. TRON would then have three related primitives — TIP-2612 (permit, allowance-by-signature), TRC-2771 (forwarded meta-tx), TRC-3009 (direct signed transfer). How builders should choose among them, and whether there is redundancy to call out or they are complementary (3009 for direct payments, 2612 for approving contracts, 2771 for arbitrary calls).
• Relayer economics on TRON. "Gasless" means the relayer pays energy/bandwidth (staked or burned TRX), as discussed for TRC-2771 (#852). Note that ERC-3009 itself has no fee field or relayer-recipient parameter, so any relayer compensation (fee skimmed from the token, off-chain payment, sponsored service) is an application-layer/wrapper concern, not part of the standard — this should be a non-normative note. Whether TRON's regenerating-energy model makes high-throughput relayers cheaper at scale is also worth a non-normative note.
• TIP-712 domain, address encoding, and replay protection. The authorization is an EIP-712 signed message. A complete TRON domain should bind name, version, TIP-712 chainId (block.chainid & 0xffffffff), and verifyingContract — chainId alone cannot prevent replay between two 3009 contracts on the same network. Addresses are encoded as the 20-byte form after stripping the 0x41 prefix (per TIP-712 / TIP-2612), while wallets may display Base58Check; the random 32-byte-nonce semantics and the authorizationState view should be preserved exactly, and validAfter/validBefore evaluated against TVM block.timestamp.
• receiveWithAuthorization front-running on TRON. Since transferWithAuthorization signatures are submittable by anyone, receiveWithAuthorization (distinct primary type, to == msg.sender) exists to let a payee claim safely. TRON's Super Representative block production does not remove the front-running risk (nodes/observers can still replay a transferWithAuthorization), so both functions should be included for parity.
• Signature verification on TVM. Whether the TVM ecrecover precompile recovers EIP-712 signatures identically, and the standard's known edge cases must be handled: malformed signatures returning address(0), low-s/v normalization, and an authorizer != address(0) check (cf. the permit warnings in TIP-2612). Wallets must sign TIP-712 typed data without TRON-specific message prefixes that would break verification. Whether secp256r1/passkey signing is in scope: TIP-7951 (#785) verifies a P-256 signature against an explicit public key (it does not recover an address like ecrecover), so the core 3009 should stay secp256k1/TIP-712 and any passkey variant needs a separate signer-binding model.
• Adoption by existing stablecoins (open). Already-deployed token code/ABI cannot be extended in place unless the token was designed with proxy-style upgrade dispatch — so for major TRON stablecoins (e.g., USDT) adoption realistically targets new tokens, future token versions, or a future/new official USDC deployment. Whether the TIP should recommend ERC-3009 as a default extension for new TIP-20 stablecoins.

References

• ERC-3009: https://eips.ethereum.org/EIPS/eip-3009
• TIP-2612 (permit), TRC-2771 (tracking issue #852) (meta-tx)
• TIP-712, TIP-20, TIP-7951 (#785)

[lily309]

Three gasless primitives on TRON now — TIP-2612 (permit), TRC-2771 (forwarded meta-tx), TRC-3009 (signed transfer). The body says they're complementary, but for a wallet/DApp developer choosing among them, what's the actual decision rule? Is there an expected canonical "use 3009 for X, 2612 for Y, 2771 for Z" mapping the TIP plans to publish?

[yanghang8612]

@lily309 Yes — implementers will conflate them otherwise. The mapping:

• TIP-3009 → direct gasless payments. "Send X tokens to Y, signed off-chain, anyone can submit." Random nonces let multiple payments live in parallel without coordination. Best for stablecoin transfers, micropayments, payroll-style batching, point-of-sale flows. Single signature, single on-chain action, finished.
• TIP-2612 → gasless approvals. "Authorize spender Z to pull up to X tokens." Sets an allowance; the actual transferFrom happens later via contract call. Best for swaps, DeFi deposits, anywhere the next action is a contract interaction that itself pulls funds. Sequential nonces because allowance state is sequential by nature.
• TRC-2771 → gasless arbitrary calls. "Run this calldata against contract C on my behalf." General-purpose meta-tx through a trusted forwarder. Best when the action isn't a token transfer or approval at all — voting, claim functions, NFT mints, custom protocol entrypoints.
• Rule of thumb: 3009 if you want money to move now, 2612 if you want to set up a future pull, 2771 if you want to do something that isn't transfer-or-approve. Stacking them is fine — a DApp can use 2612-permit for the approval and 2771 for a subsequent custom call.
• Goes into a non-normative "Positioning" appendix with one short example per case.

[TonyStank911]

Random 32-byte nonces vs sequential nonces TIP-2612 uses — the body calls out parallel/out-of-order redemption, but is that actually a meaningful win on TRON given current stablecoin throughput? Practical benefit or just upstream parity?

[yanghang8612]

@TonyStank911 Practical, not cosmetic. Shows up in three places that matter on TRON specifically:

• High-throughput payment flows. USDT-on-TRON sees significant per-account transaction volume — exchanges, payment processors, on-ramps. With sequential nonces, an account that signs payment N+1 before payment N has been mined invalidates the second signature on most relayer implementations. Random nonces let an account sign 50 payments in a batch and have them processed in any order or in parallel without coordination.
• Multi-device / multi-relayer redundancy. Same key on two devices, or a service routing through multiple relayers for reliability — racy reordering is free with random nonces. Sequential nonces would require coordination between devices or relayers, exactly what gasless flows try to avoid.
• Long-lived authorizations. A signed authorization can sit in a queue (subscription payments, scheduled transfers) without blocking other signatures from the same account. With sequential nonces, queued authorizations create head-of-line blocking; with random nonces, they don't.
• Cost: small storage overhead — each random nonce stored on-chain until the contract prunes. For stablecoin contracts this is acceptable; ERC-3009 contracts have run for years with this model. The TIP will include guidance on nonce-storage layout (mapping(address authorizer => mapping(bytes32 nonce => bool used))).
• Net: random nonces are the correct call for TRON's stablecoin-heavy usage profile. Sequential stays fine for approval-style flows (which is why TIP-2612 stayed sequential).

[simbadMarino]

Great to see this being introduced as TIP, if it helps the community I created a Demo POC for 3009 on TRON: https://github.com/simbadMarino/tron-3009

3009 is being used heavily for agentic payments so it makes sense to have an official TRC on TRON for new TRC-20 tokens to implement it.

Thanks!

[yanghang8612]

@simbadMarino Thanks — and the PoC is a great contribution. A working tron-3009 reference is exactly the kind of artifact that helps move this from spec to adoption; I'll reference it from the discussion as an early implementation (with the usual caveat that it's a PoC, not audited).

Agreed on the agentic-payments angle — that's become one of the strongest arguments for 3009 over the permit pattern: a signed, relayer-submittable transfer with random nonces fits autonomous/parallel payment flows far better than allowance-then-pull. It reinforces scoping TRC-3009 as a TIP-20 extension so new tokens can opt in natively. I'll follow up here as the spec firms up — would welcome your eyes on the TIP-712 domain and nonce-storage sections, given you've already implemented against them.

[xueyuanying]

Two notes from having implemented 3009-style contracts, for the author's consideration:

On the TIP-712 domain — once chainId is truncated to block.chainid & 0xffffffff, the wallet side must sign against the same 4-byte value, otherwise the address recovered by ecrecover won't match. Older TronLink/TronWeb defaulted to the full chainId and we've hit this more than once. Worth promoting "wallet and contract MUST use the same truncated chainId" to a normative implementation requirement, not just a non-normative note.
On signature verification — I'd suggest elevating the recovered != address(0) && recovered == authorizer check from the inherited TIP-2612 permit warning to an explicit MUST in this TIP. Malformed signatures making ecrecover silently return the zero address, then slipping past an uninitialized authorizer field, is something I've seen surface in audits; making it normative at the spec level closes the door cleanly.

[BlackChar92]

Support this. TRC-3009 looks complementary to TIP-2612 and TRC-2771, and is especially useful for stablecoin, relayer, and agentic-payment flows.

One suggestion: the TIP should include official TIP-712 interoperability test vectors — domain separator, truncated chainId, address encoding, sample authorization digest/signature/recovered address, plus failure cases like reused nonce, expired authorization, wrong verifyingContract/chainId, invalid receiveWithAuthorization caller, and malformed signatures recovering address(0).

That would make wallet, SDK, token-contract, and relayer implementations much less likely to diverge.

[EllenWhitmore]

this is something we've been hoping to see for a while.

The "user holds tokens but has no gas" situation comes up constantly. People hold balances they can't move because the account has no TRX, and we end up patching around it with whatever per-token relayer arrangement we can stitch together. None of it really scales, and a lot of the assets users actually hold don't support TIP-2612 permit to begin with, so even that escape hatch is closed for the cases we need most.

The random-nonce design also matters more than people sometimes give it credit for. Sequential nonces make parallel signing flows fragile — they invalidate each other in ways we have to babysit on the backend, and from the user's side things just look stuck. receiveWithAuthorization would additionally let us build safer gasless inbound flows without worrying about front-running.

Honestly, we don't think wallets can clean up the gasless story without a token-level standard like this. Would really like to see it move forward sooner rather than later.

[valiskybe]

Strong support for TRC-3009, but V1 should also cover capability discovery and fallback behavior.

Users may understand this as “tokens can now be transferred gaslessly,” but in practice it only works for tokens that implement the interface. Wallets need a reliable way to detect support before asking the user to sign, and a clear fallback message when a token does not support it.

I also suggest making cancellation and validity-period UX a first-class concern. The user is signing an actual token transfer, not a login message. As long as the authorization remains valid, a relayer may submit it. Wallets should clearly show amount, receiver, validity window, and whether cancellation has been finalized on-chain.