PIP-57 - PIP Lifecycle Improvements
Abstract
This proposal introduces a number of updates to the governance framework, especially in the PIP lifecycle.
We understand that the current framework related to the proposal lifecycle is adequate and functions well without conflicts for the DAO. Therefore, a profound reformulation is not necessary. However, we do think it is possible to improve certain aspects to strengthen its process and functioning, and thus strengthen the DAO’s decision-making process.
It’s important to note that this proposal applies exclusively to PIPs (ParaSwap Improvement Proposal), not to PEPs (ParaSwap Express Proposals). We believe the current framework for PEPs voted in PSP-IPΔ22: PSP 2.0 is appropriate and does not currently require modifications. Urgent situations, as in the case of PEPs, demand expedited decision-making, which is why this proposal only focuses on PIPs.
Goals & review
TL;DR
The objectives of introducing these modifications to the PIP lifecycle are as follows:
- Add fields to the proposal template so that the community can evaluate and control the implementation times and potential risks that each proposal under consideration could bring to the protocol.
- Establishing a minimum debate period for each PIP presented in the forum, to ensuring a minimum debate and comment period.
- Including a lock or frozen period to ensure that after the debate has been concluded, no changes can be made to the proposal text that have not been debated.
- Establishing a timelock period after a proposal is approved and before its execution or implementation begins, to allow the protocol, the DAO, tokenholders, and the community to prepare for the execution and implementation of the approved proposal, giving everyone a minimum time to take necessary measures. Additionally, and most importantly, introducing this timelock period will provide sufficient time to address any malicious proposal or last minute error in an approved PIP that could harm the protocol by triggering a PEP procedure that would nullify it.
- Establishing that only one proposal per topic and vote is allowed, with the sole exception of multiple necessarily related, interrelated, or interlinked proposals whose implementation requires the approval of two or more proposals together.
- Establishing that executable code proposals be published on Snapshot and include the execution timeline to allow the community can review the code before its approval and execution, potentially detecting and reporting any possible errors.
- Establishing tracking and accounting rules on approved proposals, to ensure compliance and avoid making payments in the event of noncompliance.
1.- Template
We find the current PIP template to be correct and appropriate. However, we propose adding a field related to risk assessment where the proposer outlines the pros and cons of their proposal, discusses potential issues, and describes the possible impact. This will ensure that the community is not just better informed, but also integral to the process, as they will be aware of potential negative consequences and risks associated with the proposals under consideration. Additionally, we suggest separating the “Implementation Overview” field and including a specific field for the proposer to detail the total and partial implementation timeline and the delivery deadlines, as applicable. And finally we propose to add a field where, if the proposal includes a request for a budget, all related questions, such as method of payment, dates, conditions, etc., should be detailed in order to increase clarity and transparency:
-
Current Fields:
-
Proposal Number & Name:
They will be identified by PIP - XX (A number to identify the proposal, based on the order of submission) - Identifying name. For instance: PIP-54- Delegate Program Trial Period. The number is chosen at the time of the snapshot vote, at the time of the discussions on the forum of governance, it will preserve the “XX” to keep a logic of chronology of the votes. Governance post name will be updated with the snapshot going live. -
Abstract:
Comprehensive overview of the issue being addressed and the solution proposed (~ 100w). -
Goals & Review:
What are the main goals of the proposal? Briefly list the main objectives & and the metrics that will be used to evaluate the success of the proposed implementation. -
Means:
What the proposal requires to come to life: PSP budget, additional development on the ParaSwap product, external development, etc. -
Implementation Overview:
What happens if this proposal goes through? A high-level overview of the main steps required for its implementation as well as potential future considerations.
-
-
New Proposed Fields:
-
Time of Implementation:
Specify the timelines and deadline for full or partial implementation and for the submission of reports and/or deliverables, detailing their specific content and characteristics, submission methods, KPIs, etc., tailored to each case if applicable. -
Budget: If the proposal includes a budget request to the DAO, specify the total amount, in which tokens and the payment methodology. Indicate whether the full amount is to be received in a single payment and its timing, or if partial payments are proposed, subject to a specific date, the completion of milestones or deliverables, and/or the accredited fulfillment of the committed obligation.
-
Risk Assessment:
Pro and Cons of the proposal. What can go wrong? What is the impact of the proposal on the rest of the community, ecosystem, and/or protocol? If there are any audits planned upfront?
-
Rationale: These proposals aim to provide more information to the community, tokenholders, and delegates, promoting a more informed debate. Additionally, they seek to engage the authors of proposals further in developing them with greater detail and depth on relevant issues. This includes providing information they will need to explain if the outcome differs from the proposed. It also allows the DAO to withhold pending payments in case of non-fulfillment of obligations, if applicable, as we will propose below.
If the proposal is approved, the @Laita Labs team - currently in charge of governance facilitation tasks - should adapt the forum thread template for posting a new proposal and the snapshot template for submitting a new proposal. We’d like @0xytocin to confirm this as viable. We understand that in the future the facilitation of governance could stewarded to a DAO member/s, we are willing to have that debate.
2.- Frozen Period - Minimum Debate Time
Establishing a 7-calendar days minimum debate period for each PIP presented in the forum. During this time, the author can modify the proposal based on the feedback received.
Initially, a minimum period of 7 calendar days is sufficient and reasonable to ensure the possibility of a constructive debate. The author can request the end of the debate phase at any time after this period, preferably in a way that does not interrupt any ongoing productive debate or exchange of opinions.
Rationale: The inclusion of a minimum debate period is a crucial step in addressing an omission in the current framework. The absence of such a provision could lead to a situation where a proposal is presented in the forum, and the author requests a 48-hour temp check before voting the next day, bypassing the necessary debate in a DAO.
3.- Temp Check Reformulation - Frozen Period
In line with the above, we suggest explicitly including in the PIP framework that the current temp check period of at least 48 hours before moving to a vote the proposal for PIPs, should be reformulated into a proper frozen period. The proposal, which has been presented and debated for at least 7 days, cannot be modified during this 2-days period.
If errors are detected after the lock begins, or if it is considered necessary to modify, expand, or remove something, a new process should be initiated by introducing a new proposal to enable a new debate on those modifications. In this case, the proposal’s author may, at any time until the Snapshot vote begins, request its withdrawal, suspend the process, and prevent it from being submitted to a vote.
With the frozen period, after the minimum 7 days of debate that may lead to changes to the initial draft, the author must request the end of the debate phase and the start of a 2-day frozen period during which no one can make any changes to the text of the proposal.
Rationale: We believe it is crucial to establish a frozen period, allowing voters to use these two days for a final analysis and to confidently decide their vote, assured that the proposal submitted for voting will remain unchanged following the debate stage.
4.- Timelock - Delay
We propose establishing a 2-days timelock period after a PIP is approved and before its execution or implementation begins. This means that an approved proposal can only be executed or implemented 2 days after the close of the voting. PIPs with onchain code is addressed later.
Rationale: This period allows the protocol, tokenholders, and the community to prepare for the execution and implementation of the approved proposal, giving everyone a minimum time to take necessary measures.
Additionally, and most importantly, introducing this timelock period will provide the ParaSwap team, the GovCo, and the DAO with sufficient time to address any malicious proposals or last-minute errors in an approved PIP that could harm the protocol. This time allows activating a PEP mechanism to urgently vote to nullify such potentially harmful proposals before they begin execution and implementation. The proposed 2-day timelock or delay thus becomes a preventive and defensive tool to protect the DAO and the protocol, allowing it to neutralize potentially malicious or harmful proposals.
5.- PIP Lifecycle
Consequently, we propose the following renewed lifecycle for PIPs:
- Stage 1 (Optional) - Informal Brainstorming
- Duration: No set timeframe.
- Initial presentation of the idea or concern in the forum, brainstorming, research, community consultation, etc. No template, minimum timeframe, or formality is required for this stage.
- Stage 2 - RFC and Frozen Period
- Minimum Duration: 9 days (7 days of debate and 2 days of frozen period).
- Formalization of the proposal draft in the forum according to the template for temp check, debate, discussion, comments, questions, critiques, and improvements for a minimum of 7 days. After this period, the author, when the debate is concluded, must communicate in the forum their intention to end the debate and initiate the 2-days lock or frozen period before moving to a vote, during which the proposal text cannot be modified. Until the end of this stage, the author can request to suspend the procedure and withdraw their proposal.
- Stage 3: Snapshot Vote
- Duration: 5 days.
- We propose keeping the voting period and shield voting on Snapshot unchanged.
- PIPs can be submitted to Snapshot and voting can begin on any day of the week, removing the requirement that it must be created on Tuesdays.
- If approved:
- Stage 4: Timelock or Delay
- Duration: 2 days.
- Waiting period for the execution or implementation of the approved PIP.
- Stage 5: Execution, Implementation, and Accountability
6.- One Topic = One Proposal
Only one proposal per topic and vote be allowed, with the sole exception of multiple necessarily related, interrelated, or interlinked proposals whose implementation requires the approval of two or more proposals together.
Rationale: This measure avoids proposals that cover many unrelated issues being submitted to a single vote, which can hinder an orderly debate of each proposal and prevent voting differently on each proposal.
Enforcement: The governance facilitator, or whoever performs that role until such a structure is established, should be responsible for ensuring compliance with this requirement. They should have the authority to monitor proposal debates until they comply. The community can also raise objections if they detect non-compliance with this requirement and request the governance facilitator’s intervention if it still needs to be addressed.
7.- Code Publication
Atomically executable code proposals be published on Snapshot and include the execution timeline.
Rationale: This way, the community can review the code before its approval and execution, potentially detecting and reporting any possible errors.
8.- Accountability and tracking
To promote better transparency and tracking of approved proposals, the following process once a proposal is approved:
-
If the proposal is atomically executable by code: Once executed, it must be reported in the forum within 5 days from the execution date, including the transaction hash.
-
If the proposal is not atomically executable by code: After the proposal is approved, if foresees partial or periodic compliance, the responsible party must publish the required periodic reports in the forum within the established deadlines, informing the community about the status of compliance, submission of deliverables, and evidence of the final fulfillment of the proposal. In the case of multi-phase deliverables, periodic updates or interim progress reports must be provided.
Retention of Pending Payments: If a party responsible for implementing or fulfilling an approved proposal, a winner of a grant program approved by the DAO, or members of committees, working groups, task forces, etc. designated by the DAO, and in general any beneficiary of funds based on an approved proposal, fails to meet their obligation to present periodic reports, deliverables, and/or proof of final compliance (as applicable), any pending payments, whether total or partial, will be suspended until the obligation is fulfilled.
Reports of non-compliance can come from the community at any time. There should be an obligation for structures tasked with monitoring and tracking the work of other contributors (e.g., a grant council overseeing grant winners). Failure to report non-compliance constitutes grounds for poor performance, justifying removal. Additionally, the responsibility to suspend payments in case of verified non-compliance falls on the party obligated to make the transfer, and making a payment to a contributor who has been confirmed as non-compliant constitutes grounds for poor performance and removal.
9.- Enforcement
The governance facilitator, or whoever performs that role until such a structure is established, should be responsible for ensuring compliance with this framework and therefore has the authority to monitor proposal debates until they comply. The community can also raise objections if detect non-compliance with this requirement and request the governance facilitator’s intervention if it still needs to be addressed.
Likewise, the governance facilitators, or whoever performs that role until such a structure is created, must track the approved proposals and their respective deadlines and inform the community of any non-compliance.
Means
This proposal does not requires to come to life any budget or additional development.
Implementation Overview
We do not foresee any potential negative outcome of the present proposal and it is not expected for the DAO to derive any associated implementation action.
The only requirement for the DAO will be that those in charge of Governance Facilitation takes responsibility for ensuring and enforcing compliance with this framework.
