Discussion: TIP-796 — Dual-Word + 4-Digit Username System for TRON Accounts

[alichatme]

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.

[alichatme]

---

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:

. 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
. uses a staking-based eligibility mechanism to prevent username squatting and large-scale free username farming

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:

. begins with the mandatory uppercase prefix TR
. is stored on-chain together with the prefix
. must always be displayed by wallets exactly as returned by the network
. must never be truncated, shortened, modified, or displayed without the TR prefix
. is composed exclusively of lowercase ASCII letters (a-z) and digits (0-9) following the prefix

Purpose of the TR Prefix

The mandatory TR prefix serves several important purposes:

. Instantly identifies the username as belonging to the TRON network.
. Prevents ambiguity between different blockchain naming systems.
. Provides a fixed visual anchor during transaction verification.
. Strengthens resistance against RTL/LTR display manipulation attacks.

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:

. No special characters
. No spaces
. No underscores
. ASCII characters only
. Strict Left-to-Right (LTR) storage and rendering
. The uppercase TR prefix is mandatory and forms part of the username identity
. Usernames are stored on-chain together with the TR prefix
. Wallets must display usernames exactly as returned by the network without any modification
. Usernames are generated by the network and cannot be manually selected, purchased, or reserved by users
. Each username is unique and permanently bound to a single account while assigned

LTR Enforcement and 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 part of the username.
. Usernames serve 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

1. The recipient provides the sender with both the destination TRON address and its corresponding username through any external communication channel.

2. The sender enters or pastes the destination address into the wallet.

3. The wallet retrieves the official username associated with that address directly from the network.

4. 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.

5. The sender compares the username received from the recipient with the username retrieved by the wallet from the network.

6. If both usernames match, the sender signs and confirms the transaction.

7. 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.

. Users cannot choose, purchase, reserve, or customize usernames.
. Username assignment is completely free and requires no registration or renewal fees.
. In addition to receiving a username, the account continues earning the standard staking rewards defined by the Host Protocol.

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:

. The username continues to appear in wallets and transaction verification interfaces.
. The account owner may restore the required minimum staking balance at any time to retain the same username.

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:
. An account must stake at least the minimum amount defined by the Host Protocol (default 10 TRX). Consequently, creating large numbers of usernames requires proportional capital commitment. For example, obtaining 100 usernames requires at least 1,000 TRX to be staked.
. The economic cost therefore scales linearly with the number of usernames, making large-scale farming progressively more expensive.
. Username assignment occurs only after a valid staking transaction has been successfully submitted and confirmed by the network.
. Automated farming systems must therefore create, sign, and broadcast valid blockchain transactions for every account, substantially increasing operational complexity.
. After staking is confirmed, the network automatically assigns a unique username and wallets display it to the account owner.
. Releasing staked assets remains subject to Host Protocol rules. Under the current TRON policy, unstaked assets become available only after the mandatory unfreezing period, making continuous cycling of large numbers of accounts significantly more difficult.
. If the account later loses the minimum staking requirement, the username does not remain permanently attached. Instead, after the Username Retention Period and the Reassignment Protection Period expire, it returns to the Username Pool for future assignment.
. Consequently, maintaining large numbers of usernames requires maintaining staking capital across many accounts, substantially increasing the long-term economic cost of username squatting.

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:

. Additional username structures
. Expanded supported character sets
. Ecosystem-specific namespaces and classifications
. NFT-related identity extensions
. Other application-specific namespace models

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:

. the minimum staking requirement for username eligibility;
. the username retention period following unstaking;
. the username reassignment protection period.

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:

. Competition for attractive names.
. Name squatting and speculative registrations.
. Large numbers of inactive or permanently reserved names.
. Progressive reduction of the available namespace.

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:

. Usernames are generated and assigned automatically by the network.
. No registration authority allocates usernames.
. Usernames cannot be bought, sold, reserved, auctioned, or transferred.
. Every eligible account is subject to the same protocol-defined eligibility rules.
. Eligibility parameters, including the minimum staking requirement and lifecycle periods, are determined uniformly by the Host Protocol.

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.

1. Clipboard Address Replacement

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.

2. Address Spoofing and Look-Alike Addresses

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.

3. Homograph and Confusable Character Attacks

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.

4. RTL/LTR Display Manipulation

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.

5. UI-Layer Deception

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.

6. Transaction-History and Address-Poisoning Attacks

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.

7. Human Verification Failures

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.

1. Private Key Theft

Compromise of private keys through malware, device compromise, phishing, 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 or non-compliant wallet software that intentionally ignores or violates the requirements defined by TIP-796.

4. Network-Level Attacks

Consensus attacks, validator compromise, network partitioning, denial-of-service attacks, or other protocol-level failures.

5. Real-World Identity Verification

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]

@alichatme TRON accounts can set account name freely, without strict rules. Do we really need to make it so restrictive?

[vivian1912]

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]

Thank you for your feedback 🙏 The goal of this proposal is *not to restrict* account naming freedom, but to *introduce an optional, standardized, and verifiable username format* that improves user safety. Today, TRON accounts can set any name freely — but that flexibility also allows *impersonation or misleading names*. With this system, wallets can display both the username and the full address before signing, helping users confirm they’re sending to the correct account. So the proposal doesn’t change the protocol logic — it simply *adds a reliable naming layer to prevent address-based fraud.* در تاریخ جمعه ۱۰ اکتبر ۲۰۲۵، ۱۲:۵۵ laurenceja ***@***.***> نوشت:

…

*laurenceja* left a comment (tronprotocol/tips#799) <#799 (comment)> @alichatme <https://github.com/alichatme> TRON accounts can set account name freely, without strict rules. Do we really need to make it so restrictive? — Reply to this email directly, view it on GitHub <#799 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BX4PW3BKY7NVBVLTJOYP2XD3W53PZAVCNFSM6AAAAACIY6F5LSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGOBZGA2DSMZXG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[lxcmyf]

@alichatme
Can the naming be repeated under the naming standard you provided? Is there a repetitive check?

[alichatme]

Thank you @lxcmyf for raising this point In this proposal, usernames are not created manually or through smart contracts. Instead, all ~3.6 quadrillion possible names are pre-generated and distributed randomly across accounts. That means: Each assigned username is unique, because once it’s used, it’s removed from the available pool. There’s no need for smart contract logic or fees, keeping the system lightweight and decentralized. Random assignment ensures fairness and prevents duplication or manipulation. When a user confirms a transaction, seeing the destination’s unique username (e.g. boymen4565) provides strong reassurance that the address is correct — boosting both user trust and TRON’s overall security model. در تاریخ جمعه ۱۰ اکتبر ۲۰۲۵، ۱۳:۳۱ lxcmyf ***@***.***> نوشت:

…

*lxcmyf* left a comment (tronprotocol/tips#799) <#799 (comment)> @alichatme <https://github.com/alichatme> Can the naming be repeated under the naming standard you provided? Is there a repetitive check? — Reply to this email directly, view it on GitHub <#799 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BX4PW3B35MJVZMDRAGUPGKL3W57ZHAVCNFSM6AAAAACIY6F5LSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGOBZGE3DEMRQGU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[alichatme]

Thank you @laurenceja for your thoughtful follow-up You’re absolutely right — TRON already allows free naming. This proposal does not aim to replace or restrict that flexibility. Instead, it introduces an optional, standardized, and verifiable username format that can coexist with the current free naming system. The goal is to improve transaction safety by helping users visually confirm the correct recipient before signing — reducing address mix-ups or phishing-style fraud. So, freedom stays intact, but with an added layer of trust that benefits both users and the TRON ecosystem. در تاریخ جمعه ۱۰ اکتبر ۲۰۲۵، ۱۴:۲۲ ali aram ***@***.***> نوشت:

…

Thank you @lxcmyf for raising this point In this proposal, usernames are not created manually or through smart contracts. Instead, all ~3.6 quadrillion possible names are pre-generated and distributed randomly across accounts. That means: Each assigned username is unique, because once it’s used, it’s removed from the available pool. There’s no need for smart contract logic or fees, keeping the system lightweight and decentralized. Random assignment ensures fairness and prevents duplication or manipulation. When a user confirms a transaction, seeing the destination’s unique username (e.g. boymen4565) provides strong reassurance that the address is correct — boosting both user trust and TRON’s overall security model. در تاریخ جمعه ۱۰ اکتبر ۲۰۲۵، ۱۳:۳۱ lxcmyf ***@***.***> نوشت: > *lxcmyf* left a comment (tronprotocol/tips#799) > <#799 (comment)> > > @alichatme <https://github.com/alichatme> > Can the naming be repeated under the naming standard you provided? Is > there a repetitive check? > > — > Reply to this email directly, view it on GitHub > <#799 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/BX4PW3B35MJVZMDRAGUPGKL3W57ZHAVCNFSM6AAAAACIY6F5LSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGOBZGE3DEMRQGU> > . > You are receiving this because you were mentioned.Message ID: > ***@***.***> >

[halibobo1205]

Are there similar solutions (such as Name Service) on other chains?

[alichatme]

Thank you for the great question Yes, several blockchains — such as Ethereum (ENS), Solana (SNS), and BNB Chain — have introduced name services with similar goals. However, our proposal is fundamentally different in both **design and purpose**. Most existing systems are **smart contract–based** and operate as **layer-two solutions**, meaning: - Names are registered and managed through a contract, not the native account layer. - Each operation (register, renew, or transfer) requires a **gas fee**. - Ownership of the name is stored within the contract, not within the blockchain’s core account system. In contrast, our proposal integrates the naming system **directly into TRON’s native account layer**, not as a smart contract or an external protocol. That means: - **No gas fee** for assigning or using a name. - **No central contract** controlling registration. - **No duplicate names**, as they are generated and linked algorithmically. - **Complete decentralization**, since the network itself handles name allocation. - And, most importantly, **enhanced user safety** — users can confirm a receiver’s identity right inside the wallet before signing a transaction. Beyond the technical aspect, this proposal also addresses one of the biggest barriers to blockchain adoption — **trust and usability**. People **simply cannot remember or manually type** long, unreadable wallet addresses. This complexity has been one of the main causes of user errors and fraud, such as address replacement malware. With this system, wallets can display the verified username tied to each address, so users can instantly confirm they’re sending funds to the right person. TRON, with over **400 million active accounts**, is in the perfect position to lead this change — bringing simplicity, safety, and human-centered design to decentralized systems, without compromising their core principles. **In short:** While other chains rely on smart contracts and layer-two services, TRON can deliver a **native, gas-free, and fully decentralized** naming system — turning complex blockchain addresses into something every user can trust and understand. در تاریخ دوشنبه ۱۳ اکتبر ۲۰۲۵، ۶:۳۷ halibobo1205 ***@***.***> نوشت:

…

*halibobo1205* left a comment (tronprotocol/tips#799) <#799 (comment)> Are there similar solutions (such as Name Service) on other chains? — Reply to this email directly, view it on GitHub <#799 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BX4PW3DJQGFWKKSTNGB2SXD3XMJOTAVCNFSM6AAAAACIY6F5LSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGOJVG4YTCNZSHE> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[GrothenDI]

@alichatme Hello, could you please briefly explain how these usernames are generated and how they are matched and bound to addresses?

[alichatme]

Thank you for your time and for asking such a great question. In the English language, there are approximately one million meaningful words. We use around 650,000 meaningful words after filtering out inappropriate or overly technical terms. Each username is generated by combining two random words and four random digits. Here’s the calculation for the total possible combinations: - First word: 650,000 options - Second word: 650,000 options - Four-digit number: 10,000 options (from 0000 to 9999) Therefore: 650,000 × 650,000 × 10,000 = 4,225,000,000,000,000 ≈ about 4.2 quadrillion unique usernames. Even after filtering, this number is extremely large, providing a secure and vast namespace for simple, human-readable, and decentralized usernames. Whenever a new account is created or activated on the TRON network, the system — according to the TRON development team’s configuration — randomly assigns one of the available names from the repository to that account. To prevent duplication, the assigned name is then removed from the available pool. Once a name has been assigned to an account, it remains permanently bound to that address and cannot be changed. This process does not require any smart contracts or secondary layers — it operates entirely at the **Account Layer**, ensuring that the core structure and protocols of the TRON network remain completely unchanged. As a result: - All usernames are unique and non-repetitive. - The assignment process is decentralized and trustless. - Users can visually confirm transaction destinations, effectively eliminating the risk of errors or phishing attacks. در تاریخ چهارشنبه ۱۵ اکتبر ۲۰۲۵، ۹:۰۶ GrothenDI ***@***.***> نوشت:

…

*GrothenDI* left a comment (tronprotocol/tips#799) <#799 (comment)> @alichatme <https://github.com/alichatme> Hello, could you please briefly explain how these usernames are generated and how they are matched and bound to addresses? — Reply to this email directly, view it on GitHub <#799 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BX4PW3ELDHQBWKXUJOIB6ZT3XXMNTAVCNFSM6AAAAACIY6F5LSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIMBUGU4TENZUGY> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[GrothenDI]

Thank you for your time and for asking such a great question.

In the English language, there are approximately one million meaningful
words.
We use around 650,000 meaningful words after filtering out inappropriate or
overly technical terms.
Each username is generated by combining two random words and four random
digits.

Here’s the calculation for the total possible combinations:

• First word: 650,000 options
• Second word: 650,000 options
• Four-digit number: 10,000 options (from 0000 to 9999)

Therefore:
650,000 × 650,000 × 10,000 = 4,225,000,000,000,000 ≈ about 4.2 quadrillion
unique usernames.

Even after filtering, this number is extremely large, providing a secure
and vast namespace for simple, human-readable, and decentralized usernames.

Whenever a new account is created or activated on the TRON network, the
system — according to the TRON development team’s configuration — randomly
assigns one of the available names from the repository to that account.
To prevent duplication, the assigned name is then removed from the
available pool.

Once a name has been assigned to an account, it remains permanently bound
to that address and cannot be changed.
This process does not require any smart contracts or secondary layers — it
operates entirely at the Account Layer, ensuring that the core
structure and protocols of the TRON network remain completely unchanged.

As a result:

• All usernames are unique and non-repetitive.
• The assignment process is decentralized and trustless.
• Users can visually confirm transaction destinations, effectively
  eliminating the risk of errors or phishing attacks.

در تاریخ چهارشنبه ۱۵ اکتبر ۲۰۲۵، ۹:۰۶ GrothenDI @.***>
نوشت:
…

What about the large number of addresses that already exist?

[alichatme]

Thank you very much for your insightful comment and excellent question. Yes, the allocation of usernames to existing TRON accounts can be done gradually or all at once, depending on the TRON development team’s implementation strategy. Wallets will also need to be updated so that each user can view and copy their assigned username alongside their account address. Importantly, since usernames do not affect TRON’s transaction validation protocols, accounts and wallets that have not yet been updated will continue to function normally until full integration is complete. Once all accounts have received their usernames and wallet updates are deployed, transactions will include a visual verification step: when a sender enters the destination address, the wallet will automatically display the corresponding username before final confirmation. This allows users to verify the destination account visually, effectively preventing transfer mistakes — one of the most common user concerns in crypto transactions. This approach strengthens trust, security, and usability across the TRON ecosystem without modifying the core protocol. در تاریخ چهارشنبه ۱۵ اکتبر ۲۰۲۵، ۱۰:۵۰ GrothenDI ***@***.***> نوشت:

…

*GrothenDI* left a comment (tronprotocol/tips#799) <#799 (comment)> Thank you for your time and for asking such a great question. In the English language, there are approximately one million meaningful words. We use around 650,000 meaningful words after filtering out inappropriate or overly technical terms. Each username is generated by combining two random words and four random digits. Here’s the calculation for the total possible combinations: - First word: 650,000 options - Second word: 650,000 options - Four-digit number: 10,000 options (from 0000 to 9999) Therefore: 650,000 × 650,000 × 10,000 = 4,225,000,000,000,000 ≈ about 4.2 quadrillion unique usernames. Even after filtering, this number is extremely large, providing a secure and vast namespace for simple, human-readable, and decentralized usernames. Whenever a new account is created or activated on the TRON network, the system — according to the TRON development team’s configuration — randomly assigns one of the available names from the repository to that account. To prevent duplication, the assigned name is then removed from the available pool. Once a name has been assigned to an account, it remains permanently bound to that address and cannot be changed. This process does not require any smart contracts or secondary layers — it operates entirely at the *Account Layer*, ensuring that the core structure and protocols of the TRON network remain completely unchanged. As a result: - All usernames are unique and non-repetitive. - The assignment process is decentralized and trustless. - Users can visually confirm transaction destinations, effectively eliminating the risk of errors or phishing attacks. در تاریخ چهارشنبه ۱۵ اکتبر ۲۰۲۵، ۹:۰۶ GrothenDI *@*.***> نوشت: … <#m_2055877865347725824_> What about the large number of addresses that already exist? — Reply to this email directly, view it on GitHub <#799 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BX4PW3ELS24AIWT2M5SDXQ33XXYUTAVCNFSM6AAAAACIY6F5LSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIMBUHEZTMNZZGI> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[alichatme]

Thank you for opening this community discussion.
I appreciate the opportunity to gather feedback from the TRON community.
TIP-796 aims to make account identification safer and more user-friendly at the Account Layer level.
Looking forward to hearing everyone’s insights and suggestions.