From 189fbbadcec56994ae920dc7e9c812c4a6965e75 Mon Sep 17 00:00:00 2001 From: alichatme Date: Thu, 25 Sep 2025 20:21:06 +0330 Subject: [PATCH 01/19] Create tip-alichatme-system.md TIP: Native Username System for TRON Accounts --- tip-alichatme-system.md | 57 +++++++++++++++++++++++++++++++++++++++++ 1 file changed, 57 insertions(+) create mode 100644 tip-alichatme-system.md diff --git a/tip-alichatme-system.md b/tip-alichatme-system.md new file mode 100644 index 0000000..0cc172f --- /dev/null +++ b/tip-alichatme-system.md @@ -0,0 +1,57 @@ +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 db1ac520382852783799c66a3f1f93ced3732d1a Mon Sep 17 00:00:00 2001 From: alichatme Date: Fri, 26 Sep 2025 08:28:49 +0330 Subject: [PATCH 02/19] Update proposal with username auto-display on paste --- tp/README.md | 78 ++++++++++++++++++++++++++++++++++++---------------- 1 file changed, 54 insertions(+), 24 deletions(-) diff --git a/tp/README.md b/tp/README.md index e51b5a1..583b766 100644 --- a/tp/README.md +++ b/tp/README.md @@ -1,25 +1,55 @@ -## What is a TP? -A TRON protocol (TP) is a design document describing a particular protocol, -standard, or feature which is already implemented in TRON but not published as a TIP. -A TP should list the properties of the standard, explain the design rationale, and -provide a concise but comprehensive technical specification that can guide developers to implement it conveniently with any other languages. -A TP should not be used for indicating a specific implementation(such as java-tron) or debating governance proposals. - -## Components -A TP and TIP have similar components, which include a header, a concise summary, an abstract, the motivation, the specification, the rationale, the implementation and a copyright notice. TP is an implemented protocol, so the implementation module can include a core code of java-tron. -All top-level sections are required. -References should be included inline as links or tabulated at the bottom of the section if necessary. - -## Formatting -### General -TP specifications must be written in GitHub Flavoured Markdown. - -### Language -TP specifications should be written in simple English, avoiding obscure terminologies and unnecessary jargons. -The keywords “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in specifications are to be interpreted as described in [RFC 2119](https://tools.ietf.org/html/rfc2119). -### Pseudocode -Pseudocode in specifications should be language-agnostic and formatted in a simple standard, with line numbers, variables, simple conditional blocks, for loops, and -the English fragments are necessary to explain further functionality. -## Copyright -All content herein is licensed under [Apache2.0](https://www.apache.org/licenses/LICENSE-2.0). +TIP: Native Username System for TRON Accounts +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 must display both the username and the underlying TRON address when making transfers. +- **When a user pastes an address, the system should automatically fetch and display the associated username before confirming the transaction. This ensures the sender can visually verify the recipient and avoid mistakes.** + +Rationale +- Security: Reduces misdirected transfers caused by complex addresses. The auto-display of usernames when pasting addresses adds a crucial verification step. +- 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. +- **Transaction interfaces must resolve addresses to usernames in real time, ensuring users see both before approving transfers.** From ebcd105d2104addd0fd00265dca894e156358ec0 Mon Sep 17 00:00:00 2001 From: alichatme Date: Sat, 27 Sep 2025 00:39:17 +0330 Subject: [PATCH 03/19] Update template.md --- template.md | 67 +++++++++++++++-------------------------------------- 1 file changed, 19 insertions(+), 48 deletions(-) diff --git a/template.md b/template.md index cb6c46a..1fbe1bf 100644 --- a/template.md +++ b/template.md @@ -1,54 +1,25 @@ -``` -tip: -title: -author: , FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)> -discussions-to: -status: -type: -category (*only required for Standard Track): -created: -requires (*optional): -replaces (*optional): -``` +TIP: +Title: +Author: +Status: Draft +Type: Standard Track +Created: -This is the suggested template for new TIPs. +## Abstract + -Note that an TIP number will be assigned by an editor. When opening a pull request to submit your TIP, please use an abbreviated title in the filename. +## Motivation + -The title should be 44 characters or less. +## Specification + -## Simple Summary (required) +## Rationale + -Provide a simplified explanation of the TIP. +## Backwards Compatibility + -## Abstract (required) - -A short (~200 word) description of the technical issue being addressed. - -## Motivation (required) - -The motivation is critical for TIPs that want to change the TRON protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the TIP solves. TIP submissions without sufficient motivation may be rejected outright. - -## Specification (required) - -The technical specification should describe the syntax and semantics of any new feature. - -## Rationale (required) - -The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion. - -## Backwards Compatibility (optional) - -All TIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The TIP must explain how the author proposes to deal with these incompatibilities. TIP submissions without a sufficient backwards compatibility treatise may be rejected outright. - -## Test Cases (optional) - -Test cases for an implementation are mandatory for TIPs that are affecting consensus changes. Other TIPs can choose to include links to test cases if applicable. - -## Implementation (required) - -The implementations must be completed before any TIP is given status "Final", but it need not be completed before the TIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details. - -## Copyright - -Copyright and related rights waived via [CC0](LICENSE.md). \ No newline at end of file +## Implementation + From dd0a4ef9ab3963ea3f1c83fe8ca41474e057a2f2 Mon Sep 17 00:00:00 2001 From: alichatme Date: Sat, 27 Sep 2025 10:49:02 +0330 Subject: [PATCH 04/19] Update template.md --- template.md | 42 +++++++++++++++++++++++++++--------------- 1 file changed, 27 insertions(+), 15 deletions(-) diff --git a/template.md b/template.md index 1fbe1bf..5c75b90 100644 --- a/template.md +++ b/template.md @@ -1,25 +1,37 @@ -TIP: -Title: -Author: -Status: Draft -Type: Standard Track -Created: +--- +tip: +title: +author: Author Name +discussions-to: +status: Draft +type: Standards Track +category: Core +created: +--- + +## Simple Summary +"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the TIP. ## Abstract - +A short (~200 word) description of the technical issue being addressed. ## Motivation - +The motivation is critical for TIPs that want to change the TRON protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the TIP solves. TIP submissions without sufficient motivation may be rejected outright. ## Specification - +The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current TRON platforms. ## Rationale - +The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs considered and related work, e.g., how the feature is supported in other languages. + +## Backward Compatibility +All TIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The TIP must explain how the author proposes to deal with these incompatibilities. Submissions without a sufficient backward compatibility treatise may be rejected outright. + +## Test Cases +Test cases for an implementation are mandatory for TIPs that are affecting consensus changes. Other TIPs can choose to include links to test cases if applicable. -## Backwards Compatibility - +## Implementations +The implementations must be completed before any TIP is given "Final" status, but it need not be completed before the TIP is accepted. While there is merit to referencing implementations, it is better to include the implementation in the TIP as code snippets or executable documentation. -## Implementation - +## Copyright +All TIPs are licensed under [Apache 2.0](https://www.apache.org/licenses/LICENSE-2.0). From 5456fb345c5e0f7ade193ee1cae6e5f0cbe122ec Mon Sep 17 00:00:00 2001 From: alichatme Date: Thu, 9 Oct 2025 20:24:01 +0330 Subject: [PATCH 05/19] Create SafeWalletMethod.md --- SafeWalletMethod.md | 69 +++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 69 insertions(+) create mode 100644 SafeWalletMethod.md diff --git a/SafeWalletMethod.md b/SafeWalletMethod.md new file mode 100644 index 0000000..c1fb0ac --- /dev/null +++ b/SafeWalletMethod.md @@ -0,0 +1,69 @@ +# 🔐 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 a0e9f407c71ea6aea9461420b8f14839b2214afd Mon Sep 17 00:00:00 2001 From: alichatme Date: Thu, 9 Oct 2025 20:32:49 +0330 Subject: [PATCH 06/19] Update README.md --- README.md | 223 ++++++++---------------------------------------------- 1 file changed, 30 insertions(+), 193 deletions(-) diff --git a/README.md b/README.md index e4dbb79..130f449 100644 --- a/README.md +++ b/README.md @@ -1,208 +1,45 @@ -# TRON Improvement Proposals (TIPs) +# 🌐 Safe Wallet Method – ali & chatgpt -TRON Improvement Proposals (TIPs) describe standards for the TRON platform, including core protocol specifications, client APIs, and contract standards. +**A revolutionary offline encryption method for crypto wallet recovery phrases.** +Developed by: **ali & chatgpt** +GitHub: [https://github.com/alichatme](https://github.com/alichatme) -**** +--- -## Contents -- [To Submit a TIP](#to-submit-a-tip) -- [TIP Status](#tip-status) -- [TIP Types](#tip-types) -- [TIPs Guide](#tips-guide) -**** +## 🧩 What is Safe Wallet Method? -## To Submit a TIP +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. -Before you submit a TIP, you need to create an issue for comment and add the issue URL to your TIP header. +- 100% offline +- Compatible with all BIP39 wallets (TronLink, MetaMask, TrustWallet, etc.) +- Simple and strong +- Ideal for long-term backup -1. Fork the repository by clicking "Fork" in the top right. +📘 Read full details here: +👉 [SafeWalletMethod.md](SafeWalletMethod.md) -2. Add your TIP to your fork of the repository. There is a [TIP template](https://github.com/tronprotocol/TIPs/blob/master/template.md) here. +--- -3. Submit a Pull Request to TRON's TIPs repository. +## 💬 Why It Matters -Your first PR should be a first draft of the final TIP. It must meet the formatting criteria enforced by the build (largely, correct metadata in the header). An editor will manually review the first PR for a new TIP and assign it a number before merging it. +This method protects your seed phrase from: +- Phishing attacks +- Malware clipboard hijacking +- Cloud leaks +- Social engineering -Make sure you include a discussions-to header with the URL to a discussion forum or open GitHub issue where people can discuss the TIP as a whole. If a TIP is about the feature development of java-tron, and a PR of the development exists, in your TIP and your java-tron's PR you need to refer each other's github link. +And it keeps **crypto decentralization** intact, since everything happens locally — no external apps or servers. -When you believe your TIP is mature and ready to progress past the draft phase, you should do one of two things: +--- -- For a Standards Track TIP of type Core, ask to have your issue added to the agenda of an upcoming All Core Devs meeting, where it can be discussed for inclusion in a future hard fork. If implementers agree to include it, the TIP editors will update the state of your TIP to 'Accepted'. +## 🏷️ Authors -- For all other TIPs, open a PR changing the state of your TIP to 'Final'. An editor will review your draft and ask if anyone objects to its being finalized. If the editor decides there is no rough consensus, they may close the PR and request you fix the issues in the draft before trying again. +👤 **Ali** +🤖 **ChatGPT** +Team: **ali & chatgpt** -**** +--- -## TIP Status - -TIPs are separated into several statuses. - -- **Draft**: A TIP that is undergoing rapid iteration and changes. - -- **Last Call**: A TIP that is done with its initial iteration and ready for review by a wide audience. - -- **Accepted**: A core TIP that has been in the Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author. The process for Core Devs to decide whether to encode a TIP into their clients as part of a hard fork is not part of the TIP process. If such a decision is made, the TIP will move to the final. - -- **Final (non-Core)**: A TIP that has been in the Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author. - -- **Final (Core)**: A TIP that the Core Devs have decided to implement and release in a future version or has already been released. - -- **Active**: If the TIPs are never meant to be completed, the TIPs may have a status of “Active”. - -- **Abandoned**: If a TIP is no longer pursued by the original authors or it may not be a (technically) preferred option anymore. - -- **Rejected**: A TIP that is fundamentally broken or a Core TIP that was rejected by the Core Devs and will not be implemented. - -- **Superseded**: A TIP which was previously Final but is no longer considered state-of-the-art. Another TIP will be in the Final status and cite the Superseded TIP. - -- **Deferred**: A TIP which isn't accepted now, it may be accepted in the future. - -**** - -## TIP Types - -TIPs are separated into several types, and each has its list of TIPs. - -* **Standard Track**: Describes any change that affects most or all TRON implementations, such as a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using TRON. Furthermore, Standard TIPs can be broken down into the following categories. - - **1.Core**: Improvements requiring a consensus fork, as well as changes that are not necessarily consensus critical but may be relevant to "core dev" discussions. - - **2.Networking**: Includes improvements around network protocol. - - **3.Interface**: Includes improvements around client API/RPC specifications and standards. - - **4.TRC**: Application-level standards and conventions, including contract standards such as token standards (TRC-20). - - **5.TVM**: Includes improvements around TRON Virtual Machine. - -* **Informational**: Describes a TRON design issue, or provides general guidelines or information to the TRON community, but does not propose a new feature. - -For further discussion, please enter [Telegram](https://t.me/troncoredevscommunity) - -**** - -## TIPs Guide - -
TIPs Record - - -| ID | Title | Author | Type | Category | Hard fork | Status | -|---------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------|:------------------------------:|:--------------------:|:----------:|:--------------:|:---------:| -| TIP 10 | [TRON Token Standard](https://github.com/tronprotocol/TIPs/blob/master/tip-10.md) | | Standards Track | Core | false | Final | -| TIP 12 | [TRON Event Subscription Model](https://github.com/tronprotocol/TIPs/blob/master/tip-12.md) | | Informational | TRC | false | Final | -| TIP 13 | [Design of TRON account](https://github.com/tronprotocol/TIPs/blob/master/tip-13.md) | | Standards Track | Core | false | Final | -| TIP 16 | [TRON Account Multi-Signature](https://github.com/tronprotocol/TIPs/blob/master/tip-16.md) | | Standards Track | Core | true | Final | -| TIP 17 | [TRON Adaptive Energy Limit Model](https://github.com/tronprotocol/TIPs/blob/master/tip-17.md) | | Standards Track | Core | true | Final | -| TIP 19 | [TRC-19 Deferred transaction](https://github.com/tronprotocol/TIPs/blob/master/tip-19.md) | | Standards Track | Core | true | Deferred | -| TIP 20 | [TRC-20 Token Standard](https://github.com/tronprotocol/TIPs/blob/master/tip-20.md) | | Standards Track | TRC | true | Final | -| TIP 23 | [Add the account world status tree root to the block header](https://github.com/tronprotocol/tips/blob/master/tip-23.md) | | Standards Track | Core | true | Accepted | -| TIP 24 | [Implement of DB storage with RocksDB](https://github.com/tronprotocol/tips/blob/master/tip-24.md) | | Standards Track | Core | false | Final | -| TIP 26 | [Create2](https://github.com/tronprotocol/tips/blob/master/tip-26.md) | | Standards Track | VM | false | Final | -| TIP 28 | [Built-in Message Queue in Event Subscription Model](https://github.com/tronprotocol/TIPs/blob/master/tip-28.md) | | Informational | | false | Final | -| TIP 29 | [Bitwise shifting instructions in Tron](https://github.com/tronprotocol/tips/blob/master/tip-29.md) | | Standards Track | VM | true | Final | -| TIP 30 | [Code hash instructions](https://github.com/tronprotocol/tips/blob/master/tip-30.md) | | Standards Track | VM | true | Final | -| TIP 31 | [Trigger constant contract](https://github.com/tronprotocol/tips/blob/master/tip-31.md) | | Standards Track | VM | true | Final | -| TIP 32 | [Clear the ABI of contract](https://github.com/tronprotocol/tips/blob/master/tip-32.md) | | Standards Track | VM | true | Final | -| TIP 37 | [Forbid using TransferContract & TransferAssetContract for contract account](https://github.com/tronprotocol/tips/blob/master/tip-37.md) | | Standards Track | VM | true | Final | -| TIP 41 | [Optimize transactionHistoryStore occupancy space](https://github.com/tronprotocol/tips/blob/master/tip-41.md) | | Standards Track | Core | false | Final | -| TIP 43 | [Precompiled contract function for signature parallel verification](https://github.com/tronprotocol/tips/blob/master/tip-43.md) | | Standards Track | VM | true | Final | -| TIP 44 | [Address.isContract instructions](https://github.com/tronprotocol/tips/blob/master/tip-44.md) | | Standards Track | VM | true | Final | -| TIP 51 | [Rate limit of API traffic](https://github.com/tronprotocol/tips/blob/master/tip-51.md) | | Standards Track | Interface | false | Final | -| TIP 53 | [Optimize the current TRON delegation mechanism](https://github.com/tronprotocol/tips/blob/master/tip-53.md) | | Standards Track | Core | true | Final | -| TIP 54 | [Automatically active non-existent account when transferring TRX/TRC10 asset in a smart contract](https://github.com/tronprotocol/tips/blob/master/tip-54.md) | | Standards Track | VM | true | Final | -| TIP 60 | [Precompiled contract function for multi-signature verification](https://github.com/tronprotocol/tips/blob/master/tip-60.md) | | Standards Track | VM | true | Accepted | -| TIP 62 | [Tron consensus algorithm introduction](https://github.com/tronprotocol/tips/blob/master/tip-62.md) | | Standards Track | Core | false | Final | -| TIP 64 | [Tron tron mix consensus Analytics](https://github.com/tronprotocol/tips/blob/master/tip-64.md) | | Standards Track | Core | false | Draft | -| TIP 101 | [Wallet Keystore Specification](https://github.com/tronprotocol/tips/blob/master/tip-101.md) | | Standards Track | TRC | false | Last Call | -| TIP 102 | [Hierarchical Deterministic Wallet](https://github.com/tronprotocol/tips/blob/master/tip-102.md) | | Standards Track | TRC | false | Last Call | -| TIP 104 | [Data Signing Specification](https://github.com/tronprotocol/tips/blob/master/tip-104.md) | | Standards Track | TRC | false | Last Call | -| TIP 105 | [Multi-signature Permission Operation](https://github.com/tronprotocol/tips/blob/master/tip-105.md) | | Standards Track | TRC | true | Final | -| TIP 120 | [ECDSA Signature Encoding Specification](https://github.com/tronprotocol/tips/blob/master/tip-120.md) | | Standards Track | TRC | false | Final | -| TIP 127 | [Support Tron-DEX based on system contracts](https://github.com/tronprotocol/tips/blob/master/tip-127.md) | | Standards Track | CORE | false | Draft | -| TIP 128 | [TIP128 Lite Fullnode support](https://github.com/tronprotocol/tips/blob/master/tip-128.md) | | Standards Track | CORE | false | Draft | -| TIP 135 | [Shielded TRC-20 Contract](https://github.com/tronprotocol/tips/blob/master/tip-135.md) | | Standards Track | TRC | false | Final | -| TIP 137 | [Zero-knowledge Proof Verification functions](https://github.com/tronprotocol/tips/blob/master/tip-137.md) | | Standards Track | VM | true | Final | -| TIP 138 | [Pedersen hash function](https://github.com/tronprotocol/tips/blob/master/tip-138.md) | | Standards Track | VM | true | Final | -| TIP 156 | [Vote instructions in TVM](https://github.com/tronprotocol/tips/blob/master/tip-156.md) | | Standards Track | VM | true | Withdrawn | -| TIP 157 | [Freeze instructions in TVM](https://github.com/tronprotocol/tips/blob/master/tip-157.md) | | Standards Track | VM | true | Final | -| TIP 165 | [TRC-165 Standard Interface Detection In Contract](https://github.com/tronprotocol/tips/blob/master/tip-165.md) | | Standards Track | TRC | true | Final | -| TIP 171 | [STAKE instructions in TVM](https://github.com/tronprotocol/tips/blob/master/tip-171.md) | | Standards Track | VM | true | Withdrawn | -| TIP 174 | [CHAINID instructions in TVM](https://github.com/tronprotocol/tips/blob/master/tip-174.md) | | Standards Track | VM | true | Final | -| TIP 175 | [SELFBALANCE instructions in TVM](https://github.com/tronprotocol/tips/blob/master/tip-175.md) | | Standards Track | VM | true | Final | -| TIP 176 | [altbn128 operation energy reduction in TVM](https://github.com/tronprotocol/tips/blob/master/tip-176.md) | | Standards Track | VM | true | Final | -| TIP 178 | [TOKENISSUE and UPDATEASSET Instruction in TVM](https://github.com/tronprotocol/tips/blob/master/tip-178.md) | | Standards Track | VM | true | Withdrawn | -| TIP 191 | [Signed Data Standard](https://github.com/tronprotocol/tips/blob/master/tip-191.md) | | Standards Track | TRC | false | Final | -| TIP 196 | [Reward SRs with the transaction fees charged for bandwidth and Energy](https://github.com/tronprotocol/tips/blob/master/tip-196.md) | | Standards Track | Core | true | Final | -| TIP 204 | [Make MAX_FEE_LIMIT configurable as a chain property](https://github.com/tronprotocol/tips/blob/master/tip-204.md) | | Standards Track | VM | false | Final | -| TIP 207 | [A proposal to improve network resources model ](https://github.com/tronprotocol/tips/blob/master/tip-207.md) | | Standards Track | Core | true | Draft | -| TIP 209 | [Adapt to Solidity 0.6.0](https://github.com/tronprotocol/tips/blob/master/tip-209.md) | | Standards Track | VM | false | Final | -| TIP 222 | [Improve transaction execution speed](https://github.com/tronprotocol/tips/blob/master/tip-222.md) | | Standards Track | TRC | true | Final | -| TIP 250 | [Include transaction results on the chain](https://github.com/tronprotocol/tips/blob/master/tip-250.md) | | Standards Track | Core | true | Final | -| TIP 268 | [SmartContract ABI optimization](https://github.com/tronprotocol/tips/blob/master/tip-268.md) | | Standards Track | VM | false | Final | -| TIP 269 | [Optimize the performance of block processing](https://github.com/tronprotocol/tips/blob/master/tip-269.md) | | Standards Track | Core | false | Final | -| TIP 271 | [Vote for SR in Smart Contract](https://github.com/tronprotocol/tips/blob/master/tip-271.md) | | Standards Track | VM | true | Final | -| TIP 272 | [Compatible with EVM](https://github.com/tronprotocol/tips/blob/master/tip-272.md) | | Standards Track | VM | true | Final | -| TIP 276 | [Optimize block verification logic](https://github.com/tronprotocol/tips/blob/master/tip-276.md) | | Standards Track | Core | false | Final | -| TIP 281 | [Optimize the query of database](https://github.com/tronprotocol/tips/blob/master/tip-281.md) | | Standards Track | Core | false | Final | -| TIP 285 | [Node startup optimization](https://github.com/tronprotocol/tips/blob/master/tip-285.md) | | Standards Track | Core | false | Final | -| TIP 289 | [Block Broadcast Optimization](https://github.com/tronprotocol/tips/blob/master/tip-289.md) | | Standards Track | Core | true | Final | -| TIP 290 | [Dynamic store optimization](https://github.com/tronprotocol/tips/blob/master/tip-290.md) | | Standards Track | Core | true | Final | -| TIP 292 | [Add a proposal to adjust the free net limit in an account](https://github.com/tronprotocol/tips/blob/master/tip-292.md) | | Standards Track | TRC | true | Final | -| TIP 293 | [Add a proposal to adjust the total net limit](https://github.com/tronprotocol/tips/blob/master/tip-293.md) | | Standards Track | TRC | true | Final | -| TIP 295 | [Optimize assets of account](https://github.com/tronprotocol/tips/blob/master/tip-295.md) | | Standards Track | Core | false | Final | -| TIP 298 | [Reformat manifest](https://github.com/tronprotocol/tips/blob/master/tip-298.md) | | Standards Track | Core | false | Final | -| TIP 306 | [Adapt to solidity_0.8.4](https://github.com/tronprotocol/tips/blob/master/tip-306.md) | | Standards Track | VM | false | Final | -| TIP 318 | [Adapt to Ethereum London Upgrade](https://github.com/tronprotocol/tips/blob/master/tip-318.md) | | Standards Track | VM | false | Final | -| TIP 343 | [DB params optimization ](https://github.com/tronprotocol/tips/blob/master/tip-343.md) | | Standards Track | Core | false | Draft | -| TIP 344 | [Optimize instruction execution for TVM](https://github.com/tronprotocol/tips/blob/master/tip-344.md) | | Standards Track | VM | false | Final | -| TIP 362 | [Optimized node broadcast data caching](https://github.com/tronprotocol/tips/blob/master/tip-362.md) | | Standards Track | Core | false | Final | -| TIP 366 | [Node startup optimization](https://github.com/tronprotocol/tips/blob/master/tip-366.md) | | Standards Track | Core | false | Final | -| TIP 369 | [Node support prometheus metrics](https://github.com/tronprotocol/tips/blob/master/tip-369.md) | | Standards Track | Core | false | Final | -| TIP 370 | [Node support conditionalized stop](https://github.com/tronprotocol/tips/blob/master/tip-370.md) | | Standards Track | Core | false | Final | -| TIP 382 | [TIP-382: Optimize the data structure of account assets](https://github.com/tronprotocol/tips/blob/master/tip-382.md) | | Standards Track | Core | false | Final | -| TIP 383 | [TIP-383: Optimize transaction cache loading](https://github.com/tronprotocol/tips/blob/master/tip-383.md) | | Standards Track | Core | false | Final | -| TIP 387 | [TIP-387: Transaction memo fee](https://github.com/tronprotocol/tips/blob/master/tip-387.md) | | Standards Track | Core | false | Final | -| TIP 388 | [TIP-388: Optimize light node synchronization logic](https://github.com/tronprotocol/tips/blob/master/tip-388.md) | | Standards Track | Core | false | Final | -| TIP 391 | [TIP-391: Optimize fetch block process](https://github.com/tronprotocol/tips/blob/master/tip-391.md) | | Standards Track | Core | false | Final | -| TIP 397 | [Raise limit of the 13th network parameter](https://github.com/tronprotocol/tips/blob/master/tip-397.md) | | Standards Track | VM | true | Final | -| TIP 425 | [TIP-425: Speed up TCP connection establishment](https://github.com/tronprotocol/tips/blob/master/tip-425.md) | | Standards Track | Net | false | Final | -| TIP 428 | [TIP-428: Increase the probability that the block processing thread acquires the lock](https://github.com/tronprotocol/tips/blob/master/tip-428.md) | | Standards Track | Core | false | Final | -| TIP 440 | [Transaction cache optimization](https://github.com/tronprotocol/tips/blob/master/tip-440.md) | | Standards Track | Core | false | Final | -| TIP 461 | [Optimize data consistency for system abnormals](https://github.com/tronprotocol/tips/blob/master/tip-461.md) | | Standards Track | Core | false | Final | -| TIP 465 | [New reward calculation algorithm](https://github.com/tronprotocol/tips/blob/master/tip-465.md) | | Standards Track | Core | true | Final | -| TIP 467 | [Stake 2.0 - A new TRON stake model](https://github.com/tronprotocol/tips/blob/master/tip-467.md) | | Standards Track | Core | false | Final | -| TIP 474 | [Optimize the return value of chainid opcode](https://github.com/tronprotocol/tips/blob/master/tip-474.md) | | Standards Track | VM | true | Final | -| TIP 476 | [Delegate Data Structure Optimization](https://github.com/tronprotocol/tips/blob/master/tip-476.md) | | Standards Track | Core | false | Final | -| TIP 491 | [Dynamic Energy Model](https://github.com/tronprotocol/tips/blob/master/tip-491.md) | | Standards Track | VM | true | Final | -| TIP 534 | [Remove Vulnerable APIs](https://github.com/tronprotocol/tips/blob/master/tip-534.md) | | Standards Track | Core | false | Final | -| TIP 541 | [Support canceling unstaking in Stake 2.0](https://github.com/tronprotocol/tips/blob/master/tip-541.md) | | Standards Track | Core | true | Final | -| TIP 542 | [Resource delegating supports customizable lock period](https://github.com/tronprotocol/tips/blob/master/tip-542.md) | | Standards Track | Core | true | Final | -| TIP 543 | [Implement EIP-3855 PUSH0 instruction](https://github.com/tronprotocol/tips/blob/master/tip-543.md) | | Standards Track | VM | true | Final | -| TIP 544 | [Add `data` to the http interfaces interacting with smart contract](https://github.com/tronprotocol/tips/blob/master/tip-544.md) | | Standards Track | Interface | false | Final | -| TIP 547 | [Connection precheck before P2P communication](https://github.com/tronprotocol/tips/blob/master/tip-547.md) | | Standards Track | Networking | false | Final | -| TIP 548 | [Node Discovery via DNS](https://github.com/tronprotocol/tips/blob/master/tip-548.md) | <317787106@qq.com> | Standards Track | Networking | false | Final | -| TIP 549 | [P2P support IPv6 protocol](https://github.com/tronprotocol/tips/blob/master/tip-549.md) | <317787106@qq.com> | Standards Track | Networking | false | Final | -| TIP 550 | [P2P message snappy compression](https://github.com/tronprotocol/tips/blob/master/tip-550.md) | | Standards Track | Networking | false | Final | -| TIP 555 | [Network upgrade logic optimization](https://github.com/tronprotocol/tips/blob/master/tip-555.md) | | Standards Track | Core | false | Final | -| TIP 586 | [GRPC Implementation for Resource Price Interfaces](https://github.com/tronprotocol/tips/blob/master/tip-586.md) | | Standards Track | Core | false | Final | -| TIP 592 | [Supplement Disconnect Reasons in Java-tron](https://github.com/tronprotocol/tips/blob/master/tip-592.md) | <317787106@qq.com> | Standards Track | Networking | false | Final | -| TIP 621 | [Add code version column to HelloMessage](https://github.com/tronprotocol/tips/blob/master/tip-621.md) | <317787106@qq.com> | Standards Track | Networking | false | Final | -| TIP 635 | [Optimize Reward Withdrawal To Improve TPS](https://github.com/tronprotocol/tips/blob/master/tip-635.md) | | Standards Track | Core | true | Final | -| TIP 650 | [Implement EIP-1153 Transient storage opcodes](https://github.com/tronprotocol/tips/blob/master/tip-650.md) | | Standards Track | VM | true | Final | -| TIP 651 | [Implement EIP-5656 MCOPY - Memory copying instruction](https://github.com/tronprotocol/tips/blob/master/tip-651.md) | | Standards Track | VM | true | Final | -| TIP 652 | [Announce EIP-6049 Deprecate SELFDESTRUCT](https://github.com/tronprotocol/tips/blob/master/tip-652.md) | | Meta | VM | false | Final | -| TIP 653 | [Adjust energy cost of SUICIDE and VOTEWITNESS opcodes in TVM](https://github.com/tronprotocol/tips/blob/master/tip-653.md) | | Standards Track | VM | true | Final | -| TIP 694 | [Enhance Verification of Transaction Limitation at Consensus Layer](https://github.com/tronprotocol/tips/blob/master/tip-694.md) | | Standards Track | Core | true | Final | -| TIP 697 | [Migrate Floating-Point Calculations from Math to StrictMath](https://github.com/tronprotocol/tips/blob/master/tip-697.md) | | Standards Track | Core | true | Final | -| 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 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 | -| 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 | - -
- -**** +## 📄 License +**MIT License – 2025** +Open Source for education and personal use. From ddc0bd96e8738e18468a4d4ecae99fbc7bb06c35 Mon Sep 17 00:00:00 2001 From: alichatme Date: Fri, 10 Oct 2025 01:36:11 +0330 Subject: [PATCH 07/19] 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 08/19] 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 09/19] 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 10/19] 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 11/19] 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 12/19] 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 13/19] 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 14/19] 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 15/19] 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 21b891a97be224a887acb6c373f75f21baff5ab6 Mon Sep 17 00:00:00 2001 From: alichatme Date: Sun, 16 Nov 2025 23:53:00 +0330 Subject: [PATCH 16/19] 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 17/19] 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 2aaf1a8b999013325a155757bd60477b11779c0e Mon Sep 17 00:00:00 2001 From: alichatme Date: Thu, 11 Dec 2025 17:37:22 +0330 Subject: [PATCH 18/19] 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 19/19] 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 @@ +