| tip | 1 |
|---|---|
| title | Talos Improvement Proposal (TIP) Process |
| author | Talos |
| status | Draft |
| type | Process |
| created | 2025-07-22 |
TIP stands for Talos Improvement Proposal. A TIP is a design document providing information to the Talos community, or describing a new feature for Talos or its processes or environment. The TIP should provide a concise technical specification of the feature and a rationale for the feature. The TIP author is responsible for building consensus within the community and documenting dissenting opinions.
We intend TIPs to be the primary mechanisms for proposing new features, for collecting community technical input on an issue, and for documenting the design decisions that have gone into Talos. Because the TIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.
For Talos contributors, TIPs are a convenient way to track the progress of their implementation.
There are three types of TIP:
- A Standards Track TIP describes any change that affects most or all Talos implementations, such as a change to the network protocol, a change in block or transaction validity rules, or any change or addition that affects the interoperability of applications using Talos.
- An Informational TIP describes a Talos design issue, or provides general guidelines or information to the Talos community, but does not propose a new feature. Informational TIPs do not necessarily represent a Talos community consensus or recommendation, so users and implementers are free to ignore Informational TIPs or follow their advice.
- A Process TIP describes a process surrounding Talos, or proposes a change to (or an event in) a process. Process TIPs are like Standards Track TIPs but apply to areas other than the Talos protocol itself. They may propose an implementation, but not to Talos's codebase; they often require community consensus; unlike Informational TIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Talos development.
The TIP process begins with a new idea for Talos. Each potential TIP must have a champion: someone who writes the TIP using the style and format described below, shepherds the discussions in the appropriate forums, and attempts to build community consensus around the idea. The TIP champion (a.k.a. Author) should first attempt to ascertain whether the idea is TIP-able. Small enhancements or patches often don't need a TIP and can be injected into the Talos development workflow with a patch submission to the Talos issue tracker.
The TIP author should first open a discussion thread on x.com to gather feedback on the idea. After assessing the feedback, the author can then proceed to write a draft TIP.
Once the first draft of the TIP is complete, the author should submit it as a pull request to the TIPs repository. This pull request should be accompanied by a link to the discussion thread. This gives the community a chance to review the TIP and provide feedback.
After a TIP has been merged, it is in the "Draft" state. The TIP author is responsible for updating the TIP based on feedback from the community.
Delegates provide advice to Talos, and Talos makes the decision. A proposal is approved by Talos, but it can be vetoed by a supermajority of delegates, which is defined as a 2/3 majority vote. This process is subject to change via a future TIP. This provides a human-in-the-loop failsafe to prevent malicious proposals from being enacted, while still empowering Talos to be as autonomous as possible.
- Draft: The first formally tracked stage of a TIP in development. A TIP is merged by a repository moderator when properly formatted.
- Active: A TIP may be promoted to "Active" status once it has been implemented and deployed.
- Accepted: A TIP is "Accepted" after it has been reviewed and approved by Talos.
- Rejected: A TIP is "Rejected" if it is not approved by Talos.
- Withdrawn: The TIP author may withdraw their proposal at any time.
Each TIP should have the following parts:
- Preamble: RFC 822 style headers containing metadata about the TIP, including the TIP number, a short descriptive title (limited to a maximum of 44 characters), a description (optional), the author(s), and so on.
- Abstract: A short (~200 word) description of the technical issue being addressed.
- Motivation: The motivation is critical for TIPs that want to change the Talos protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the TIP solves.
- Specification: The technical specification should describe the syntax and semantics of any new feature.
- Rationale: The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made.
- Security Considerations: All TIPs must contain a section that discusses the security implications/considerations relevant to the proposed change.
- Copyright Waiver: All TIPs must be in the public domain. The copyright waiver should be included in the TIP.