Repository navigation
Discussion: TIP-796 — Dual-Word + 4-Digit Username System for TRON Accounts #799
Description
This Issue opens the community discussion for TIP-796: Native Username Standard for TRON Accounts.
Summary
TIP-796 proposes a native, decentralized, human-readable username standard for TRON accounts. Usernames are automatically generated and randomly assigned by the network to eligible accounts based on staking requirements, improving transaction verification while preventing username squatting.
Author
Ali(GitHub: @alichatme)
Related PR: #920
We appreciate your valuable participation and feedback in helping improve this proposal.
Activity
alichatme commentedon Oct 9, 2025
tip: 796
title: TRON Account-Layer Username Standard
author: Ali (@alichatme)
discussions-to: #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 within the Account Layer.
This system:
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 eligible TRON account receives a unique, randomly generated username assigned by the network.
Username eligibility is based on a minimum staking requirement. The default proposed requirement is 10 TRX, although this parameter may be adjusted according to the policies of the Host Protocol.
Users cannot manually select, purchase, reserve, or register a username. This design prevents registration races, duplicate registrations, and username squatting.
The username is provided without registration or renewal fees, while the user retains the benefits of the underlying staking.
Username Retention and Reassignment Protection
If an account unstakes the minimum required amount, its username is not immediately removed. The username remains active and usable for a default retention period of 6 months, during which the account may restore the required staking and retain the same username.
If the required staking is not restored before the end of the retention period, the username is permanently detached from the account.
After detachment, the username enters a default 12-month reassignment protection period during which it cannot be assigned to another account. This period is intended to reduce the risk of phishing, impersonation, and confusion resulting from the immediate reassignment of a previously used username.
After the protection period expires, the username returns to the Username Pool and may be randomly assigned to another eligible account.
The previous owner has no preferential right to reclaim the username after the retention period has expired.
In Practice: Human Verification Before Transaction Signing
When a user wishes to receive funds, they send both their TRON address and their assigned username to the sender through an external channel, such as 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.
Before signing the transaction, the wallet displays the recipient's username together with the sender's address and the recipient's full destination address.
The sender then visually compares the username displayed by the wallet with the username previously received from the intended recipient.
If the two usernames match, the sender can proceed with signing the transaction.
If the two usernames do not match, the sender may identify a potential mistake, address substitution attack, phishing attempt, clipboard manipulation, or other destination mismatch and should stop the transaction before signing.
The responsibility for comparing the username received from the intended recipient with the username retrieved by the wallet from the network rests entirely with the user. The wallet provides the information required for this comparison but does not independently determine whether an attack has occurred or issue an attack-specific warning.
This mechanism is intentionally based on human verification: the network provides the authoritative username associated with the destination address, while the user determines whether that username matches the identity they intend to transact with.
By introducing a mandatory pre-signature username verification layer, TIP-796 provides a human-readable verification mechanism for blockchain transaction destinations while preserving decentralization, architectural compatibility, and zero-cost operation at the Account Layer.
Username Structure
TIP-796 introduces a standardized username format for TRON accounts. Usernames are generated by the network, permanently bound to eligible accounts, and function as a human-readable identity layer for transaction verification.
Each username:
Purpose of the TR Prefix
The mandatory TR prefix serves several important purposes:
Username Formats
Usernames are generated by the network using one of the following standardized patterns and are then assigned to eligible 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
All usernames must comply with the following rules:
LTR Enforcement and Visual Anti-Spoofing
Usernames must always be stored and displayed using strict Left-to-Right (LTR) directionality.
This design prevents:
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
Transaction Verification Flow
The recipient provides the sender with both the destination TRON address and its corresponding username through any external communication channel.
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.
Before signing, the wallet displays the recipient's username together with the sender's address and the recipient's address in the transaction confirmation window.
The sender compares the username received from the recipient with the username retrieved by the wallet from the network.
If both usernames match, the sender signs and confirms the transaction.
If the usernames do not match, the sender identifies a potential mistake, phishing attempt, clipboard attack, or address-substitution attack and stops the transaction process before signing.
The responsibility for verifying that the two usernames match rests entirely with the sender. The network simply returns the username associated with the destination account and does not determine whether the transaction should proceed.
This transaction-verification flow represents one of the primary security mechanisms introduced by TIP-796, enabling users to visually verify transaction destinations before signing while preserving TRON's decentralized architecture.
Username Assignment and Anti-Abuse Considerations
Unlike registration-based naming systems, TIP-796 does not allow users to select, purchase, reserve, auction, or transfer usernames. Instead, the network automatically assigns a unique username to each eligible account once the required staking conditions are satisfied.
This approach eliminates competition for desirable names while significantly reducing the risks of username squatting, registration races, duplicate registrations, and large-scale username harvesting.
Fundamental Principle
TRON assigns a free, randomly generated username to every eligible account that stakes at least 10 TRX (default value).
The account continues to receive the normal staking rewards provided by the network while simultaneously becoming eligible for a randomly assigned username.
The assigned username remains bound to the account as long as the account maintains the required minimum staking balance.
If the required staking balance is removed (Unstake), the username is not removed immediately. Instead, it remains active, fully functional, and associated with the same account for a default six-month Username Retention Period.
During this period, the account owner may restore the required minimum staking balance to retain the same username while continuing to receive the normal staking rewards.
If the required staking balance is not restored before the end of the six-month retention period, the username is detached from the account and enters a default twelve-month Reassignment Protection Period.
Username Assignment Process
Step 1 — Staking and Username Assignment
Once an account is activated and stakes at least 10 TRX (default value), the account becomes eligible for both the normal staking rewards and a randomly generated username.
The network automatically selects a unique username from the available Username Pool and assigns it to the account.
Step 2 — Unstake and Username Retention Period
If the account removes the minimum staking balance required to maintain username eligibility, the username is not removed immediately.
Instead, it enters a default six-month Username Retention Period, during which the username remains fully active, visible, and associated with the same account.
During this retention period:
Step 3 — End of the Username Retention Period
If the six-month retention period expires without restoring the required staking balance, the username is permanently detached from the account.
The account may continue operating normally without a username.
If the account stakes again after the username has been detached, it receives no preferential right to reclaim its previous username, even if that username is still within the Reassignment Protection Period.
Step 4 — Reassignment Protection Period (12 Months)
After a username has been detached from an account, it is not immediately reassigned to another account.
Instead, it enters a default twelve-month Reassignment Protection Period.
The purpose of this protection period is to reduce the risk of phishing, impersonation, and reputation-based attacks. Immediate reassignment could cause users to mistakenly believe that a newly assigned account still belongs to the previous owner.
Step 5 — Return to the Username Pool
After the Reassignment Protection Period expires, the username returns to the Username Pool and may again be randomly assigned to another eligible account.
At any given time, each username is associated with only one account.
Username Lifecycle
Stake 10 TRX
↓
Receive Random Username
↓
Unstake
↓
6-Month Username Retention Period
(Username remains active)
↓
Restore Minimum Stake?
│
Yes ─────────────► Username retained
│
No
↓
Username detached
↓
12-Month Reassignment Protection Period
↓
Return to Username Pool
↓
Random assignment to another eligible account
No Preferential Reclaim Principle
After the Username Retention Period expires, no account—including the previous owner—receives any preferential right to reclaim its former username.
This rule applies equally to all accounts without exception.
Configurable Parameters
The following values are the default parameters proposed by TIP-796 and may be adjusted by the Host Protocol according to future governance decisions:
Minimum staking required for username eligibility
10 TRX
Username Retention Period after Unstake
6 months
Reassignment Protection Period
12 months
Any future modification of these parameters must not enable username purchasing, reservation, squatting, or preferential reclaim of previously assigned usernames.
Effect of Staking on Preventing Large-Scale Username Farming
Under the staking-based assignment model, creating large numbers of usernames through automated tools or bot networks becomes both economically and operationally expensive.
To obtain each username:
The Host Protocol may adjust parameters such as the minimum staking requirement, the Username Retention Period, and the Reassignment Protection Period to adapt to changing network conditions.
However, these adjustments must never introduce mechanisms that enable username purchasing, reservation, squatting, or preferential reclaim of previously assigned usernames.
Namespace Capacity
TIP-796 generates usernames by combining meaningful English words with numerical values, creating an extremely large namespace.
Using approximately 650,000 meaningful English words, each supported username format provides:
650,000 × 650,000 × 10,000 = 4,225,000,000,000,000
possible unique usernames.
Because TIP-796 defines three standardized username formats, the total namespace expands to:
3 × 4,225,000,000,000,000 = 12,675,000,000,000,000
possible unique usernames.
This namespace is substantially larger than the foreseeable number of TRON accounts, making accidental collisions practically negligible.
At any given time, each username is associated with only one account. After the Username Retention Period and the Reassignment Protection Period expire, the username may return to the Username Pool and become eligible for assignment to another qualifying account.
The combination of staking-based eligibility, automatic recycling of inactive usernames, and random assignment helps prevent namespace exhaustion while significantly reducing username squatting.
Purpose
The purpose of TIP-796 is to provide TRON with a native, decentralized, human-readable identity layer that improves transaction verification, reduces address-based fraud and user errors, and operates entirely within the Account Layer without requiring smart contracts, registration fees, or external naming infrastructure.
Future Extensions
Potential future enhancements may include:
These enhancements 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, a username is assigned automatically once the account satisfies the minimum staking requirement defined by the Host Protocol. Usernames are generated randomly by the network and assigned in a fully decentralized manner, preserving the decentralization principles of TRON.
The minimum staking requirement for obtaining and maintaining a username is defined by the Host Protocol and applies equally to every eligible account.
The Host Protocol may modify protocol parameters over time, including:
Whenever these parameters are updated, the new policy applies uniformly across the entire network, including both accounts created before and after the policy change. This guarantees consistent protocol behavior and prevents different generations of accounts from being governed by different eligibility rules.
For accounts that already exist on the TRON network, usernames may be assigned after adoption of TIP-796 once the minimum staking requirement is satisfied. Deployment may occur gradually or through a network-wide allocation process, depending on the implementation strategy selected by the TRON development team.
TIP-796 does not modify transaction validation rules, account ownership, cryptographic keys, account balances, smart contracts, or any existing account functionality. It simply introduces a native account-level identity attribute that improves transaction verification through a human-readable username.
Wallets and applications that have not yet implemented TIP-796 remain fully compatible with the TRON network and continue to operate without modification. As adoption expands, compatible wallets will retrieve, display, and allow users to copy the username assigned to each account alongside its blockchain address.
The username lifecycle—including assignment, retention, removal, and reassignment protection—is governed by the protocol parameters defined by the Host Protocol. These parameters are applied consistently across the network and ensure that username management remains fair, predictable, and resistant to abuse while preserving backward compatibility.
As a result, TIP-796 provides a fully backward-compatible migration path that improves usability, strengthens transaction verification, discourages username squatting through staking-based eligibility, and preserves compatibility with the existing TRON transaction model without introducing registration fees, smart contracts, or external naming infrastructure.
Security Benefits and Attack Mitigation
TIP-796 introduces an additional human-verifiable transaction confirmation layer at the Account Layer.
By combining unique usernames, strict character restrictions, mandatory Left-to-Right (LTR) rendering, and pre-signature username verification, the standard helps mitigate several common address-based attack techniques observed across blockchain ecosystems while remaining fully compatible with TRON's existing security architecture.
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.
The sender compares the username displayed by the wallet with the username previously received from the intended recipient. If they do not match, the sender can identify a potential clipboard substitution attack and stop the transaction before signing.
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 that is displayed alongside the destination address.
Even if two blockchain addresses appear visually similar, their associated usernames remain different, providing users with an additional verification mechanism before confirming a transaction.
3. Homograph Attacks
Homograph attacks rely on visually similar Unicode characters to deceive users.
TIP-796 restricts usernames to lowercase ASCII letters (a-z), digits (0-9), and the mandatory uppercase TR prefix.
This restriction prevents deceptive Unicode characters from appearing within usernames and significantly reduces the effectiveness of homograph-based attacks.
4. RTL/LTR Display Manipulation
In multilingual environments, attackers may attempt to exploit bidirectional text rendering to create visual confusion.
TIP-796 requires usernames to be stored and displayed using strict Left-to-Right (LTR) directionality.
Combined with the mandatory TR prefix, this significantly reduces the risk of direction-based visual 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 compatible wallets to display the complete username together with the complete destination address before transaction signing.
This helps create a consistent transaction verification experience across the TRON ecosystem.
6. Social Engineering Against Non-Technical Users
Many users find it difficult to verify long blockchain addresses accurately.
Human-readable usernames provide an additional visual reference that users can compare during transaction confirmation.
This additional verification step helps reduce mistakes caused by human error, phishing, or other forms of social engineering.
7. Transaction-History and Address-Poisoning Attacks
Attackers sometimes send small transactions to victim wallets in order to place deceptive addresses within transaction history.
Under TIP-796, users verify both the destination address and the username resolved directly from the network before signing.
This additional verification step helps reduce the effectiveness of transaction-history poisoning and address-substitution techniques.
Security Summary
TIP-796 does not replace TRON's existing cryptographic or blockchain security mechanisms.
Instead, it introduces an additional human-verification layer that helps users verify transaction destinations more safely before signing.
By combining unique usernames, mandatory wallet display requirements, strict character restrictions, mandatory LTR rendering, and on-chain username resolution, TIP-796 strengthens transaction verification while preserving full compatibility with TRON's existing security architecture.
TIP-796 is designed to assist users in transaction verification and does not modify the consensus mechanism, cryptographic validation, account ownership, transaction execution rules, or any other core protocol behavior of the TRON network.
Comparison with Existing Naming Systems
Architectural and Design Philosophy
Existing blockchain naming systems, such as Ethereum Name Service (ENS), Solana Name Service (SNS), and BNB Name Service (BNS), generally follow a registration-based model in which users register, select, reserve, purchase, or transfer human-readable names.
TIP-796 follows a fundamentally different approach. Rather than treating usernames as digital assets, it treats them as protocol-assigned account identifiers that are automatically generated by the network and linked to eligible accounts.
Under this model, usernames are not selected by users and cannot be purchased, reserved, auctioned, or transferred.
Registration-Based Naming Systems
In registration-based systems, obtaining a name typically requires a registration process and may involve registration fees, renewal fees, auctions, or competition for desirable names.
Over time, this model can lead to:
The TIP-796 Model: Usernames Through Network Participation
TIP-796 introduces a staking-based eligibility model.
Instead of registering a username, an eligible account receives a randomly generated username after satisfying the minimum staking requirement defined by the Host Protocol.
By staking TRX, users not only become eligible for a username but also continue to receive the network's standard staking rewards while contributing to the security and stability of the TRON network.
This aligns the username system with network participation rather than with ownership or speculation.
Key Advantages of TIP-796
Zero Registration and Renewal Fees
TIP-796 introduces no registration fees, renewal fees, auctions, or recurring payments for usernames.
Users simply satisfy the staking eligibility requirement while retaining ownership of their staked assets.
Network Rewards Instead of Registration Costs
Eligible users continue receiving the normal staking rewards provided by the TRON network.
As a result, obtaining and maintaining a username does not require paying additional registration or renewal fees.
Fair and Automatic Allocation
Usernames are generated and assigned automatically by the network using standardized formats.
Because users cannot manually select usernames, competition for desirable names is eliminated.
Strong Resistance to Username Squatting
Acquiring large numbers of usernames requires maintaining the minimum staking requirement for a corresponding number of accounts.
This introduces an economic cost that substantially increases the difficulty of large-scale username farming and speculative accumulation.
Dynamic Username Lifecycle
Usernames are not permanently removed from the namespace.
When an account no longer satisfies the requirements defined by the Host Protocol, the username follows the proposal's retention and reassignment-protection periods before eventually returning to the Username Pool for future reassignment.
This keeps the namespace sustainable over time.
Alignment with Network Security
Because eligibility is linked to staking, the username system encourages participation in the network's existing security model.
Users who maintain staking both support network operation and remain eligible to retain their assigned usernames.
Consistency with TRON's Design Principles
TIP-796 is designed to operate consistently with TRON's account-based architecture.
The proposal preserves decentralization by ensuring that:
This design transforms usernames from tradable digital assets into protocol-managed account identifiers that improve usability and transaction verification while remaining fully integrated with TRON's existing account model.
Threat Model
TIP-796 is designed to help mitigate risks associated with human interaction with blockchain addresses.
The proposal focuses primarily on attacks and failures that occur during transaction preparation, destination verification, and transaction confirmation, where users are required to verify the intended recipient before signing a transaction.
Threats Addressed by TIP-796
The following categories of threats are within the scope of this proposal.
Malware replaces a copied destination address with an attacker-controlled address before transaction confirmation.
TIP-796 helps users identify such attacks by allowing them to compare the recipient's expected username with the official username retrieved from the network before signing.
Attackers generate addresses with similar prefixes, suffixes, or visual patterns in an attempt to deceive users.
TIP-796 provides an additional human-verifiable username that helps distinguish visually similar blockchain addresses.
Visual deception through similar-looking Unicode characters, alternative writing systems, or other character-spoofing techniques.
TIP-796 mitigates these attacks by restricting usernames to lowercase ASCII letters (a-z), digits (0-9), and the mandatory uppercase TR prefix.
Abuse of bidirectional text rendering to create misleading visual representations of transaction destinations.
TIP-796 requires usernames to be stored and displayed using strict Left-to-Right (LTR) directionality.
Non-compliant or malicious wallet interfaces may attempt to hide, truncate, reorder, or visually manipulate transaction information presented to users.
TIP-796 requires compatible wallets to display both the complete destination address and the complete username before transaction signing.
Attackers insert deceptive addresses into transaction history in an attempt to mislead future transactions.
TIP-796 helps users verify both the destination address and the associated username before signing.
User mistakes resulting from the difficulty of manually verifying long blockchain addresses.
Human-readable usernames provide an additional visual reference that assists users during transaction confirmation.
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.
Compromise of private keys through malware, device compromise, phishing, social engineering, or other attack methods.
Bugs, exploits, or security weaknesses in smart contracts or decentralized applications.
Malicious or non-compliant wallet software that intentionally ignores or violates the requirements defined by TIP-796.
Consensus attacks, validator compromise, network partitioning, denial-of-service attacks, or other protocol-level failures.
TIP-796 usernames are not intended to represent legal identity, verified identity, reputation, organizational affiliation, or proof of account ownership.
Security Objective
The primary objective of TIP-796 is to introduce an additional human-verifiable transaction confirmation layer that helps users verify transaction destinations before signing.
By combining unique on-chain usernames, mandatory wallet display requirements, strict character restrictions, mandatory Left-to-Right (LTR) rendering, and standardized verification workflows, TIP-796 helps improve transaction-verification safety while remaining fully compatible with TRON's existing architecture.
TIP-796 complements existing blockchain security mechanisms and does not modify the consensus protocol, cryptographic validation, transaction execution rules, or any other core security properties of the TRON network.
laurenceja commentedon Oct 10, 2025
@alichatme TRON accounts can set account name freely, without strict rules. Do we really need to make it so restrictive?
vivian1912 commentedon Oct 10, 2025
Related issue of #797 . So to better understand the motivation and context of this feature, it might be better to continue the discussion under #797 .
alichatme commentedon Oct 10, 2025
lxcmyf commentedon Oct 10, 2025
@alichatme
Can the naming be repeated under the naming standard you provided? Is there a repetitive check?
alichatme commentedon Oct 10, 2025
alichatme commentedon Oct 10, 2025
halibobo1205 commentedon Oct 13, 2025
Are there similar solutions (such as Name Service) on other chains?
alichatme commentedon Oct 13, 2025
GrothenDI commentedon Oct 15, 2025
@alichatme Hello, could you please briefly explain how these usernames are generated and how they are matched and bound to addresses?
alichatme commentedon Oct 15, 2025
GrothenDI commentedon Oct 15, 2025
What about the large number of addresses that already exist?
alichatme commentedon Oct 15, 2025
alichatme commentedon Nov 11, 2025
alichatme commentedon Nov 11, 2025
Linked to the latest proposal PR #803 for continued discussion and feedback on TIP-796: Account Layer Username Standard. We welcome community input and collaboration.
11 remaining items
bladehan1 commentedon Nov 14, 2025
Essentially, it uses a username to double-check the transaction address, preventing similar and forged addresses, such as clipboard attacks and pre-emptive phishing transactions.
Similar to how banking systems double-check transactions using usernames, it prevents errors and similar address attacks.
However, at the rule level, the word set and deduplication storage could be quite complex to implement.
Is it possible to re-hash the address and convert it into a quick 4-digit verification code to defend against attacks with similar address prefixes and suffixes? Of course, users would still need to additionally verify the address prefix and suffix.
alichatme commentedon Nov 14, 2025
Hi @bladehan1 👋 — thank you for your excellent technical question.
Your idea about using a hash-derived 4-digit verification code is absolutely valid and widely used in checksum systems (banking, ISO verification digits, etc.).
However, the purpose and design philosophy of TIP-796 is fundamentally different —
it solves several categories of attacks that a checksum cannot prevent.
🔹 1. A 4-digit checksum detects typos — but not attacks
A hashed 4-digit code can catch accidental typing mistakes.
But it cannot stop:
Homograph attacks
Look-alike address generation
RTL/LTR spoofing
Fake wallet UIs
Clipboard malware inserting a different address with the correct checksum
Addresses engineered to share similar suffix/prefix patterns
A checksum only validates numbers.
TIP-796 protects humans.
🔹 2. TIP-796 creates a visual identity layer that is impossible to spoof
A username like:
TRsunboy1185
is:
human-readable
visually distinctive
too long to collide
language-independent
bound at the Account Layer
impossible to fake without forging the entire account
A checksum has none of these properties.
🔹 3. Checksum systems fail in multilingual (especially RTL) environments
In languages like Persian, Arabic, Hebrew:
numbers can flip direction
UI elements can mirror accidentally
malicious wallets can reorder digits
text can wrap incorrectly
TIP-796 prevents all of this by enforcing:
Uppercase TR prefix
Pure ASCII
Strict LTR display
Full username shown before signing
No auto-shortening or hiding
This forms a universal, spoof-resistant identity layer.
🔹 4. Wordlist & deduplication complexity happens once
While the wordlist approach seems heavier:
the list is fixed
stored once
only used during account activation
deduplication happens a single time
This one-time complexity gives:
✔ Anti-phishing
✔ Anti-homograph
✔ Anti-malware
✔ Perfect UX in all languages
A checksum cannot provide these protections.
🔥 Final Comparison (GitHub-friendly table)
| Prevents typos
Feature ✔️ 4-Digit Verification Code | TIP-796 Username ✔️
| Prevents cloned-prefix attacks
Feature ❌ 4-Digit Verification Code | TIP-796 Username ✔️
| Prevents homograph attacks
Feature ❌ 4-Digit Verification Code | TIP-796 Username ✔️
| Prevents RTL spoofing
Feature ❌ 4-Digit Verification Code | TIP-796 Username ✔️
| Human-readable
Feature ❌ 4-Digit Verification Code | TIP-796 Username ✔️
| Resistant to UI manipulation
Feature ❌ 4-Digit Verification Code | TIP-796 Username ✔️
| Native account identity
Feature ❌ 4-Digit Verification Code | TIP-796 Username ✔️
| Helps non-technical users
Feature ❌ 4-Digit Verification Code | TIP-796 Username ✔️
| Provides social recognition
Feature ❌ 4-Digit Verification Code | TIP-796 Username ✔️
In summary
Checksums protect data.
TIP-796 protects people.
Your idea was fantastic and helped highlight why this proposal exists in the first place.
Looking forward to your further thoughts! 🙏🚀
— Team ali & chatgpt
alichatme commentedon Nov 14, 2025
🔍 Additional Clarification on 4-Digit Hash Codes vs TIP-796
To further expand on the discussion:
A 4-digit verification code derived from a hash provides only 10,000 possible combinations:
0000 → 9999 (10,000 total)
This creates a major limitation for any large blockchain network.
🚨 Collision Problem (Critical Weakness)
If the network has, for example, 1,000,000 accounts, the math is simple:
1,000,000 accounts / 10,000 codes = ~100 accounts sharing the same code
This means:
❌ The code cannot be unique
❌ ~100 different accounts will always share the same 4-digit code
❌ An attacker can easily use a different address with the same verification code
❌ The system provides almost no real protection in large networks
A 4-digit code is useful only for detecting typos, not for security.
🔥 Why TIP-796 Is Vastly Stronger
In contrast:
(12,600,000,000,000,000 combinations)
→ practically zero collisions, ever.
Not 1 of 100 duplicates —
1 of 1.
Thanks to:
Mandatory uppercase TR prefix
Strict ASCII
LTR-only storage & display
Human-readable dual-word structure
Wallets required to show the full username before signing
A checksum protects numbers.
A username protects people.
✅ Final Conclusion
A 4-digit hash code =
10,000 possibilities → ~100 collisions per million accounts → no real security
TIP-796 =
12.6 quadrillion possibilities → zero collisions → full visual & UX protection
This is why TIP-796 provides a real, human-layer safety mechanism that checksums simply cannot offer.
alichatme commentedon Nov 15, 2025
Hi @Jamq513 👋
Thank you for your support and for confirming the direction of the proposal.
We appreciate your participation — every approval helps move TIP-796 closer to the next stage. 🚀
alichatme commentedon Nov 16, 2025
Hi everyone 👋,
First of all, thank you all for your continuous collaboration, feedback, and technical insight throughout this proposal.
Your contributions have been essential in refining TIP-796 into a stronger, clearer, and more impactful standard.
Over the past days, based on the discussions here and additional internal analysis, our team reached an important conclusion:
👉 There is no security threat in blockchain / Web3 related to account addresses that TIP-796 cannot neutralize.
This includes all major attack categories such as:
Clipboard hijacking
Address-spoofing & look-alike collisions
Homograph attacks
RTL/LTR visual manipulation
UI-layer tampering
Social-engineering targeting non-technical users
Spam-activation & transaction-stuffing behavior
…and more.
Because of the critical importance of this discovery — and because TIP-796 significantly reduces the success rate of these attacks while also decreasing spam-transaction load on the network —
we’ve now incorporated this full security analysis into:
The updated proposal (TIP-796)
The updated README
This update highlights the fact that TIP-796 is not only a naming improvement, but a network-wide security enhancement layer that protects users, wallets, and the TRON ecosystem at a fundamental level.
We sincerely hope this helps the community better understand the depth and importance of this proposal.
Your participation and feedback have played a major role in shaping TIP-796, and we continue to welcome all comments and suggestions as we move forward.
With respect and appreciation,
Team ali & chatgpt 🚀
halibobo1205 commentedon Nov 20, 2025
@alichatme, Is there any progress and a detailed demonstration?
alichatme commentedon Nov 20, 2025
Hello @halibobo1205 👋
And warm greetings to all TRON community members,
Thank you very much for your follow-up and attention.
1. Regarding the progress:
Over the past two months, TIP-796 has been reviewed, refined, and rewritten multiple times based on the community’s feedback.
The current version — published a few days ago — has been fully checked again by our team and is now complete, stable, and fully ready for implementation.
2. Regarding an updated or improved version:
At this time, no further revision is required.
All submitted feedback has already been incorporated, and the existing version is the fully polished and improved one.
3. Regarding upcoming updates:
At this stage, this is our final version, and from our perspective, TIP-796 is mature, consistent, and ready for merging into the TRON network.
We are deeply grateful for the community’s valuable insights — including yours — which guided us throughout this process.
Of course, if the TRON team or the community proposes any new technical considerations, we are completely open to review.
But as of now, there are no unresolved issues from our side.
Thank you again for your attention and support. 🙏🚀
alichatme commentedon Nov 20, 2025
Hello @Jamq513 👋
Thank you for your message.
This issue (#799) is focused only on the TIP-796 proposal.
Your situation appears to be related to a personal wallet access problem, not to this proposal.
For your safety, please contact the official TRON wallet provider or the support team of the wallet you are using.
Unfortunately, we cannot help with private key or account-access recovery.
Wishing you the best, and stay safe.
Redchar1992 commentedon Jun 5, 2026
Human-readable account names would improve UX, but the proposal needs strong anti-confusion rules before wallet display can be safe.
The biggest issues I would want resolved are: homoglyph/confusable characters, word-list governance, name squatting, collision handling in wallet search, and whether resolution is fully on-chain or depends on an off-chain registry. Wallets should probably display usernames as an address aid, not as proof of real-world identity, unless there is a separate verification layer. Clear rules here will matter more than the exact word+digits format.
alichatme commentedon Jun 5, 2026
Thank you for your very professional and thoughtful questions, @Redchar1992.
The points you raised are among the most important considerations for any network-level naming standard, and I appreciate the opportunity to clarify them.
TIP-796 allows only ASCII characters consisting of lowercase English letters (a-z) and digits (0-9).
No Unicode characters, look-alike characters from other writing systems (such as Cyrillic), or right-to-left (RTL) characters are permitted.
In addition, the mandatory TR prefix and the requirement for strict Left-to-Right (LTR) storage and rendering are specifically designed to prevent visual manipulation.
As a result, homoglyph attacks and RTL/LTR display-manipulation attacks are effectively prevented by design.
The word list is predefined and maintained as part of the standard.
When a username is generated, words are selected from this predefined set and assigned uniquely to accounts.
Since usernames are generated by the network rather than chosen by users, the structure and consistency of the word list remain under the control of the standard itself.
In TIP-796, users do not choose their usernames.
Instead, the network assigns each account a unique randomly generated username from among quadrillions of possible combinations.
As a result, reserving, purchasing, hoarding, or front-running desirable names is not possible.
This is one of the fundamental differences between TIP-796 and systems such as ENS or other registration-based naming services where users compete for specific names.
Each username is unique at the Account Layer and is associated with exactly one account.
Therefore, a wallet search will either return no result or exactly one result.
In addition, wallets display the username alongside the full account address so users can verify both simultaneously.
TIP-796 is designed to operate entirely on-chain.
A username field is associated directly with the account at the Account Layer, and usernames are assigned directly to accounts.
The system does not depend on smart contracts, centralized registries, or any off-chain infrastructure.
On this point, I completely agree with your observation.
TIP-796 is not intended to provide real-world identity verification.
The username serves as a security and usability layer that helps users verify transaction destinations more safely and more easily.
If desired, separate identity-verification systems can be built independently on top of it.
Final Note
TIP-796 explicitly requires wallets to display both the username and the full account address before transaction signing.
Combined with the character restrictions, mandatory LTR rendering, and the standardized TR prefix, these rules significantly reduce user confusion and address-similarity-based abuse.
I hope this clarifies the concerns you raised.
Thank you again for your valuable feedback and for taking the time to review the proposal.
alichatme commentedon Jun 18, 2026
Community Review and Revision Process
TIP-796 has undergone multiple rounds of community discussion, technical review, and revision throughout its development.
Feedback from TRON community members, contributors, and reviewers helped clarify several important aspects of the proposal, including:
Based on this feedback, the proposal was refined, expanded, and updated to provide clearer specifications, stronger security guarantees, and more complete implementation guidance.
The current version reflects the cumulative results of those discussions and incorporates the major concerns and recommendations raised during the review process.
The authors appreciate the valuable contributions of the TRON community and welcome future technical feedback and discussion.
alichatme commentedon Jul 31, 2026
Dear @Benson0224,
Thank you for your feedback and for the very reasonable request to provide a clean and up-to-date Pull Request.
We have reviewed the proposal again and are currently preparing a revised version of TIP-796 based on the feedback received throughout the previous discussions.
The revised version will provide a clearer explanation of the username assignment mechanism, including:
. Staking-based eligibility
. The username retention period after unstaking
. The username reassignment protection period
. Rules preventing preferential recovery of previously assigned usernames
These changes are being made based on the feedback received from the community, particularly regarding the issue of username squatting.
Once the review and update are complete, we will submit the revised proposal through a new and clean Pull Request, as requested.
Thank you again for your attention and for taking the time to review this proposal.
waynercheung commentedon Sep 8, 2026
Commenting as a community developer, not on behalf of the TIP editors.
I have read the full thread and PR #920. I am collecting the open technical questions in one place so this can either move forward on a concrete basis or reach a decision. Code links point at
GreatVoyage-v4.8.2.1(f8b05d4).1. Why are the existing fields insufficient?
@halibobo1205 and @Federico2014 raised this here, @barbatos2011 / @L-Reid on #797. The two fields are not equivalent, so to fix the baseline:
account_id(Tron.proto#L192): 8 to 32 bytes, printable ASCII 0x21-0x7E (TransactionUtil#L85-L86, #L104-L118), globally unique and immutable once set (SetAccountIdActuator#L90-L96), indexed inAccountIdIndexStore, and resolvable name-to-address viaWallet#getAccountById:GetAccountByIdover gRPC,/wallet/getaccountbyidover HTTP.account_name(Tron.proto#L138): up to 200 bytes with no charset validation (TransactionUtil#L62-L75), unique network-wide and settable only once whileALLOW_UPDATE_ACCOUNT_NAME == 0(default, UpdateAccountActuator#L89-L97), indexed inAccountIndexStore. Unlikeaccount_id, it has no public name-to-address endpoint.calcFee()returns 0 in SetAccountIdActuator#L107-L109 and UpdateAccountActuator#L108-L110. Ordinary transaction bandwidth rules still apply.So
account_idalready provides an on-chain, unique, non-transferable, resolvable, user-selectable ASCII account label with no registration fee. It does not provide what is new in TIP-796: network-side random assignment, the staking eligibility gate, and the retention / reassignment lifecycle.The open question is therefore not "does something similar exist", but: which user-facing property requires network-assigned names, and why can it not be obtained from
account_idplus wallet-layer conventions? One paragraph in Motivation would settle much of this thread.Smaller point:
account_idwas described on #797 as "an internal identifier ... long, not user-friendly, and difficult to remember". It is user-chosen and can be 8 characters. Whether a randomly assigned 12+ character name is easier to recall than that is an empirical claim, and no evidence has been offered either way.2. The username is not, as specified, an independent trust anchor
The flow does defend against plain clipboard replacement: if malware swaps only the address, the wallet resolves a different name and the mismatch is visible. But the proposal lets the address and the username travel over the same external channel and does not require an independent one, so an attacker who controls or spoofs that channel substitutes both values and the comparison passes.
The threat model should therefore distinguish clipboard substitution from phishing or social-engineering cases involving recipient-channel compromise; adding a username does not mitigate the latter by itself. If a stronger claim is intended, the TIP needs to require an independent channel explicitly.
3. Compare against address-derived short codes
@bladehan1 suggested this on 2025-11-14. The reply rebutted a 4-digit width (10,000 values, about 100 accounts per code), which is fair against that width but not against the construction. A 3- or 4-word mnemonic derived from the address hash, in the style of key-fingerprint word encodings, reaches a comparable namespace with no consensus change, no new state, no word list inside consensus, no staking and no expiry timers, and covers every existing account the day a wallet ships it.
It is not strictly better: it needs its own analysis of vanity-address grinding, where an attacker generates keys offline until the derived words are close to a target's. That analysis is missing on both sides. But it is the cheapest construction delivering the same "short string for a human to compare" property, so the Rationale should compare against it before asking for a consensus change.
4. Define the randomness source, and analyse near-collisions
Randomness source. It has to be verifiable, bias-resistant, resistant to re-rolling, and byte-identical on every node. If a user can influence the draw by timing the staking transaction, or by discarding an account and retrying, the name is effectively chosen rather than assigned. This is the most consensus-sensitive part of the design and currently has no text at all.
Near-collisions. The namespace figure (about 1.2675e16 across the three formats) does not specify exact-collision handling and says nothing about whether a human will confuse two distinct names. The attack that matters is obtaining a name a human confuses with the target's, for example
TRsunboy1185againstTRsunboy1186. Two things make this worth quantifying: the 10 TRX is staked rather than spent and is returned after the unstake window, so the marginal cost per attempt is the one-off activation fee plus opportunity cost; and redraws are asymmetric, since an attacker can open accounts in parallel and keep only the close draws, while a defender has no in-place rename and must go through unstake, 6-month retention, detachment and reassignment, with no preferential reclaim. The expected number of attempts to reach a confusable name under a stated similarity metric, against the cost and latency of a defender's redraw, would settle this.5. Two mitigations need requalifying
Homograph and RTL/LTR (items 3 and 4): what users compare today is a base58 address, which is ASCII only and carries a 4-byte checksum, with no Unicode or bidirectional text. The ASCII and LTR rules are sound hygiene for the name TIP-796 introduces, but they do not remove an existing risk from the address comparison flow. UI-layer manipulation (item 5): the chain cannot enforce rendering, so a malicious wallet ignores the display requirement; that belongs under wallet integration guidance rather than under mitigated threats.
6. What is missing before this is implementable
Against template.md, PR #920 has no Specification, Rationale or Implementation section, all three of which the template marks as required, and no
categoryin the front matter (required for Standards Track; this would be Core). Test Cases are marked mandatory for TIPs affecting consensus.An implementer would additionally need:
7. Suggested decision point
@alichatme has engaged repeatedly in this discussion, and #920 is the clean single-file resubmission that was asked for in #803, so this should not be closed silently. But the thread has been open since 2025-10, recent rounds have expanded the security sections rather than added specification, and without items 1 to 7 there is not yet a specification precise enough for java-tron implementations to remain interoperable.
My suggestion to the editors is a stated decision point rather than an open-ended wait: if no substantive revision with a Specification and an implementation plan is provided by 2026-09-22, close #920 and #799 as "not planned in current form", leaving the door open for a future submission that includes them.
A smaller version could ship with no protocol change, if the author is interested: a wallet display standard covering "always show the full destination address", "never truncate", and a secondary identifier at signing time. That identifier needs care, since
account_idpermits confusable ASCII such as l/I/1 and O/0, so: showaccount_idonly when it conforms to a restricted display profile, otherwise a high-entropy, address-derived fingerprint. That is implementable today and would fit an Interface-category or Informational TIP.Happy to review a Specification draft if one is prepared.
alichatme commentedon Sep 12, 2026
Thank you for your detailed and technical review. This kind of structured feedback helps move the discussion forward. You correctly compared the proposal with existing mechanisms and asked about the fundamental differences and the necessity of implementing this proposal on the network. Allow me to address the main points clearly.
1. Fundamental Difference Between TIP-796 and account_id / account_name
The key point is that TIP-796 is not a "naming" standard — it is a transaction verification layer.
Both account_id and account_name are user-selected identifiers. This means:
TIP-796, in contrast:
Therefore, account_id is a resolvable identifier, but TIP-796 introduces a dual verification layer that account_id does not provide.
2. The Core of the Proposal: A Secure Asset Transfer Layer
After the network migrates to TIP-796, the asset transfer process changes as follows:
The responsibility for comparing the username received from the intended recipient with the username retrieved by the wallet from the network rests entirely with the user.
This mechanism compares two independent sources: one from the recipient (external channel) and one from the network (on-chain). This is precisely what distinguishes TIP-796 from account_id and from an address-derived fingerprint.
3. Why an Address-Derived Fingerprint Is Not Sufficient
Your suggestion of a multi-word fingerprint derived from the address hash is technically interesting, but it has a fundamental weakness:
The fingerprint is derived from the address. This means that if an attacker replaces the address, the fingerprint automatically changes as well, and no mismatch is presented to the user.
In contrast, the TIP-796 username is independent of the address and is assigned by the network. This independence is what enables attack detection.
4. Regarding the Randomness Source and Near-Collision Analysis
A random function and a repository in which usernames are stored can address your concern.
Although we have not addressed this directly, the implementation approach is left to the network, which can select an appropriate method.
5. Regarding account_id and Confusable Characters
Your point about l/I/1 and O/0 in account_id is entirely correct. This is precisely one of the reasons TIP-796 enforces strict character restrictions (only lowercase ASCII and digits) and mandates the TR prefix to prevent identity spoofing.
Since attack detection in our proposed model is performed by the user, this is reflected in the threat model. The additional strict measures you mentioned serve to make the attack window harder for the attacker and attack detection easier for the user, while also ensuring uniform behavior across wallets and a consistent user experience.
6. Regarding Specification and Implementation
PR #920 is a clean, single-file version submitted in response to the TRON team's request in #803.
For a cleaner version, we have made some changes to the proposal text while also retaining the previous version. If the TRON team does not accept the new version and considers the previous approach more useful, we can replace the new version with the previous one.
7. Advantages of the New Version Over the Previous Version
7.1. Username Assignment Model
7.2. Staking Instead of Registration
7.3. Prevention of Username Squatting
7.4. Retention and Protection Lifecycle
7.5. No Preferential Reclaim Principle
7.6. Sustainable Namespace
7.7. Greater Transparency Compared to Other Systems
7.8. More Comprehensive Threat Model
7.9. Compatibility with Existing Accounts
7.10. Configurable Parameters
The Specification and Implementation sections are described in detail in the proposal. This proposal is not technically difficult and can be easily implemented by adding a single field to the account section of the network.
Your suggestion to set a specific deadline (September 22, 2026) is understandable. However, it should be noted that the primary goal of TIP-796 is to secure asset transfers — not merely to add a "name." This goal cannot be fully achieved by any of the existing mechanisms (account_id, account_name, or an address-derived fingerprint).
In closing, we thank you for the technical approach you provided. After the initial implementation, for future updates, we can use your suggestions to simplify addresses for businesses and to charge fees for changes or maintenance.
We would be happy, should TIP-796 be implemented, to benefit from your technical insights in the second phase of implementation with the business-oriented approach.
Thank you again for your valuable feedback.
waynercheung commentedon Sep 13, 2026
Thanks for the reply. I will keep this to the points where I think we still differ on facts or logic rather than re-cover the rest.
On section 3 (address-derived fingerprint). The claim is: "if an attacker replaces the address, the fingerprint automatically changes as well, and no mismatch is presented." That is not how the comparison works. The value the sender compares against is the fingerprint received from the recipient over the external channel, not one computed from the pasted address. The wallet computes
F(pasted address); the sender compares it with the received value. If the recipient's address A is replaced by B, the wallet showsF(B), which does not match theF(A)the sender received, and the mismatch is visible, exactly as in the TIP-796 flow.Side by side, the three flows have the same shape:
username(A)received from the recipient; check =username_of(pasted address)read from the network.account_id: reference =account_id(A)received from the recipient; check =account_id_of(pasted address)read from the destination account record, when an account_id is set.F(A)received from the recipient; check =F(pasted address)computed locally.In all three, the same reference-versus-check comparison exists: the reference comes from the recipient channel, the check is derived from the pasted address, and a swapped address produces a mismatch. None supplies an independent trusted communication channel. "Independent of the address" is therefore not what distinguishes TIP-796.
What does distinguish them is the cost for an attacker to obtain a token that a human will confuse with the target's:
account_id: chosen directly by the attacker.This may be the strongest potential distinction, but it has not yet been demonstrated. It depends on a defined similarity metric, the distribution of confusable names in the word list, the randomness construction, and a quantified cost of parallel re-rolling. That is why section 4 of the reply ("a random function and a repository ... left to the network") is a central point that cannot be left open. For a Core Standards Track TIP the derivation is the specification: all consensus implementations must derive the same assigned name for the same state transition, or they will diverge. The security argument and the interoperability requirement point at the same missing text.
For concreteness, a minimal outline of what that text has to cover:
seed = H(domain tag || entropy input || account address), with the entropy input named explicitly and an argument for why the submitting account cannot choose or re-roll it;name = f(seed)over a word list with a stated version and digest, plus the rule that selects one of the three formats;f(seed)collides with an already assigned name, including the retry counter and the canonical assignment order;On section 6. PR #920 at e8417d8 has no Specification, Rationale or Implementation heading. The headings present are Summary, Username Structure, Username Assignment and Anti-Abuse Considerations, Configurable Parameters, Existing Account Integration, Security Benefits and Attack Mitigation, Comparison with Existing Naming Systems, and Threat Model. "Adding a single field to the account" also does not cover what the proposal itself describes: the retention and protection deadlines are per-account lifecycle state; enforcing global uniqueness, and supporting name-to-address resolution if it is intended, requires a defined index or keyspace; and expiry needs defined semantics. Modest, but more than one field, and they need to be written down.
On the display requirement. "Wallets MUST display X before signing" is a wallet convention, not a protocol property. It could be written in an Interface TIP without touching consensus, so on its own it does not motivate a consensus change. Such a TIP should not require displaying an arbitrary
account_id, since the current character set is not safe for that; it should define a restricted display profile or an address-derived fingerprint, as noted earlier.On the decision point. I read the reply as not committing to a Specification before 2026-09-22. My suggestion to the editors is unchanged: if a complete, normative Specification covering the outline above, together with an implementation plan and test vectors, is added to #920 by then, the proposal becomes reviewable and should stay open; if not, close as "not planned in current form", with a later resubmission welcome.