PGP 3 : Liquidity Mining Adjustment #1 and Optimistic Governance

PGP 3 : Liquidity Mining Adjustment #1 and Optimistic Governance

TL-DR : Let the core team adjust liquidity mining for the rest of the campaign with optimistic governance

Context :

As stated in PuRe 1, we have gathered data to optimize the distribution of PAL for deposits.

Reminder : The LM campaign was created to push the deposit pools to proposal threshold, this goal hasn’t been reached yet, but some pools have clearly shown progress

Let’s look at the performance pool by pool :

StkAave is our flagship pool that illustrates the composability we’re striving for with Paladin Lending. LM has been a major success with continuous growth (+248% in one month).


On the other hand, and logically, the Aave pool has not taken off (+27%)

All in all, Paladin can lend roughly 16% of proposal threshold.

Uniswap (+2%) and Compound (+6%) pools have been disappointing with a few whales dominating the pools.

The Idle pool has been a huge success with +1500% growth and nearly 90% of proposal threshold deposited.

Initially, we wanted to hand out a bi-weekly report as such, discuss her with the community, vote and then modify the program each time. We have come to realise that this modus operandi is very inefficient to quickly adapt the LM program.

Proposal :

  • Reduce COMP pool to 10k PAL / month ;

  • Reduce AAVE pool to 10k PAL / month ;

  • Reduce UNI pool to 75k PAL / month ;

  • Raise StkAAVE pool to 100k PAL / month ;

  • Allocate 20k PAL / month for palStkAave integrations to benefit from LM externally (to be voted via governance) ;

Additionally, we will keep posting such reports on a bi-weekly basis but would like the community to give a mandate to the core team to execute via optimistic governance (inspired from friends at Lido). We’ll submit the report and our recommended modifications and the community will have 72h to shut us down if there is a large belief another path should be optimal.

Rationale :

We believe that Paladin should focus on specific assets and concentrate marketing, BD and integrations on them to foster adoption of vote lending. StkAave is in a prime position for this.

Additionally, current LM doesn’t reward people who use their palStkAave in other protocols (ie : APWine), granting an external budget would allow them to allocate rewards to these integrations.

On optimistic governance, we believe introducing this system for very specific tasks will allow the DAO to avoid the over-administration problem that is often found in more traditional organisations, while keeping in place the permanent veto the community should have on operations.

Means :

None outside of gas spendings to adjust mining output.

A 72h vote will be put out on a bi-weekly basis with all the LM modifications, if community votes past the threshold, the modifications will be postponed until a formal vote passes.

Sustainability :

This optimistic execution method is solely for the 3 month LM program, and we will keep posting a bi-weekly update on the LM program performance.

Voting Options :

Yes / No / Abstain


I like this proposal a lot because it makes sense to adjust rewards based on data that we are collecting. Biweekly reports would be pretty great.

In the long run it makes sense for any reward allocation to be a community-wide decision. In the short term, while we bootstrap our governance system - it makes sense to take a different more flexible approach like the one discussed here.

While I am comfortable with the approach laid out in this proposal I think it is worth discussing an alternative which is creating a Pal community multisig. It is better for the overall decentralization of the network if the community is ultimately responsible for executing these decisions.

The multisig could have a few early responsibilities including initial treasury management decisions such as directing LM rewards to the pools where they are most valuable for the protocol. The multisig could also start to implement governance mining campaigns or smaller community incentive programs (such as an Ambassador group) to start compensating / directly aligning long term interest with early DAO contributors.

There is much more that the multisig can do. Delegating responsibility to a multisig is also not mutually exclusive with our current proposal flow. It strengthens it.


+1 to this idea. A community multisig would effectively function as a ‘board of directors’. This would have a dual function: (1) giving the community more ‘ownership’ over the protocol and (2) allowing the team to operate with less friction.

In the short term, optimistic governance makes since to me as long as the logic and adjustments are broadcasted effectively (as they have been).

Also, disappointing to see that Uni & Comp rewards are not working great. Maybe we need a more strategic approach to marketing this opportunity to those communities. Does anyone have any thoughts on how to go about this?


I’m into the idea of concentrated marketing / BD. I am not saying we should totally ignore comp / uni but agree with the approach of focusing our early resources (including time) on trying to hit TVL equal to proposal threshold in one critical pool first. This to me results in a faster overall road to wider vote lending adoption in DeFi or allows us to iterate if we need to.

What are your thoughts here Jake?


Okay, so let’s do this to avoid sidetracking everything : if no other objections on modifications arise, we’ll put it up for vote in 24h. I will also open a discussion now to create a community multisig with 1 core dev + 2 community members and once elected they will have control over the 250k/month PAL emissions.

Indeed, as core dev we don’t really have time to develop everything perfectly. Creating strategies to attract volume to these pools might be a task to bootstrap the marketing DAO.
Also bear in mind that pools v2 should be here before the end of Q1 (fingers crossed) !


What is threshold with the 2 community plus 1 core dev composition?

Bootstrapping the marketing core unit of the DAO and a establishing a community multisig with limited access to treasury funds can be interconnected.


Does it mean a total LM allocation of 20k that would be split between integrations, or an average estimation that would be allocated to every promising integrations ?

I would suggest the second option in order to make it a greater incentive to integrate Paladin in other DApps / protocols, but maybe I am missing some shortcomings of diluting LM rewards too much ?

1 Like

Hey everyone !

Quickly, on the whole Multisig to control the LM and the emissions:
The current implement only has 1 admin over the Controller, that can manage the Liquidity Mining speeds and parameters. But it’s the same admin that controls the rest of the Controller contract, and with the Controller system, a good part of the Protocol.
So, with the current system, it could bring a lot of issues to give up the control over that contract: the Controller is also the contract handling the emergency shutdown for the protocol, and giving up control over that piece currently will not allow the team to react quickly in case of emergencies.

Interesting proposal Will. I definitely like the more focused approach. Also, aiming for a higher TVL may not be the most favorable proposition under these market conditions (but the core team is always working at it).

1 Like

I think multi signature is necessary, but we can decide when to implement it,it is good to long-term development

1 Like

This is the current budget, but there is only one integration and this budget is set to increase every 2 week if needed

@Figue - thanks for taking the time to bring this forward.

As for the LM adjustment, we are aligned with concentrated liquidity to target specific communities and ignite more rapid adoption of the Paladin App.

Do any of these adjustments consider the volumes of votes on each protocol? Seems a reasonable hypothesis that the most active votes + the largest treasury = the highest demand for voting power.

Second, I will mirror @Will’s suggestion above:

Creating a community multisig allows for greater transparency and trust among the Paladin community.

It also cuts down the need for as frequent voting and bi-weekly reports - encouraging more strategic adjustments because of burdensome gas costs.

A few questions about the organization of this proposed multisig:

  1. What is the ideal balance of this multisig?
  2. How many community members? How many from the Paladin team?
  3. Finally, what is the total amount of signers - and the best threshold for efficiency purposes?

Hello everyone, we’re tremendously excited by the amount and the quality of reactions this proposal has gathered. The will of stewarding Paladin towards a decentralized management is clear.

With that being said, the current implementation of LM doesn’t allow us to pass power in a secure and rapid fashion (LM is supposed to be adjusted bi-weekly). As the emission modification doesn’t seem to be put into question, we will move PGP 2 for vote tomorrow.
In the meantime we can talk about creating a Incentive Allocation Committee in the following RFP.

Additionally, because we live by trustlesness, we’d like to begin by opening the operational multisig to a community member. Currently it is composed of 3 core team members, one investor and one external DAO contributor (need to check if he is okay in being doxxed). We will now remove a core team member and replace him after an election (PGP 3?)

  • Yes, add a community member to the Operations multisig
  • No, leave as is and leave the core team be lean for the moment

0 voters