We propose to formalize the Tron Improvement Proposal (TIP) process by introducing TIP-1 — a meta-proposal that defines the structure, workflow, roles, and governance model for all future TIPs in the Tron ecosystem.
Currently, while TIPs exist, Tron lacks a single canonical reference that outlines how proposals should be authored, categorized, discussed, reviewed, and finalized. This gap creates inconsistency in how TIPs are submitted and evaluated, and it limits broader community participation.
TIP-1: Tron Improvement Proposal Process and Guidelines
WHAT IS A TIP
A Tron Improvement Proposal (TIP) is a design document that outlines new features, enhancements, or information relevant to the Tron blockchain and ecosystem. TIPs serve as the primary mechanism for proposing changes to Tron’s core protocol, APIs, virtual machine, or application standards, as well as for documenting general guidelines or processes for the community.
A TIP provides a concise technical specification of the proposal and the rationale behind it, enabling the Tron community and developers to discuss and refine the idea. The TIP author (or champion) is responsible for driving community consensus around the proposal and addressing feedback or dissenting opinions during the TIP’s development. Once accepted, TIPs become part of Tron’s historical record, allowing implementers to track the progress and status of features across different Tron client implementations.
TIP TYPES
There are two primary types of Tron Improvement Proposals, each serving a different purpose:
- Standards Track TIP
- Proposes a change that affects multiple Tron implementations or impacts interoperability across the Tron ecosystem.
- This category includes changes to network protocol rules, transaction or block validity, client API/RPC specifications, or smart contract standards.
- A Standards Track TIP generally requires a reference implementation and possibly updates to formal specifications.
-
Standards Track TIP categories include:
i. Core: Changes requiring a consensus fork (hard fork) or other critical protocol modifications. These include low-level protocol changes and improvements that need agreement from Tron core developers (for example, changes to block validation, transaction processing, or the Tron Virtual Machine core rules). Core TIPs typically must be discussed in All Core Devs meetings and implemented in Tron node software.
ii. Networking: Improvements to the peer-to-peer network protocol or network-layer interactions. For example, proposals that optimize node communication, message propagation, or networking security fall under this category.
iii. Interface: Proposals that affect client APIs, RPC interfaces, and usage standards for applications or wallets. These changes define how external software (like DApps, wallets, or exchanges) interfaces with Tron nodes and services.
iv. TRC: Application-level standards and conventions, including smart contract standards such as token specifications (e.g., TRC-20 tokens). “TRC” stands for Tron Request for Comment, analogous to Ethereum’s ERC. TIPs in this subcategory establish common contract interfaces or protocols for DApp developers.
v. TVM: Improvements to the Tron Virtual Machine or smart contract execution environment. These TIPs might introduce new opcodes, adjust execution costs, or otherwise enhance the functionality and performance of the TVM (often requiring coordination with Core changes).
- Informational TIP
- Provides general guidelines, design explanations, or other information to the Tron community without proposing a new feature.
- Informational TIPs can describe design principles, governance processes, or best practices.
- They do not require consensus or implementation and are offered for community consideration.
- This document, TIP-0001, is itself an Informational TIP (sometimes also called a “meta” TIP), since it describes the TIP process.
- Informational TIPs do not mandate any changes to the Tron protocol, and stakeholders are free to adopt or ignore the guidance they provide.
Note: It is highly recommended that each TIP focus on a single key proposal or idea. Keeping proposals focused makes discussion and evaluation easier. Minor changes that only affect one implementation usually do not require a TIP; only changes with cross-implementation impact or that define a new standard for the ecosystem should go through the TIP process.
ROLES AND RESPONSIBILITIES
Several roles are involved in the TIP process, each with specific responsibilities:
- TIP Author (Champion)
- The person or team who writes the TIP and shepherds it through the process.
- Responsible for drafting a clear and complete proposal, soliciting feedback from the community, and updating the TIP to address concerns or technical suggestions.
- Builds consensus around the proposal, ensuring that differing viewpoints are documented and that the proposal reflects community input.
- Revises the content as needed, especially during Draft and Last Call stages.
- Responds to reviewer comments.
- For Standards Track proposals, may also provide or coordinate a reference implementation and testing.
- TIP Editors
- Experienced community members entrusted with maintaining the TIP repository and enforcing process rules.
- Review new TIP pull requests for proper formatting and required metadata.
- Assign TIP numbers in sequence once a draft meets the basic criteria.
- Merge TIPs into the repository in Draft status and ensure headers and structures conform to the template.
- Facilitate status changes (Draft → Last Call → Final).
- Ensure TIPs are clear, complete, and consensual.
- Do not judge the merit of content; their role is administrative and editorial, not decision-making.
- Can refuse to advance a TIP or ask for further changes if consensus or clarity is lacking.
- Tron Core Developers
- For Core category proposals (those affecting the Tron protocol or requiring a hard fork), core developers play a key decision-making role.
- Hold regular meetings (All Core Devs calls) to discuss protocol changes.
- Evaluate proposals for technical viability and risk/reward.
- When consensus is reached to include a change in a future network upgrade, they signal acceptance of the TIP.
- Accepted Core TIPs have their status updated to “Accepted” by editors.
- Core developers are responsible for implementing Core TIPs in the Tron client software (for example, java-tron) and deploying those changes in network upgrades.
- Governance decisions about integration are made through Tron DAO mechanisms.
- If rejected, the TIP status is updated to “Rejected.”
- For non-core proposals, community consensus determines whether they move to “Final.”
TIP WORKFLOW: PROPOSAL PROCESS
The process for creating, discussing, reviewing, and finalizing a Tron Improvement Proposal is designed to be transparent and open to the community. Below is a full description of each stage of the workflow.
- Idea Formation & Preliminary Discussion
Before writing a formal TIP, an author should first discuss the idea with the community to gauge interest and gather initial feedback. This can be done by opening a discussion thread on the TRON DAO Forum or by creating an issue in the TIPs repository. The goal of this stage is to refine the idea and prevent duplicate efforts. It is recommended to begin with a clear problem statement or motivation for the proposal.
When opening a discussion, the author should provide a short summary of the proposal and invite other participants — developers, community members, and core developers — to comment and ask questions. Early discussion helps to identify potential obstacles or alternatives before time is spent on writing the full proposal. If the proposal involves technical changes to the Tron software, it may also be helpful to informally discuss feasibility with Tron core developers.
- Drafting the TIP
Once the idea has been refined and community interest confirmed, the author writes the draft TIP document. The draft must follow the official TIP template and Markdown format, including all required header fields such as Summary, Abstract, Motivation, and Specification. At this stage, the author should provide as much detail as possible: a clear description of the problem, rationale for the solution, its technical specification, and any design considerations or backward compatibility issues.
If the TIP is a Standards Track proposal, it should include test cases or reference implementations when possible. The author must also include a “discussions-to” link in the TIP header, which points to the public forum thread or GitHub issue where discussion is taking place. This ensures that all participants know where to follow or join the conversation.
- Submitting a Pull Request
When the draft is ready, the author submits it as a Pull Request (PR) to the official TIPs repository. Each PR should contain only one TIP. The PR title usually includes the proposal’s title or a temporary TIP number if one has already been assigned.
At this stage, the TIP has not yet been formally numbered — the author should use a placeholder such as:
tip: <to be assigned>
The PR description may include a short note that this is a new draft TIP and provide the discussion thread link for context. The draft must comply with formatting and style requirements; automated checks may verify the presence of all required fields. If any checks fail, the author must correct the errors and resubmit the PR.
Community members and TIP editors can comment on the PR to suggest revisions or improvements. This feedback phase is part of the Draft stage.
- Draft Review and Number Assignment
Once the draft is submitted, a TIP editor reviews it to ensure that it meets the basic quality standards. The review focuses on structure and completeness rather than content. The editor checks that:
- All mandatory header fields (title, author, type, etc.) are present.
- The document follows the proper structure and includes the necessary sections.
- The text is clear and understandable.
After confirming compliance, the editor assigns an official TIP number, updates the header, and merges the PR into the main repository branch. From this point, the proposal becomes an official part of the TIP repository with status “Draft” and can be publicly referenced (for example, “TIP-25”). The file will appear in the repository as tips/tip-N.md, where N is the assigned number.
- Draft Phase and Iteration
Once merged, the proposal remains in Draft status, meaning it is still under active development and discussion. The author continues to engage with the community, collect feedback, and refine the document as needed. Changes to the draft are made through additional PRs.
During this phase, the content may evolve significantly as details are refined. The discussions and all revisions must occur publicly, ensuring transparency. The draft stage continues until the author and community reach a consensus that the proposal is mature and stable.
There is no fixed time limit for how long a TIP can remain in Draft, but rushing the process is discouraged. If the author decides not to continue working on the TIP or if the community loses interest, the status can be changed to “Abandoned,” indicating that development of the idea has stopped.
- Last Call (Final Review)
When the author believes the proposal is ready for final review and no further major changes are anticipated, they may request to move the TIP to “Last Call.” The “Last Call” status signals that, unless significant objections arise, the TIP will soon be finalized.
An editor assigns the “Last Call” status and sets a review deadline — typically at least two weeks in the future. The purpose of this period is to give a broader audience time to review the proposal one last time, including stakeholders who may not have followed earlier discussions.
During the Last Call period, the TIP should not be modified except for minor clarifications or corrections. If substantial technical issues are raised or reasonable objections appear, the TIP may be reverted to “Draft” for additional refinement. Assuming no major concerns arise, the Last Call period usually lasts a minimum of two weeks before the proposal advances.
- Decision and Acceptance
After Last Call, the process diverges depending on the type of TIP.
For Standards Track – Core proposals, the TIP must be formally presented to Tron core developers for decision-making. The author should request that the TIP be included in the agenda of an upcoming “All Core Devs” meeting. During or after the meeting, if the developers agree to implement the proposal in a future network upgrade, the TIP is marked as “Accepted.”
“Accepted” means that core developers approve the proposal and commit to implementation. However, it does not yet reach “Final” status until the implementation has been completed and released. If developers decide not to proceed — for example, due to technical risk or insufficient benefit — the TIP is marked “Rejected.” Rejection reasons should always be recorded for transparency.
For Standards Track – Non-Core proposals (Networking, Interface, TRC, TVM) and Informational proposals, core developer approval is not required. After the Last Call review, if community consensus indicates that the proposal is beneficial and no significant objections remain, the author or an editor can update its status to “Final.”
In such cases, an editor verifies that consensus has been achieved — often by confirming that there are no unresolved objections in the forum discussion. If disputes remain, the transition may be delayed, and the TIP can be returned to Draft for further refinement.
- Final Status and Implementation
A TIP with “Final” status is considered complete and accepted by the community. “Final” means the proposal has passed all review stages and, in the case of Core TIPs, has been approved for implementation or is already implemented.
There are two forms of Final status in the Tron process:
- Final (non-Core): used for Informational or Standards Track proposals that do not modify consensus rules. It indicates that the community recognizes the proposal as an agreed-upon standard or guideline.
- Final (Core): applied once the proposal’s changes have been implemented in the Tron protocol or officially scheduled for release.
Once a TIP reaches Final status, it is effectively locked and becomes a permanent part of Tron’s governance and documentation.
- Post-Final Maintenance
After a TIP is finalized, its contents should not change substantively. Any future modifications or follow-up developments must be introduced through new TIPs. Only minor editorial corrections, such as fixing typos or clarifying text, may be made with editor coordination.
Final TIPs often serve as reference materials for implementers and for subsequent proposals that build upon them.
- Other Outcome States
Not every TIP reaches “Final.” Several alternative terminal states exist depending on circumstances:
- Deferred: The proposal is postponed for future consideration, often because more research or better timing is needed.
- Abandoned: The author ceases work, or the community loses interest; the TIP is no longer active.
- Rejected: Officially dismissed as unsuitable, unfeasible, or unnecessary.
- Superseded: Replaced by a newer TIP that covers the same subject in an improved way.
- Active: Used for proposals that remain continuously relevant, such as process documents or parameters that may evolve over time.
For example, certain ongoing governance or policy documents can be labeled “Active” to indicate that they remain current and are subject to periodic updates. This very TIP-0001 may later be marked “Active,” since it defines a living process that can evolve through future revisions.
Throughout all stages of the workflow, transparency is mandatory. Every discussion, comment, and decision should remain publicly accessible. Major decisions — such as rejections or significant changes — must always be explained and justified in writing, ensuring openness and accountability within the Tron community.
TIP FORMAT AND STRUCTURE
Each Tron Improvement Proposal consists of two major parts:
- A header section containing metadata.
- A body containing the detailed proposal content.
This structure ensures consistency, readability, and clarity across all proposals.
TIP Header
The header is a block of metadata placed at the top of the document. It provides key information in both human- and machine-readable form.
Example of a TIP header format:
tip: <TIP number>
title: <Short Title Limited to 44 Characters>
author: <Author Name (or Username) <contact>, Additional Authors...>
discussions-to: <URL of discussion thread or issue>
status: <Draft | Last Call | Accepted | Final | Active | Deferred | Rejected | Superseded | Abandoned>
type: <Standards Track | Informational>
category: <Core | Networking | Interface | TRC | VM> (required for Standards Track TIPs only)
created: <YYYY-MM-DD>
requires: <Optional: TIP number(s) that this TIP depends on>
replaces: <Optional: TIP number(s) that this TIP supersedes>
Explanation of fields:
- tip: A unique identification number assigned by a TIP Editor once the proposal is accepted as a draft. For new drafts, authors should write “”. Once assigned, this number never changes.
- title: A concise descriptive title (maximum 44 characters). It should clearly convey the purpose of the proposal without being overly general.
- author: A list of the authors’ names or usernames, with optional contact information such as email or GitHub handle. Multiple authors are separated by commas; the first listed author is considered the primary champion.
- discussions-to: The URL or forum thread where community discussion takes place. This field ensures transparency and centralized dialogue.
- status: The current stage of the TIP in its lifecycle (Draft, Last Call, Accepted, Final, Active, Deferred, Rejected, Superseded, or Abandoned). This field is updated only by an editor to reflect community consensus or governance decisions.
- type: Specifies whether the TIP is a Standards Track or Informational document. Process guidelines, such as this one, are considered Informational.
- category: For Standards Track TIPs, this field defines the subcategory — Core, Networking, Interface, TRC, or VM. Informational TIPs do not require this field.
- created: The date the TIP was first created, formatted as YYYY-MM-DD. This date should remain constant even as the TIP evolves.
- requires: Optional. Lists other TIPs that this proposal depends on. A TIP with dependencies cannot be finalized until the required TIPs are themselves accepted or finalized.
- replaces: Optional. Indicates earlier TIPs that this one supersedes. When finalized, editors mark the replaced TIPs as “Superseded” to maintain historical continuity.
All fields except “requires” and “replaces” are mandatory. Authors must adhere to the exact field names and capitalization.
TIP Body
The body of the TIP contains the technical and conceptual substance of the proposal. It must provide sufficient detail for implementers and reviewers to understand precisely what is being proposed.
Typical sections of the TIP body include:
- Simple Summary
A short, non-technical explanation of the proposal in one or two sentences, written in plain language. It should enable readers with minimal technical background to grasp the proposal’s purpose. - Abstract
A concise technical summary explaining what the proposal changes or introduces, and why. The Abstract should give an overview of the problem, the proposed solution, and the expected outcome. - Motivation
Describes why the proposal is needed and what limitations or issues it addresses. It provides the rationale for change and explains what benefits or new use cases the proposal enables. While technically optional, a Motivation section is highly recommended for clarity. - Specification
The most critical section of the TIP. It contains the exact technical details — algorithms, parameters, data structures, interfaces, and behavioral rules — needed to implement the change. The specification must be unambiguous and precise. For complex proposals, this section may include subsections or pseudocode. If visual aids are necessary, diagrams or flowcharts can be included as image files in the TIP’s assets directory. - Rationale
Explains why the chosen design was selected and discusses alternative options that were considered and rejected. This section captures the reasoning and trade-offs behind decisions, helping future readers understand the design logic. It may also record major objections and how they were addressed. - Backward Compatibility
This section is required if the proposal introduces changes that might disrupt existing contracts, nodes, or systems. Authors should explain any incompatibilities and provide transition or mitigation strategies. If no compatibility issues exist, the section should state so explicitly. - Test Cases
Required for consensus-related changes and recommended for complex proposals. Authors may specify example scenarios or test vectors demonstrating expected behavior under the new rules. This ensures consistent interpretation and implementation across clients. - Implementation
Describes the status of the implementation. Initially, this section may note that no implementation exists yet. Later, it should include references to prototype code, repository branches, or client versions that include the change. For non-Core TIPs, this section may list independent projects that have adopted the standard. - Security Considerations
Optional but encouraged, especially for proposals involving cryptography or consensus. This section should outline any potential attack vectors, security risks, or mitigations introduced by the change.
Additional sections may be included when appropriate, such as References, Copyright, or Appendices. However, the sections listed above form the recommended baseline structure for all TIPs.
A key rule is that TIPs must be self-contained. They should not depend on external websites or documents for critical specifications. External resources may be cited for background reading, but the proposal must remain understandable and complete even if those references become unavailable.
Referencing Other TIPs and Assets
TIPs frequently refer to one another or include supporting materials such as diagrams. To ensure consistency and durability of references, the following conventions apply:
- When referring to another TIP, use the format “TIP-X” where X is the proposal number.
- Images and diagrams must be stored in the repository’s assets folder, under a subdirectory named after the TIP (for example, assets/TIP-100/diagram.png).
- Relative paths should be used for all embedded media to guarantee they display correctly within the repository.
By maintaining all resources within the repository, each TIP remains an independent, permanent record that can be read and understood without relying on external content.
MANAGING TIP CHANGES AND VERSIONING
Once a TIP reaches a particular status — especially “Final” — its contents are effectively frozen. Major modifications require a new TIP to be written. The following principles govern how TIPs are updated and versioned:
- Draft Updates
While in Draft status, authors are free to make updates and improvements through new pull requests. Each change is recorded in the repository’s version control history. Significant rewrites should be documented in a “History” or “Change Log” section, though this is not mandatory. - Changing Status
A TIP’s status can only change through an approved pull request. Authors may request transitions such as Draft → Last Call or Last Call → Final, but editors verify that all process requirements — such as minimum review periods — have been satisfied before merging. Authors cannot unilaterally modify status fields. - Final TIP Updates
Once a TIP becomes Final or Active, it is considered complete. No normative or functional changes may be introduced. Only editorial corrections — such as fixing typos, clarifying ambiguous wording, or adjusting non-critical formatting — are allowed. All edits to Final TIPs must be documented through version control for traceability. - Superseding and Replacing
If a finalized TIP requires substantial revisions or extensions, a new TIP must be drafted to replace it. The new TIP should include a “replaces” field in its header referencing the older proposal. Once finalized, editors mark the earlier TIP as “Superseded.” This ensures that historical continuity is preserved while allowing the standard to evolve.
For example, if TIP-50 defines a token standard and TIP-105 introduces an improved version, TIP-105 would include “replaces: 50” in its header. After TIP-105 is finalized, TIP-50’s status is updated to “Superseded.”
- Dependencies (Requires)
When a TIP relies on another proposal, it lists the dependency using the “requires” field. A TIP that depends on another cannot be finalized until the prerequisite TIP is accepted or finalized. Editors review these relationships to ensure logical consistency. - Coordination with Software Versions
For Core TIPs, implementation and release schedules are often tied to specific network upgrades or node software versions. Although not formally part of the TIP document, it is useful to note the software version or block height in the Implementation section for clarity. - Transferring Ownership
If an author becomes inactive, ownership of a Draft TIP can be transferred to another contributor with editor approval. The new author assumes responsibility for addressing outstanding feedback and guiding the proposal through completion.
CONCLUSION
TIP-0001 establishes the formal framework for how Tron Improvement Proposals are authored, reviewed, and adopted within the Tron ecosystem. By modeling the proven structure of Ethereum’s EIP process and adapting it to Tron’s governance model, this framework ensures that all protocol, network, and application-level changes are introduced in a consistent, transparent, and inclusive manner.
The TIP process clearly defines the roles of authors, editors, and core developers, promoting collaboration and accountability across all stages of development.
This document is intended to serve as a living reference for Tron governance. As the ecosystem evolves, this process may itself be updated through future TIPs. In line with the principles of decentralization, the improvement proposal process remains open to everyone — any community member can draft, discuss, or contribute to a proposal.
By following TIP-0001, developers and stakeholders contribute to a structured record of technical decisions that shape the Tron network. The TIP repository becomes the collective memory of Tron’s evolution, while TIP-0001 stands as the foundational guide ensuring order, clarity, and participation in that ongoing process.
All participants — from developers and editors to DAO members and community contributors — are invited to engage actively in the TIP process, helping to guide the continuous growth and innovation of the Tron ecosystem.