Hi all,
Cory here from Tronpower.xyz
I have proposed TIP-155 (temporary TIP id , pending assignment , but referencing EIP-155)
Summary
To protect users from cross-network replay attacks, this proposal introduces a chain_id field into TRON transactions. This ensures signatures are valid only on the intended network by modifying the way transaction hashes are generated and signed. This mirrors the role of EIP-155 in Ethereum.
opened 10:40PM - 27 Jun 25 UTC
> tip: <to be assigned> Temporarily matching EIP-155
> title: Cross-Chain Replay… Protection via Chain ID
> author: Cory Tam (@corytam)
> discussions-to: <URL>
> status: Draft
> type/category: Core / TVM
> created: 2025-06-28
### 📖 Summary
To protect users from cross-network replay attacks, this proposal introduces a chain_id field into TRON transactions. This ensures signatures are valid only on the intended network by modifying the way transaction hashes are generated and signed. This mirrors the role of EIP-155 in Ethereum.
### 🎯 Motivation
As TRON grows to support more decentralized applications (dApps), testnets and alternative chains become critical for safe experimentation and onboarding. Developers and users must be confident that transactions signed on a testnet cannot be replayed on mainnet, and vice versa.
Without this protection, malicious actors can take a testnet-signed transaction and replay it on mainnet, potentially tricking users or draining wallets.
By introducing a chain-specific identifier directly into transaction signing and verification logic, TIP-155 ensures cross-network safety while maintaining compatibility with TRON's existing infrastructure.
### 📚 Background
In Ethereum, EIP‑155 embeds the chainId into the signature. The signing process hashes nine RLP fields instead of six, and sets` v = parity + 2*chainId + 35`, preventing transactions signed on one chain (e.g., mainnet) from replaying on another (e.g., testnet).
🔗Reference: [https://eips.ethereum.org/EIPS/eip-155](https://eips.ethereum.org/EIPS/eip-155)
**Tron’s Current Replay Protection**
Tron transactions rely on:
- `ref_block_bytes ` and `ref_block_hash` : included in `raw_data` to tie the transaction to a recent block.
- `expiration` timestamp to limit replay window .
🔗Reference: [https://developers.tron.network/docs/tron-protocol-transaction](https://developers.tron.network/docs/tron-protocol-transaction)
These prevent replay within the **same chain**, but **do not guard against replay across Tron networks/chains** (e.g., Shasta ↔ Mainnet ↔ Nile).
### 💡 Proposal: TIP‑155 for Tron
**1. Define a chain_id field**
Add a `chain_id` (uint32) to Transaction.raw_data, analogous to Ethereum’s chainId.
`uint32 chain_id = XX;
`
This is a 32-bit identifier unique to each TRON network.
Network | Chain ID (hex) | Chain ID (uint32)
-- | -- | --
Mainnet | 0x2b6653dc | 728126428
Shasta | 0x94a9059e | 2494108574
Nile | 0xcd8690dc | 3448148956
_Chain ID values match the last 4 bytes of the genesis block hash (as per eth_chainId compatibility)._
**2. Modify Signature Hashing**
When signing a transaction:
- Append` chain_id`, `0`, `0` bytes after the standard serialized data (similar to Ethereum’s nine-field RLP).
- Compute `SHA256` over `raw_data + chain_id` instead of just `raw_data`.
`signed_data = SHA256(serialize(raw_data) || chain_id || 0 || 0)`
**3. Embed chain_id in Signature**
TRON signatures are currently raw SECP256k1 ECDSA bytes.
This TIP proposes encoding chain_id directly into the signature:
`signedTransaction.signature = chain_id (4 bytes) || 65-byte ECDSA signature`
During signature verification, nodes:
- Extract the chain_id from the first 4 bytes
- Ensure it matches the local chain’s configured chain_id
- Reject mismatched transactions as invalid
### 🔗 Related Work and TIPs
TIP-174: Adds a CHAINID opcode to the TRON Virtual Machine (TVM), enabling smart contracts to identify the current chain
🔗Reference: [https://github.com/tronprotocol/tips/blob/master/tip-174.md](https://github.com/tronprotocol/tips/blob/master/tip-174.md)
TIP-474: Aligns CHAINID with JSON-RPC eth_chainId, simplifying integration with Ethereum tooling
🔗Reference: [https://github.com/tronprotocol/tips/blob/master/tip-474.md](https://github.com/tronprotocol/tips/blob/master/tip-474.md)
WalletConnect v2.0: Identifies TRON networks using tron:<chainId> (e.g., tron:0x2b6653dc), making chainId consistency essential
These TIPs lay the groundwork for network differentiation and validate the need for embedded chain_id.
### ✳️ Benefits
Simple: Clean extension over hash–sign flow.
Secure: Allows replay protection across Tron mainnet, Nile, Shasta, custom networks.
Flexible: chain_id stays independent of ref_block and expiration.
### ↔️ Compatibility & Rollout
Based on EIP-155 , it uses a pre-determined FORK_BLKNUM and checks if block.number >= FORK_BLKNUM .
All transactions post fork based on block number will be compatible
Like wise for TIP-155the following should happen:
- Transactions without chain_id will remain valid until the hard fork
- Post-FORK_BLKNUM, transactions must include and match chain_id
- Older SDKs remain compatible for legacy transactions
- SDKs (E.g TronWeb) must adopt support for chain_id encoding and validation
- Hardware wallets and WalletConnect integrations will need signature decoding logic updates
### 📃 Tip‑155 Specification Summary
Item | Description
-- | --
Field added | raw_data.chain_id (uint32)
Hashing | `SHA256(serialize(raw_data)
Signature | `signature = chain_id(4‑bytes)
Verification | Node extracts chain_id, checks it against eth_chainId, rejects mismatches
Activation | Applies post-defined FORK_BLKNUM; legacy transactions remain valid
🧠 Ending summary & Rationale
This proposal is the minimal necessary change to:
- Secure users from replay attacks
- Align TRON with the EVM-compatible ecosystem
- Support modern tooling like WalletConnect, MetaMask Snap bridges, etc.
The presence of a chain_id within smart contracts and RPC responses (via TIP-174 and TIP-474) makes this the next logical step in protocol security and developer ergonomics.
Motivation
Tronpower’s goal is simple. Build a better TRON ecosystem and lead the charge for innovation and hope others follow suit.
We have built TRON’s first and only dedicated, full fledge dApp on the testnet which allows users to have a hands-on experience with TRON and learning about its unique resource model and permission model.
Building this testnet made us realize that bad actors or phishing sites may tarnish the TRON ecosystem if it does not have a robust security standard that Tronpower is upholding and want to prevent as many loopholes as possible.
We want to set a standard , the Tronpower Standard
.
Bringing innovation , security and benefits/prosperity for all TRON users.
Additional Context
As TRON grows to support more decentralized applications (dApps), testnets and alternative chains become critical for safe experimentation and onboarding. Developers and users must be confident that transactions signed on a testnet cannot be replayed on mainnet, and vice versa.
Without this protection, malicious actors can take a testnet-signed transaction and replay it on mainnet, potentially tricking users or draining wallets.
By introducing a chain-specific identifier directly into transaction signing and verification logic, TIP-155 ensures cross-network safety while maintaining compatibility with TRON’s existing infrastructure.
Please read more about the specification & feel free to share your thoughts and improvements.