PIP-XX: Amending The Paladin Emergency Proposal (PEP) Process

PIP-XX: Amending The Paladin Emergency Proposal (PEP) Process

Authors: Kene_stablenode, Bobbay_stablenode


Simple Summary

PIP-XX introduces an amendment to the Paladin Emergency Proposal (PEP) type, which is a proposal type used to shorten the proposal life cycle in an emergency. PEP has a lifecycle of 24 hours due to the nature of the proposal.


This proposal amends the PEP to include a number of responsibilities for the existing Paladin Community Elected Multi-Sig, Community Multi-Sig members will work hand in hand with the Core Team to address emergencies; this proposal also proposes decreasing the quorum for PEP to pass and increasing the scope of PEP to include time-sensitive financial opportunities that could be beneficial to the Paladin DAO.

As Paladin DAO further decentralizes, an emergency proposal process will address emergencies in a decentralized and coordinated manner.


There will be emergencies for an urgent vote for the sake of the DAO. For example, since Paladin operates within the voting markets space, if members of the DAO identify a time-sensitive treasury strategy opportunity by utilizing this PEP process, the DAO can take advantage of this opportunity.

On the contrary, where there is a time-sensitive opportunity or emergency involving the DAOs assets or technological infrastructure, through this PEP process, the DAO can take action to perform damage control in such a situation.


  1. Current Process
  2. Amendment to PEP Quorum
  3. Scope of the PEP process
  4. Additional Community Multi-Sig Responsibilities

Current Process.

According to the Governance Framework Amendment Proposal, here is the current PEP process.

“PEP: Paladin Emergency Protocol

Considering the importance of timing in certain situations, this category was recently brought to Paraswap Governance and aimed to prepare the DAO for any potential emergency action that might have to be done.

Tier 1

Scope: User funds are at risk

Actions: Immediate intervention by pausing the system, then a community discussion + PEP 24h vote time for further actions. Since the admin rights are held by the Paladin Core multisig at the moment, only the Core Team will be able to pause the contracts and should release a postmortem on the forum.

However, we could consider electing a Governance committee to take this function and further decentralize the protocol ownership in the future.

Tier 2

Scope: Risk on protocol economic activity (eg: Bug on Warden allowing to keep a boost after the renting period, bug on Quest allowing to be in several ones at the same time etc, or any economic attack/exploit possible)

Actions: 6-12h feedback emergency on the discord/forum then PEP 24h vote time. If the attack happens 24h before the distribution, the reaction should be immediate and follows the same process as Tier-1. The action should be to pause the compromised module only, if possible. A post-mortem is also needed in this case.

Admin: Team multisig

Quorum: 5% of the hPAL total supply (vs 15% currently)

Voting duration: 1 day (vs 3 days currently)”

Amendment to PEP Quorum

We propose reducing the quorum for PEP proposals from 5% of the hPAL total supply to 3% of the hPAL total supply; by reducing this number, we believe we can ensure that these proposals pass.

A possible criticism of further reducing the quorum would be the possibility of a governance attack; however, with the creation of additional responsibilities for the Community Multi-Sig Signers, the signers would be able to veto any malicious proposals.

Proposed Scope of the PEP process

This process can be utilized under the following circumstances.

  1. Addressing a potential or actual vulnerability could put user funds/assets or Paladin technological infrastructure at risk. (This is covered under Tier 1 and 2 of PEP in the Paladin Governance Framework Amendment)
  2. Where there is a time-sensitive opportunity that could bring significant benefits to the DAO, for example, where purchasing a strategic asset over Over-The-Counter (OTC) within a limited time frame would grant the DAO access to more voting power to boost our quest rewards.
  3. Where market conditions necessitate a quick change in the protocol’s risk parameters or smart contracts.
  4. The PEP process can also be used in any emergency where time is of the essence.

Additional Community Multi-Sig Responsibilities

It is essential to acknowledge that introducing the PEP process can open the Paladin DAO to particular vulnerabilities. Malicious actors can take advantage of the PEP process, so we recommend creating additional responsibilities for the Community Multi-Sig Signers, this will give the signers the power to veto certain decisions if they aren’t suitable for the community.

Community Multi-Sig Signers can approve or reject PEP proposals before going to a snapshot vote.

At least three Community Multi-Sig Signers must leave a comment showing their approval or disapproval of a PEP on the forum post. It will need to be a unanimous approval for a vote to move forward to Snapshot.

In practice, if someone introduced an emergency vote to claim the treasury for themselves and passed the vote, the Community Multi-Sig Signers could veto this before it moved to Snapshot.

We believe this is important because some malicious actors might try to take advantage of a PEP. Due to its swift nature, these votes could go unnoticed; therefore, we must have a Community Multi-Sig Signers in place to prevent this damaging behaviour.


To indicate a PEP proposal, community members will have to insert “[PEP]” into the title of a proposal, i.e., “[PEP] PIP-20: Remove liquidity from XYZ”. This is to alert community members about the nature of the proposal. This will also introduce a new tag to the Paladin forum, “PEP”, to keep track of all fast-track proposals.

However, this is how the PEP proposal process would look in some specific circumstances:

  1. If Paladin user funds are at risk, immediate action will be taken by the core team, and a post-mortem of what actions were taken will be posted on the forum by the Community members involved or core team, the post shall carry the tag [PEP Post Mortem].
  2. If there is a bug in any of Paladin’s Smart Contracts then a forum post should be posted on the forum with the tag [PEP Bug] to notify the community of the existence of a bug, this post should contain a brief overview of the issue. The core team will be required to intervene and address the bug immediately. After the bug has been addressed, there shall be a [PEP Bug Post Mortem] posted on the forum where at least three Community Multi-Sig Signersl will give the community an overview of the bug, how it was addressed, and any next steps required; this must be done, within 12 hours after the bug has been addressed.
  3. If there is an attack 24h before the distribution, the reaction should be immediate and follows the same process as Tier-1. The action should be to pause the compromised module only, if possible. A post-mortem is also needed in this case.
  4. If there is a financially viable opportunity that could bring benefits to the DAO, the proposer will post the proposal with the following tag [PEP Oppurtunity]; the Community Multi-Sig Signers will have 24 hours to comment on the forum to indicate with a rationale whether it should move forward to SnapShot 24h vote time.
  5. Once a proposal is approved by at least three members of the Community Multi-Sig, hPAL token holders will vote on the proposal via SnapShot.


Every DAO needs a fast-track proposal process to cater to emergencies; the Paladin Governance process would require a significant amount of time from discussion to voting duration to cater to an emergency. As the Paladin protocol decentralizes, the community needs this fast-track process to address time-sensitive emergencies.

Next Steps

  1. Discuss the Amendment

  2. Forum Poll

  3. Move it to a vote

  4. [Yes]: Amend the PEP Process

  5. [No]: Do not amend the PEP Process

  • [Yes] Amend the PEP Process
  • [No] Do not amend the PEP Process

0 voters

1 Like

From my understanding these oversight tasks were included in the role of the Community Multisig. Could you highlight the need for an additional council?

The community-multi sig is to manage the community treasury and eventually protocol parameters.

With this governance council the sole purpose of this Governance Council would be to manage the PEP process and ensure that it is used correctly.

Could you please point to the proposal where the Community Multi-Sig responsibilities are stated?

The goal of this proposal is to clearly define all aspects of the PEP process and give ownership to the community; from what I have seen, I am not sure the Community Multi-Sig Covers that.

Upon further analysis I have edited the Proposal and removed the creation of a new Governance Council, the responsibilities I laid down for the Governance Council have now been given to the existing Community Multi-Sig.

Gm, sorry for the late feedback !

It feels like a way to bypass the PGM process, which can be definitely risky since it’s about the treasury changes. About OTC deals (if we find some as this never happened yet) I have trouble understanding why there would be a limited time, I believe this can be settled in the current associated category

By opening the possibility to manipulate the treasury in a such short timeframe, this is where malicious actor could be interested.

Moreover, giving the ownership rights to the community will be done in due time, but this requires some serious technical skills in case something happens. In the meantime, the Core Multisig is handling this part.

In the current framework, only the Core Msig signers (the Core team) can submit PEP on the forum to basically explain what happened, the actions taken and discuss about the next steps

While this is not too relevant at the moment because only the signers handling the admin rights should matter on this one (currently the Core Msig), I really like the idea for when we’ll transfer the ownership to the Community Msig

This can’t happen because of the framework. If someones pushes a PEP about treasury on the forum it should be moved to PGM category.

If the proposer decides to push on snapshot anyway (without forum consensus), he first need 5% of the circulating supply held or delegated, and even with it, the proposal would be invalid (lack of consensus, wrong framework category, wrong feedback & voting periods) and an obvious risk for the protocol, so the snapshot vote would be voted against and/or deleted.

This is an interesting example, because different from the OTC one. The only good reason to include “withdraw liquidity from x strategy” in PEP would be in case of exploit, but in that case, the withdraw would be done instantly (risk for the protocol treasury) by community members since they control the treasury Msig, then Core or Community signers would submit the PEP on the forum to explain what happened.

However, the vote would be mostly about “post mortem”, because the reallocation to a new strategy can be discussed in PGM if the funds have been retrieved, especially since it would not be smart to rush a new strategy.

For these reasons, I believe that we shouldn’t amend to include treasury deals & management in PEP.

Thank you for the feedback @Dydymoon, it is appreciated.

1 Like