Add Tron namespace with CAIP-2 and CAIP-10 specifications

[riveign]

Summary

This PR adds the Tron namespace to the Chain Agnostic Namespaces repository, implementing CAIP-2 (Blockchain ID) and CAIP-10 (Account ID) specifications.

Networks Supported

• Tron Mainnet (tron:0x2b6653dc)
• Tron Shasta Testnet (tron:0xcd8690dc)
• Tron Nile Testnet (tron:0x94a9059e)

Files Added

• tron/README.md - Namespace overview and introduction
• tron/caip2.md - CAIP-2 blockchain ID specification
• tron/caip10.md - CAIP-10 account ID specification

Key Features

• Hexadecimal chain ID format aligned with TIP-474
• Resolution methods via eth_chainId JSON-RPC
• Comprehensive test cases for all networks
• Base58Check address validation
• Support for TRC-20, TRC-10, and TRC-721 token standards

References

• WalletConnect Tron Documentation
• TIP-474: Chain ID Specification
• Tron Developer Hub

Testing

All test cases have been included in the specification documents with valid and invalid examples.

[bumblefudge]

Whoops, sorry, did you notice #162 ?

[bumblefudge]

It might be good to link here to some canonical, authoritative, and/or Foundation-funded source for RPC and chainId information, as these examples will probably be out of date in a year or three?

[bumblefudge]

but doesn't eth_chainId take integers (1), not bytestrings (0x01)?

[bumblefudge]

I'm not understanding the 0x prefix: even though it's derived from a bytestring (the genesis hash), it still seems to me like the basic type is integer, not bytestring? Note also that #162 , which was approved but not merged before this PR was opened, went the integer root, which seems more ergonomic to me (if nothing else because it's shorter and easier to validate)

[bumblefudge]

Suggested change

	discussions-to: https://github.com/ChainAgnostic/namespaces/pull/XXX
	discussions-to: https://github.com/ChainAgnostic/namespaces/pull/170

[bumblefudge]

Hey! Despite all the nitpicky comments above, I am super grateful for this very thorough and explicit PR, I wish all the namespaces were this detailed.

The little things are little things, but there is one thing really blocking me from closing #162 as redundant (for being less detailed), adding its author (@danroc ) to the author list here, and merging this: the CAIP-2 0x prefix. Between the weakly-held argument made inline and CASA's first-over-the-pole policy when contributors disagree about aesthetics, I tend to prefer the terser expression, but happy to hear arguments in favor of the 0x?

[danroc]

Hey @bumblefudge, thanks for the ping. I left CAIP-10 out of the PR because I wasn’t sure whether I should cover Hex addresses.

We used the integer format since it seems to be the most common and matches what we do in other namespaces (like eip155).

On the level of detail, I tried to keep the spec pretty minimal. Happy to add more if needed, and I’ll keep that in mind next time!

[obstropolos]

A few changes + @bumblefudge 's requests still outstanding. Thanks for submitting this so far!

[danroc]

@bumblefudge, if we’re favoring this PR over #162, can we use integer representations for the chain IDs?

[bumblefudge]

can we use integer representations for the chain IDs?

basically waiting on OP ( @riveign ) to consent to this proposal before merging :D

[bumblefudge]

Taking @riveign 's silence as consent, but happy to PR post-facto!

[bumblefudge]

We used the integer format since it seems to be the most common and matches what we do in other namespaces (like eip155).

It seems the integer format is now standard in TRONland and the genesis hash is deprecated actually:

https://tronprotocol.github.io/documentation-en/releases/history/?h=chainid#3-optimize-the-return-value-of-the-chainid-opcode

https://github.com/tronprotocol/tips/blob/master/tip-474.md

The MetaMask PR from July matches the new integer convention-- seems like MM and WC should be aligned on this!

[riveign]

Hey @bumblefudge @danroc apologies for the delay here,picking this up now.

To give some context on the hex format: we had discussed this directly with the Tron team when scoping the namespace spec, and they aligned on using hex chain IDs at the time. That's why the PR was submitted this way.

That said, we can see the ecosystem is clearly converging on integer format. We've reached out to the Tron team to get their final confirmation on switching to decimals. Once we hear back, we'll either update this PR to use integer chain IDs or keep the current format based on their input.

Will follow up here as soon as we have their response. Thanks for your patience!

[danroc]

Thanks @riveign! Hopefully, they are okay with the decimals. We couldn't wait until my PR got merged to release, and we already have a big number of TRON accounts using the decimal chain IDs internally.

[riveign]

Hey @bumblefudge @danroc — update on the chain ID format discussion.

We checked with the Tron team and they've come back recommending we keep the hex format. Their main concern is that changing to integer would be a breaking change — there are existing integrations that already use hex chain IDs based on their documentation, and a format switch could introduce compatibility risks.

So the path forward as we see it:

1. Proceed with hex as-is in this PR — respecting the Tron team's decision on their own chain ID format
2. MetaMask alignment — @danroc since you're using decimal internally, this may need coordination on your side to map to the canonical hex format in CAIP-2

Let us know if there are concerns with this approach or if you see other alternatives, happy to address any remaining review comments and get this over the line once we agree on the path forward.