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 The full template can be found here

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 The full text related to Accountability and tracking can be consulted here

9.- Enforcement The full text related to the enforcement can be consulted here

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.

To read the full text, please follow the link to the forum discussion.