PIP-8 : Paladin Governance Framework update (Formerly PGP-24)

[Dydymoon]

Summary
Proposal to improve the Paladin Governance framework

Context
The Paladin Governance framework currently have the following categories:

• PGP : Paladin Governance Proposal : Treasury allocations, change of parameters, partnerships
• PCM : Paladin Constitution Modification : Change the Paladin Constitution (20% Quorum)
• PURe : Paladin Upgrade Request : Addition of new dApps to be managed by the DAO or large modification of the Paladin codebase
• PPP : Paladin Partner Program : Create a framework to whitelist partners to host a front end of Paladin’s dapps or use our software for internal use.

Paladin governance evolved since the first framework implementation. Some categories are not very used until now (eg:PCM), and others were created for a specific goal but included different topics (eg: modifying Quest fees in the Partner program category)

The new categories intend to group vote types by theme and risk exposure for Paladin in order to have a correlated level of parameters and voting duration. This will be done with an update of the scope and parameters for each category.

Rationale

A) Reminder of the required information for any proposal type

Governance forum post: Each proposal should be posted on the forum for at least 48h which allows the community to give feedback, propose changes, and vote on a sentiment poll. Forum topics also need to reach some consensus before posting on snapshot.

Proposal type, number and name: Each proposal must be easily identifiable and classified :

• Type: This will be detailed in the second part of the proposal
• Name: The name must be the same on the forum post and snapshot (Max 10 words)
• Number: Each topic needs a n° to identify the post order on the forum & on snapshot

Summary: Short description of the proposal (1-2 sentences max)
Rationale: Detailed explanation of the proposal
Means: Resources needed for this proposal (if any)

• Human resources: Special skills required (Dev or others)
• Treasury resources: Proposal cost, % of the treasury required

Voting options: List the options available on the snapshot vote, including an “Abstain” one.

B) Proposition of new categories

The different types of proposals depend on the subject discussed and the importance for the protocol.

Each category could have a different duration and quorum, however the Paladin quorum is currently set up at 15% and can’t be updated for each proposal as the governance is off chain on snapshot.
To verify, we could calculate and add the quorum to each proposal, we can discuss if this would be relevant in the comments.

This proposal aims to focus on 4 categories: PIR, PGM and PIP and PEP. The categories PUR, ¨PCM and PPP would be deleted and included in the ones selected.

Why remove the PUR and PCM categories ?
The PCM category is only about Paladin constitution, and is the only vote with a higher quorum than any other topic. As updating it represents an important improvement, I propose to move it to the PIP category (described below)

The PURe is a category that included several topics that could be added partially in PGM and partially in PIR (described below)

Why remove the PPP category ?
The PPP framework started in the PURe category, offering to external projects the possibility to host a Quest front end Integration. Later on it was used to vote on a launch partner program with a protocol that did not follow their part of the deal. The others votes were updates of the Quests fees.

I suggest moving the front end hosting/partnerships in PIR and protocol fees updates in PIP.

• Paladin Integration Request (PIR)
  PIRs are mainly focus on integrations and would regroup several topics such as :

• Partnerships (initially included in PGP)

• Front end hosting/Integration request (initially included in PPP)

• Whitelist of DAO/Contracts to lock hPAL (New)

• Support of a new asset on Paladin Lending (New)

• Support of a new veToken on Warden (New)

• Whitelist a new token as reward on Quest (New)

Additional informations required for a PIR:

• Project Presentation: (After summary)
• Protocol name, app link and TVL
• Asset TVL (If new asset on Paladin or Warden)
• Docs & audit(s) links
• Twitter/Discord/Telegram/Lens links and community sizes

Considering that integrations proposals could happen a lot in the future, and that the risk for the protocol is lower than other proposal types, we could consider the following parameters:

• Admin: Team multisig
• Quorum: 10% of the hPAL total supply (vs 15% currently)
• Voting duration: 3 days

Paladin Governance Management (PGM)
PGMs are mainly about the treasury, the DAO organization and common governance proposals such as PGP 11. It would regroup several topics such as:

• Treasury allocation strategy & allocations
• POL Management
• DAO expenses (operational costs, quests…)
• Tokens swaps / D2D swaps
• Contributors/Dao committees rewards
• Liquidity Mining adjustments (Included, then removed after starting optimistic votes)
• Bounties/Grants budgets
• Common Governance proposals (ex: Paladin Visual Identity)

Additional informations required for a PGM:

• Context: (After summary)

Removed from the PGMs scope :

• Partnerships (PIRs)
• Parameters update (moved to the next category)
• Election of DAO committee and Multisig signers (moved to the next category)

PGMs mostly concern the protocol treasury and governance management, which is why it might be best to define more conservative parameters than PIRs:

• Admin: Community multisig
• Quorum: 15% of the hPAL total supply
• Voting duration: 5 days (vs 3 days currently)

Paladin Improvement Protocol (PIP)
PIPs are about the most important modifications either on the protocol directly, on the DAO, on the constitution or on the governance framework.

The PIPs would regroup several topics such as:

• New dApps managed by the DAO (Initially PURe category)
• Modification of the smart contract parameters (Initially in PGP category)
• Large modification on the codebase (Initially in PURe category)
• Modification of the protocols fees (Initially in PPP for Quest)
• Deployment of new versions of the protocols (New)
• DAO committees & Multisig signers election or modification (Initially in PGP category)
• Change the Paladin Constitution (Initially PCM category)
• Modification of the governance framework (New)
• Deprecate a Paladin Lending Pool (New)
• Unlist a Warden Whitelisted Token (New)
• Minimum holding to post on snapshot (New) ?

Additional information required for a PIP:

• Context: What’s the modification and why it’s needed.
• Technical implementation: Highlight the technical implementations of this proposal if any.

PIPs are the most critical and important types of proposals, as it’s directly about the core products or a major change in constitution/ governance framework. For this reason, we should consider more conservative parameters than other categories:

• Admin: Team multisig (for the 5 starting points) or Community Msig (for the 4 following)
• Quorum: 20% of the hPAL total supply (vs 15% currently except PCM already 20%)
• Voting duration: 7 days (vs 3 days currently)

PEP: Paladin Emergency Protocol
Considering the importance of timing in certain situations, this category was recently brought to Paraswap Governance and aims 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)

Means: No resources needed
Technical implementations:

• Archive PURe, PCM and PPP categories
• Create PIR, PIP and PEP categories
• Rename PGP in PGM category

Voting Options:

• Yes, accept the governance framework update
• No, rework the proposal
• Abstain

Should we update the Paladin Governance framework ?

• Yes
• No
• Abstain

[StephaneSG]

What a great and comprehensive work!
It would simplify the understanding of the governance framework IMHO…

Take care!

[Figue]

Thank you for this massive work showing a wealth of experience in the art of governance.
Generally in favor of such framework with a few exceptions:

@Dydymoon

• Whitelist a new token as reward on Quest (New)

I’m against this for the time being as it would slow down our BD efforts by at least a week each time.

• In which cateogries would governance elections go?

I’m also worried the current proposal complexifies an already too complex format, do we have a way to standardize this a bit more? Or is this simple enough and we just need a recap in a table?

Also, having " different quorums means we need 3 different snapshot spaces? A big topic we are tackling internally is simplifying community UX by reducing the number of platforms members need to access to get a full picture. I’m not sure this would contribute to such efforts in its current form

[Dydymoon]

@Figue

I’m against this for the time being as it would slow down our BD efforts by at least a week each time.

Agree it make sense to add this later as not very important

@Figue

In which cateogries would governance elections go?

I added this in PIP as I believe Governance committees, multisig signers etc are very important as it defines who “controls” the treasury, or the contracts admin once transfered.

For sure I can do a recap table and if anyone has questions please dont hesitate guys it’s a very important topic.

@Figue

Also, having " different quorums means we need 3 different snapshot spaces? A big topic we are tackling internally is simplifying community UX by reducing the number of platforms members need to access to get a full picture. I’m not sure this would contribute to such efforts in its current form

About this point, I was thinking to calculate and add the Quorum on each proposal, so we dont need different snapshot spaces, wdyt ?

We can probably automatise something in a doc so everyone can access current quorums anytime.

[StephaneSG]

A recap table is a very good idea!
It will allow to see the logic of the classification: differentiation of subjects and validity requirements of decisions between categories.

Snapshot, when not integrated in an automation framework (Zodiac…), still needs to be interpreted “by hand” by humans: the quorum could be present in the proposal, as proposed by @Dydymoon and thus a requirement transparently submitted to human interpretation (Quorum reached or not…).

[Kene_StableLab]

This is a comprehensive governance framework that will solve a lot of problems for Paladin before they really have to come up. Great Job!

I applaud the emphasis laid on moving PCM to PIP, I think Paladin’s Constitution is a fundamental document and a change to it is a major improvement.

I also think we should calculate the quorum for each proposal, we don’t need 3 different snapshot spaces, a quorum calculator can be built with Dune Analytics, this is something I have seen being used in Index Coop Governance.

[Figue]

@Dydymoon

About this point, I was thinking to calculate and add the Quorum on each proposal, so we dont need different snapshot spaces, wdyt ?

We can probably automatise something in a doc so everyone can access current quorums anytime.

That seems very cumbersome, Ideally we should have only one quorum point, at max a second for exceptional proposals.

Does anyone feel it would add extra complexity ? If not we’ll move to a vote

[Tomo]

Great work Dydy! The new proposal types clarify a lot of actions. I also agree a table would list out the new structure well.

Second that we should avoid creating extra spaces at all costs, would create unnecessary complexity. If there’s no good way of managing multiple quorums I think keeping it at 15% could be an acceptable compromise.

[StephaneSG]

Maybe, you and @Figue are both right…
The proposed Quorum was:
10% for PIR,
15% for PGM,
20% for PIP,
5% for PEP.

Maybe the first 3 could be set to 15%, to avoid complexity, even if the difference in consequences for the protocole make it understandable to have increasing quorum.

What is your take for the Emergency protocol?
Wouldn’t a higher quorum slow down any emergency process and even block some important decisions?
What would be the right Quorum, fitted for a 24h decision ?

[Tomo]

PEPs are an interesting scenario. I think we should view it more as a consensus check given how time sensitive an emergency can be (hours can be too long in some cases). Which is kind of the same rationale of giving it a lower quorum. Also the admin is still the team multi-sig, which isn’t an ideal set up but it works for these cases.

When governance is fully on-chain it’ll be essential to have this parameter well tuned.

[StephaneSG]

In each scenario, it’s 1. action and 2. Discussion&vote.
It’s an equilibrium between time sensitive mesures and enough communication and community implication towards the final result : correcting the problem.

And if gouvernance is fully on-chain, you’ll most certainly have a “guardian commitee” that would have the responsability to pause the system in case of emergency, before the discussion/vote/resolution.

[Dydymoon]

@Figue

That seems very cumbersome, Ideally we should have only one quorum point, at max a second for exceptional proposals.

I asked Kipit and he can ship a dashboard updating the circulating supply & Quorums if needed, which would make updating the Quorum in a proposal very easy as it would only need to copy the right amount of vote needed at the time of the snapshot subscription as it would become a mandatory mention for each post

@Tomo

Great work Dydy! The new proposal types clarify a lot of actions. I also agree a table would list out the new structure well.

Thanks ! Sure i’ll post this asap

@Tomo

Second that we should avoid creating extra spaces at all costs, would create unnecessary complexity. If there’s no good way of managing multiple quorums I think keeping it at 15% could be an acceptable compromise.

Yeah agree, i’d say we basically have 4 possibility here:

• We use different spaces (I think we all agree about this not really being an option)
• We use sub spaces (it would be all related to Paladin but it’s different spaces too, so it could confuse people so probably not the best too)
• We stay to 15% for PIR, PGM, PIP and 5% for PIP, even if action would already be taken (not an issue for now as the circulating supply is low, but it could become one in the future)
• We create an automated dashboard so we can update exact quorums over time (requires an additional step of checking the dashboard when writing proposals)

@StephaneSG

Maybe the first 3 could be set to 15%, to avoid complexity, even if the difference in consequences for the protocole make it understandable to have increasing quorum.

Agree, that’s the main goal of separate quorums

Really glad to see some discussions on this topic, thanks for the feedback and suggestions

[Dydymoon]

@Tomo

I also agree a table would list out the new structure well.

Gm ! Lmk if it’s clearer or if there are others questions/something I forgot

[Figue]

Outside of the quorum stuff where I totally agree with Stephane, it seems pretty good

[Dydymoon]

Thanks for the feedback.
While looking at the Quorum calculation and Snapshot parameters, I noticed two things:

1. Unfortunately, it seems that Snapshot parameters does not allow to follow a % of the circulating supply (which would update it automatically), instead it’s required to enter an amount of token manually, so to be correct it should be updated before each proposal.

For example, the current total supply is 3,41M hPAL, so with 15% the Quorum should be 512K hPAL, yet it’s set to 450K since a few proposals as it would be too much time consuming to update the parameters every time.

2. The total hPAL supply is used to calculate the Quorum instead of the voting supply, meaning that the hPAL lockers boost is not taken into account. While we could consider fixing this in the future, it makes it much easier to track rn as we only need to fetch the current total supply and calculate the updated quorums.

I made a small google sheet posted below with two tabs, the 1st one is Quorum/Category and the 2nd is the governance framework recap. This sheet will auto update , and can be checked publicly by anyone writing a proposal could, in one line, mention the correct quorum and the table as proof.

Here’s the link: Paladin DAO Quorums & Gov + Quest Fees Frameworks - Google Sheets

@StephaneSG

Maybe the first 3 could be set to 15%, to avoid complexity, even if the difference in consequences for the protocole make it understandable to have increasing quorum.

Also I believe Stephane liked the increasing Quorum but proposed 15% to avoid complexity as mentioned, which is quite reduced with a Quorum dashboard imo, but can we get your point on this @StephaneSG pls ?

Now, considering that it’s the only blocking point left before moving to vote and since the choice is clear, let’s push a poll and move forward.

Option 1: Quorums based on manual Snapshot Parameters: 15% for PIR, PGM, PIP and 5% PEP

Option 2: Quorums updated in the proposal based on the correct total supply and quorums: 10% PIR, 15% PGM, 20% PIP and 5% PEP.

Option 3: Abstain

Which quorum update and repartition should we pick ?

• Snapshot Parameters based: Around 15% except 5% PEP
• Propsal Update: 10% PIR, 15% PGM, 20% PIP & 5% PEP
• Abstain

[StephaneSG]

Nice Work !
Yeah, I think that with the updated Quorums directly in the proposal, the different percentage (10%, 15%, 20% & 5%) can be kept.

And I completly agree with your 2.
But it’s quite difficult to do because of the different boost from different locking time, that evolve…

[Dydymoon]

Thanks for the feedback.

Yeah agree it can be quite hard to calculate, which is why I initially thought that we’d need a more complex dashboard, but yes for now using the total hPAL supply makes it easier to track the right quorums.

Btw I added the contract address on the document, so if someone gets error msgs (might be because of high amount of requests or bug) it’s possible to check the supply on Etherscan directly and calculate the % corresponding to the proposal category.

[Dydymoon]

Gm ! The proposal will be live on snapshot in 15min