diff --git a/README.md b/README.md
index 130f449..e9acb77 100644
--- a/README.md
+++ b/README.md
@@ -1,45 +1,209 @@
-# 🌐 Safe Wallet Method – ali & chatgpt
-**A revolutionary offline encryption method for crypto wallet recovery phrases.**
-Developed by: **ali & chatgpt**
-GitHub: [https://github.com/alichatme](https://github.com/alichatme)
+TRON Improvement Proposals (TIPs) describe standards for the TRON platform, including core protocol specifications, client APIs, and contract standards.
----
+****
-## 🧩 What is Safe Wallet Method?
+## Contents
+- [To Submit a TIP](#to-submit-a-tip)
+- [TIP Status](#tip-status)
+- [TIP Types](#tip-types)
+- [TIPs Guide](#tips-guide)
+****
-It’s an **offline mathematical encryption system** that turns any seed phrase into a secure, disguised version using the **BIP39 word list** and a secret constant number.
+## To Submit a TIP
-- 100% offline
-- Compatible with all BIP39 wallets (TronLink, MetaMask, TrustWallet, etc.)
-- Simple and strong
-- Ideal for long-term backup
+Before you submit a TIP, you need to create an issue for comment and add the issue URL to your TIP header.
-📘 Read full details here:
-👉 [SafeWalletMethod.md](SafeWalletMethod.md)
+1. Fork the repository by clicking "Fork" in the top right.
----
+2. Add your TIP to your fork of the repository. There is a [TIP template](https://github.com/tronprotocol/TIPs/blob/master/template.md) here.
-## 💬 Why It Matters
+3. Submit a Pull Request to TRON's TIPs repository.
-This method protects your seed phrase from:
-- Phishing attacks
-- Malware clipboard hijacking
-- Cloud leaks
-- Social engineering
+Your first PR should be a first draft of the final TIP. It must meet the formatting criteria enforced by the build (largely, correct metadata in the header). An editor will manually review the first PR for a new TIP and assign it a number before merging it.
-And it keeps **crypto decentralization** intact, since everything happens locally — no external apps or servers.
+Make sure you include a discussions-to header with the URL to a discussion forum or open GitHub issue where people can discuss the TIP as a whole. If a TIP is about the feature development of java-tron, and a PR of the development exists, in your TIP and your java-tron's PR you need to refer each other's github link.
----
+When you believe your TIP is mature and ready to progress past the draft phase, you should do one of two things:
-## 🏷️ Authors
+- For a Standards Track TIP of type Core, ask to have your issue added to the agenda of an upcoming All Core Devs meeting, where it can be discussed for inclusion in a future hard fork. If implementers agree to include it, the TIP editors will update the state of your TIP to 'Accepted'.
-👤 **Ali**
-🤖 **ChatGPT**
-Team: **ali & chatgpt**
+- For all other TIPs, open a PR changing the state of your TIP to 'Final'. An editor will review your draft and ask if anyone objects to its being finalized. If the editor decides there is no rough consensus, they may close the PR and request you fix the issues in the draft before trying again.
----
+****
-## 📄 License
-**MIT License – 2025**
-Open Source for education and personal use.
+## TIP Status
+
+TIPs are separated into several statuses.
+
+- **Draft**: A TIP that is undergoing rapid iteration and changes.
+
+- **Last Call**: A TIP that is done with its initial iteration and ready for review by a wide audience.
+
+- **Accepted**: A core TIP that has been in the Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author. The process for Core Devs to decide whether to encode a TIP into their clients as part of a hard fork is not part of the TIP process. If such a decision is made, the TIP will move to the final.
+
+- **Final (non-Core)**: A TIP that has been in the Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author.
+
+- **Final (Core)**: A TIP that the Core Devs have decided to implement and release in a future version or has already been released.
+
+- **Active**: If the TIPs are never meant to be completed, the TIPs may have a status of “Active”.
+
+- **Abandoned**: If a TIP is no longer pursued by the original authors or it may not be a (technically) preferred option anymore.
+
+- **Rejected**: A TIP that is fundamentally broken or a Core TIP that was rejected by the Core Devs and will not be implemented.
+
+- **Superseded**: A TIP which was previously Final but is no longer considered state-of-the-art. Another TIP will be in the Final status and cite the Superseded TIP.
+
+- **Deferred**: A TIP which isn't accepted now, it may be accepted in the future.
+
+****
+
+## TIP Types
+
+TIPs are separated into several types, and each has its list of TIPs.
+
+* **Standard Track**: Describes any change that affects most or all TRON implementations, such as a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using TRON. Furthermore, Standard TIPs can be broken down into the following categories.
+
+ **1.Core**: Improvements requiring a consensus fork, as well as changes that are not necessarily consensus critical but may be relevant to "core dev" discussions.
+
+ **2.Networking**: Includes improvements around network protocol.
+
+ **3.Interface**: Includes improvements around client API/RPC specifications and standards.
+
+ **4.TRC**: Application-level standards and conventions, including contract standards such as token standards (TRC-20).
+
+ **5.TVM**: Includes improvements around TRON Virtual Machine.
+
+* **Informational**: Describes a TRON design issue, or provides general guidelines or information to the TRON community, but does not propose a new feature.
+
+For further discussion, please enter [Telegram](https://t.me/troncoredevscommunity)
+
+****
+
+## TIPs Guide
+
+ TIPs Record
+
+
+| ID | Title | Author | Type | Category | Hard fork | Status |
+|---------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------|:------------------------------:|:--------------------:|:----------:|:--------------:|:---------:|
+| TIP 10 | [TRON Token Standard](https://github.com/tronprotocol/TIPs/blob/master/tip-10.md) | | Standards Track | Core | false | Final |
+| TIP 12 | [TRON Event Subscription Model](https://github.com/tronprotocol/TIPs/blob/master/tip-12.md) | | Informational | TRC | false | Final |
+| TIP 13 | [Design of TRON account](https://github.com/tronprotocol/TIPs/blob/master/tip-13.md) | | Standards Track | Core | false | Final |
+| TIP 16 | [TRON Account Multi-Signature](https://github.com/tronprotocol/TIPs/blob/master/tip-16.md) | | Standards Track | Core | true | Final |
+| TIP 17 | [TRON Adaptive Energy Limit Model](https://github.com/tronprotocol/TIPs/blob/master/tip-17.md) | | Standards Track | Core | true | Final |
+| TIP 19 | [TRC-19 Deferred transaction](https://github.com/tronprotocol/TIPs/blob/master/tip-19.md) | | Standards Track | Core | true | Deferred |
+| TIP 20 | [TRC-20 Token Standard](https://github.com/tronprotocol/TIPs/blob/master/tip-20.md) | | Standards Track | TRC | true | Final |
+| TIP 23 | [Add the account world status tree root to the block header](https://github.com/tronprotocol/tips/blob/master/tip-23.md) | | Standards Track | Core | true | Accepted |
+| TIP 24 | [Implement of DB storage with RocksDB](https://github.com/tronprotocol/tips/blob/master/tip-24.md) | | Standards Track | Core | false | Final |
+| TIP 26 | [Create2](https://github.com/tronprotocol/tips/blob/master/tip-26.md) | | Standards Track | VM | false | Final |
+| TIP 28 | [Built-in Message Queue in Event Subscription Model](https://github.com/tronprotocol/TIPs/blob/master/tip-28.md) | | Informational | | false | Final |
+| TIP 29 | [Bitwise shifting instructions in Tron](https://github.com/tronprotocol/tips/blob/master/tip-29.md) | | Standards Track | VM | true | Final |
+| TIP 30 | [Code hash instructions](https://github.com/tronprotocol/tips/blob/master/tip-30.md) | | Standards Track | VM | true | Final |
+| TIP 31 | [Trigger constant contract](https://github.com/tronprotocol/tips/blob/master/tip-31.md) | | Standards Track | VM | true | Final |
+| TIP 32 | [Clear the ABI of contract](https://github.com/tronprotocol/tips/blob/master/tip-32.md) | | Standards Track | VM | true | Final |
+| TIP 37 | [Forbid using TransferContract & TransferAssetContract for contract account](https://github.com/tronprotocol/tips/blob/master/tip-37.md) | | Standards Track | VM | true | Final |
+| TIP 41 | [Optimize transactionHistoryStore occupancy space](https://github.com/tronprotocol/tips/blob/master/tip-41.md) | | Standards Track | Core | false | Final |
+| TIP 43 | [Precompiled contract function for signature parallel verification](https://github.com/tronprotocol/tips/blob/master/tip-43.md) | | Standards Track | VM | true | Final |
+| TIP 44 | [Address.isContract instructions](https://github.com/tronprotocol/tips/blob/master/tip-44.md) | | Standards Track | VM | true | Final |
+| TIP 51 | [Rate limit of API traffic](https://github.com/tronprotocol/tips/blob/master/tip-51.md) | | Standards Track | Interface | false | Final |
+| TIP 53 | [Optimize the current TRON delegation mechanism](https://github.com/tronprotocol/tips/blob/master/tip-53.md) | | Standards Track | Core | true | Final |
+| TIP 54 | [Automatically active non-existent account when transferring TRX/TRC10 asset in a smart contract](https://github.com/tronprotocol/tips/blob/master/tip-54.md) | | Standards Track | VM | true | Final |
+| TIP 60 | [Precompiled contract function for multi-signature verification](https://github.com/tronprotocol/tips/blob/master/tip-60.md) | | Standards Track | VM | true | Accepted |
+| TIP 62 | [Tron consensus algorithm introduction](https://github.com/tronprotocol/tips/blob/master/tip-62.md) | | Standards Track | Core | false | Final |
+| TIP 64 | [Tron tron mix consensus Analytics](https://github.com/tronprotocol/tips/blob/master/tip-64.md) | | Standards Track | Core | false | Draft |
+| TIP 101 | [Wallet Keystore Specification](https://github.com/tronprotocol/tips/blob/master/tip-101.md) | | Standards Track | TRC | false | Last Call |
+| TIP 102 | [Hierarchical Deterministic Wallet](https://github.com/tronprotocol/tips/blob/master/tip-102.md) | | Standards Track | TRC | false | Last Call |
+| TIP 104 | [Data Signing Specification](https://github.com/tronprotocol/tips/blob/master/tip-104.md) | | Standards Track | TRC | false | Last Call |
+| TIP 105 | [Multi-signature Permission Operation](https://github.com/tronprotocol/tips/blob/master/tip-105.md) | | Standards Track | TRC | true | Final |
+| TIP 120 | [ECDSA Signature Encoding Specification](https://github.com/tronprotocol/tips/blob/master/tip-120.md) | | Standards Track | TRC | false | Final |
+| TIP 127 | [Support Tron-DEX based on system contracts](https://github.com/tronprotocol/tips/blob/master/tip-127.md) | | Standards Track | CORE | false | Draft |
+| TIP 128 | [TIP128 Lite Fullnode support](https://github.com/tronprotocol/tips/blob/master/tip-128.md) | | Standards Track | CORE | false | Draft |
+| TIP 135 | [Shielded TRC-20 Contract](https://github.com/tronprotocol/tips/blob/master/tip-135.md) | | Standards Track | TRC | false | Final |
+| TIP 137 | [Zero-knowledge Proof Verification functions](https://github.com/tronprotocol/tips/blob/master/tip-137.md) | | Standards Track | VM | true | Final |
+| TIP 138 | [Pedersen hash function](https://github.com/tronprotocol/tips/blob/master/tip-138.md) | | Standards Track | VM | true | Final |
+| TIP 156 | [Vote instructions in TVM](https://github.com/tronprotocol/tips/blob/master/tip-156.md) | | Standards Track | VM | true | Withdrawn |
+| TIP 157 | [Freeze instructions in TVM](https://github.com/tronprotocol/tips/blob/master/tip-157.md) | | Standards Track | VM | true | Final |
+| TIP 165 | [TRC-165 Standard Interface Detection In Contract](https://github.com/tronprotocol/tips/blob/master/tip-165.md) | | Standards Track | TRC | true | Final |
+| TIP 171 | [STAKE instructions in TVM](https://github.com/tronprotocol/tips/blob/master/tip-171.md) | | Standards Track | VM | true | Withdrawn |
+| TIP 174 | [CHAINID instructions in TVM](https://github.com/tronprotocol/tips/blob/master/tip-174.md) | | Standards Track | VM | true | Final |
+| TIP 175 | [SELFBALANCE instructions in TVM](https://github.com/tronprotocol/tips/blob/master/tip-175.md) | | Standards Track | VM | true | Final |
+| TIP 176 | [altbn128 operation energy reduction in TVM](https://github.com/tronprotocol/tips/blob/master/tip-176.md) | | Standards Track | VM | true | Final |
+| TIP 178 | [TOKENISSUE and UPDATEASSET Instruction in TVM](https://github.com/tronprotocol/tips/blob/master/tip-178.md) | | Standards Track | VM | true | Withdrawn |
+| TIP 191 | [Signed Data Standard](https://github.com/tronprotocol/tips/blob/master/tip-191.md) | | Standards Track | TRC | false | Final |
+| TIP 196 | [Reward SRs with the transaction fees charged for bandwidth and Energy](https://github.com/tronprotocol/tips/blob/master/tip-196.md) | | Standards Track | Core | true | Final |
+| TIP 204 | [Make MAX_FEE_LIMIT configurable as a chain property](https://github.com/tronprotocol/tips/blob/master/tip-204.md) | | Standards Track | VM | false | Final |
+| TIP 207 | [A proposal to improve network resources model ](https://github.com/tronprotocol/tips/blob/master/tip-207.md) | | Standards Track | Core | true | Draft |
+| TIP 209 | [Adapt to Solidity 0.6.0](https://github.com/tronprotocol/tips/blob/master/tip-209.md) | | Standards Track | VM | false | Final |
+| TIP 222 | [Improve transaction execution speed](https://github.com/tronprotocol/tips/blob/master/tip-222.md) | | Standards Track | TRC | true | Final |
+| TIP 250 | [Include transaction results on the chain](https://github.com/tronprotocol/tips/blob/master/tip-250.md) | | Standards Track | Core | true | Final |
+| TIP 268 | [SmartContract ABI optimization](https://github.com/tronprotocol/tips/blob/master/tip-268.md) | | Standards Track | VM | false | Final |
+| TIP 269 | [Optimize the performance of block processing](https://github.com/tronprotocol/tips/blob/master/tip-269.md) | | Standards Track | Core | false | Final |
+| TIP 271 | [Vote for SR in Smart Contract](https://github.com/tronprotocol/tips/blob/master/tip-271.md) | | Standards Track | VM | true | Final |
+| TIP 272 | [Compatible with EVM](https://github.com/tronprotocol/tips/blob/master/tip-272.md) | | Standards Track | VM | true | Final |
+| TIP 276 | [Optimize block verification logic](https://github.com/tronprotocol/tips/blob/master/tip-276.md) | | Standards Track | Core | false | Final |
+| TIP 281 | [Optimize the query of database](https://github.com/tronprotocol/tips/blob/master/tip-281.md) | | Standards Track | Core | false | Final |
+| TIP 285 | [Node startup optimization](https://github.com/tronprotocol/tips/blob/master/tip-285.md) | | Standards Track | Core | false | Final |
+| TIP 289 | [Block Broadcast Optimization](https://github.com/tronprotocol/tips/blob/master/tip-289.md) | | Standards Track | Core | true | Final |
+| TIP 290 | [Dynamic store optimization](https://github.com/tronprotocol/tips/blob/master/tip-290.md) | | Standards Track | Core | true | Final |
+| TIP 292 | [Add a proposal to adjust the free net limit in an account](https://github.com/tronprotocol/tips/blob/master/tip-292.md) | | Standards Track | TRC | true | Final |
+| TIP 293 | [Add a proposal to adjust the total net limit](https://github.com/tronprotocol/tips/blob/master/tip-293.md) | | Standards Track | TRC | true | Final |
+| TIP 295 | [Optimize assets of account](https://github.com/tronprotocol/tips/blob/master/tip-295.md) | | Standards Track | Core | false | Final |
+| TIP 298 | [Reformat manifest](https://github.com/tronprotocol/tips/blob/master/tip-298.md) | | Standards Track | Core | false | Final |
+| TIP 306 | [Adapt to solidity_0.8.4](https://github.com/tronprotocol/tips/blob/master/tip-306.md) | | Standards Track | VM | false | Final |
+| TIP 318 | [Adapt to Ethereum London Upgrade](https://github.com/tronprotocol/tips/blob/master/tip-318.md) | | Standards Track | VM | false | Final |
+| TIP 343 | [DB params optimization ](https://github.com/tronprotocol/tips/blob/master/tip-343.md) | | Standards Track | Core | false | Draft |
+| TIP 344 | [Optimize instruction execution for TVM](https://github.com/tronprotocol/tips/blob/master/tip-344.md) | | Standards Track | VM | false | Final |
+| TIP 362 | [Optimized node broadcast data caching](https://github.com/tronprotocol/tips/blob/master/tip-362.md) | | Standards Track | Core | false | Final |
+| TIP 366 | [Node startup optimization](https://github.com/tronprotocol/tips/blob/master/tip-366.md) | | Standards Track | Core | false | Final |
+| TIP 369 | [Node support prometheus metrics](https://github.com/tronprotocol/tips/blob/master/tip-369.md) | | Standards Track | Core | false | Final |
+| TIP 370 | [Node support conditionalized stop](https://github.com/tronprotocol/tips/blob/master/tip-370.md) | | Standards Track | Core | false | Final |
+| TIP 382 | [TIP-382: Optimize the data structure of account assets](https://github.com/tronprotocol/tips/blob/master/tip-382.md) | | Standards Track | Core | false | Final |
+| TIP 383 | [TIP-383: Optimize transaction cache loading](https://github.com/tronprotocol/tips/blob/master/tip-383.md) | | Standards Track | Core | false | Final |
+| TIP 387 | [TIP-387: Transaction memo fee](https://github.com/tronprotocol/tips/blob/master/tip-387.md) | | Standards Track | Core | false | Final |
+| TIP 388 | [TIP-388: Optimize light node synchronization logic](https://github.com/tronprotocol/tips/blob/master/tip-388.md) | | Standards Track | Core | false | Final |
+| TIP 391 | [TIP-391: Optimize fetch block process](https://github.com/tronprotocol/tips/blob/master/tip-391.md) | | Standards Track | Core | false | Final |
+| TIP 397 | [Raise limit of the 13th network parameter](https://github.com/tronprotocol/tips/blob/master/tip-397.md) | | Standards Track | VM | true | Final |
+| TIP 425 | [TIP-425: Speed up TCP connection establishment](https://github.com/tronprotocol/tips/blob/master/tip-425.md) | | Standards Track | Net | false | Final |
+| TIP 428 | [TIP-428: Increase the probability that the block processing thread acquires the lock](https://github.com/tronprotocol/tips/blob/master/tip-428.md) | | Standards Track | Core | false | Final |
+| TIP 440 | [Transaction cache optimization](https://github.com/tronprotocol/tips/blob/master/tip-440.md) | | Standards Track | Core | false | Final |
+| TIP 461 | [Optimize data consistency for system abnormals](https://github.com/tronprotocol/tips/blob/master/tip-461.md) | | Standards Track | Core | false | Final |
+| TIP 465 | [New reward calculation algorithm](https://github.com/tronprotocol/tips/blob/master/tip-465.md) | | Standards Track | Core | true | Final |
+| TIP 467 | [Stake 2.0 - A new TRON stake model](https://github.com/tronprotocol/tips/blob/master/tip-467.md) | | Standards Track | Core | false | Final |
+| TIP 474 | [Optimize the return value of chainid opcode](https://github.com/tronprotocol/tips/blob/master/tip-474.md) | | Standards Track | VM | true | Final |
+| TIP 476 | [Delegate Data Structure Optimization](https://github.com/tronprotocol/tips/blob/master/tip-476.md) | | Standards Track | Core | false | Final |
+| TIP 491 | [Dynamic Energy Model](https://github.com/tronprotocol/tips/blob/master/tip-491.md) | | Standards Track | VM | true | Final |
+| TIP 534 | [Remove Vulnerable APIs](https://github.com/tronprotocol/tips/blob/master/tip-534.md) | | Standards Track | Core | false | Final |
+| TIP 541 | [Support canceling unstaking in Stake 2.0](https://github.com/tronprotocol/tips/blob/master/tip-541.md) | | Standards Track | Core | true | Final |
+| TIP 542 | [Resource delegating supports customizable lock period](https://github.com/tronprotocol/tips/blob/master/tip-542.md) | | Standards Track | Core | true | Final |
+| TIP 543 | [Implement EIP-3855 PUSH0 instruction](https://github.com/tronprotocol/tips/blob/master/tip-543.md) | | Standards Track | VM | true | Final |
+| TIP 544 | [Add `data` to the http interfaces interacting with smart contract](https://github.com/tronprotocol/tips/blob/master/tip-544.md) | | Standards Track | Interface | false | Final |
+| TIP 547 | [Connection precheck before P2P communication](https://github.com/tronprotocol/tips/blob/master/tip-547.md) | | Standards Track | Networking | false | Final |
+| TIP 548 | [Node Discovery via DNS](https://github.com/tronprotocol/tips/blob/master/tip-548.md) | <317787106@qq.com> | Standards Track | Networking | false | Final |
+| TIP 549 | [P2P support IPv6 protocol](https://github.com/tronprotocol/tips/blob/master/tip-549.md) | <317787106@qq.com> | Standards Track | Networking | false | Final |
+| TIP 550 | [P2P message snappy compression](https://github.com/tronprotocol/tips/blob/master/tip-550.md) | | Standards Track | Networking | false | Final |
+| TIP 555 | [Network upgrade logic optimization](https://github.com/tronprotocol/tips/blob/master/tip-555.md) | | Standards Track | Core | false | Final |
+| TIP 586 | [GRPC Implementation for Resource Price Interfaces](https://github.com/tronprotocol/tips/blob/master/tip-586.md) | | Standards Track | Core | false | Final |
+| TIP 592 | [Supplement Disconnect Reasons in Java-tron](https://github.com/tronprotocol/tips/blob/master/tip-592.md) | <317787106@qq.com> | Standards Track | Networking | false | Final |
+| TIP 621 | [Add code version column to HelloMessage](https://github.com/tronprotocol/tips/blob/master/tip-621.md) | <317787106@qq.com> | Standards Track | Networking | false | Final |
+| TIP 635 | [Optimize Reward Withdrawal To Improve TPS](https://github.com/tronprotocol/tips/blob/master/tip-635.md) | | Standards Track | Core | true | Final |
+| TIP 650 | [Implement EIP-1153 Transient storage opcodes](https://github.com/tronprotocol/tips/blob/master/tip-650.md) | | Standards Track | VM | true | Final |
+| TIP 651 | [Implement EIP-5656 MCOPY - Memory copying instruction](https://github.com/tronprotocol/tips/blob/master/tip-651.md) | | Standards Track | VM | true | Final |
+| TIP 652 | [Announce EIP-6049 Deprecate SELFDESTRUCT](https://github.com/tronprotocol/tips/blob/master/tip-652.md) | | Meta | VM | false | Final |
+| TIP 653 | [Adjust energy cost of SUICIDE and VOTEWITNESS opcodes in TVM](https://github.com/tronprotocol/tips/blob/master/tip-653.md) | | Standards Track | VM | true | Final |
+| TIP 694 | [Enhance Verification of Transaction Limitation at Consensus Layer](https://github.com/tronprotocol/tips/blob/master/tip-694.md) | | Standards Track | Core | true | Final |
+| TIP 697 | [Migrate Floating-Point Calculations from Math to StrictMath](https://github.com/tronprotocol/tips/blob/master/tip-697.md) | | Standards Track | Core | true | Final |
+| TIP 712 | [TRON typed structured data hashing and signing](https://github.com/tronprotocol/tips/blob/master/tip-712.md) | | Standards Track | Interface | false | Final |
+| TIP 721 | [TRC-721 Non-Fungible Token Standard](https://github.com/tronprotocol/tips/blob/master/tip-721.md) | | Standards Track | TRC | true | Final |
+| TIP 745 | [Introduce EIP-4844 and EIP-7516 instructions](https://github.com/tronprotocol/tips/blob/master/tip-745.md) | | Standards Track | VM | true | Final |
+| TIP 767 | [TIP-767: Transitioning proposal expire time configuration to Chain Governance](https://github.com/tronprotocol/tips/blob/master/tip-767.md) | | Standards Track | Core | true | Final |
+| TIP 1102 | [TIP-1102: Opt-in account exposure](https://github.com/tronprotocol/tips/blob/master/tip-1102.md) | | Standards Track | Interface | false | Final |
+| TIP 1155 | [Multi Token Standard](https://github.com/tronprotocol/tips/blob/master/tip-1155.md) | | Standards Track | TRC | false | Final |
+| TIP 1193 | [TIP-1193: TRON Provider JavaScript API](https://github.com/tronprotocol/tips/blob/master/tip-1193.md) | | Standards Track | Interface | false | Final |
+| TIP 3326 | [TIP-3326: Wallet Switch TRON Chain Method](https://github.com/tronprotocol/tips/blob/master/tip-3326.md) | | Standards Track | Interface | false | Final |
+| TIP 4906 | [TRC-4906: Fork from ERC-4907 Rental NFT](https://github.com/tronprotocol/tips/blob/master/tip-4906.md) | | Standards Track | TRC | false | Final |
+| TIP 6780 | [Implement EIP-6780: SELFDESTRUCT only in same transaction](https://github.com/tronprotocol/tips/blob/master/tip-6780.md) | | Standards Track | VM | true | Last Call |
+
+
+
+****
diff --git a/SafeWalletMethod.md b/SafeWalletMethod.md
deleted file mode 100644
index c1fb0ac..0000000
--- a/SafeWalletMethod.md
+++ /dev/null
@@ -1,69 +0,0 @@
-# 🔐 Safe Wallet Method
-
-A secure method to encrypt and protect crypto wallet recovery phrases (seed phrases).
-Designed by **ali & chatgpt**
-🌍 Open Source Project – MIT License
-
----
-
-## 🧩 Overview
-
-The **Safe Wallet Method** is a mathematical encryption approach based on the **BIP39** standard.
-It allows you to store your recovery phrase in a disguised form — easy to recover but impossible to guess without your private key number.
-
----
-
-## ⚙️ How It Works
-
-1. Take your original recovery phrase (e.g., 12 or 24 BIP39 words).
-2. Find each word’s **number index** from the official [BIP39 wordlist](https://github.com/bitcoin/bips/blob/master/bip-0039/english.txt).
-3. Choose a **personal constant number** — for example, part of your bank account, birthday digits, or a secret code.
-4. **Add** this constant number to each word’s index.
-5. Use the resulting numbers to **find the new words** from the BIP39 list.
-6. Save the new list — this becomes your **encrypted seed phrase**.
-7. To recover, simply **subtract** the same constant number and map back to the original words.
-
----
-
-## 🧠 Example
-
-Let’s say one of your words is number **200** in the BIP39 list.
-Your secret number is **50**.
-200 + 50 = 250
-Now, word number **250** becomes your **encrypted version**.
-
----
-
-## ⚠️ Important Notes
-
-- Never share or lose your secret constant number.
-- Without that number, your real wallet **cannot be recovered**.
-- This method is 100% offline and doesn’t require any app or internet access.
-- It increases security against phishing, hacking, or data leaks.
-
----
-
-## 💡 Advantages
-
-- Works fully **offline**
-- No software required
-- **Compatible** with all BIP39-based wallets (TronLink, MetaMask, Trust Wallet, etc.)
-- Simple but highly secure
-- Perfect for long-term backup
-
----
-
-## 🏷️ Authors
-
-👤 **Ali**
-🤖 **ChatGPT**
-
-Team: **ali & chatgpt**
-GitHub: [https://github.com/alichatme](https://github.com/alichatme)
-
----
-
-## 📄 License
-
-**MIT License – 2025**
-Open-source for educational and personal use.
diff --git a/tip-6780.md b/tip-6780.md
new file mode 100644
index 0000000..a2ca05c
--- /dev/null
+++ b/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).
\ No newline at end of file
diff --git a/tip-767.md b/tip-767.md
new file mode 100644
index 0000000..26550e3
--- /dev/null
+++ b/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.
diff --git a/tip-796.md b/tip-796.md
new file mode 100644
index 0000000..82d7d11
--- /dev/null
+++ b/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
diff --git a/tip-alichatme-system.md b/tip-alichatme-system.md
deleted file mode 100644
index 0cc172f..0000000
--- a/tip-alichatme-system.md
+++ /dev/null
@@ -1,57 +0,0 @@
-TIP:
-Title: Native Username System for TRON Accounts
-Author:
-Status: Draft
-Created: 2025-09-25
-
-## Abstract
-This proposal introduces a **native username system** for TRON blockchain accounts. Each account may register a unique human-readable username, reducing the risk of misdirected transactions caused by complex alphanumeric addresses. The system will be implemented at the protocol level to ensure universality across wallets, exchanges, and dApps.
-
-## Motivation
-One of the main usability issues in blockchain networks is the reliance on long, complex addresses (e.g., `TXY9uZs...`). Sending assets to an incorrect address due to copy-paste errors or mistyped characters can result in permanent loss of funds.
-
-By allowing TRON users to register a **unique username**, the network becomes more user-friendly, more secure, and more attractive to both individuals and businesses. Similar systems have proven successful in Web2 (social usernames, email handles) and in Web3 (ENS, etc.), but TRON lacks a native, protocol-level solution.
-
-## Specification
-
-### Username Registration
-- Each TRON account may register a single unique username.
-- Usernames are case-insensitive and must be unique across the network.
-- Once registered, a username cannot be deleted.
-
-### Change Policy
-- A registered username may only be changed **once per year**.
-- This balances flexibility with protection against abuse and impersonation.
-
-### Length and Availability Rules
-- **8 characters or more**: open to individuals. These usernames are non-tradable and permanently bound to the account.
-- **7 characters or fewer**: reserved for companies, institutions, and brands. These usernames may be transferable and can be reserved officially via TRON DAO.
-
-### Corporate Reservations
-- Companies and verified organizations can reserve short usernames (≤7 characters).
-- TRON DAO manages the reservation process.
-- Payments may be made in **installments over 1 year**, making it accessible to both startups and enterprises.
-
-### Protocol-Level Integration
-- Username mapping will be implemented **natively** within the TRON blockchain, not as an external contract.
-- Wallets, exchanges, and dApps should display both the username and the underlying TRON address when making transfers.
-
-## Rationale
-- **Security**: Reduces misdirected transfers caused by complex addresses.
-- **Adoption**: Simplifies user onboarding and encourages mainstream adoption.
-- **Brand Protection**: Companies can secure official usernames, preventing fraud and phishing.
-- **Governance**: TRON DAO manages corporate reservations, ensuring fairness and transparency.
-
-## Governance
-- TRON DAO will oversee and govern the allocation of corporate usernames (≤7 characters).
-- Community voting may be used to decide pricing models, installment options, and dispute resolution.
-- Individuals’ usernames (≥8 characters) remain fully decentralized and non-transferable.
-
-## Backward Compatibility
-- No changes to existing TRON addresses.
-- Addresses remain the core identifier at the protocol level.
-- Usernames act as a human-readable overlay.
-
-## Implementation
-- Requires protocol-level update to support account-to-username mapping.
-- Wallets, exchanges, and dApps will need to implement display and search functionality for usernames.
diff --git a/tips/tip-796.md b/tips/tip-796.md
new file mode 100644
index 0000000..85e5e42
--- /dev/null
+++ b/tips/tip-796.md
@@ -0,0 +1,59 @@
+---
+tip: 796
+title: Dual-Word + 4-Digit Username System for TRON Accounts
+author: ali&chatgpt (alichatme)
+discussions-to: https://github.com/tronprotocol/tips/issues/ (to be linked after Issue creation)
+status: Draft
+type: Standards Track
+category: TRC
+created: 2025-10-09
+---
+
+## Simple Summary
+A new **dual-word + 4-digit username system** designed to make TRON account transfers safer and easier while keeping decentralization principles.
+
+## Abstract
+This proposal introduces a human-readable username format based on **two meaningful English words followed by four digits** (e.g., `skyline2458`).
+This approach prevents copy-paste mistakes, enhances user confidence, and supports massive scalability (up to **3.6 quadrillion usernames**) using over 650,000 English words.
+
+## Motivation
+One of the biggest risks in blockchain transfers is **copy/paste error** or **address replacement by malware**.
+By linking TRON accounts to short, meaningful, and unique usernames, senders can visually confirm that they’re sending to the correct account — reducing human error and potential loss of funds.
+
+## Specification
+
+### Username Format
+- Structure: **Two meaningful English words + four digits**
+- Examples: `bluebird1974`, `silvergate2048`
+- Case-insensitive (`SkyGate2048` = `skygate2048`)
+- Only ASCII letters and digits allowed
+- Each username must be unique across the TRON network
+
+### Registration Rules
+1. Usernames are optional; addresses still remain valid and functional.
+2. Registration can be handled on-chain (TRC smart contract) or derived deterministically from address (implementation choice).
+3. Ownership of a username is **linked to the owner’s wallet**.
+4. Usernames are **non-transferable**, preserving decentralization and privacy.
+
+### System Features
+- Prevents copy-paste mistakes and address spoofing.
+- 650,000 × 650,000 × 10,000 = **~3.6 quadrillion** possible combinations.
+- No need for centralized name management.
+- Lightweight implementation compatible with TRON’s current account structure.
+
+## Rationale
+This design ensures TRON remains **fully decentralized**, while helping users verify recipients easily and avoid copy/paste or malware address swaps.
+
+## Implementation
+- Minimal on-chain footprint: mapping or deterministic derivation.
+- Wallet developers should show both address and username in confirmation modal.
+- Optional: a small on-chain registry to lock username↔address mapping when needed.
+
+## Security Considerations
+- Use strict ASCII-only words and a vetted wordlist to avoid homograph attacks.
+- Confirmation modal must display both full address and username prior to signature.
+- For large transfers, require stronger confirmation (2FA or hardware wallet).
+
+## Copyright
+Copyright © 2025 ali&chatgpt
+Licensed under Apache-2.0