TIP-795 Discussion: Username Registration Rules

[alichatme]

TIP-795 Discussion: Username Registration Rules

Summary
This issue opens community discussion for TIP-795 (Username Registration Rules). The proposal introduces a native username system for TRON accounts with two categories:

• Short usernames (≤ 8 characters): premium, transferable, subject to an annual maintenance fee; initial allocation managed by TRON DAO.
• Regular usernames (≥ 9 characters): free to register, non-transferable, no maintenance fee.

Motivation
Human-readable usernames reduce user mistakes (copy/paste errors) and improve UX and adoption. This issue invites community feedback to refine rules, security, governance, and implementation details.

Specification (short)

• Allowed characters: ASCII letters (A–Z, case-insensitive) and digits (0–9). No Unicode or special characters.
• Length rules:
  • ≤ 8 chars: premium, initial sale/auction by TRON DAO, annual maintenance fee, transferable and tradable on secondary markets.
  • ≥ 9 chars: free, register-first-come-first-served, non-transferable.
• Name change policy: one name change per account per year.
• Governance: TRON DAO manages pricing/auctions and maintenance fees for premium names.
• Backward compatibility: usernames are an alias layer; existing base58 addresses remain valid.

Discussion points / Questions for the community

1. Are the character and normalization rules sufficient to prevent phishing (e.g., homograph attacks)? Suggestions: forbid similar-looking characters, normalization rules, or a blacklist?
2. Should premium name allocation use auctions, lotteries, or other mechanisms?
3. What is an appropriate model for the annual maintenance fee? (fixed fee, dynamic, DAO-voted)
4. Transfer and marketplace rules — any constraints or recommended on-chain mechanisms?
5. Implementation: protocol-level vs smart-contract – pros/cons for TRON ecosystem?
6. Any regional, legal, or trademark considerations we should add (brand protection, dispute resolution)?

Implementation notes

• A TRC (or protocol-level) mapping username → account address is proposed. Normalization to lowercase for matching.
• New RPC endpoints for resolution (username → address) would be needed; wallets/exchanges adoption required.

Next steps

• Please comment with feedback, objections, or suggested edits below.
• After community consensus and addressing major concerns, TIP-795 PR (TIP-795: Username Registration Rules #795) will be updated / approved and proceed toward merge.

Links

• PR: TIP-795: Username Registration Rules #795
• Previous draft: TIP-794 (superseded)

Author / Contact

• @alichatme

Thanks — looking forward to community feedback!

[alichatme]

Hello TRON community 👋

This Issue is opened for discussion of TIP-795: Username Registration Rules (#797).

Summary of the Proposal:

• Native username system for TRON accounts
• ≤8 characters: premium, transferable, with fee (managed by TRON DAO)
• ≥9 characters: free, open to everyone, no maintenance cost
• Case-insensitive, ASCII letters + digits only

Motivation:
The main goal is to improve user safety by reducing copy/paste mistakes in addresses, and to make TRON accounts easier to use and remember.

We welcome feedback, suggestions, and discussions from the community.
Your input is very valuable to make this proposal stronger. 🙏

Thanks for your time!

[barbatos2011]

It may be worth considering whether the existing on-chain account_name can be reused, with its features extended or propagated.
For the “short name” design, implementing it as a smart contract may be preferable, as it would provide richer functionality and allow more frequent updates.
Further discussion is needed to determine whether a unified approach could cover all these cases, which would be the ideal solution.

In addition, more background information is needed about the scenarios in which the username can be used — specifically, when, where, and how the name should be applied. This will help the community design it in a more suitable and effective way. Very glad to see more discussion happening here!

[halibobo1205]

Apart from the above account_name, a similar field account_id is also provided. Please review it first to see if it meets the requirements.

message Account {
  // account nick name
  bytes account_name = 1;
   // the identity of this account, case insensitive
  bytes account_id = 23;
}

[alichatme]

Thank you very much for your valuable feedback! 🙏 We have considered the idea of implementing the short name system as a smart contract, but we see some important challenges with that approach: Complexity and cost – Every registration or update would require a smart contract transaction, which increases resource costs and makes the process harder for regular users. Ecosystem integration – A contract-based solution would require each wallet, explorer, and service to add support individually, while a protocol-level feature would be natively supported across the ecosystem. Security and consistency – With contracts, there is a risk of fragmentation (different versions or competing standards). At the protocol level, the system would remain unified and stable. User experience – Our main goal is simplicity. We want any user to easily claim a name without needing to interact directly with a contract or manage additional steps. That’s why we currently lean towards a protocol-level extension of the existing account_name instead of a smart contract model. We truly appreciate your suggestions and look forward to more discussion on how to design this feature in the most effective way for the whole community. در تاریخ سه‌شنبه ۳۰ سپتامبر ۲۰۲۵، ۹:۴۱ halibobo1205 < ***@***.***> نوشت:

…

*halibobo1205* left a comment (tronprotocol/tips#797) <#797 (comment)> Apart from the above account_name, a similar field account_id is also provided. Please review it first to see if it meets the requirements. message Account { // account nick name bytes account_name = 1; // the identity of this account, case insensitive bytes account_id = 23; } — Reply to this email directly, view it on GitHub <#797 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BX4PW3GGLODDKPHMDYQIIQL3VININAVCNFSM6AAAAACHZSRQ6CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNJQGEYTONRSHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[alichatme]

Thank you very much for pointing this out and for highlighting the existing account_id field. 🙏 We have reviewed account_id, but we believe it cannot fully meet the requirements for a user-facing username/short name system: System identity vs. user identity – account_id is more of an internal identifier used by the protocol, not something designed for users to choose or interact with directly. User experience – account_id works like a bank account number: it is long, not user-friendly, and difficult to remember. In contrast, a username can be chosen by the user, is short, and stays in memory easily. This directly serves our goal of reducing risks of lost funds due to copy-paste errors. Public-facing use cases – Our design is meant to give users a human-readable identity (e.g. alice.trx) that they can easily share, display, or type. account_id does not provide this functionality. Future compatibility – Even if account_id were extended, significant changes would be needed, which essentially leads us back to introducing a new dedicated field for usernames. For these reasons, we believe extending account_name (or introducing a dedicated username system) would be more suitable than relying on account_id. We really appreciate your input and look forward to more discussion on how to make this feature as secure and user-friendly as possible در تاریخ سه‌شنبه ۳۰ سپتامبر ۲۰۲۵، ۱۰:۴۴ ali aram ***@***.***> نوشت:

…

Thank you very much for your valuable feedback! 🙏 We have considered the idea of implementing the short name system as a smart contract, but we see some important challenges with that approach: Complexity and cost – Every registration or update would require a smart contract transaction, which increases resource costs and makes the process harder for regular users. Ecosystem integration – A contract-based solution would require each wallet, explorer, and service to add support individually, while a protocol-level feature would be natively supported across the ecosystem. Security and consistency – With contracts, there is a risk of fragmentation (different versions or competing standards). At the protocol level, the system would remain unified and stable. User experience – Our main goal is simplicity. We want any user to easily claim a name without needing to interact directly with a contract or manage additional steps. That’s why we currently lean towards a protocol-level extension of the existing account_name instead of a smart contract model. We truly appreciate your suggestions and look forward to more discussion on how to design this feature in the most effective way for the whole community. در تاریخ سه‌شنبه ۳۰ سپتامبر ۲۰۲۵، ۹:۴۱ halibobo1205 < ***@***.***> نوشت: > *halibobo1205* left a comment (tronprotocol/tips#797) > <#797 (comment)> > > Apart from the above account_name, a similar field account_id is also > provided. Please review it first to see if it meets the requirements. > > message Account { > // account nick name > bytes account_name = 1; > // the identity of this account, case insensitive > bytes account_id = 23; > } > > — > Reply to this email directly, view it on GitHub > <#797 (comment)>, > or unsubscribe > <https://github.com/notifications/unsubscribe-auth/BX4PW3GGLODDKPHMDYQIIQL3VININAVCNFSM6AAAAACHZSRQ6CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGNJQGEYTONRSHE> > . > You are receiving this because you authored the thread.Message ID: > ***@***.***> >

[L-Reid]

It would be preferable to make use of the existing fields where possible. Otherwise, introducing new fields that involve protocol changes could be quite risky.

[alichatme]

Hello @L-Reid Thank you very much for reviewing our proposal and sharing your thoughts We fully agree — protocol-level changes must be avoided whenever possible. In our design, the TRON core protocol remains completely unchanged. Each account can simply have an optional username tag (two meaningful English words + 4 digits), stored or referenced at the wallet/application layer. During a transaction confirmation, the wallet displays the receiver’s username together with their full address — giving users extra confidence that the pasted address is correct before signing. So, the blockchain logic and transaction validation stay exactly the same; this only adds a lightweight verification layer for user safety. Thanks again for your valuable time and feedback در تاریخ جمعه ۱۰ اکتبر ۲۰۲۵، ۱۲:۱۸ L-Reid ***@***.***> نوشت:

…

*L-Reid* left a comment (tronprotocol/tips#797) <#797 (comment)> It would be preferable to make use of the existing fields where possible. Otherwise, introducing new fields that involve protocol changes could be quite risky. — Reply to this email directly, view it on GitHub <#797 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BX4PW3D7XPG45WI63XLATZT3W5XG3AVCNFSM6AAAAACHZSRQ6CVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGOBYHEZDONJVHA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[alichatme]

Thank you everyone for your valuable feedback and participation in this discussion.
Based on the extensive community feedback and structural improvements, the proposal has been updated and migrated to a new issue for continued discussion and review.

👉 Updated Proposal: TIP-796 (New Issue)
👉 Related Pull Request: #803

This issue will now be archived and marked as superseded by the updated version.

The new version reflects major refinements:

• Improved username structure with strict TR uppercase prefix
• Enhanced LTR enforcement for multilingual and RTL environments
• Mandatory wallet display of the full username before transaction signing
• Fully decentralized and gas-free design at the account layer

We warmly invite everyone to continue the discussion in the updated thread.
Your insights have been incredibly helpful and deeply appreciated 🙏

Thanks again to all contributors who supported the evolution of this proposal.