Skip to content

TIP-795 Discussion: Username Registration Rules #797

Closed
Closed
TIP-795 Discussion: Username Registration Rules#797

Description

@alichatme
alichatme
opened on Sep 29, 2025

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

Author / Contact

Thanks — looking forward to community feedback!

Activity

  1. alichatme commented on Sep 29, 2025

    @alichatme
    alichatme
    on Sep 29, 2025
    Author

    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!

  2. barbatos2011 commented on Sep 30, 2025

    @barbatos2011
    barbatos2011
    on Sep 30, 2025

    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!

  3. halibobo1205 commented on Sep 30, 2025

    @halibobo1205
    halibobo1205
    on Sep 30, 2025
    Contributor

    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;
}

  4. alichatme commented on Sep 30, 2025

    @alichatme
    alichatme
    on Sep 30, 2025 via email
    Author

  5. alichatme commented on Sep 30, 2025

    @alichatme
    alichatme
    on Sep 30, 2025 via email
    Author

  6. L-Reid commented on Oct 10, 2025

    @L-Reid
    L-Reid
    on Oct 10, 2025

    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.

  7. alichatme commented on Oct 10, 2025

    @alichatme
    alichatme
    on Oct 10, 2025 via email
    Author

  8. alichatme commented on Nov 13, 2025

    @alichatme
    alichatme
    on Nov 13, 2025
    Author

    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.

  9. Redchar1992 commented on Jun 5, 2026

    @Redchar1992
    Redchar1992
    on Jun 5, 2026

    Since this discussion has been superseded by #799, I suggest marking this issue as superseded/closing it to keep future feedback in one canonical place.

    The remaining username-standard questions — transferability, anti-squatting, wallet display rules, and registry implementation — are easier to track if they all live under the updated TIP-796 thread.

  10. waynercheung commented on Sep 3, 2026

    @waynercheung
    waynercheung
    on Sep 3, 2026

    The author previously confirmed that this proposal was revised and migrated to #799. PR #795 has since been closed, and the current revised proposal is tracked in #799 and PR #920 - the tip-796.md frontmatter in #920 also lists discussions-to: https://github.com/tronprotocol/tips/issues/799, so #799 is the canonical discussion thread.

    @alichatme could you close this as superseded, or could a maintainer close it as a duplicate of #799? The thread remains readable after closing, so the historical context is preserved while further feedback stays centralized in one place.

  11. Benson0224
    closed this as completedon Sep 3, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions