PIP-20: Whitelisting process for tokenomics emissions


Setup a conditional whitelisting process (which can be temporary) to access the new tokenomics emissions.


Paladin is reshaping its tokenomics & several proposals were already published:

  • PIP-14: Tokenomics 2.0: Approved the global design idea
  • PIP-16: Emission Budget: Approved a max spending (15,6% of PAL supply) over 3y
  • PIP-17: Boosting System: Approved x5 initial boost for hPAL lockers on LOOT yield

The goal is to attract more lockers & enable them to redirect extra emissions to whitelisted Quests. However the PAL liquidity is limited, which can be a blocker for projects interested in large buys.

This post ideas were suggested in PIP-16 comments but another proposal was requested.


The post proposes a conditional whitelisting system to enable projects to drive emissions to their Quests. This condition can be temporary & update by the DAO later.
Also, a PAL budget dedicated to OTC deals has been proposed in this PGM.

Whitelisting Process

A whitelisting process was already planned in the initial tokenomics to whitelist eligible Quests, so this post aims to add a condition of an amount of PAL locked for the proposal to be valid. This condition can be removed by the DAO later if the bootstrapping phase was successful.

The current design is a great way to align voters, but projects incentivizing Quests can benefit from the system without necessarily having “skin in the game”, as they will be able to bribe voters to attract extra emissions.

Requiring an amount of locked hPAL doesn’t remove this option, but it can slightly impact the amount of bribes available for external voters as projects would potentially create their own flywheel by voting on their Quests to recycle bribes & receive LOOT (useful to increase their emission power).

This would also require interested projects to dig into the new tokenomics before getting involved in Paladin governance by submitting the WL proposal, sharing their intention to be an active player & their locker address.

The amount should remain marginal for most projects in order to not create a huge blocker, soI propose from 5K$ to 10K$ in PAL using a 1 week TWAP price. This amount currently represents from 50K to 100K PAL locked at least 1 year.

Another condition of minimum bribe commitment could also be added, as projects would be able to recycle it, please share your thoughts in the comments to potentially add it.

Whitelisting proposals are expected to be posted in PIR - Paladin Integration Request (an update of the framework to include these in the PIR scope will follow if approved).

The current framework can be found here.

Whitelisting Template:

  • Basics: Category, Name, Number, Summary + Project presentation
  • Rationale + Condition(s): Debank link of locked position
  • Means, Voting Option & Poll

Current PIR parameters: 3 days voting, 10% quorum


  • Align interests between Paladin & External projects
  • Create PAL buying pressure to enter the Tokenomics
  • Increase the locked hPAL supply
  • Easily demonstrate flywheel effect to projects creating Quests


  • Can block projects from entering if they consider the entry cost too high
  • Can reduce bribes available for external voters as projects could vote for themselves



Technical Implementation

Update governance framework to include Quest whitelisting in PIR

Voting Options:

  • Yes, Conditional WL
  • No, Rework proposal
  • Abstain


Should we implement a condition to have locked hPAL for the Quest whitelisting process ?
  • Yes, Implement the conditional WL
  • No, Rework proposal
  • Abstain
0 voters

Hi, thank you for going forward with a WL template proposal for the impending tokenomics release.

I think that the WL system, as you point out, is extremely important to familiarize participating stakeholders to the system. Additionally, it gives the possibility for the DAO to push out Quests that would be obvious farm and dump loops built solely to extract value.

However, I’m quite worried adding another condition to benefitting from tokenomics is just too much (buy PAL + Lock + Get WL is already a lot). Additionally it would prevent smaller protocols to benefit from the system, especially if Paladin keeps scaling and PAL price rises.

Also totally against bribe commitments, as it is not a mandatory part of the system, and we have no incentive in forcing behaviors that might not be meant to be on this system.

1 Like

Gm ! Thanks for your feedback !

Buying & locking to benefit from tokenomics are the basics, and as you mention whitelisting is needed to prevent “bad” quests so it doesn’t really add a lot of additional efforts since if a projects locked the amount required once, it won’t have to bother with this condition for future Quests wl proposals.

However, I agree (& mentioned it in the cons too) that the small projects might refrain from participating if the entry cost is too high but small protocols usually also generate small revenues.

Moreover I believe the range proposed is quite reasonable (5 to 10k$) as most projects can afford this, especially if that means reducing their bribe expenses afterwards, but open to discuss a reduced amount if you think that would be better.

Imo we need to be careful with these decisions. For example if I understood correctly, voting Option 3 on the PIP-19 means that hPAL holders (stakers) will have better conditions than hPAL lockers with a potential double discount:

  • Minimum fees on Quests creation with 250k PAL staked
  • Ability to subsidize cost with LOOT emissions by bribing hPAL lockers

Quest creators with better parameters without being truly aligned with the protocol (no lock, only a staking cooldown) seems the opposite of what we should aim to increase the amount of lockers.

The main issue with the current tokenomics design is that voters are well aligned, but Quest creators are not so this proposal is an attempt to get both side aligned.

Thanks for raising this point. Agree that if the conditional wl is approved, adding bribes requests might be too much (that’s why just mentioned the idea but it’s fully included in the initial proposal.)

However, if the conditional whitelist is rejected, this could definitely be considered to insure a minimal alignment with projects receiving LOOT emissions.

Good luck in finding projects on board with this. Will not support a WL process with these conditions

What, in your opinion, are the right conditions for establishing a whitelist then ? How can we prevent a bad actor from taking advantage of emissions ? A blacklist, as suggested in the Discord, seems like a lot of work and will always be lagging behind malicious actions.

We can do a WL, but it shouldn’t need a minimum threshold of voting power. The example is the Curve governance. You don’t need a lot of vecrv but a sponsor to push the vote and people voting in your gauge. This alone should be sufficiently hard. No need to force buys, it is just additional friction with very little actual utility.

I guess we agree with Figue on adding a whitelisting process as it was suggested in a previous PIP (a blacklist as you say isn’t really better as it requires an issue to happen before taking actions). Where we disagree is adding a conditional whitelist based on a minimum of hPAL locked for a proposal to be valid.

The goals of this proposal are not only to prevent bad actors, but also to align Quest creators with the new voted tokenomics, as only ones are voters atm (and increase the PAL lock rate).

Iirc 2500 veCRV are needed to publish a proposal on Curve, which at the moment is worth 1,25K$ but went up to 14K$ around CRV ATH so your point is not really valid.

It’s also inappropriate to compare Paladin tokenomics bootstrapping capabilities with one of the biggest DeFi protocols for which the tokenomics are the base layer.

I’m not sure that we can qualify outcomes like aligning both sides (voters & creators) in the long term or doing a successful tokenomics bootstrap as very little actual utility.

Thanks for this helpful feedback.

If you’d like to propose an alternative idea to fix the tokenomics design currently incomplete, I’m listening.

The tokenomics are neither broken nor incomplete, tbh I have no idea how you can say this before their release…

The addition of frictions considering the we already have a locked token + a WL obligations is sufficient. I have zero obligation to support anything other than the creation of a WL.

Exactly this, thank you for the summary.

Because locking PAL isn’t sufficient alignment…

Again, you misinterpret my point. What I am trying (and obviously failing) to explain is that you do not need to own 2500 veCRV, just know someone who does and is ready to sponsor you. I can guarantee at least half of gauges are sponsored as I’ve done it for 20+ of them.

Yes of course, Because it doesn’t fit your narrative.

Let’s be transparent about your worry: you fear the PAL emissions will create sell pressure strong enough for a death spiral. This is pretty ironic as you were perfectly happy when we spent so much money on incentives for the palStkAAVE pool

But regardless, you are right, there is always a risk, which is mitigated by a multitude of steps:

  1. You need to lock PAL to benefit from tokenomics
  2. Only ~20% of emissions will go to voters that are not “aligned” (because of the 5x boost)
  3. A Whitelist will prevent bad actors from exploiting the system, this enables to do DD each new player and remove the ones we could miss

I do not believe adding a cap creates more defensibility, I actually think it just reduces the number of potential users. The only use case you have disclosed where there could be risk is if an already WL Quest started bribing hPAL lockers to abuse the system. Again, outside of the fact that its extremely ironic that a bribe marketplace would fear bribes, we can simply remove nefarious projects from the WL.

I understand and appreciate your worries, but these are extremely theoritical assumptions and killing the efficiency of a project for this much seems absurd at best.

Except Quest creators are not forced to lock hPAL to benefit from emissions with the current design.

This can be done ofc, but the initial goal is to enable aligned holders to participate in the governance, so sponsoring shouldn’t be the base solution to push a gauge proposal.

No, because imo the comparaison makes no sense. Same as giving better conditions to stakers than lockers btw.

It’s surprising to see you go against bootstrapping ideas this much, without even suggesting a counter proposal.

Not only as this concerned was discussed on the emssion post, but I’m also worried that Quest creators are not aligned as they can benefit from the tokemonics & exit any time.

Unrelated to the discussion but on that topic, the goal of this pool was to retain stkAAVE deposits so they could be migrated to Dullahan, which partially failed since the amount deposited dropped by more than half.

Moreover; several community members were LP on this pool and tried to create a flywheel by relocking AURA farmed to vote & sustain it to reduce incentives over time.

Finally, the palStkAAVE yield was not supposed to be stopped before starting dstkAAVE ones, but at the moment there is still no dstkAAVE liquidity strategy and yield on the old pool was killed weeks ago.

  1. Not only, you can bribe hPAL lockers too
  2. I’m not talking about voters but Quest creators, voters are indeed aligned.
  3. Yes, but a classic whitelist doesn’t align Quest creators long term

Anyway thanks for your feedback, feel free to propose an alternative.

Would also appreciate others delegates to participate in the discussion :pray:

gm thank you for the proposal and all the discussion !

To be honest not easy for me to make up my mind as we don’t have any market feedbacks, we can only think from a theoretical viewpoint. I agree with the fact that a WL is making sense and on this point everybody seems ok.

Regarding the minimum threshold of voting power to lock, I understand the fear that it can create even more frictions to onboard users. Do we have other DeFI protocol other than Curve that we can use as benchmark ? Personnaly I don’t know about them but this could help.

What about doing this in two times:
Firstly, users don’t need to lock any voting power so there isn’t too much frictions to jump in. They will try and benefit from Paladin.
Secondly, at some point a low level of locking could be asked if needed.

This is inspired from what we ususally see in DeFI no or almost 0 fees at the beginning and then there is always the opportunity to switch on. Doing it the opposite way seems way much more difficult imo. In any cases as I previously said it would be key to have good analytics to monitor the new tokneomics when they are live.

1 Like

Gm, thanks for the feedback !

Actually, most of the ones with emission driving capabilities have some kind of alignment required for it, most of the time with a lock. However, it is hard to compare these with Paladin which has a few layers on top of the base ones (Curve, Balancer, Bunni…)

I really feel like we should do the opposite. First add this as a requirement (which doesn’t impact projects too much considering amounts proposed), then once we see the tokenomics are successful, or in the opposite if we see this is actually creating a huge blocker, it can be removed, enabling more projects to enter.

As long as we define what metrics we want to monitor, we should have the resources at Mithras to do so.

And I 100% disagree (simply because we actually have to build it, and it is much easier to add features than remove them - this is Dev 101).

Let’s just push this for a vote tomorrow if we have no other comments and see where we land on this.

This one should be reposted as PIP-20 as PIP-19 already exists.

Quorum PIP-20: 958 569 votes


It’s not, the vote started yesterday


From my perspective, I do not believe that it is best to add a locked hPAL requirement as an additional barrier for teams looking to leverage these Tokenomics Emissions.

If the DAO chooses not to go with a hPAL requirement, this is clearly not set in stone, however I believe we want to lower the barriers to entry initially and then consider adding a locked hPAL requirement later on, after this process has proven its value to early adopters.