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

tip-6780.md

@@ -0,0 +1,72 @@
+```
+tip: 6780
+title: Implement EIP-6780: SELFDESTRUCT only in same transaction
+author: liang3885@hotmail.com
+status: Last Call 
+type: Standards Track
+category: VM
+created: 2025-05-29
+```
+
+## Summary
+Ethereum has incorporated [EIP-6780](https://eips.ethereum.org/EIPS/eip-6780) in the Cancun upgrade, modifying the behavior of the `SELFDESTRUCT` opcode. To maintain compatibility with Ethereum's implementation of this opcode modification, TRON needs to introduce this TIP and correspondingly update the `SELFDESTRUCT` opcode behavior in the TVM. Additionally, this TIP proposes increasing the constant energy cost of SELFDESTRUCT from `0` to `5000` to align with Ethereum's gas pricing.
+
+## Abstract
+This TIP changes the functionality of the `SELFDESTRUCT` opcode. The new functionality will be only to send all TRX in the account to the target, except that the current behaviour is preserved when `SELFDESTRUCT` is called in the same transaction a contract was created.
+
+## Motivation
+To maintain compatibility with Ethereum EVM instruction modifications, we are implementing corresponding changes to the `SELFDESTRUCT` opcode behavior in TRON.
+
+**Original motivation from EIP-6780:**
+
+The `SELFDESTRUCT` opcode requires large changes to the state of an account, in particular removing all code and storage. This will not be possible in the future with Verkle trees: Each account will be stored in many different account keys, which will not be obviously connected to the root account.
+
+This EIP implements this change. Applications that only use `SELFDESTRUCT` to retrieve funds will still work. Applications that only use `SELFDESTRUCT` in the same transaction as they created a contract will also continue to work without any changes.
+
+## Specification
+The constant energy cost of `SELFDESTRUCT` is changed from 0 to 5000:
+1. When `SELFDESTRUCT` is executed in a transaction that is not the same as the contract calling `SELFDESTRUCT` was created:
+- The current execution frame halts.
+- `SELFDESTRUCT` does not delete any data (including storage keys, code, or the account itself).
+- `SELFDESTRUCT` transfers the entire account assets(TRX, Staked TRX, TRC10) to the target.
+- Note that if the target is the same as the contract calling `SELFDESTRUCT` there is no net change in balances. Unlike the prior specification, assets will not be burnt in this case.
+
+2. When `SELFDESTRUCT` is executed in the same transaction as the contract was created:
+- `SELFDESTRUCT` continues to behave as it did prior to this TIP, this includes the following actions
+- Third item
+    - The current execution frame halts.
+    - `SELFDESTRUCT` deletes data as previously specified.
+    - `SELFDESTRUCT` transfers the entire account assets(TRX, Staked TRX, TRC10) to the target.
+    - The account balance of the contract calling `SELFDESTRUCT` is set to 0.
+- Note that if the target is the same as the contract calling `SELFDESTRUCT` that assets will be burnt.
+
+A contract is considered created at the beginning of a create transaction or when a CREATE series operation begins execution (CREATE, CREATE2, and other operations that deploy contracts in the future). If a balance exists at the contract's new address it is still considered to be a contract creation.
+
+The `SELFDESTRUCT` opcode remains deprecated as specified in [TIP-652](https://github.com/tronprotocol/tips/blob/master/tip-652.md). Any use in newly deployed contracts is strongly discouraged even if this new behaviour is taken into account, and future changes to the TVM might further reduce the functionality of the opcode.
+
+## Rationale
+Getting rid of the `SELFDESTRUCT` opcode has been considered in the past, and there are currently no strong reasons to use it. This TIP implements a behavior that will attempt to leave some common uses of `SELFDESTRUCT` working, while reducing the complexity of the change on TVM implementations that would come from contract versioning.
+
+Handling the account creation and contract creation as two distinct and possibly separate events is needed for use cases such as counterfactual accounts. By allowing the `SELFDESTRUCT` to delete the account at contract creation time it will not result in stubs of counterfactually instantiated contracts that never had any on-chain state other than a balance prior to the contract creation. These accounts would never have any storage and thus the trie updates to delete the account would be limited to the account node, which is the same impact a regular transfer of TRX would have.
+
+## Backwards Compatibility
+
+This TIP requires a hard fork, since it modifies consensus rules.
+
+Contracts that depended on re-deploying contracts at the same address using `CREATE2` (after a `SELFDESTRUCT`) will no longer function properly if the created contract does not call `SELFDESTRUCT` within the same transaction.
+
+Previously it was possible to burn TRX by calling `SELFDESTRUCT` targeting the executing contract as the beneficiary. If the contract existed prior to the transaction the TRX will not be burned. If the contract was newly created in the transaction the TRX will be burned, as before.
+
+## Test Cases
+
+Test cases for this TIP can reference EIP-6780 test cases [eip6780_selfdestruct](https://github.com/ethereum/execution-spec-tests/tree/1983444bbe1a471886ef7c0e82253ffe2a4053e1/tests/cancun/eip6780_selfdestruct).
+
+## Security Considerations
+The following applications of `SELFDESTRUCT` will be broken and applications that use it in this way are not safe anymore:
+
+Where `CREATE2` is used to redeploy a contract in the same place in order to make a contract upgradable. This is not supported anymore and other types of proxy contracts should be used instead.
+
+Where a contract depended on burning TRX via a `SELFDESTRUCT` with the contract as beneficiary, in a contract not created within the same transaction.
+
+## Copyright
+Copyright and related rights waived via [CC0](LICENSE.md).

tip-767.md

@@ -0,0 +1,56 @@
+```
+tip: 767
+title: Transitioning proposal expire time configuration to Chain Governance
+author: lxcmyf@gmail.com
+discussions-to: https://github.com/tronprotocol/tips/issues/767
+status: Final
+type: Standards Track 
+category: Core
+created: 2025-06-09
+```
+# Simple Summary
+This proposal suggests migrating the proposal expire time period from node-local configurations to on-chain governance parameters, ensuring all Super Representatives (SRs) adhere to a unified proposal expiration rule (proposal expires after the voting window period and during the maintenance period). The default value is 72 hours (259200000), but subsequent adjustments must be made through an SR vote.
+# Abstract
+Currently, Super Representatives (SRs) can locally configure the proposalExpireTime, which may lead to inconsistent judgments on proposal expiration times across different nodes. This proposal recommends changing it to an on-chain governance parameter (default: 259200000), with future adjustments requiring an SR vote. This ensures network uniformity and supports flexible governance optimization.
+# Motivation
+**Fully Decentralized Governance**​​: Key network parameters (such as the proposalExpireTime period) should be determined by on-chain voting rather than relying on manual node configurations.
+
+**Enhanced Consensus Security**​​: Unify the judgment logic for proposal voting expiration times across all nodes.
+
+**Support Dynamic Adjustments**​​: The community can flexibly adjust the proposalExpireTime period through approving (e.g., shortening it to 48 hours to accelerate governance processes).
+# Specification
+
+- Add an on-chain proposal parameter:
+
+```
+public enum ProposalType {
+  ...
+  PROPOSAL_EXPIRE_TIME(92);
+}
+```
+
+# Rationale
+**Proposal Voting Lifecycle​​**:
+
+- The countdown for proposal approving expiration starts from its creation time.
+
+- After exceeding the on-chain `proposalExpireTime` and during the nearest maintenance period, the proposal automatically expires (even if approving is incomplete).
+
+​​**Pre-Upgrade​​**: `proposalExpireTime` will still be set via the default value or local configuration (if it exists).
+
+**Post-Upgrade**​​: After all SRs complete the upgrade, the timing for initiating the `PROPOSAL_EXPIRE_TIME` proposal will be discussed. Once the proposal takes effect, the expiration logic will be executed by reading the proposal value.
+
+# Implementation
+### Protocol Changes​​
+​​**Core Modules**​​:
+
+- Modify **ProposalService** to add `PROPOSAL_EXPIRE_TIME`, making it governed by proposals and ignoring local configurations.
+
+**​​Interface Adjustments​​:**
+
+- Deprecate the `proposalExpireTime` parameter in the node configuration file config.conf after the proposal is activated.
+
+Add the proposalExpireTime parameter to the `/wallet/getchainparameters` interface.
+
+# Compatibility
+This feature constitutes a hard fork.

tip-796.md

@@ -0,0 +1,114 @@
+🧠 TIP-796 — TRON Account-Layer Username Standard
+Status: Draft
+Type: Standards Track
+Authors: Ali & ChatGPT
+GitHub: @alichatme
+Created: September 25, 2025
+License: MIT © 2025
+📘 Summary
+TIP-796 introduces a native, unique, non-transferable username standard for TRON accounts, implemented directly at the Account Layer.
+This system:
+requires no smart contracts
+charges zero gas/fees
+enhances security, usability, and human readability
+neutralizes dozens of address-based attack vectors
+remains fully compatible with TRON’s existing architecture
+Its goal is to create a trustworthy, human-readable identity layer that eliminates address confusion, phishing, and UI-level manipulation.
+🧩 Username Structure
+All TRON usernames must begin with uppercase TR and follow one of three valid patterns using lowercase ASCII letters (a–z) and digits (0–9).
+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
+Rules:
+No special characters, spaces, or underscores
+100% ASCII
+100% LTR storage and rendering
+Uppercase TR prefix is mandatory and part of the username identity
+🔠 LTR Enforcement & Visual Anti-Spoofing
+Usernames must always be stored and displayed Left-to-Right (LTR).
+This eliminates:
+Homograph attacks
+RTL/LTR direction-switch attacks
+Font-based spoofing
+Display manipulation in Persian/Arabic/Hebrew UI environments
+⚙️ Core Rules
+The TR prefix is mandatory and stored on-chain exactly as is.
+Wallets must display the full username (including TR) and the full address before signing any transaction.
+Wallets may not shorten or hide any part of the username.
+The system operates entirely at the Account Layer, with zero cost and no protocol burden.
+🔥 Full Elimination of All Known Address-Based Attacks
+(Highest Security Level Achievable in Blockchain Username Systems)
+TIP-796 neutralizes every major attack vector involving addresses, including:
+1. Clipboard Hijacking
+Malware replacing clipboard addresses →
+Mismatch with destination username immediately exposes the attack.
+2. Address Spoofing / Look-Alike Generation
+Attackers generate thousands of similar addresses →
+Username is non-spoofable and breaks the attack.
+3. Homograph Attacks
+Swapping characters like "0" with "٠" →
+Disallowed entirely by ASCII-only enforcement.
+4. RTL/LTR Direction Attacks
+Manipulating direction to flip parts of the address →
+LTR-only rendering disables this attack type completely.
+5. UI-Layer Manipulation Attacks
+Fake wallets hiding or visually slicing an address →
+Mandatory full username display prevents deception.
+6. Social Engineering on Non-Technical Users
+Human-readable usernames + enforced visibility →
+Human error nearly eliminated.
+7. Spam-Activation & Transaction Injection Attacks
+Spammers send micro-transactions to appear in “recent activity” →
+A consistent, unfakeable username breaks this deception model.
+🔥 Username Assignment — Anti-Bot & Anti-Abuse Mechanisms
+To prevent large-scale automated account creation or username farming:
+1. Time-Delay Assignment (Cooldown Window)
+A username is assigned only after a configurable delay following account activation.
+Default: 24 hours
+Nodes may increase to 48 hours or more for stricter anti-abuse.
+2. Minimum Balance Requirement
+A username is assigned only if the account maintains a minimum balance during the cooldown.
+Suggested default: 2 TRX (or equivalent frozen balance)
+Can be increased to 10 TRX for stronger protection.
+3. Mandatory Wallet Onboarding Before Display
+Before showing the username, the wallet must display a multilingual onboarding panel explaining:
+what the username is
+how it is generated
+how it is bound to the account
+how it protects the user
+where it is displayed
+how to use it safely
+User must scroll and explicitly confirm.
+4. Optional Anti-Bot Challenge (Local CAPTCHA / PoW)
+Wallets may require a lightweight challenge.
+Network only verifies the result; execution remains wallet-side.
+Combined effect:
+Bots must:
+wait 24–48 hours
+hold real TRX
+complete onboarding
+solve CAPTCHAs
+repeat this for every account
+➡️ Economically impossible
+➡️ Fully kills username-mining bots
+📊 Namespace Capacity
+With over 650,000 English words, the system supports:
+12.6 quadrillion unique usernames
+🎯 Purpose
+To provide TRON with a native, decentralized, visually safe, and non-spoofable identity layer —
+eliminating human-layer vulnerabilities without gas, fees, or smart contracts.
+🔮 Future Extensions
+Additional structural modes
+Expanded character sets
+Special categories for NFTs, MemeCoins, or ecosystem tags
+📄 License
+MIT © 2025
+🔗 References
+Primary Issue: #799
+Updated Pull Request: #803