diff --git a/tip-796.md b/tip-796.md new file mode 100644 index 0000000..7fdc177 --- /dev/null +++ b/tip-796.md @@ -0,0 +1,618 @@ +--- +tip: 796 +title: TRON Account-Layer Username Standard +author: Ali (@alichatme) +discussions-to: https://github.com/tronprotocol/tips/issues/799 +status: Draft +type: Standards Track +created: 2025-09-25 +license: MIT +--- +# Summary + +TIP-796 introduces a native, unique, non-transferable username standard for TRON accounts, implemented directly 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.