diff --git a/README.md b/README.md index 6a679e53..e9acb774 100644 --- a/README.md +++ b/README.md @@ -1,4 +1,3 @@ -# TRON Improvement Proposals (TIPs) TRON Improvement Proposals (TIPs) describe standards for the TRON platform, including core protocol specifications, client APIs, and contract standards. diff --git a/template.md b/template.md index cb6c46a1..5c75b90d 100644 --- a/template.md +++ b/template.md @@ -1,54 +1,37 @@ -``` -tip: +--- +tip: title: -author: , FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)> +author: Author Name discussions-to: -status: -type: -category (*only required for Standard Track): +status: Draft +type: Standards Track +category: Core created: -requires (*optional): -replaces (*optional): -``` +--- -This is the suggested template for new TIPs. - -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. - -The title should be 44 characters or less. - -## Simple Summary (required) - -Provide a simplified explanation of the TIP. - -## Abstract (required) +## 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 (required) - +## 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 (required) +## 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. -The technical specification should describe the syntax and semantics of any new feature. +## 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. -## 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) +## 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. -## 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. +## 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. ## Copyright - -Copyright and related rights waived via [CC0](LICENSE.md). \ No newline at end of file +All TIPs are licensed under [Apache 2.0](https://www.apache.org/licenses/LICENSE-2.0). diff --git a/tip-796.md b/tip-796.md new file mode 100644 index 00000000..d76c61db --- /dev/null +++ b/tip-796.md @@ -0,0 +1,454 @@ +--- +tip: 796 +title: TRON Account-Layer Username Standard +author: Ali (@alichatme) +discussions-to: https://github.com/tronprotocol/tips/issues/799 +status: Draft +type: Standards Track +created: 2025-09-25 +license: MIT +--- +# 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 or registration fees +· enhances security, usability, and human readability +· significantly reduces address-based fraud and user errors +· remains fully compatible with TRON's existing architecture + +The core objective of TIP-796 is to create a trustworthy and human-readable identity layer that helps users verify transaction destinations before signing. + +Under TIP-796, each TRON account receives a unique username permanently bound to that account. + +According to this proposal, wallets are required to display the username alongside the account address to the user and, in addition to the address copy option, provide a username copy option for accounts. + +These usernames are generated and assigned by the network rather than chosen manually by users, preventing name squatting, registration races, and duplicate registrations. + +### In practice, this process works as follows: + +When a user wishes to receive funds, they send both their TRON address and their account's assigned username to the sender through an external channel (e.g., messaging, email, or in-person). + +When the sender enters the destination address into their wallet, the wallet retrieves the official username associated with that account directly from the network. + +Then, in the transaction confirmation window before signing, the wallet displays the recipient's username to the user in addition to the sender's address and the recipient's address. + +The sender can now visually compare the displayed username with the username they received from the intended recipient. + +If both match, they can safely sign and confirm the transaction. + +If they do not match, the user is immediately alerted to a potential mistake, address substitution attack, phishing attempt, or clipboard manipulation and stops the transaction process. + +### The responsibility for matching the recipient's username with the username queried by the wallet from the network at the time of the transaction rests with the user, and the network bears no responsibility in this regard. + +### By introducing a mandatory pre-signature verification layer, TIP-796 transforms blockchain addresses from opaque strings into human-verifiable transaction targets while preserving decentralization, compatibility, and zero- +___ +___ +# Username Structure + +TIP-796 usernames are permanently tied to TRON accounts and must follow a standardized format. + +. Each username begins with the mandatory uppercase prefix TR. + +. Usernames are stored on-chain with this prefix and must always be displayed by wallets exactly as assigned by the network. + +. Wallets are not permitted to truncate, shorten, modify, or remove the TR prefix or any other part of the username. + +. Following the TR prefix, usernames are constructed using lowercase ASCII letters (a-z) and digits (0-9). + +### The TR prefix serves several important purposes: + +. Instantly identifies the username as belonging to the TRON network. + +. Prevents ambiguity between naming systems on different blockchains. + +. Provides a fixed visual anchor during transaction verification. + +. Strengthens protection against RTL/LTR display manipulation attacks. + +## Usernames on the TRON network are generated using one of the following standardized patterns and are then assigned to accounts. + +### 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 + +## Username Rules + +. No special characters + +. No spaces + +. No underscores + +. Strict ASCII-only character set + +. Strict Left-to-Right (LTR) storage and rendering + +. The uppercase TR prefix is mandatory and forms part of the username identity + +. The network stores and assigns usernames together with the TR prefix + +. Wallets must display the username exactly as returned by the network without modification + +. Usernames are generated by the network and cannot be manually selected by users + +. Each username is unique and permanently bound to a single account + +. LTR Enforcement & Visual Anti-Spoofing + +. Usernames must always be stored and displayed using strict Left-to-Right (LTR) directionality. + +## This design prevents: + +.Homograph attacks using visually similar characters + +. RTL/LTR direction-switch attacks + +. Font-based spoofing techniques + +. Visual manipulation in Persian, Arabic, Hebrew, and other bidirectional-language environments + +### By restricting usernames to ASCII characters and enforcing LTR rendering, TIP-796 provides a predictable, consistent, and spoof-resistant visual representation across all wallets and user interfaces. + +## Core Rules + +. The TR prefix must be stored on-chain exactly as defined. + +. Wallets must display both the full username and the full destination address before transaction signing. + +. Wallets must not shorten, truncate, collapse, or hide any portion of the username. + +. Usernames function as a transaction-verification layer and do not replace blockchain addresses. + +. The system operates entirely at the Account Layer without requiring smart contracts, registration fees, or external infrastructure. + +## Transaction Verification Flow + +. The sender receives the destination address and its corresponding username. + +. The sender enters or pastes the destination address into the wallet. + +. The wallet retrieves the official username associated with that address directly from the network. + +. In the confirmation window before signing, the wallet displays the recipient's username in addition to the sender's address and the recipient's address. + +. The sender compares the username retrieved from the network (displayed in the wallet) with the username of the destination address they expected. + +. If both usernames match, the sender signs and confirms the transaction. + +. If the usernames do not match, the sender immediately identifies a potential error, phishing attempt, or address-substitution attack and stops the transaction process. + +### This transaction-verification flow represents one of the primary security mechanisms introduced by TIP-796 and is designed to help users visually verify transaction destinations before signing. +___ +___ +# Security Benefits and Attack Mitigation + +TIP-796 introduces a human-verifiable transaction confirmation layer at the Account Layer. + +By combining unique usernames, strict character restrictions, mandatory LTR rendering, and pre-signature username verification, the standard significantly reduces the effectiveness of many common address-based attack techniques observed across blockchain ecosystems. + +### 1. Clipboard Hijacking + +Clipboard malware typically replaces a copied destination address with an attacker-controlled address. + +Under TIP-796, the wallet retrieves and displays the official username associated with the destination address directly from the network before transaction signing. + +If the address has been replaced, the displayed username will not match the username expected by the sender, allowing the attack to be detected before confirmation. + +### 2. Address Spoofing and Look-Alike Addresses + +Attackers often generate addresses with similar prefixes or suffixes in an attempt to deceive users. + +TIP-796 introduces a unique username layer that is displayed alongside the destination address. + +Even if two addresses appear visually similar, their associated usernames remain different, providing an additional verification mechanism for users. + +### 3. Homograph Attacks + +Homograph attacks rely on visually similar Unicode characters. + +TIP-796 restricts usernames to ASCII lowercase letters (a-z), digits (0-9), and the mandatory TR prefix. + +This restriction prevents the use of deceptive Unicode characters within usernames. + +### 4. RTL/LTR Display Manipulation + +In multilingual environments, attackers may attempt to exploit bidirectional text rendering to create visual confusion. + +TIP-796 requires strict Left-to-Right (LTR) storage and display of usernames. + +Combined with the mandatory TR prefix, this significantly reduces the risk of direction-based spoofing attacks. + +### 5. UI-Layer Manipulation + +Malicious or poorly designed wallet interfaces may attempt to hide, shorten, or visually alter transaction information. + +TIP-796 requires wallets to display the complete username and the complete destination address before transaction signing. + +This creates a consistent verification experience across the ecosystem. + +### 6. Social Engineering Against Non-Technical Users + +Many users struggle to verify long blockchain addresses accurately. + +Human-readable usernames provide an additional visual reference that users can compare during transaction confirmation. + +This reduces the likelihood of mistakes caused by human error or deception. + +### 7. Transaction-History and Address-Poisoning Attacks + +Attackers sometimes send small transactions to victim wallets in order to place deceptive addresses in transaction history. + +Under TIP-796, users verify both the destination address and the associated username before signing. + +This additional verification step helps reduce the effectiveness of transaction-history poisoning techniques. + +## Security Summary + +TIP-796 does not replace existing blockchain security mechanisms. + +Instead, it adds a human-verifiable identity layer that helps users confirm transaction destinations more safely and more consistently before signing. + +By combining unique usernames, mandatory wallet display requirements, strict character restrictions, and on-chain username resolution, TIP-796 provides a substantial improvement in transaction-verification security and user experience across the TRON ecosystem. +___ +___ +# Username Assignment and Anti-Abuse Considerations + +. TIP-796 assigns usernames automatically at the Account Layer. + +. Unlike registration-based naming systems, usernames are not selected, purchased, reserved, auctioned, or transferred by users. + +. Instead, the network generates and assigns a unique username to each eligible account. + +. This approach removes competition for desirable names and significantly reduces the risk of name squatting and large-scale username harvesting. + +## Optional Anti-Abuse Mechanisms + +Network operators and wallet providers may implement additional anti-abuse measures to discourage large-scale automated account creation and username farming. + +### Possible mechanisms include: + +### 1. Username assignment conditional on account activation, for example, after the first deposit of digital assets to the account. + +### 2. Assignment Delay (Cooldown Period) + +### 2.1. A username may be assigned after a configurable waiting period following account activation. + +Example configurations: +· 24 hours +· 48 hours +· Longer periods if required by network policy + +### 2.2. Minimum Balance Requirement: + +A username may be assigned only if an account maintains a minimum balance during the cooldown period. + +Example thresholds: +· 2 TRX +· 10 TRX +. Other values determined by network policy + +### 2.3. User Education and Onboarding + +Wallets may provide educational onboarding before displaying usernames for the first time. + +Topics may include: + +· What usernames are +· How usernames are generated +· How usernames are linked to accounts +· How usernames improve transaction verification +· How to use usernames safely + +### 2.4. Optional Anti-Automation Challenges + +Wallets may implement lightweight anti-automation mechanisms such as: + +· CAPTCHA challenges +· Local proof-of-work mechanisms +· Other anti-bot verification methods + +The exact implementation remains wallet-specific and does not require protocol-level changes. + +## Combined Effect + +When combined with automatic username assignment, these mechanisms increase the economic and operational cost of large-scale username farming. + +As a result, mass automated harvesting of usernames becomes significantly less practical. + +## Namespace Capacity + +TIP-796 uses combinations of English words and numerical values to create an extremely large username space. + +Using a vocabulary of approximately 650,000 meaningful English words and combining two meaningful English words with a four-digit number, the supported username structures provide approximately 12.6 quadrillion unique usernames for TRON accounts. + +### Calculation: +650,000 * 650,000 * 10,000 = 4,225,000,000,000,000 + +Considering that usernames on the TRON network based on this proposal are constructed and assigned to accounts using three different combinations, the total namespace expands to: + +3 * 4,225,000,000,000,000 = 12,675,000,000,000,000 + +This namespace is substantially larger than the foreseeable number of TRON accounts and makes accidental collisions practically negligible. + +Because usernames are generated and assigned uniquely by the network, each username is permanently associated with a single account. + +## Purpose + +The purpose of TIP-796 is to provide TRON with a native, decentralized, human-readable, and security-focused identity layer that improves transaction verification without requiring smart contracts, registration fees, or external naming infrastructure. + +## Future Extensions + +Potential future enhancements may include: + +· Additional username structures +· Expanded supported character sets +· Specialized namespaces for ecosystem applications +· NFT-related identity extensions +· Ecosystem-specific tags and classifications + +These extensions are outside the scope of the current proposal and may be addressed in future TIPs. +___ +___ +# Existing Account Integration + +TIP-796 is designed to be fully compatible with both existing and future TRON accounts. + +For newly activated accounts, usernames may be assigned automatically during the account activation process according to the network's implementation strategy. + +For accounts that already exist on the TRON network, username assignment can be performed either gradually or through a network-wide allocation process, depending on the deployment model chosen by the TRON development team. + +Importantly, TIP-796 does not modify transaction validation rules, account ownership, cryptographic keys, balances, smart contracts, or existing account functionality. + +Wallets and applications that have not yet implemented TIP-796 remain fully operational and compatible with the network. + +This allows the username system to be introduced incrementally without disrupting existing users, wallets, services, or network operations. + +As wallet support expands, users will be able to view, copy, and verify their assigned usernames alongside their existing account addresses. + +The result is a backward-compatible migration path that improves usability and security without requiring changes to the core transaction model of TRON. +___ +___ +# Comparison with Existing Naming Systems + +Several blockchain ecosystems have introduced naming services, including ENS (Ethereum), SNS (Solana), BNS (BNB Chain), and other registration-based solutions. + +While these systems share the goal of improving usability, TIP-796 differs fundamentally in both architecture and operation. + +Most existing naming systems: + +. rely on smart contracts +. require name registration processes +. often require registration or renewal fees +. allow users to compete for specific names +. permit name trading, resale, or speculation +. operate outside the native account layer + +In contrast, TIP-796: + +. operates directly at the Account Layer +. does not require smart contracts +. does not require registration fees +. does not require renewal fees +. assigns usernames automatically through the network +. permanently binds usernames to accounts +. prevents name squatting, name auctions, and speculative registration +. provides a mandatory pre-signature username verification model + +Rather than functioning as a tradable naming service, TIP-796 is designed as a native security and usability layer that helps users verify transaction destinations before signing. + +This distinction allows TIP-796 to focus on transaction safety, human-readable account identification, and ecosystem-wide consistency while remaining fully decentralized and compatible with TRON's existing architecture. +___ +___ +# Threat Model + +TIP-796 is designed to reduce risks associated with human interaction with blockchain addresses. + +The proposal focuses primarily on attacks and failures that occur during transaction preparation, address verification, and transaction confirmation. + +## Threats Addressed by TIP-796 + +The following categories of threats are within the scope of this proposal: + +### 1. Clipboard Address Replacement + +Malware replaces a copied destination address with an attacker-controlled address before transaction confirmation. + +### 2. Address Spoofing and Look-Alike Addresses + +Attackers generate addresses with similar prefixes, suffixes, or visual patterns in an attempt to deceive users. + +### 3. Homograph and Confusable Character Attacks + +Visual deception through the use of similar-looking characters, alternative writing systems, or Unicode-based spoofing techniques. + +### 4. RTL/LTR Display Manipulation + +Abuse of bidirectional text rendering to create misleading visual representations of transaction destinations. + +### 5. UI-Layer Deception + +Wallet interfaces that hide, truncate, reorder, or visually manipulate destination information presented to users. + +### 6. Transaction-History and Address-Poisoning Attacks + +Insertion of deceptive addresses into transaction history with the goal of misleading future transactions. + +### 7. Human Verification Failures + +User mistakes resulting from the difficulty of verifying long blockchain addresses manually. + +## Threats Outside the Scope of TIP-796 + +TIP-796 is not intended to solve every security problem within the blockchain ecosystem. + +The following threats remain outside the scope of this proposal: + +### 1. Private Key Theft + +Compromise of private keys through malware, device compromise, social engineering, or other attack methods. + +### 2. Smart Contract Vulnerabilities + +Bugs, exploits, or security weaknesses in smart contracts or decentralized applications. + +### 3. Compromised Wallet Software + +Malicious wallets that intentionally ignore or violate TIP-796 requirements. + +### 4. Network-Level Attacks + +Consensus attacks, validator compromise, network partitioning, or protocol-level failures. + +### 5. Real-World Identity Verification + +TIP-796 usernames are not intended to represent legal identity, verified identity, reputation, or account ownership claims. + +## Security Objective + +The primary objective of TIP-796 is to introduce a human-verifiable transaction confirmation layer that helps users verify transaction destinations before signing. + +By providing unique on-chain usernames, mandatory wallet display requirements, strict character restrictions, and standardized verification workflows, TIP-796 significantly improves transaction-verification safety while remaining fully compatible with TRON's existing architecture. diff --git a/tips/tip-796.md b/tips/tip-796.md new file mode 100644 index 00000000..85e5e42e --- /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 diff --git a/tp/README.md b/tp/README.md index e51b5a12..583b7667 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.**