specs(exact): add TRON exact scheme specification

[boboliu-1010]

Description

Adds formal specification for the exact payment scheme on TRON, covering both assetTransferMethod variants defined by the EVM spec: permit2 and eip3009. Payload schemas are byte-identical to scheme_exact_evm.md — same JSON field names, same EIP-712 typehashes, same Permit2 Witness pattern. TRON-specific rules are limited to address conversion (Base58 in paymentRequirements, 0x hex inside signed payload) and on-chain SDK (TronWeb vs. viem).

Closes #2075.

• Adds specs/schemes/exact/scheme_exact_tron.md — full TRON exact spec (both paths).
• Updates specs/schemes/exact/scheme_exact.md — appends TRON to the scheme index and the critical-validation requirements list.

No SDK/runtime implementation changes. The TypeScript (@x402/tron) and Python (x402[tron]) implementations will follow in separate PRs after this spec is approved.

Design property: gasless client

TRON debits energy/bandwidth from the owner_address of the on-chain transaction. In this spec the facilitator is owner_address; the user signs only TIP-712 structured data. The user never needs to hold TRX, matching x402's gasless-client property on EVM.

Why TRON as an independent package

• Different address format: Base58 (T...) vs. 0x hex
• Different chain SDK: TronWeb vs. viem / ethers
• Different CAIP-2 namespace: tron: vs. eip155:
• No ERC-1271, ERC-6492, or Multicall3 support
• Follows the existing pattern: all 5 mechanism packages (evm, svm, avm, aptos, stellar) are independent.

Dual assetTransferMethod

This spec defines both paths already established by the EVM exact scheme:

1. permit2 — uses SUN.io's production Permit2 (source), byte-identical to Uniswap Permit2 adapted to TIP-712. Covers every TRC-20 (USDT, USDD, etc.). Mainnet deployment TTJxU3P8rHycAyFY4kVtGNfmnMH4ezcuM9 is TronScan-verified with 29,000+ live txs.
2. eip3009 — transferWithAuthorization signed via TIP-712. Requires the token to implement the ERC-3009 interface. BofAI will deploy an ERC-3009-compatible TRC-20 on Nile (and optionally mainnet) before PR2 opens, and add the address + source-verification link to the "Supported Tokens" appendix.

Why no TIP-3009 dependency

tronprotocol/tips does not currently contain a TIP-3009 document. This spec follows the USDC precedent — USDC shipped transferWithAuthorization on Ethereum before EIP-3009 reached Final status. The on-chain interface is well-established via EIP-3009 and the signing layer uses TIP-712 (Final). A formal TIP-3009 can be proposed to tronprotocol/tips in a separate thread without blocking this x402 work.

Permit2 compatibility with Uniswap Permit2

SUN.io Permit2 is a byte-identical fork of Uniswap Permit2:

• Same EIP-712 domain typehash and nameHash (keccak256("Permit2"), no version field)
• Same PermitTransferFrom / PermitBatchTransferFrom / PermitSingle / PermitBatch / AllowanceTransferDetails typehashes and struct layouts
• Same nonce bitmap (248-bit wordPos + 8-bit bitPos, via _useUnorderedNonce)
• DOMAIN_SEPARATOR uses block.chainid at full value (no truncation)

No contract modifications are required. An x402 exact.permit2 payload produces identical EIP-712 digests on EVM and TRON modulo chainId + verifyingContract.

TRON-specific constraints called out in the spec

• No approval sponsoring. TRC-20's approve() requires msg.sender to be the token owner, so a facilitator cannot sponsor the approve() call. The Permit2 fallback is two-layer: EIP-2612 permit → manual user approve.
• ecrecover-only signature verification. TRON has no ERC-1271, so contract-wallet signatures are not supported.
• No Multicall3. Diagnosis uses sequential triggerConstantContract calls.
• TIP-712 (Final) is the formal TRON standard referenced for signing semantics.

Tests

No code affected.

Checklist

• My commits are signed (required for merge)
• Spec follows the structure of scheme_exact_evm.md
• All error codes listed in the Appendix
• All supported networks enumerated with CAIP-2 + chain ID
• Both assetTransferMethod values documented with payload examples

[vercel]

@boboliu-1010 is attempting to deploy a commit to the Coinbase Team on Vercel.

A member of the Team first needs to authorize it.

[boboliu-1010]

@x402-foundation/core gentle ping — this spec PR (companion to #2075) has been open without review since 2026-04-20. Whenever someone has bandwidth, would appreciate a triage pass or initial feedback.

Note: the failing Vercel check is due to deploy authorization scoped to the Coinbase team — not something I can resolve from this fork. The labeler workflow passed.

[ukstv]

@boboliu-1010 Apparently, Tron does not have a proper CAIP chain id. There are two PRs to CASA: ChainAgnostic/namespaces#170 and ChainAgnostic/namespaces#162, and looks like you're using custom "tron:nile" identifier.

[ukstv]

@boboliu-1010 FYI: the chain ids are borked in the PR. Should be:

Network	Hex	Numeric	Chain ID
Mainnet	0x2b6653dc	728126428	tron:0x2b6653dc
Nile	0xcd8690dc	3448148188	tron:0xcd8690dc

As for x402ExactPermit2Proxy contracts deployed:

Network	Chain ID	Address
Mainnet	tron:0x2b6653dc	TNtw4Wg6uQe4bqFywtcn5qagVZesSdYBSs
Nile	tron:0xcd8690dc	TTjbkCh8sC4gNTWG48iWNssrLBqZq2tiTy

[roger-gan]

@boboliu-1010 Apparently, Tron does not have a proper CAIP chain id. There are two PRs to CASA: ChainAgnostic/namespaces#170 and ChainAgnostic/namespaces#162, and looks like you're using custom "tron:nile" identifier.

Thanks @ukstv — agreed. I’ll update the spec&codes to avoid the custom tron:nile / tron:mainnet identifiers and use the TRON hex chain IDs instead.
BTW, we have also been working on a downstream implementation based on the community version of x402: https://github.com/BofAI/x402, This implementation currently adds support for both TRON and BSC. You mentioned that you have deployed the x402ExactPermit2Proxy contract on the TRON network. Are you also planning to support TRON-related development in x402?

[ukstv]

@roger-gan For easier testing (JS is more malleable than Rust), there are few JS scripts on https://github.com/fareside/tron-x402-js It'd be curious to see, if BofAI, our JS code and Rust counterpart conform to the same protocol. I mean our JS<>Rust def works, and AI convinced me it is straight to spec you wrote, BofAI<>Rust - that'd be interesting.

You mentioned that you have deployed the x402ExactPermit2Proxy contract on the TRON network. Are you also planning to support TRON-related development in x402?

Apparently, yes on https://github.com/x402-rs/x402-rs/tree/main/crates/chains/x402-chain-tron, as requested by our users and you know, as contributions flow in. You are more than welcome too. That's a part of straight to spec x402 protocol implementation in Rust https://x402.rs. Tron impl across mainnet and Nile testnet for "exact" scheme. For Nile testnet, as well as other testiest, you could use a deployed https://facilitator.x402.rs

And, one more thing. @roger-gan If you are with the Tron Network, I'd really appreciate talking to someone close to The Network on how to accommodate to economics of TRX tx fees please? Ping anytime @ukstv on TG/X or sergey@fareside.com

[roger-gan]

ukstv

Thanks for sharing the JS and Rust implementations.

From our side, the main goal is to keep our TRON/BSC implementation aligned with the x402 Foundation specification as closely as possible. If the implementation proves compatible with the x402 Foundation spec, we would be happy to upstream the relevant TRON/BSC-related changes where appropriate.

As far as I understand, TRON does not currently support an EVM-style gas sponsoring / paymaster mechanism.

One possible TRON-native direction could be an Energy delegation model, where a facilitator or service provider maintains delegated Energy capacity and uses it to absorb or subsidize transaction costs, keeping the client-side x402 flow as close to gasless as possible.