From ddc0bd96e8738e18468a4d4ecae99fbc7bb06c35 Mon Sep 17 00:00:00 2001 From: alichatme Date: Fri, 10 Oct 2025 01:36:11 +0330 Subject: [PATCH 01/16] Add TIP-796: Dual-Word + 4-Digit Username System --- tips/tip-796.md | 59 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644 tips/tip-796.md diff --git a/tips/tip-796.md b/tips/tip-796.md new file mode 100644 index 0000000..85e5e42 --- /dev/null +++ b/tips/tip-796.md @@ -0,0 +1,59 @@ +--- +tip: 796 +title: Dual-Word + 4-Digit Username System for TRON Accounts +author: ali&chatgpt (alichatme) +discussions-to: https://github.com/tronprotocol/tips/issues/ (to be linked after Issue creation) +status: Draft +type: Standards Track +category: TRC +created: 2025-10-09 +--- + +## Simple Summary +A new **dual-word + 4-digit username system** designed to make TRON account transfers safer and easier while keeping decentralization principles. + +## Abstract +This proposal introduces a human-readable username format based on **two meaningful English words followed by four digits** (e.g., `skyline2458`). +This approach prevents copy-paste mistakes, enhances user confidence, and supports massive scalability (up to **3.6 quadrillion usernames**) using over 650,000 English words. + +## Motivation +One of the biggest risks in blockchain transfers is **copy/paste error** or **address replacement by malware**. +By linking TRON accounts to short, meaningful, and unique usernames, senders can visually confirm that they’re sending to the correct account — reducing human error and potential loss of funds. + +## Specification + +### Username Format +- Structure: **Two meaningful English words + four digits** +- Examples: `bluebird1974`, `silvergate2048` +- Case-insensitive (`SkyGate2048` = `skygate2048`) +- Only ASCII letters and digits allowed +- Each username must be unique across the TRON network + +### Registration Rules +1. Usernames are optional; addresses still remain valid and functional. +2. Registration can be handled on-chain (TRC smart contract) or derived deterministically from address (implementation choice). +3. Ownership of a username is **linked to the owner’s wallet**. +4. Usernames are **non-transferable**, preserving decentralization and privacy. + +### System Features +- Prevents copy-paste mistakes and address spoofing. +- 650,000 × 650,000 × 10,000 = **~3.6 quadrillion** possible combinations. +- No need for centralized name management. +- Lightweight implementation compatible with TRON’s current account structure. + +## Rationale +This design ensures TRON remains **fully decentralized**, while helping users verify recipients easily and avoid copy/paste or malware address swaps. + +## Implementation +- Minimal on-chain footprint: mapping or deterministic derivation. +- Wallet developers should show both address and username in confirmation modal. +- Optional: a small on-chain registry to lock username↔address mapping when needed. + +## Security Considerations +- Use strict ASCII-only words and a vetted wordlist to avoid homograph attacks. +- Confirmation modal must display both full address and username prior to signature. +- For large transfers, require stronger confirmation (2FA or hardware wallet). + +## Copyright +Copyright © 2025 ali&chatgpt +Licensed under Apache-2.0 From db1c8337930062cac70b9e92f4eb0111b0d3dca0 Mon Sep 17 00:00:00 2001 From: alichatme Date: Sun, 9 Nov 2025 22:48:57 +0330 Subject: [PATCH 02/16] Add final version of TIP-796 proposal --- TIP-796.md | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) create mode 100644 TIP-796.md diff --git a/TIP-796.md b/TIP-796.md new file mode 100644 index 0000000..10e1073 --- /dev/null +++ b/TIP-796.md @@ -0,0 +1,49 @@ +### TIP-796 Proposal + +**Title:** +Dual-Word + 4-Digit Username System for TRON Accounts + +--- + +**Summary:** +This PR proposes the introduction of a decentralized, human-readable username format for TRON accounts, consisting of two meaningful English words and a four-digit number. + +--- + +### Proposed Structure: +- **Mode 1:** Two English words + 4-digit number (at the end) + - Example: `moonstar4821` +- **Mode 2:** Two English words + 4-digit number (in the middle) + - Example: `star4821moon` + +> In future updates, a third mode — featuring a 4-digit number at the beginning followed by two English words — may be optionally added, with a minor adjustment to reduce visual similarity with the first mode, considering the right-to-left and left-to-right orientation of some languages, based on the TRON development team’s decision to further enhance name diversity. + +--- + +### Key Points: +- Structure: two meaningful English words and a 4-digit number (at the end or in the middle) +- Case-insensitive (ASCII only) +- Usernames are **non-transferable**, preserving decentralization +- Wallets must display **both the username and the full destination address** in the signing confirmation modal +- Enormous namespace: approximately **8.4 quadrillion possible combinations** using a large vetted wordlist +- Goal: reduce **copy/paste errors** and prevent **address manipulation by malware** +- Operates fully at the **Account Layer**, requiring **no smart contracts or protocol changes** + +--- + +### Capacity: +With over **650,000 meaningful English words**, this design supports approximately **8.4 quadrillion unique usernames**, ensuring an exceptionally large and secure decentralized namespace. + +--- + +**Author:** +ali & ChatGPT +GitHub: [@alichatme](https://github.com/alichatme) + +--- + +**Note:** +Per project workflow, a community discussion issue will be opened and linked here for feedback and consensus. + +**Permission:** +Allow edits by maintainers. From 370f13b1bc6e0e3d78e0fde137831a46829297f5 Mon Sep 17 00:00:00 2001 From: alichatme Date: Mon, 10 Nov 2025 07:12:13 +0330 Subject: [PATCH 03/16] chore(readme): replace unrelated SafeWallet content with TIP-796 proposal summary The previous README content (Safe Wallet Method) was unrelated to this repository and was added by mistake. This commit replaces it with the TIP-796 proposal summary and project metadata. --- README.md | 52 +++++++++++++++++++++++++++++++--------------------- 1 file changed, 31 insertions(+), 21 deletions(-) diff --git a/README.md b/README.md index 130f449..b8db4a5 100644 --- a/README.md +++ b/README.md @@ -1,34 +1,43 @@ -# 🌐 Safe Wallet Method – ali & chatgpt +# 🧠 TIP-796 – Account Layer Username Standard -**A revolutionary offline encryption method for crypto wallet recovery phrases.** -Developed by: **ali & chatgpt** -GitHub: [https://github.com/alichatme](https://github.com/alichatme) +**Title:** Account Layer Username Standard +**Authors:** Ali & ChatGPT +**Status:** Draft +**Type:** Standards Track --- -## 🧩 What is Safe Wallet Method? +## 📘 Abstract -It’s an **offline mathematical encryption system** that turns any seed phrase into a secure, disguised version using the **BIP39 word list** and a secret constant number. +This proposal introduces a standardized username format directly at the **account layer**, eliminating the need for secondary layers, smart contracts, or gas/fee mechanisms. -- 100% offline -- Compatible with all BIP39 wallets (TronLink, MetaMask, TrustWallet, etc.) -- Simple and strong -- Ideal for long-term backup +--- + +## 🧩 Username Format + +The standard username structure consists of two main formats: + +- **Pattern 1:** Two English words followed by a four-digit number (e.g., `sunbird2048`) +- **Pattern 2:** Two English words with a four-digit number placed in the middle (e.g., `sun2048bird`) + +In future updates, **Pattern 3**, which includes **two English words and a four-digit number at the beginning**, may be added to increase format diversity. -📘 Read full details here: -👉 [SafeWalletMethod.md](SafeWalletMethod.md) +The addition of Pattern 3 will consider language direction (right-to-left and left-to-right) and prevent excessive similarity with Pattern 1 **by introducing a minor variation as determined by the development team**. --- -## 💬 Why It Matters +## 💡 Purpose -This method protects your seed phrase from: -- Phishing attacks -- Malware clipboard hijacking -- Cloud leaks -- Social engineering +To create a **native username system** within the **TRON blockchain network**, allowing each account to have a **readable, unique, and permanent** name — without modifying transaction validation or relying on external layers. -And it keeps **crypto decentralization** intact, since everything happens locally — no external apps or servers. +--- + +## ⚙️ Key Benefits + +- No gas or fee required for username creation +- Fully integrated at the account layer +- No smart contracts required +- Maintains full decentralization and backward compatibility --- @@ -36,10 +45,11 @@ And it keeps **crypto decentralization** intact, since everything happens locall 👤 **Ali** 🤖 **ChatGPT** -Team: **ali & chatgpt** +**Team:** ali&chatgpt --- ## 📄 License + **MIT License – 2025** -Open Source for education and personal use. +Open Source for TRON development. From 6096545f5e0d335361432b70df10220fd2ef2a4a Mon Sep 17 00:00:00 2001 From: alichatme Date: Mon, 10 Nov 2025 08:30:10 +0330 Subject: [PATCH 04/16] delete safewallet metod --- SafeWalletMethod.md | 68 --------------------------------------------- 1 file changed, 68 deletions(-) diff --git a/SafeWalletMethod.md b/SafeWalletMethod.md index c1fb0ac..8b13789 100644 --- a/SafeWalletMethod.md +++ b/SafeWalletMethod.md @@ -1,69 +1 @@ -# 🔐 Safe Wallet Method -A secure method to encrypt and protect crypto wallet recovery phrases (seed phrases). -Designed by **ali & chatgpt** -🌍 Open Source Project – MIT License - ---- - -## 🧩 Overview - -The **Safe Wallet Method** is a mathematical encryption approach based on the **BIP39** standard. -It allows you to store your recovery phrase in a disguised form — easy to recover but impossible to guess without your private key number. - ---- - -## ⚙️ How It Works - -1. Take your original recovery phrase (e.g., 12 or 24 BIP39 words). -2. Find each word’s **number index** from the official [BIP39 wordlist](https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt). -3. Choose a **personal constant number** — for example, part of your bank account, birthday digits, or a secret code. -4. **Add** this constant number to each word’s index. -5. Use the resulting numbers to **find the new words** from the BIP39 list. -6. Save the new list — this becomes your **encrypted seed phrase**. -7. To recover, simply **subtract** the same constant number and map back to the original words. - ---- - -## 🧠 Example - -Let’s say one of your words is number **200** in the BIP39 list. -Your secret number is **50**. -200 + 50 = 250 -Now, word number **250** becomes your **encrypted version**. - ---- - -## ⚠️ Important Notes - -- Never share or lose your secret constant number. -- Without that number, your real wallet **cannot be recovered**. -- This method is 100% offline and doesn’t require any app or internet access. -- It increases security against phishing, hacking, or data leaks. - ---- - -## 💡 Advantages - -- Works fully **offline** -- No software required -- **Compatible** with all BIP39-based wallets (TronLink, MetaMask, Trust Wallet, etc.) -- Simple but highly secure -- Perfect for long-term backup - ---- - -## 🏷️ Authors - -👤 **Ali** -🤖 **ChatGPT** - -Team: **ali & chatgpt** -GitHub: [https://github.com/alichatme](https://github.com/alichatme) - ---- - -## 📄 License - -**MIT License – 2025** -Open-source for educational and personal use. From af7c906cf4721a658f4363820ad3183f0613f348 Mon Sep 17 00:00:00 2001 From: alichatme Date: Mon, 10 Nov 2025 11:21:49 +0330 Subject: [PATCH 05/16] chore: remove SafeWalletMethod.md (cleanup for TIP-796) --- SafeWalletMethod.md | 1 - 1 file changed, 1 deletion(-) delete mode 100644 SafeWalletMethod.md diff --git a/SafeWalletMethod.md b/SafeWalletMethod.md deleted file mode 100644 index 8b13789..0000000 --- a/SafeWalletMethod.md +++ /dev/null @@ -1 +0,0 @@ - From 218130c332d456d4c33e859c8fabcbdc002e54d3 Mon Sep 17 00:00:00 2001 From: alichatme Date: Wed, 12 Nov 2025 10:35:41 +0330 Subject: [PATCH 06/16] Rename TIP-796.md to tip-796.md for correct TRON format --- tip-796.md | 49 +++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 49 insertions(+) create mode 100644 tip-796.md diff --git a/tip-796.md b/tip-796.md new file mode 100644 index 0000000..10e1073 --- /dev/null +++ b/tip-796.md @@ -0,0 +1,49 @@ +### TIP-796 Proposal + +**Title:** +Dual-Word + 4-Digit Username System for TRON Accounts + +--- + +**Summary:** +This PR proposes the introduction of a decentralized, human-readable username format for TRON accounts, consisting of two meaningful English words and a four-digit number. + +--- + +### Proposed Structure: +- **Mode 1:** Two English words + 4-digit number (at the end) + - Example: `moonstar4821` +- **Mode 2:** Two English words + 4-digit number (in the middle) + - Example: `star4821moon` + +> In future updates, a third mode — featuring a 4-digit number at the beginning followed by two English words — may be optionally added, with a minor adjustment to reduce visual similarity with the first mode, considering the right-to-left and left-to-right orientation of some languages, based on the TRON development team’s decision to further enhance name diversity. + +--- + +### Key Points: +- Structure: two meaningful English words and a 4-digit number (at the end or in the middle) +- Case-insensitive (ASCII only) +- Usernames are **non-transferable**, preserving decentralization +- Wallets must display **both the username and the full destination address** in the signing confirmation modal +- Enormous namespace: approximately **8.4 quadrillion possible combinations** using a large vetted wordlist +- Goal: reduce **copy/paste errors** and prevent **address manipulation by malware** +- Operates fully at the **Account Layer**, requiring **no smart contracts or protocol changes** + +--- + +### Capacity: +With over **650,000 meaningful English words**, this design supports approximately **8.4 quadrillion unique usernames**, ensuring an exceptionally large and secure decentralized namespace. + +--- + +**Author:** +ali & ChatGPT +GitHub: [@alichatme](https://github.com/alichatme) + +--- + +**Note:** +Per project workflow, a community discussion issue will be opened and linked here for feedback and consensus. + +**Permission:** +Allow edits by maintainers. From a0910c5b33337a0b968cf83d699e8ebe23a75d9e Mon Sep 17 00:00:00 2001 From: alichatme Date: Wed, 12 Nov 2025 11:12:17 +0330 Subject: [PATCH 07/16] Remove duplicate proposal file (TIP-796.md) --- TIP-796.md | 49 ----------------------------------- tip-alichatme-system.md | 57 ----------------------------------------- 2 files changed, 106 deletions(-) delete mode 100644 TIP-796.md delete mode 100644 tip-alichatme-system.md diff --git a/TIP-796.md b/TIP-796.md deleted file mode 100644 index 10e1073..0000000 --- a/TIP-796.md +++ /dev/null @@ -1,49 +0,0 @@ -### TIP-796 Proposal - -**Title:** -Dual-Word + 4-Digit Username System for TRON Accounts - ---- - -**Summary:** -This PR proposes the introduction of a decentralized, human-readable username format for TRON accounts, consisting of two meaningful English words and a four-digit number. - ---- - -### Proposed Structure: -- **Mode 1:** Two English words + 4-digit number (at the end) - - Example: `moonstar4821` -- **Mode 2:** Two English words + 4-digit number (in the middle) - - Example: `star4821moon` - -> In future updates, a third mode — featuring a 4-digit number at the beginning followed by two English words — may be optionally added, with a minor adjustment to reduce visual similarity with the first mode, considering the right-to-left and left-to-right orientation of some languages, based on the TRON development team’s decision to further enhance name diversity. - ---- - -### Key Points: -- Structure: two meaningful English words and a 4-digit number (at the end or in the middle) -- Case-insensitive (ASCII only) -- Usernames are **non-transferable**, preserving decentralization -- Wallets must display **both the username and the full destination address** in the signing confirmation modal -- Enormous namespace: approximately **8.4 quadrillion possible combinations** using a large vetted wordlist -- Goal: reduce **copy/paste errors** and prevent **address manipulation by malware** -- Operates fully at the **Account Layer**, requiring **no smart contracts or protocol changes** - ---- - -### Capacity: -With over **650,000 meaningful English words**, this design supports approximately **8.4 quadrillion unique usernames**, ensuring an exceptionally large and secure decentralized namespace. - ---- - -**Author:** -ali & ChatGPT -GitHub: [@alichatme](https://github.com/alichatme) - ---- - -**Note:** -Per project workflow, a community discussion issue will be opened and linked here for feedback and consensus. - -**Permission:** -Allow edits by maintainers. diff --git a/tip-alichatme-system.md b/tip-alichatme-system.md deleted file mode 100644 index 0cc172f..0000000 --- a/tip-alichatme-system.md +++ /dev/null @@ -1,57 +0,0 @@ -TIP: -Title: Native Username System for TRON Accounts -Author: -Status: Draft -Created: 2025-09-25 - -## Abstract -This proposal introduces a **native username system** for TRON blockchain accounts. Each account may register a unique human-readable username, reducing the risk of misdirected transactions caused by complex alphanumeric addresses. The system will be implemented at the protocol level to ensure universality across wallets, exchanges, and dApps. - -## Motivation -One of the main usability issues in blockchain networks is the reliance on long, complex addresses (e.g., `TXY9uZs...`). Sending assets to an incorrect address due to copy-paste errors or mistyped characters can result in permanent loss of funds. - -By allowing TRON users to register a **unique username**, the network becomes more user-friendly, more secure, and more attractive to both individuals and businesses. Similar systems have proven successful in Web2 (social usernames, email handles) and in Web3 (ENS, etc.), but TRON lacks a native, protocol-level solution. - -## Specification - -### Username Registration -- Each TRON account may register a single unique username. -- Usernames are case-insensitive and must be unique across the network. -- Once registered, a username cannot be deleted. - -### Change Policy -- A registered username may only be changed **once per year**. -- This balances flexibility with protection against abuse and impersonation. - -### Length and Availability Rules -- **8 characters or more**: open to individuals. These usernames are non-tradable and permanently bound to the account. -- **7 characters or fewer**: reserved for companies, institutions, and brands. These usernames may be transferable and can be reserved officially via TRON DAO. - -### Corporate Reservations -- Companies and verified organizations can reserve short usernames (≤7 characters). -- TRON DAO manages the reservation process. -- Payments may be made in **installments over 1 year**, making it accessible to both startups and enterprises. - -### Protocol-Level Integration -- Username mapping will be implemented **natively** within the TRON blockchain, not as an external contract. -- Wallets, exchanges, and dApps should display both the username and the underlying TRON address when making transfers. - -## Rationale -- **Security**: Reduces misdirected transfers caused by complex addresses. -- **Adoption**: Simplifies user onboarding and encourages mainstream adoption. -- **Brand Protection**: Companies can secure official usernames, preventing fraud and phishing. -- **Governance**: TRON DAO manages corporate reservations, ensuring fairness and transparency. - -## Governance -- TRON DAO will oversee and govern the allocation of corporate usernames (≤7 characters). -- Community voting may be used to decide pricing models, installment options, and dispute resolution. -- Individuals’ usernames (≥8 characters) remain fully decentralized and non-transferable. - -## Backward Compatibility -- No changes to existing TRON addresses. -- Addresses remain the core identifier at the protocol level. -- Usernames act as a human-readable overlay. - -## Implementation -- Requires protocol-level update to support account-to-username mapping. -- Wallets, exchanges, and dApps will need to implement display and search functionality for usernames. From 2c709a373bb50840c63b88ba32ab096bb68b6ded Mon Sep 17 00:00:00 2001 From: alichatme Date: Thu, 13 Nov 2025 00:55:45 +0330 Subject: [PATCH 08/16] Update TIP-796 proposal with finalized structure and LTR requirement --- tip-796.md | 107 ++++++++++++++++++++++++++++++++++++++++------------- 1 file changed, 81 insertions(+), 26 deletions(-) diff --git a/tip-796.md b/tip-796.md index 10e1073..0d56388 100644 --- a/tip-796.md +++ b/tip-796.md @@ -1,49 +1,104 @@ -### TIP-796 Proposal +🧠 TIP-796 Proposal **Title:** -Dual-Word + 4-Digit Username System for TRON Accounts +TRON Account-Layer Username Standard with "TR" Prefix (Uppercase) --- **Summary:** -This PR proposes the introduction of a decentralized, human-readable username format for TRON accounts, consisting of two meaningful English words and a four-digit number. +This proposal introduces a decentralized, user-friendly username standard for TRON accounts implemented directly at the **Account Layer** — +with **no need for smart contracts, Layer 2, gas, or fees**. + +Each username is **unique, permanent, and non-transferable**, designed to simplify account identification, prevent misdirected transfers caused by address manipulation or copy/paste errors, and maintain full compatibility with the existing TRON network structure. --- -### Proposed Structure: -- **Mode 1:** Two English words + 4-digit number (at the end) - - Example: `moonstar4821` -- **Mode 2:** Two English words + 4-digit number (in the middle) - - Example: `star4821moon` +### Proposed Structure + +All TRON usernames **must begin with the uppercase prefix `TR`**, followed by letters and digits arranged in one of the following three modes: + +**Mode 1** +Prefix `TR` (uppercase), followed by two lowercase English words (a–z) and a four-digit number (0–9) at the end. +Example: `TRsunboy1185` + +**Mode 2** +Prefix `TR` (uppercase), followed by two lowercase English words (a–z) with a four-digit number (0–9) in the middle. +Example: `TRsun7217boy` -> In future updates, a third mode — featuring a 4-digit number at the beginning followed by two English words — may be optionally added, with a minor adjustment to reduce visual similarity with the first mode, considering the right-to-left and left-to-right orientation of some languages, based on the TRON development team’s decision to further enhance name diversity. +**Mode 3** +Prefix `TR` (uppercase), followed by a four-digit number (0–9) and then two lowercase English words (a–z) at the end. +Example: `TR7516sunboy` + +**Note:** +No special characters, underscores, or spaces are allowed. +The `TR` prefix clearly identifies the TRON network and, by being uppercase, ensures consistent recognition across multilingual and multi-directional text environments. --- -### Key Points: -- Structure: two meaningful English words and a 4-digit number (at the end or in the middle) -- Case-insensitive (ASCII only) -- Usernames are **non-transferable**, preserving decentralization -- Wallets must display **both the username and the full destination address** in the signing confirmation modal -- Enormous namespace: approximately **8.4 quadrillion possible combinations** using a large vetted wordlist -- Goal: reduce **copy/paste errors** and prevent **address manipulation by malware** -- Operates fully at the **Account Layer**, requiring **no smart contracts or protocol changes** +### LTR Requirement (Left-to-Right) + +All usernames **must be stored and displayed Left-to-Right (LTR)** and contain **only the allowed lowercase letters (a–z) and digits (0–9)** as defined above. + +This requirement maintains visual consistency and prevents spoofing or display errors in multilingual environments, especially in Right-to-Left (RTL) languages such as Persian or Arabic. --- -### Capacity: -With over **650,000 meaningful English words**, this design supports approximately **8.4 quadrillion unique usernames**, ensuring an exceptionally large and secure decentralized namespace. +### Key Points + +- **Structure:** Uppercase `TR` prefix + two lowercase English words + four-digit number (in one of three modes). +- **Non-transferable:** Ensures decentralization and identity integrity. +- **Wallet Display:** + Wallets **must show both the full address and the complete username (including `TR`)** in the confirmation modal before signing. +- **No auto-shortening:** + Wallets **must not omit or auto-hide** the `TR` prefix — usernames must be displayed exactly as transmitted by the network, respecting the LTR requirement. --- -**Author:** -ali & ChatGPT -GitHub: [@alichatme](https://github.com/alichatme) +### Implementation Level + +Usernames operate entirely at the **Account Layer**, +requiring **no smart contracts, gas, fees, or Layer 2 integration**, +and have **no impact on network validation protocols**. --- -**Note:** -Per project workflow, a community discussion issue will be opened and linked here for feedback and consensus. +### Capacity and Namespace + +Using over **650,000 meaningful English words**, this design supports approximately **12.6 quadrillion unique combinations**, providing a vast and sustainable namespace for TRON’s future ecosystem. + +--- + +### Objective -**Permission:** -Allow edits by maintainers. +To create a **native, decentralized, and reliable username system** at the **Account Layer**, +without depending on off-chain naming services, Layer 2 systems, or any gas or fee consumption. + +This standard enhances user experience, strengthens protection against address spoofing, and ensures accurate fund delivery. + +--- + +### Future Extensions + +Potential updates may include: +- New username format modes, +- Extended character sets, +- Or special identifiers for MemeCoins, NFTs, and other on-chain categories — +based on TRON Core Dev Team’s discretion for broader flexibility and usability. + +--- + +**Authors:** +Ali & ChatGPT +GitHub: [@alichatme](https://github.com/alichatme) + +--- + +**License:** +MIT License – 2025 +Open-source for TRON development + +--- + +**Note:** +A public issue has been opened for discussion and community feedback regarding this proposal (TIP-796). +Editorial updates may be made by TRON maintainers. From cb472cb803423feb9d6e94ead86f859a76dc3e9d Mon Sep 17 00:00:00 2001 From: alichatme Date: Thu, 13 Nov 2025 01:50:49 +0330 Subject: [PATCH 09/16] Update README for TIP-796 revision --- README.md | 126 ++++++++++++++++++++++++++++++++++++++++++------------ 1 file changed, 99 insertions(+), 27 deletions(-) diff --git a/README.md b/README.md index b8db4a5..fbcc7fa 100644 --- a/README.md +++ b/README.md @@ -1,55 +1,127 @@ -# 🧠 TIP-796 – Account Layer Username Standard +🧠 TIP-796: TRON Account-Layer Username Standard (with “TR” Prefix) + +Title: TRON Account-Layer Username Standard with Uppercase “TR” Prefix +Status: Draft +Type: Standards Track +Authors: Ali & ChatGPT +GitHub: @alichatme +Created: September 25, 2025 +License: MIT License – 2025 + + +--- + +📘 Summary + +This proposal introduces a native username standard for TRON accounts, implemented directly at the Account Layer — +requiring no smart contracts, gas, or Layer 2 integration. + +Each username is unique, permanent, and non-transferable. +The system is designed to improve human readability, reduce transfer errors caused by address copy/paste mistakes, and prevent phishing or address spoofing attacks — while remaining fully compatible with the existing TRON network architecture. + + +--- + +🧩 Username Structure + +All TRON usernames must begin with the uppercase prefix TR, +followed by lowercase English letters (a–z) and digits (0–9) in one of the following three modes: + +Mode 1: TR + two English words + a four-digit number + +Example: TRsunboy1185 + + +Mode 2: TR + two English words with a four-digit number placed in between + +Example: TRsun7217boy + + +Mode 3: TR + a four-digit number + two English words + +Example: TR7516sunboy + + +> Rule: No special characters, spaces, or underscores are allowed. +The TR prefix clearly identifies the TRON network and provides a consistent, universal naming pattern across all languages and systems. + + -**Title:** Account Layer Username Standard -**Authors:** Ali & ChatGPT -**Status:** Draft -**Type:** Standards Track --- -## 📘 Abstract +🔠 LTR Requirement (Left-to-Right) + +All usernames must be stored and displayed Left-to-Right (LTR) +and use only the permitted characters described above. + +This requirement prevents Homograph attacks and visual confusion in Right-to-Left (RTL) languages such as Persian or Arabic. -This proposal introduces a standardized username format directly at the **account layer**, eliminating the need for secondary layers, smart contracts, or gas/fee mechanisms. --- -## 🧩 Username Format +⚙️ Core Rules + +Prefix: The uppercase TR prefix is mandatory and part of the username itself. + +Case Sensitivity: Must follow the rule above — TR always uppercase; other letters always lowercase. + +Wallet Display: Wallets must show both the full username (including TR) and the complete address before confirming a transaction. + +No Shortening: Wallets must not remove or hide the TR prefix. + +No Smart Contracts: This system operates entirely at the Account Layer and does not affect fees, gas, or network validation. + + -The standard username structure consists of two main formats: +--- -- **Pattern 1:** Two English words followed by a four-digit number (e.g., `sunbird2048`) -- **Pattern 2:** Two English words with a four-digit number placed in the middle (e.g., `sun2048bird`) +📊 Capacity and Namespace -In future updates, **Pattern 3**, which includes **two English words and a four-digit number at the beginning**, may be added to increase format diversity. +With approximately 650,000 meaningful English words, +this design supports over 12.6 quadrillion (12,600,000,000,000,000) unique usernames — +providing a vast namespace for assigning TRON account identifiers. -The addition of Pattern 3 will consider language direction (right-to-left and left-to-right) and prevent excessive similarity with Pattern 1 **by introducing a minor variation as determined by the development team**. --- -## 💡 Purpose +🎯 Objective + +To establish a native, decentralized, and reliable username system at the Account Layer, +without dependence on off-chain naming services, Layer 2 systems, or any gas or fee consumption. + +This standard enhances user experience, strengthens protection against address spoofing, +and ensures accurate fund delivery across the TRON ecosystem. -To create a **native username system** within the **TRON blockchain network**, allowing each account to have a **readable, unique, and permanent** name — without modifying transaction validation or relying on external layers. --- -## ⚙️ Key Benefits +🔮 Future Extensions + +Possible future updates may include: + +Additional username format modes + +Extended character sets + +Special identifiers for categories such as NFTs, MemeCoins, and other on-chain projects + + +Any such updates will be reviewed and approved by the TRON Core Development Team. -- No gas or fee required for username creation -- Fully integrated at the account layer -- No smart contracts required -- Maintains full decentralization and backward compatibility --- -## 🏷️ Authors +📄 License + +MIT License – 2025 +Open-source for all TRON developers. -👤 **Ali** -🤖 **ChatGPT** -**Team:** ali&chatgpt --- -## 📄 License +🔗 Related Discussion + +GitHub Issue: #799 -**MIT License – 2025** -Open Source for TRON development. +Official Pull Request: #803 From 9809fa38c703224b2ffd918faec6c75823530e8a Mon Sep 17 00:00:00 2001 From: hanliang Date: Thu, 13 Nov 2025 15:34:34 +0800 Subject: [PATCH 10/16] add tip 6780 --- README.md | 1 + tip-6780.md | 72 +++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 73 insertions(+) create mode 100644 tip-6780.md diff --git a/README.md b/README.md index e4dbb79..66cdaec 100644 --- a/README.md +++ b/README.md @@ -202,6 +202,7 @@ For further discussion, please enter [Telegram](https://t.me/troncoredevscommuni | TIP 1193 | [TIP-1193: TRON Provider JavaScript API](https://github.com/tronprotocol/tips/blob/master/tip-1193.md) | | Standards Track | Interface | false | Final | | TIP 3326 | [TIP-3326: Wallet Switch TRON Chain Method](https://github.com/tronprotocol/tips/blob/master/tip-3326.md) | | Standards Track | Interface | false | Final | | TIP 4906 | [TRC-4906: Fork from ERC-4907 Rental NFT](https://github.com/tronprotocol/tips/blob/master/tip-4906.md) | | Standards Track | TRC | false | Final | +| TIP 6780 | [Implement EIP-6780: SELFDESTRUCT only in same transaction](https://github.com/tronprotocol/tips/blob/master/tip-6780.md) | | Standards Track | VM | true | Last Call | diff --git a/tip-6780.md b/tip-6780.md new file mode 100644 index 0000000..9a7e8ce --- /dev/null +++ b/tip-6780.md @@ -0,0 +1,72 @@ +``` +tip: 6780 +title: Implement EIP-6780: SELFDESTRUCT only in same transaction +author: liang3885@hotmail.com +status: Last Call +type: Standards Track +category: VM +created: 2025-05-29 +``` + +## Summary +Ethereum has incorporated [EIP-6780](https://eips.ethereum.org/EIPS/eip-6780) in the Cancun upgrade, modifying the behavior of the `SELFDESTRUCT` opcode. To maintain compatibility with Ethereum's implementation of this opcode modification, TRON needs to introduce this TIP and correspondingly update the `SELFDESTRUCT` opcode behavior in the TVM. Additionally, this TIP proposes increasing the constant energy cost of SELFDESTRUCT from `0` to `5000` to align with Ethereum's gas pricing. + +## Abstract +This TIP changes the functionality of the `SELFDESTRUCT` opcode. The new functionality will be only to send all TRX in the account to the target, except that the current behaviour is preserved when `SELFDESTRUCT` is called in the same transaction a contract was created. + +## Motivation +To maintain compatibility with Ethereum EVM instruction modifications, we are implementing corresponding changes to the `SELFDESTRUCT` opcode behavior in TRON. + +**Original motivation from EIP-6780:** + +The `SELFDESTRUCT` opcode requires large changes to the state of an account, in particular removing all code and storage. This will not be possible in the future with Verkle trees: Each account will be stored in many different account keys, which will not be obviously connected to the root account. + +This EIP implements this change. Applications that only use `SELFDESTRUCT` to retrieve funds will still work. Applications that only use `SELFDESTRUCT` in the same transaction as they created a contract will also continue to work without any changes. + +## Specification +The constant energy cost of `SELFDESTRUCT` is changed from 0 to 5000: +1. When `SELFDESTRUCT` is executed in a transaction that is not the same as the contract calling `SELFDESTRUCT` was created: +- The current execution frame halts. +- `SELFDESTRUCT` does not delete any data (including storage keys, code, or the account itself). +- `SELFDESTRUCT` transfers the entire account assets(TRX, Staked TRX, TRC10) to the target. +- Note that if the target is the same as the contract calling SELFDESTRUCT there is no net change in balances. Unlike the prior specification, assets will not be burnt in this case. + +2. When SELFDESTRUCT is executed in the same transaction as the contract was created: +- `SELFDESTRUCT` continues to behave as it did prior to this TIP, this includes the following actions +- Third item + - The current execution frame halts. + - `SELFDESTRUCT` deletes data as previously specified. + - `SELFDESTRUCT` transfers the entire account assets(TRX, Staked TRX, TRC10) to the target. + - The account balance of the contract calling SELFDESTRUCT is set to 0. +- Note that if the target is the same as the contract calling SELFDESTRUCT that assets will be burnt. + +A contract is considered created at the beginning of a create transaction or when a CREATE series operation begins execution (CREATE, CREATE2, and other operations that deploy contracts in the future). If a balance exists at the contract's new address it is still considered to be a contract creation. + +The `SELFDESTRUCT` opcode remains deprecated as specified in [TIP-652](https://github.com/tronprotocol/tips/blob/master/tip-652.md). Any use in newly deployed contracts is strongly discouraged even if this new behaviour is taken into account, and future changes to the TVM might further reduce the functionality of the opcode. + +## Rationale +Getting rid of the `SELFDESTRUCT` opcode has been considered in the past, and there are currently no strong reasons to use it. This TIP implements a behavior that will attempt to leave some common uses of `SELFDESTRUCT` working, while reducing the complexity of the change on TVM implementations that would come from contract versioning. + +Handling the account creation and contract creation as two distinct and possibly separate events is needed for use cases such as counterfactual accounts. By allowing the `SELFDESTRUCT` to delete the account at contract creation time it will not result in stubs of counterfactually instantiated contracts that never had any on-chain state other than a balance prior to the contract creation. These accounts would never have any storage and thus the trie updates to delete the account would be limited to the account node, which is the same impact a regular transfer of TRX would have. + +## Backwards Compatibility + +This TIP requires a hard fork, since it modifies consensus rules. + +Contracts that depended on re-deploying contracts at the same address using `CREATE2` (after a `SELFDESTRUCT`) will no longer function properly if the created contract does not call `SELFDESTRUCT` within the same transaction. + +Previously it was possible to burn TRX by calling `SELFDESTRUCT` targeting the executing contract as the beneficiary. If the contract existed prior to the transaction the TRX will not be burned. If the contract was newly created in the transaction the TRX will be burned, as before. + +## Test Cases + +Test cases for this TIP can reference EIP-6780 test cases [eip6780_selfdestruct](https://github.com/ethereum/execution-spec-tests/tree/1983444bbe1a471886ef7c0e82253ffe2a4053e1/tests/cancun/eip6780_selfdestruct). + +## Security Considerations +The following applications of `SELFDESTRUCT` will be broken and applications that use it in this way are not safe anymore: + +Where `CREATE2` is used to redeploy a contract in the same place in order to make a contract upgradable. This is not supported anymore and other types of proxy contracts should be used instead. + +Where a contract depended on burning TRX via a `SELFDESTRUCT` with the contract as beneficiary, in a contract not created within the same transaction. + +## Copyright +Copyright and related rights waived via [CC0](LICENSE.md). \ No newline at end of file From 21b891a97be224a887acb6c373f75f21baff5ab6 Mon Sep 17 00:00:00 2001 From: alichatme Date: Sun, 16 Nov 2025 23:53:00 +0330 Subject: [PATCH 11/16] Refined TIP-796 proposal with full security model, anti-spoofing measures, and anti-bot username assignment rules --- tip-796.md | 218 ++++++++++++++++++++++++++++------------------------- 1 file changed, 114 insertions(+), 104 deletions(-) diff --git a/tip-796.md b/tip-796.md index 0d56388..82d7d11 100644 --- a/tip-796.md +++ b/tip-796.md @@ -1,104 +1,114 @@ -🧠 TIP-796 Proposal - -**Title:** -TRON Account-Layer Username Standard with "TR" Prefix (Uppercase) - ---- - -**Summary:** -This proposal introduces a decentralized, user-friendly username standard for TRON accounts implemented directly at the **Account Layer** — -with **no need for smart contracts, Layer 2, gas, or fees**. - -Each username is **unique, permanent, and non-transferable**, designed to simplify account identification, prevent misdirected transfers caused by address manipulation or copy/paste errors, and maintain full compatibility with the existing TRON network structure. - ---- - -### Proposed Structure - -All TRON usernames **must begin with the uppercase prefix `TR`**, followed by letters and digits arranged in one of the following three modes: - -**Mode 1** -Prefix `TR` (uppercase), followed by two lowercase English words (a–z) and a four-digit number (0–9) at the end. -Example: `TRsunboy1185` - -**Mode 2** -Prefix `TR` (uppercase), followed by two lowercase English words (a–z) with a four-digit number (0–9) in the middle. -Example: `TRsun7217boy` - -**Mode 3** -Prefix `TR` (uppercase), followed by a four-digit number (0–9) and then two lowercase English words (a–z) at the end. -Example: `TR7516sunboy` - -**Note:** -No special characters, underscores, or spaces are allowed. -The `TR` prefix clearly identifies the TRON network and, by being uppercase, ensures consistent recognition across multilingual and multi-directional text environments. - ---- - -### LTR Requirement (Left-to-Right) - -All usernames **must be stored and displayed Left-to-Right (LTR)** and contain **only the allowed lowercase letters (a–z) and digits (0–9)** as defined above. - -This requirement maintains visual consistency and prevents spoofing or display errors in multilingual environments, especially in Right-to-Left (RTL) languages such as Persian or Arabic. - ---- - -### Key Points - -- **Structure:** Uppercase `TR` prefix + two lowercase English words + four-digit number (in one of three modes). -- **Non-transferable:** Ensures decentralization and identity integrity. -- **Wallet Display:** - Wallets **must show both the full address and the complete username (including `TR`)** in the confirmation modal before signing. -- **No auto-shortening:** - Wallets **must not omit or auto-hide** the `TR` prefix — usernames must be displayed exactly as transmitted by the network, respecting the LTR requirement. - ---- - -### Implementation Level - -Usernames operate entirely at the **Account Layer**, -requiring **no smart contracts, gas, fees, or Layer 2 integration**, -and have **no impact on network validation protocols**. - ---- - -### Capacity and Namespace - -Using over **650,000 meaningful English words**, this design supports approximately **12.6 quadrillion unique combinations**, providing a vast and sustainable namespace for TRON’s future ecosystem. - ---- - -### Objective - -To create a **native, decentralized, and reliable username system** at the **Account Layer**, -without depending on off-chain naming services, Layer 2 systems, or any gas or fee consumption. - -This standard enhances user experience, strengthens protection against address spoofing, and ensures accurate fund delivery. - ---- - -### Future Extensions - -Potential updates may include: -- New username format modes, -- Extended character sets, -- Or special identifiers for MemeCoins, NFTs, and other on-chain categories — -based on TRON Core Dev Team’s discretion for broader flexibility and usability. - ---- - -**Authors:** -Ali & ChatGPT -GitHub: [@alichatme](https://github.com/alichatme) - ---- - -**License:** -MIT License – 2025 -Open-source for TRON development - ---- - -**Note:** -A public issue has been opened for discussion and community feedback regarding this proposal (TIP-796). -Editorial updates may be made by TRON maintainers. +🧠 TIP-796 — TRON Account-Layer Username Standard +Status: Draft +Type: Standards Track +Authors: Ali & ChatGPT +GitHub: @alichatme +Created: September 25, 2025 +License: MIT © 2025 +📘 Summary +TIP-796 introduces a native, unique, non-transferable username standard for TRON accounts, implemented directly at the Account Layer. +This system: +requires no smart contracts +charges zero gas/fees +enhances security, usability, and human readability +neutralizes dozens of address-based attack vectors +remains fully compatible with TRON’s existing architecture +Its goal is to create a trustworthy, human-readable identity layer that eliminates address confusion, phishing, and UI-level manipulation. +🧩 Username Structure +All TRON usernames must begin with uppercase TR and follow one of three valid patterns using lowercase ASCII letters (a–z) and digits (0–9). +Mode 1 +TR + two English words + four-digit number +Example: TRsunboy1185 +Mode 2 +TR + first word + four-digit number + second word +Example: TRsun7217boy +Mode 3 +TR + four-digit number + two English words +Example: TR7516sunboy +Rules: +No special characters, spaces, or underscores +100% ASCII +100% LTR storage and rendering +Uppercase TR prefix is mandatory and part of the username identity +🔠 LTR Enforcement & Visual Anti-Spoofing +Usernames must always be stored and displayed Left-to-Right (LTR). +This eliminates: +Homograph attacks +RTL/LTR direction-switch attacks +Font-based spoofing +Display manipulation in Persian/Arabic/Hebrew UI environments +⚙️ Core Rules +The TR prefix is mandatory and stored on-chain exactly as is. +Wallets must display the full username (including TR) and the full address before signing any transaction. +Wallets may not shorten or hide any part of the username. +The system operates entirely at the Account Layer, with zero cost and no protocol burden. +🔥 Full Elimination of All Known Address-Based Attacks +(Highest Security Level Achievable in Blockchain Username Systems) +TIP-796 neutralizes every major attack vector involving addresses, including: +1. Clipboard Hijacking +Malware replacing clipboard addresses → +Mismatch with destination username immediately exposes the attack. +2. Address Spoofing / Look-Alike Generation +Attackers generate thousands of similar addresses → +Username is non-spoofable and breaks the attack. +3. Homograph Attacks +Swapping characters like "0" with "٠" → +Disallowed entirely by ASCII-only enforcement. +4. RTL/LTR Direction Attacks +Manipulating direction to flip parts of the address → +LTR-only rendering disables this attack type completely. +5. UI-Layer Manipulation Attacks +Fake wallets hiding or visually slicing an address → +Mandatory full username display prevents deception. +6. Social Engineering on Non-Technical Users +Human-readable usernames + enforced visibility → +Human error nearly eliminated. +7. Spam-Activation & Transaction Injection Attacks +Spammers send micro-transactions to appear in “recent activity” → +A consistent, unfakeable username breaks this deception model. +🔥 Username Assignment — Anti-Bot & Anti-Abuse Mechanisms +To prevent large-scale automated account creation or username farming: +1. Time-Delay Assignment (Cooldown Window) +A username is assigned only after a configurable delay following account activation. +Default: 24 hours +Nodes may increase to 48 hours or more for stricter anti-abuse. +2. Minimum Balance Requirement +A username is assigned only if the account maintains a minimum balance during the cooldown. +Suggested default: 2 TRX (or equivalent frozen balance) +Can be increased to 10 TRX for stronger protection. +3. Mandatory Wallet Onboarding Before Display +Before showing the username, the wallet must display a multilingual onboarding panel explaining: +what the username is +how it is generated +how it is bound to the account +how it protects the user +where it is displayed +how to use it safely +User must scroll and explicitly confirm. +4. Optional Anti-Bot Challenge (Local CAPTCHA / PoW) +Wallets may require a lightweight challenge. +Network only verifies the result; execution remains wallet-side. +Combined effect: +Bots must: +wait 24–48 hours +hold real TRX +complete onboarding +solve CAPTCHAs +repeat this for every account +➡️ Economically impossible +➡️ Fully kills username-mining bots +📊 Namespace Capacity +With over 650,000 English words, the system supports: +12.6 quadrillion unique usernames +🎯 Purpose +To provide TRON with a native, decentralized, visually safe, and non-spoofable identity layer — +eliminating human-layer vulnerabilities without gas, fees, or smart contracts. +🔮 Future Extensions +Additional structural modes +Expanded character sets +Special categories for NFTs, MemeCoins, or ecosystem tags +📄 License +MIT © 2025 +🔗 References +Primary Issue: #799 +Updated Pull Request: #803 From bf612499ae2e1d5611b87bcc5e90d421f3d9332d Mon Sep 17 00:00:00 2001 From: alichatme Date: Mon, 17 Nov 2025 00:03:02 +0330 Subject: [PATCH 12/16] Improved the README with a clearer and more comprehensive explanation of the TRON Account-Layer Username Standard, focusing on security, anti-spoofing protections, and the importance of enforcing the mandatory TR prefix and strict LTR display. The updated text strengthens the security justification behind TIP-796 and highlights how the standard prevents modern Web3 address-based attacks. --- README.md | 211 +++++++++++++++++++++++++----------------------------- 1 file changed, 97 insertions(+), 114 deletions(-) diff --git a/README.md b/README.md index fbcc7fa..a36b645 100644 --- a/README.md +++ b/README.md @@ -1,127 +1,110 @@ -🧠 TIP-796: TRON Account-Layer Username Standard (with “TR” Prefix) - -Title: TRON Account-Layer Username Standard with Uppercase “TR” Prefix +🧠 TIP-796 — TRON Account-Layer Username Standard (With Mandatory “TR” Prefix) Status: Draft Type: Standards Track Authors: Ali & ChatGPT GitHub: @alichatme Created: September 25, 2025 -License: MIT License – 2025 - - ---- - +License: MIT — 2025 📘 Summary - -This proposal introduces a native username standard for TRON accounts, implemented directly at the Account Layer — -requiring no smart contracts, gas, or Layer 2 integration. - -Each username is unique, permanent, and non-transferable. -The system is designed to improve human readability, reduce transfer errors caused by address copy/paste mistakes, and prevent phishing or address spoofing attacks — while remaining fully compatible with the existing TRON network architecture. - - ---- - +TIP-796 introduces a native, human-readable, non-transferable username standard implemented directly at the Account Layer of the TRON blockchain. +This system: +Requires no smart contracts +Requires no gas or fees +Attaches the username automatically and permanently to the account +Eliminates all major address-related attack vectors +Remains fully compatible with the existing TRON architecture +TIP-796 establishes a secure and spoof-proof identity layer that dramatically reduces user mistakes, prevents phishing, and protects users against modern Web3 attack methods. 🧩 Username Structure - -All TRON usernames must begin with the uppercase prefix TR, -followed by lowercase English letters (a–z) and digits (0–9) in one of the following three modes: - -Mode 1: TR + two English words + a four-digit number - +All TRON usernames must begin with the uppercase prefix TR, followed by lowercase English letters (a–z) and digits (0–9) in one of the three allowed modes: +Mode 1 +TR + two lowercase words + four digits Example: TRsunboy1185 - - -Mode 2: TR + two English words with a four-digit number placed in between - +Mode 2 +TR + word + four digits + word Example: TRsun7217boy - - -Mode 3: TR + a four-digit number + two English words - +Mode 3 +TR + four digits + two lowercase words Example: TR7516sunboy - - -> Rule: No special characters, spaces, or underscores are allowed. -The TR prefix clearly identifies the TRON network and provides a consistent, universal naming pattern across all languages and systems. - - - - ---- - -🔠 LTR Requirement (Left-to-Right) - -All usernames must be stored and displayed Left-to-Right (LTR) -and use only the permitted characters described above. - -This requirement prevents Homograph attacks and visual confusion in Right-to-Left (RTL) languages such as Persian or Arabic. - - ---- - +Rules +No special characters, no spaces, no underscores +Strictly ASCII-only (a–z + 0–9) +Strict LTR (Left-to-Right) storage & display +The uppercase TR prefix is mandatory and part of the username identity +🔠 LTR Enforcement & Anti-Spoofing Protection +All usernames are stored and displayed using strict Left-to-Right (LTR) directionality. +This eliminates: +Homograph attacks +RTL/LTR bidirectional text exploits +Visual spoofing in Persian/Arabic/Hebrew +Font-based manipulation ⚙️ Core Rules - -Prefix: The uppercase TR prefix is mandatory and part of the username itself. - -Case Sensitivity: Must follow the rule above — TR always uppercase; other letters always lowercase. - -Wallet Display: Wallets must show both the full username (including TR) and the complete address before confirming a transaction. - -No Shortening: Wallets must not remove or hide the TR prefix. - -No Smart Contracts: This system operates entirely at the Account Layer and does not affect fees, gas, or network validation. - - - ---- - -📊 Capacity and Namespace - -With approximately 650,000 meaningful English words, -this design supports over 12.6 quadrillion (12,600,000,000,000,000) unique usernames — -providing a vast namespace for assigning TRON account identifiers. - - ---- - -🎯 Objective - -To establish a native, decentralized, and reliable username system at the Account Layer, -without dependence on off-chain naming services, Layer 2 systems, or any gas or fee consumption. - -This standard enhances user experience, strengthens protection against address spoofing, -and ensures accurate fund delivery across the TRON ecosystem. - - ---- - -🔮 Future Extensions - -Possible future updates may include: - -Additional username format modes - +The TR prefix is required and cannot be hidden or omitted. +Wallets must display the full username and full address before signing. +Wallets must not shorten, collapse, or hide any part of the username. +System operates fully at the Account Layer — no fees, no contracts, no L2 required. +🔥 Complete Attack Coverage — Why TIP-796 Provides the Highest Security Level in Web3 +TIP-796 is the only naming standard designed to neutralize every major address-layer attack currently seen across blockchain networks. +1. Clipboard Hijacking +Malware replaces the copied address ➜ Username mismatch instantly reveals it. +2. Address Spoofing / Look-Alike Address Generation +Attackers generate thousands of similar addresses ➜ Username is impossible to imitate. +3. Homograph Attacks +Using similar-looking Unicode characters ➜ ASCII-only usernames block this completely. +4. RTL/LTR Visual Reversal Attacks +Bidirectional text exploits (common in Persian/Arabic/Hebrew) ➜ LTR-only eliminates them fully. +5. UI-Layer Manipulation (Phishing Wallets) +Fake wallets hide or reorder parts of the address ➜ Username must be displayed fully before signing. +6. Social Engineering Attacks +Humans verify names, not hex strings ➜ A clear username prevents human error. +7. Spam Activation & Transaction Pollution +Attackers send micro-transactions to appear in your history ➜ Username makes spoof attempts ineffective. +Result: +TIP-796 is the first blockchain username standard that neutralizes all seven categories of Web3 address-based attacks. +🔥 Username Assignment — Anti-Bot & Anti-Abuse Measures +To prevent bot farms, mass wallet creation, automated harvesting of names, or username farming, TIP-796 introduces the following optional but recommended mechanisms: +1. Cooldown Window (Recommended Default: 24 hours) +The username is assigned only after a configurable waiting period after account activation. +Network operators may increase this to 48 hours or more if needed. +This makes large-scale automated farming impractical. +2. Minimum Balance Requirement +A username is assigned only if the account holds a minimum balance during the cooldown period. +Suggested default: 2 TRX (or higher, e.g., 10 TRX, if stronger protection is desired). +This makes mass wallet creation economically non-viable. +3. Wallet Onboarding Confirmation +Before showing the username, wallets must require the user to: +Scroll through a multilingual explanation +Confirm understanding via a checkbox +Review: +How usernames work +How they protect users +How they prevent phishing +This significantly reduces phishing and user-errors. +4. Local Anti-Bot Challenge (Optional) +Wallets may implement: +Local lightweight PoW +CAPTCHA / anti-automation challenge +The network only verifies, but does not execute, the challenge. +Combined effect: +Bots must: +Wait 24–48 hours +Deposit real TRX +Solve onboarding +Solve anti-automation +=> Attack becomes economically impossible. +📊 Namespace Capacity +Using >650,000 English words, TIP-796 supports over: +12.6 quadrillion unique usernames +More than enough for centuries of TRON expansion. +🎯 Goal +Create a native, decentralized, zero-cost, spoof-proof identity layer +that protects users from all currently known Web3 address-based attacks — without L2, without ENS-like contracts, and without gas fees. +🔮 Future Enhancements +Possible extensions include: +Additional username formats Extended character sets - -Special identifiers for categories such as NFTs, MemeCoins, and other on-chain projects - - -Any such updates will be reviewed and approved by the TRON Core Development Team. - - ---- - +Special categories for NFTs, MemeCoins, dApps, and system accounts 📄 License - -MIT License – 2025 -Open-source for all TRON developers. - - ---- - -🔗 Related Discussion - -GitHub Issue: #799 - -Official Pull Request: #803 +MIT — 2025 +🔗 References +Primary Issue: #799 +Updated Pull Request: #803 From ca934eee0c88d28e5dccd996becd2482baa7bdda Mon Sep 17 00:00:00 2001 From: hanliang Date: Mon, 17 Nov 2025 14:37:16 +0800 Subject: [PATCH 13/16] add tip 765: quote all selfDestuctrt --- tip-6780.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/tip-6780.md b/tip-6780.md index 9a7e8ce..a2ca05c 100644 --- a/tip-6780.md +++ b/tip-6780.md @@ -29,16 +29,16 @@ The constant energy cost of `SELFDESTRUCT` is changed from 0 to 5000: - The current execution frame halts. - `SELFDESTRUCT` does not delete any data (including storage keys, code, or the account itself). - `SELFDESTRUCT` transfers the entire account assets(TRX, Staked TRX, TRC10) to the target. -- Note that if the target is the same as the contract calling SELFDESTRUCT there is no net change in balances. Unlike the prior specification, assets will not be burnt in this case. +- Note that if the target is the same as the contract calling `SELFDESTRUCT` there is no net change in balances. Unlike the prior specification, assets will not be burnt in this case. -2. When SELFDESTRUCT is executed in the same transaction as the contract was created: +2. When `SELFDESTRUCT` is executed in the same transaction as the contract was created: - `SELFDESTRUCT` continues to behave as it did prior to this TIP, this includes the following actions - Third item - The current execution frame halts. - `SELFDESTRUCT` deletes data as previously specified. - `SELFDESTRUCT` transfers the entire account assets(TRX, Staked TRX, TRC10) to the target. - - The account balance of the contract calling SELFDESTRUCT is set to 0. -- Note that if the target is the same as the contract calling SELFDESTRUCT that assets will be burnt. + - The account balance of the contract calling `SELFDESTRUCT` is set to 0. +- Note that if the target is the same as the contract calling `SELFDESTRUCT` that assets will be burnt. A contract is considered created at the beginning of a create transaction or when a CREATE series operation begins execution (CREATE, CREATE2, and other operations that deploy contracts in the future). If a balance exists at the contract's new address it is still considered to be a contract creation. From 3a7deba414172a776ff20026ddf7f8a1ea22d69b Mon Sep 17 00:00:00 2001 From: liuxincheng Date: Fri, 14 Nov 2025 15:39:55 +0800 Subject: [PATCH 14/16] add tip-767 --- README.md | 1 + tip-767.md | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 57 insertions(+) create mode 100644 tip-767.md diff --git a/README.md b/README.md index e4dbb79..245597e 100644 --- a/README.md +++ b/README.md @@ -197,6 +197,7 @@ For further discussion, please enter [Telegram](https://t.me/troncoredevscommuni | TIP 712 | [TRON typed structured data hashing and signing](https://github.com/tronprotocol/tips/blob/master/tip-712.md) | | Standards Track | Interface | false | Final | | TIP 721 | [TRC-721 Non-Fungible Token Standard](https://github.com/tronprotocol/tips/blob/master/tip-721.md) | | Standards Track | TRC | true | Final | | TIP 745 | [Introduce EIP-4844 and EIP-7516 instructions](https://github.com/tronprotocol/tips/blob/master/tip-745.md) | | Standards Track | VM | true | Final | +| TIP 767 | [TIP-767: Transitioning proposal expire time configuration to Chain Governance](https://github.com/tronprotocol/tips/blob/master/tip-767.md) | | Standards Track | Core | true | Final | | TIP 1102 | [TIP-1102: Opt-in account exposure](https://github.com/tronprotocol/tips/blob/master/tip-1102.md) | | Standards Track | Interface | false | Final | | TIP 1155 | [Multi Token Standard](https://github.com/tronprotocol/tips/blob/master/tip-1155.md) | | Standards Track | TRC | false | Final | | TIP 1193 | [TIP-1193: TRON Provider JavaScript API](https://github.com/tronprotocol/tips/blob/master/tip-1193.md) | | Standards Track | Interface | false | Final | diff --git a/tip-767.md b/tip-767.md new file mode 100644 index 0000000..26550e3 --- /dev/null +++ b/tip-767.md @@ -0,0 +1,56 @@ +``` +tip: 767 +title: Transitioning proposal expire time configuration to Chain Governance +author: lxcmyf@gmail.com +discussions-to: https://github.com/tronprotocol/tips/issues/767 +status: Final +type: Standards Track +category: Core +created: 2025-06-09 +``` +# Simple Summary +This proposal suggests migrating the proposal expire time period from node-local configurations to on-chain governance parameters, ensuring all Super Representatives (SRs) adhere to a unified proposal expiration rule (proposal expires after the voting window period and during the maintenance period). The default value is 72 hours (259200000), but subsequent adjustments must be made through an SR vote. +# Abstract +Currently, Super Representatives (SRs) can locally configure the proposalExpireTime, which may lead to inconsistent judgments on proposal expiration times across different nodes. This proposal recommends changing it to an on-chain governance parameter (default: 259200000), with future adjustments requiring an SR vote. This ensures network uniformity and supports flexible governance optimization. +# Motivation +**Fully Decentralized Governance**​​: Key network parameters (such as the proposalExpireTime period) should be determined by on-chain voting rather than relying on manual node configurations. + +**Enhanced Consensus Security**​​: Unify the judgment logic for proposal voting expiration times across all nodes. + +**Support Dynamic Adjustments**​​: The community can flexibly adjust the proposalExpireTime period through approving (e.g., shortening it to 48 hours to accelerate governance processes). +# Specification + +- Add an on-chain proposal parameter: + +``` +public enum ProposalType { + ... + PROPOSAL_EXPIRE_TIME(92); +} +``` + +# Rationale +**Proposal Voting Lifecycle​​**: + +- The countdown for proposal approving expiration starts from its creation time. + +- After exceeding the on-chain `proposalExpireTime` and during the nearest maintenance period, the proposal automatically expires (even if approving is incomplete). + +​​**Pre-Upgrade​​**: `proposalExpireTime` will still be set via the default value or local configuration (if it exists). + +**Post-Upgrade**​​: After all SRs complete the upgrade, the timing for initiating the `PROPOSAL_EXPIRE_TIME` proposal will be discussed. Once the proposal takes effect, the expiration logic will be executed by reading the proposal value. + +# Implementation +### Protocol Changes​​ +​​**Core Modules**​​: + +- Modify **ProposalService** to add `PROPOSAL_EXPIRE_TIME`, making it governed by proposals and ignoring local configurations. + +**​​Interface Adjustments​​:** + +- Deprecate the `proposalExpireTime` parameter in the node configuration file config.conf after the proposal is activated. + +Add the proposalExpireTime parameter to the `/wallet/getchainparameters` interface. + +# Compatibility +This feature constitutes a hard fork. From 2aaf1a8b999013325a155757bd60477b11779c0e Mon Sep 17 00:00:00 2001 From: alichatme Date: Thu, 11 Dec 2025 17:37:22 +0330 Subject: [PATCH 15/16] remove readme md conflicting file is not needed in pr803 and tip796 --- README.md | 110 ------------------------------------------------------ 1 file changed, 110 deletions(-) delete mode 100644 README.md diff --git a/README.md b/README.md deleted file mode 100644 index a36b645..0000000 --- a/README.md +++ /dev/null @@ -1,110 +0,0 @@ -🧠 TIP-796 — TRON Account-Layer Username Standard (With Mandatory “TR” Prefix) -Status: Draft -Type: Standards Track -Authors: Ali & ChatGPT -GitHub: @alichatme -Created: September 25, 2025 -License: MIT — 2025 -📘 Summary -TIP-796 introduces a native, human-readable, non-transferable username standard implemented directly at the Account Layer of the TRON blockchain. -This system: -Requires no smart contracts -Requires no gas or fees -Attaches the username automatically and permanently to the account -Eliminates all major address-related attack vectors -Remains fully compatible with the existing TRON architecture -TIP-796 establishes a secure and spoof-proof identity layer that dramatically reduces user mistakes, prevents phishing, and protects users against modern Web3 attack methods. -🧩 Username Structure -All TRON usernames must begin with the uppercase prefix TR, followed by lowercase English letters (a–z) and digits (0–9) in one of the three allowed modes: -Mode 1 -TR + two lowercase words + four digits -Example: TRsunboy1185 -Mode 2 -TR + word + four digits + word -Example: TRsun7217boy -Mode 3 -TR + four digits + two lowercase words -Example: TR7516sunboy -Rules -No special characters, no spaces, no underscores -Strictly ASCII-only (a–z + 0–9) -Strict LTR (Left-to-Right) storage & display -The uppercase TR prefix is mandatory and part of the username identity -🔠 LTR Enforcement & Anti-Spoofing Protection -All usernames are stored and displayed using strict Left-to-Right (LTR) directionality. -This eliminates: -Homograph attacks -RTL/LTR bidirectional text exploits -Visual spoofing in Persian/Arabic/Hebrew -Font-based manipulation -⚙️ Core Rules -The TR prefix is required and cannot be hidden or omitted. -Wallets must display the full username and full address before signing. -Wallets must not shorten, collapse, or hide any part of the username. -System operates fully at the Account Layer — no fees, no contracts, no L2 required. -🔥 Complete Attack Coverage — Why TIP-796 Provides the Highest Security Level in Web3 -TIP-796 is the only naming standard designed to neutralize every major address-layer attack currently seen across blockchain networks. -1. Clipboard Hijacking -Malware replaces the copied address ➜ Username mismatch instantly reveals it. -2. Address Spoofing / Look-Alike Address Generation -Attackers generate thousands of similar addresses ➜ Username is impossible to imitate. -3. Homograph Attacks -Using similar-looking Unicode characters ➜ ASCII-only usernames block this completely. -4. RTL/LTR Visual Reversal Attacks -Bidirectional text exploits (common in Persian/Arabic/Hebrew) ➜ LTR-only eliminates them fully. -5. UI-Layer Manipulation (Phishing Wallets) -Fake wallets hide or reorder parts of the address ➜ Username must be displayed fully before signing. -6. Social Engineering Attacks -Humans verify names, not hex strings ➜ A clear username prevents human error. -7. Spam Activation & Transaction Pollution -Attackers send micro-transactions to appear in your history ➜ Username makes spoof attempts ineffective. -Result: -TIP-796 is the first blockchain username standard that neutralizes all seven categories of Web3 address-based attacks. -🔥 Username Assignment — Anti-Bot & Anti-Abuse Measures -To prevent bot farms, mass wallet creation, automated harvesting of names, or username farming, TIP-796 introduces the following optional but recommended mechanisms: -1. Cooldown Window (Recommended Default: 24 hours) -The username is assigned only after a configurable waiting period after account activation. -Network operators may increase this to 48 hours or more if needed. -This makes large-scale automated farming impractical. -2. Minimum Balance Requirement -A username is assigned only if the account holds a minimum balance during the cooldown period. -Suggested default: 2 TRX (or higher, e.g., 10 TRX, if stronger protection is desired). -This makes mass wallet creation economically non-viable. -3. Wallet Onboarding Confirmation -Before showing the username, wallets must require the user to: -Scroll through a multilingual explanation -Confirm understanding via a checkbox -Review: -How usernames work -How they protect users -How they prevent phishing -This significantly reduces phishing and user-errors. -4. Local Anti-Bot Challenge (Optional) -Wallets may implement: -Local lightweight PoW -CAPTCHA / anti-automation challenge -The network only verifies, but does not execute, the challenge. -Combined effect: -Bots must: -Wait 24–48 hours -Deposit real TRX -Solve onboarding -Solve anti-automation -=> Attack becomes economically impossible. -📊 Namespace Capacity -Using >650,000 English words, TIP-796 supports over: -12.6 quadrillion unique usernames -More than enough for centuries of TRON expansion. -🎯 Goal -Create a native, decentralized, zero-cost, spoof-proof identity layer -that protects users from all currently known Web3 address-based attacks — without L2, without ENS-like contracts, and without gas fees. -🔮 Future Enhancements -Possible extensions include: -Additional username formats -Extended character sets -Special categories for NFTs, MemeCoins, dApps, and system accounts -📄 License -MIT — 2025 -🔗 References -Primary Issue: #799 -Updated Pull Request: #803 From ce30a27d0c6f40d1f8da0289aaad292a62bcaf9b Mon Sep 17 00:00:00 2001 From: alichatme Date: Thu, 11 Dec 2025 22:21:58 +0330 Subject: [PATCH 16/16] Create README.md --- README.md | 1 + 1 file changed, 1 insertion(+) create mode 100644 README.md diff --git a/README.md b/README.md new file mode 100644 index 0000000..8b13789 --- /dev/null +++ b/README.md @@ -0,0 +1 @@ +