Tokamak Improvement Proposal

Tokamak DAO operates a Tokamak Improvement Proposal (TIP) lifecycle to systematically address proposals and encourage active community participation.

1. Writing an RFC (Request for Comment)

RFCs can be written in the Discussion-RFC channel on the DAO github, and the written RFCs will be shared in a dedicated channel in Discord (#💡|proposal-rfc) and on X and Telegram. Below are the main elements that should be included when writing an RFC.

A sample written in RFC can be found at the link.

1-1. Required elements

  1. Title And Author

    • Clearly state the title and author (or team name) of the proposal.

    • If necessary, you can include the Tokamak DAO proposal number or tag.

    • Example: “Improving the governance compensation structure”

  2. Summary

    • Summarize the core content of your proposal in two or three sentences.

    • Write it so that you can see at a glance what you are proposing.

  3. Background & Motivation

    • Describe the background and problem awareness that led to the proposal.

    • Clearly explain what the current problem is and what value this proposal brings to the Tokamak ecosystem.

  4. Specification

    • Create a step-by-step, concrete plan to implement or execute your proposal.

    • If a smart contract needs to be modified, specify which parts and how to modify/add them.

    • If necessary, refer to similar cases from other projects and describe the specifications, changes, compatibility with previous versions, etc.

  5. Expected Impact

    • Describes the expected effect when the proposal is implemented.

    • consider both positive impacts (e.g., improved protocol performance, increased participation) as well as potential risks or side effects.

1-2. Assistance elements

  1. Backwards Compatibility

    • Briefly describe how your proposal is compatible with existing systems, any technical changes required, and the expected development schedule.

  2. Reference Implementation

    • explain, including examples, how the proposed feature can be utilized in other Contracts.

  3. Security Considerations

    • This section outlines security considerations that should be taken into account when making a proposal or code change.

  4. Additional Materials and References

    • Include external materials, references, technical specifications, and similar cases that support the validity of your proposal.

RFC discussion period

Once an RFC is submitted, it will be open for community comment for at least 7 days. Proposers are free to revise the draft to reflect comments raised during this period.

This step greatly helps to improve the completeness of the proposal, build community consensus, and reduce unnecessary misunderstandings. Additionally, when creating an RFC, we promote it through Discord, X, Telegram, etc. to encourage more users to see the proposal and participate in governance.

Last updated