Hello Push Fam! Ever wondered how you can bring your great ideas for Push DAO to life? PIPs help you achieve that. Let’s take a look at how it works.
What are PIPs?
A Push Improvement Proposal (PIP) is a proposal submitted by a member of the Push community that proposes a change to the Push ecosystem in a standardized and implementable way.
What can be Proposed?
In this current iteration of Push DAO (aka Push Governance v2), there are only two types of PIPs that can be made: Governance and Ecosystem PIPs.
- Governance PIPs are those that propose changes or improvements to Push DAO. This includes proposals concerning the Push DAO constitution, subDAOs, governance processes, changes to PIPs, etc.
- Ecosystem PIPs are those that propose non-technical changes or improvements to the Push ecosystem. This includes proposals concerning the Push Ambassador Program, provision of general guidelines or information to the community, community development initiatives, etc.
What is the Lifecycle of a PIP?
A PIP goes through five phases from inception to conclusion. It starts with a discussion on the governance forum and eventually, its end-state is implementation if it successfully passes the other phases.
Phase-1: Forum Discussion
This is the idea-vetting stage where community members engage in conversation about potential improvements to any of the two permitted governance aspects of the Push Governance v2. Anyone can participate in this phase, and it occurs on the Push DAO governance Forum.
Prefix: [Discussion]
Duration: 7 Days Minimum
Phase-2: PIP Formalization
Here, the idea is formalized into a PIP that must include all the criteria specified in the PIP template (template below). Once the PIP has been drafted, the author must post it on the Push governance forum. While the PIP is in a draft state, the author is free to amend the proposal based on community feedback. In this phase, the forum post should be prefixed with [RFC] i.e., request for comment.
Prefix: [RFC]
Duration: 5 Days Minimum
Phase-3: PIP Temperature Check
PIPs should be progressed to Phase-3 once the author has considered and implemented all community feedback and believes the PIP is ready for voting.
To do this, the author must initiate a poll on the Governance forum to gauge the community’s sentiment. The poll should be ‘single-choice’ and only limited to forum members with ‘trust level 1’ and above as a measure of Sybil resistance.
The poll must receive 5 ‘For’ votes before the proposal can proceed, with only the following options:
- For
- Against
- Abstain
This process is irreversible. A PIP cannot be reverted to Phase 2 if it fails the temperature check vote. At this stage, the proposal is final and should not be edited, except for correcting errors.
Prefix: [Temp-Check]
Duration: Open-ended
Phase-4: Snapshot Vote
Once your proposal passes the temperature check stage, you can call for a snapshot vote by adding a reply to your post requesting a snapshot vote and tagging the Push Governance Lead.
Here, the PIP is approved or rejected by the Push Community via an off-chain Snapshot vote. The Snapshot vote must link to the results of the successful Phase-3 forum poll and include the full text of the finalized PIP.
All snapshot votes will be scheduled on Mondays when possible, and will run for 5 days, with only the following options:
- For
- Against
- Abstain
Note:
- Only the DAO/Governance Lead or members with 75,000 $PUSH (aka PUSH Delegatees) can submit proposals on the Snapshot.
- All $PUSH token holders can vote by delegating their voting power to themselves or another person.
- For a vote to be successful, it must achieve a quorum of 1% of the circulating supply of $PUSH voting, with a majority voting “Yes” on the proposal.
After the snapshot vote, the forum post (the proposal on the forum) should be suffixed with the outcome of the vote.
Suffix: [PASSED or FAILED]
Duration: 5 Days
Phase-5: Implementation
After the Snapshot voting period has concluded, a successful PIP is fully executed and implemented in line with the proposal. Because this iteration of PIPs is not focused on the functionality of Push Protocol itself, core development resources will only be required when a technically related governance update or something similar, as noted above, is initiated.
Duration: As contained in the proposal.
What is the PIP Template?
Each PIP should contain the following sections:
PIP: [to be assigned by Governance Lead]
Author(s): [a list of author(s) names, usernames]
Discussions: [Link to any previous discussions on the topic in the proposal]
Created: [date created on MM-DD-YYYY]
Quorum: [1% of Circulating Supply]
Simple Summary
Describe the outcome the proposed change intends to achieve. This should be non-technical and accessible to a casual community member.
Abstract
A short (~200 words) description of the proposed change, the abstract should clearly describe the proposed change. This is what will be done if the proposal is implemented, not why it should be done or how it will be done. If the proposal proposes deploying a new contract, write, “We propose to deploy a new contract that will do x”.
Motivation
This is the problem statement. This is the why of the proposal. It should clearly explain why the current state of the DAO / protocol is inadequate. You must explain why the change is needed, if the proposal proposes changing how something is calculated, you must address why the current calculation is inaccurate or wrong.
Specification
Overview
This is a high-level overview of how the proposal will solve the problem. The overview should clearly describe how the new feature will be implemented.
Rationale
This is where you explain the reasoning behind how you propose to solve the problem. Why did you propose to implement the change in this way, what were the considerations and trade-offs. The rationale fleshes out what motivated the design and why particular decisions were made. It should describe alternate designs that were considered and related work. The rationale may also provide evidence of consensus within the community and should discuss important objections or concerns raised during the discussion.
Implementation
Outline of implementation steps, including manpower, budget, measurable KPIs, milestones, and specific timelines. Proposals missing any of these elements will not be successful.
Voting
FOR:
Short description of what a future voter will be voting for.
AGAINST:
Short description of what a future voter will be voting against.
Copyright
Copyright and related rights waived via CC0.
Resubmitting a Proposal
If a PIP fails to pass on the first attempt, a proposal may be resubmitted which addresses the concerns of the community. When re-submitting a proposal, it should contain the following additional sections:
- A link to the previous PIP - The link to the previous PIP should be included in the resubmitted PIP.
- Reasons why the PIP was not passed - The reasons why the PIP was not passed should be included in the resubmitted PIP.
- Changes made to the PIP - The changes made to the PIP should be included to address the concerns raised during the previous PIP submission.
- Additional information - Any further information which can aid understanding of the resubmitted proposal and increase its chances of being passed.
If a PIP fails to reach a quorum, the author may request a resubmission of the vote by tagging the Governance Lead.
Fast-Track Proposals
Fast-Track Proposals is an alternative streamlined governance process to allow for faster implementation and execution of important , urgent, and strategic proposals that gain immediate traction within the community.
The fast-track proposal process is as follows:
Step 1 : The Governance Lead posts the proposal in the Push governance forum, together with a temperature-check poll. The proposal should contain a section that justifies why it should pass through the fast-track process by demonstrating that it is important , urgent and strategic . A fast-track proposal that fails to demonstrate these qualities reverts to the normal governance process.
Prefix: [Fast-Track]
Step 2 : The proposal must receive 5 ‘Yes’ votes on the temperature-check poll within the first 48 hours of being posted on the forum. If the proposal fails this step, it reverts to the normal governance process.
Duration: 48 hours
Step 3 : If the poll succeeds, the proposal will be promoted to a Snapshot vote as soon as possible while providing sufficient awareness to the community beforehand. The duration of the vote is 3 days.
Duration: 3 days
Note:
- Only the DAO/Governance Lead is allowed to post fast-track proposals.
- At least 5 of the ‘Yes’ voters in the temperature-check poll must be community members who have a trust level 1 (Basic or above).
- The same quorum requirements and voting options for normal proposals apply to fast-track proposals.