Track and Introduce ERC-7730 Structured Data Clear Signing Format to TRON

[yanghang8612]

Background

ERC-7730 defines a JSON format for describing how wallets and other signing tools should display structured data for clear signing. It covers smart contract calls and typed messages, including EVM calldata and EIP-712 style messages, by providing contextual metadata, display rules, field formatting, and intent descriptions.

This is relevant to TRON because clear signing can improve the user experience and reduce phishing or frontend attack risks when users review contract interactions or structured messages before signing.

Proposal

We propose to track ERC-7730 and introduce it to the TRON ecosystem as a TIP.

The current plan is to keep the standard content unchanged, so TRON wallets, DApps, SDKs, and tooling can follow the same JSON schema and semantics as ERC-7730 without introducing TRON-specific modifications to the standard itself.

Scope

The proposed TIP should:

• Follow ERC-7730 as closely as possible.
• Preserve the original standard structure, including context, metadata, and display.
• Maintain compatibility with existing ERC-7730 tooling and schemas.
• Provide TRON ecosystem guidance only where necessary, such as examples or non-normative implementation notes.

Current Plan

At this stage, we do not plan to modify the ERC-7730 standard content.

If TRON-specific details need to be clarified, such as address representation, chain ID usage, or integration with existing TRON signing standards, those should be handled as explanatory notes or examples rather than changes to the normative specification.

Compatibility Topics for Discussion

Although the current plan is to keep ERC-7730 unchanged, several TRON-specific details may need to be clarified before wallets and tooling can implement it consistently.

TIP-712 and trcToken

TIP-712 follows EIP-712 but introduces TRON-specific handling for some fields, including trcToken as an atomic type encoded as uint256.

Questions:

• Should ERC-7730 files for TRON typed data allow trcToken in display.formats type definitions when the underlying message follows TIP-712?
• Should trcToken be formatted as a raw uint256, or should wallets treat it as a token identifier and resolve metadata such as token name, symbol, decimals, and issuer?
• If a field contains both a trcToken id and an amount, should the recommended ERC-7730 pattern use tokenAmount, a TRON-specific metadata path, or a plain amount plus a separate token label?
• Can this be documented as TRON implementation guidance without changing the ERC-7730 schema or field format list?

Address Representation

TRON addresses may appear as Base58Check addresses, hex addresses with the 0x41 prefix, or ABI-level 20-byte values after removing the TRON prefix. ERC-7730 examples generally use Ethereum-style hex addresses.

Questions:

• What should be the canonical address representation in TRON ERC-7730 files, especially under context.contract.deployments.address and context.eip712.deployments.address?
• Should wallets accept multiple address encodings for matching, while recommending one canonical form for authored files?
• Should displayed addresses prefer the user-facing Base58Check form even if the ERC-7730 file uses a hex form for matching?
• How should addressName resolution work in TRON contexts, and should it be limited to wallet-local address books unless a trusted TRON naming source is available?

Chain ID and Domain Binding

ERC-7730 uses chainId in deployment and EIP-712 domain contexts. TIP-712 defines the domain chainId as block.chainid & 0xffffffff.

Questions:

• Should TRON ERC-7730 files use the TIP-712 chainId value for context.eip712.deployments.chainId and EIP-712 domain matching?
• Should the same value be used for smart contract call contexts under context.contract.deployments.chainId?
• How should wallets prevent accidental cross-network matching between Mainnet, Nile, Shasta, and private networks?
• Do we need non-normative examples showing the expected chainId values for common TRON networks?

TRON Transaction Container Mapping

ERC-7730 currently describes EVM calldata and EIP-712 messages. TRON smart contract calls are ABI-compatible at the calldata level, but the outer transaction container is TRON-specific.

Questions:

• Can wallets map TRON TriggerSmartContract fields into the same container-level paths used by ERC-7730, such as @.from, @.to, @.value, and @.chainId?
• Should @.to refer to the called contract address and @.from refer to the transaction owner address in TRON transactions?
• Should @.value represent only TRX call_value, or should call_token_value and token_id require additional container paths?
• Should the first TRON implementation scope be limited to TVM smart contract calldata and TIP-712 messages, leaving native TRX and TRC-10 system transactions for later discussion?

TRX, TRC-10, and TRC-20 Display

Clear signing needs consistent display for native TRX, TRC-10 assets, and TRC-20 tokens.

Questions:

• Should TRX values be formatted using sun as the base unit with 6 decimals, and should this be captured only as implementation guidance?
• For TRC-20 transfers and approvals, can existing ERC-7730 tokenAmount patterns be reused directly when token metadata is available from the contract?
• For TRC-10 assets, should wallets resolve token metadata by token id, and how should missing or ambiguous metadata be displayed?
• Should unlimited approval thresholds and token decimal handling follow existing ERC-7730 conventions without TRON-specific changes?

Registry and Security Considerations

ERC-7730 relies on correct binding between the file, contract or message context, and the data being signed.

Questions:

• How should a TRON ERC-7730 registry normalize addresses and chain IDs before matching files?
• How should wallets avoid applying an ERC-7730 file to a proxy, factory deployment, or contract clone unless the binding context is verified?
• Should TRON wallets require stricter matching when the file contains TRON-specific metadata or examples?
• What review process should be used before a TRON ERC-7730 file is considered trusted by wallets?

Naming and Documentation

Questions:

• Should the TRON proposal refer to the standard as ERC-7730 for compatibility, or introduce a TRON-facing TIP title while preserving the ERC-7730 name in the specification?
• Should the eventual TIP include TRON examples only, or should it also include a short compatibility note for TIP-712, TRC-10, TRC-20, and TRON address formats?
• Should any TRON-specific behavior be placed in an appendix or implementation guide to make clear that the ERC-7730 standard content remains unchanged?

References

• ERC-7730: https://eips.ethereum.org/EIPS/eip-7730
• ERC-7730 discussion: https://ethereum-magicians.org/t/eip-7730-proposal-for-a-clear-signing-standard-format-for-wallets/20403
• TIP-712: https://github.com/tronprotocol/tips/blob/master/tip-712.md

[lxcmyf]

This is a useful direction. I agree that ERC-7730 itself should remain unchanged, but the TIP should probably add a short TRON implementation profile so wallets and tooling handle matching consistently.

Suggested scope:

• Address normalization: use ABI-level 20-byte hex addresses in ERC-7730 files for compatibility, but let wallets normalize Base58Check, 0x41 hex, and 20-byte hex during matching. Display should prefer Base58Check or a trusted wallet/registry name.
• Chain ID: use the TIP-712 value, block.chainid & 0xffffffff, consistently for TRON ERC-7730 matching. Add Mainnet/Nile examples to avoid cross-network reuse.
• trcToken: keep it as a TIP-712 type. For display, resolve token metadata only from trusted TRON sources; otherwise show the raw token id and amount.
• Container mapping: define @.from as TriggerSmartContract.owner_address, @.to as TriggerSmartContract.contract_address, and @.value as TRX call_value in sun. Do not overload @.value for TRC-10 call_token_value / token_id; that can be a later TRON-specific extension.
• First version: focus on TVM calldata, TIP-712 typed messages, TRX/TRC-20 display, address/chainId normalization, and registry security rules.

This keeps upstream ERC-7730 compatibility while giving TRON wallets enough guidance to avoid inconsistent address matching, token display, or network binding behavior.

[yanghang8612]

Thanks @lxcmyf — strong agreement on adding a short TRON implementation profile while keeping ERC-7730 itself intact. The profile-not-fork approach keeps us compatible with upstream tooling while clearing the ambiguities specific to TRON. Going through your points:

Address normalization — agreed. Storing ABI-level 20-byte hex in the file is the right canonical form for portability, with wallets responsible for accepting Base58Check / 0x41-prefixed / 20-byte hex during matching and preferring Base58Check (or a trusted name) for display. Worth calling out explicitly that the matching layer MUST NOT reject valid TRON address forms just because the file is in 20-byte hex.

Chain ID — agreed. Pin the value to TIP-712's block.chainid & 0xffffffff for consistency with how TIP-712 signing already works on TRON, and include both Mainnet and Nile worked examples to prevent cross-network reuse.

trcToken — agreed. Keeping it as a TIP-712 type and requiring trusted-source metadata resolution (with raw tokenId + amount as the safe fallback) avoids the same display-spoofing risks ERC-7730 already addresses for fungible tokens. Wallets and TronScan-class indexers are the natural trust sources.

Container mapping — agreed with the conservative scope: @.from → TriggerSmartContract.owner_address, @.to → TriggerSmartContract.contract_address, @.value → TRX call_value (in sun). I also want to not overload @.value for TRC-10 — keeping call_token_value / token_id as a TRON-specific extension in a later revision is the safer path; it avoids surprising wallets that follow upstream semantics.

V1 scope — TVM calldata + TIP-712 typed messages + TRX/TRC-20 display + address/chainId normalization + registry security rules sounds right. Once wallet support lands behind that, TRC-10 / shielded extensions can come as additive revisions.

One open question: do you have a preference between (a) publishing TRON's profile as a section inside the TIP itself vs. (b) keeping the TIP short and shipping the profile rules as a companion "TRON ERC-7730 Profile" document in a tools/wallet repo? I'm leaning toward (a) for V1 so everything lives in one place.

[waynercheung]

@yanghang8612 +1 on the profile-not-fork shape.
On (a) vs (b) - also leaning (a) for V1, with one constraint: the TIP should pin the exact ERC-7730 revision it targets (commit hash or version tag) and define how upstream changes get reviewed. "Follow ERC-7730 as closely as possible" otherwise drifts silently as the upstream spec evolves, which is the exact cross-wallet inconsistency this profile is meant to prevent.

Two concrete gaps worth nailing down before V1 freezes. First, trcToken in display.formats needs a concrete shape, not just a type registration. ERC-7730 keys formats off ABI-type paths, and trcToken is uint256 on the wire but semantically a token id - so the profile has to pick how it appears in the JSON. My preference is an additive TRON format type (e.g. tip712TrcToken) with a defined resolution algorithm (lookup(id) -> "{symbol} (id: {raw})", raw-on-failure): explicit beats implicit for clear-signing, and upstream tooling that doesn't recognize the type degrades to raw uint256, which is the safe fallback we want anyway. Second, the signing surface is bigger than calldata + TIP-712. TRON wallets sign SHA256(Transaction.raw_data), and the container carries expiration, fee_limit, ref_block_*, and - critically for multi-sig accounts - Permission_id. If V1 is silent on the container, clear-signing covers the function arguments but leaves the transaction-level fields opaque, which is precisely the phishing surface this is meant to close. The profile should mandate wallets display these container fields (@.feeLimit, @.expiration, @.permissionId) alongside the ERC-7730-rendered body.

One smaller note on the registry security rules: worth a worked proxy contract example. Ethereum ERC-7730 wallets are still inconsistent on proxy-vs-implementation binding, and TRON's TriggerSmartContract targets the proxy address, so we'll inherit that problem unless we pin a matching rule early - e.g. file binds to implementation, registry resolves proxy at match time, explicit failure when resolution diverges. Also worth adding non-normative guidance that wallets SHOULD show energy + bandwidth estimates separately rather than collapse them into a single "fee" number, before wallets ship divergent UIs.

[EllenWhitmore]

Strong +1 on adopting ERC-7730, and I hope this lands soon. As someone shipping wallet integrations on top of TIP-712, the current signing UX is one of the weakest links in our stack — users routinely see opaque hex or partially-decoded structs in the confirmation screen, and that gap is exactly what phishing campaigns have been exploiting on EVM chains. Converging on the same descriptor format that Ledger, Rabby, and MetaMask Snaps already speak is clearly the right call, and the "minimal modifications, TRON guidance via notes" approach is the only viable one — forking the schema would just guarantee tooling vendors deprioritize us.

[mixiaowu2023]

First, TRC-7730 will definitely help solve some blind signing problems and make contract interactions safer for users.
Question 1: For the TRC-7730 descriptor files — I'm talking about the parsed descriptor files for contracts like JustLend and sun.io, derived from their events/ABI — where exactly should these files be stored in the end? And for submitted descriptors, who is responsible for reviewing and merging them?
Question 2: If other DeFi protocols don't proactively submit their TRC-7730 descriptors, is there a more automated way to generate the parsing/descriptors?