PIP-47 - Updating Token Allowlist for ParaBoost #2

PIP-47 - Updating Token Allowlist for ParaBoost #2


Following the PSP-EPΔ02 voted on February 20th, several feedbacks in the discord have been made to add additional tokens in the allowlist of the Paraboost.
This proposal tends to agregate those several requests while keeping the spirit of Social Escrow in the allowlist.

Goals & review

Taking up the spirit of the first PSP-EPΔ02 proposal, as new projects and networks are developed, and as feedbacks are received from members of the community, it’s a fact that the Token Allowlist to filter healthy trades is missing the tokens of key projects which are either critical players in large ecosystems, important infrastructure present across multiple ecosystems.

As the research thread has not yet succeeded in finding a consensus allowing tokens to be added to the allowlist according to predefined rules, without the need for a governance vote, the proposal is to add a list of tokens to the allowlist.


We propose to add the following projects and their token addresses in the specified Paraswap-supported chains to the token allowlists.


2. $wstETH (Wrapped stETH)

3. $USDC (Circle)

4. $CAPS (Capsule Coin)

5. $PSP (ParaSwap)

Implementation Overview

The tokens will be added to the allowlist and will be taken into account when calculating the ParaBoost.

Votiong option

  • Add tokens on the allowlist
  • Don’t add token to the allowlist
  • Abstain

Hey @Albist thanks for the proposal!

I’ve cleaned the already added issues on the repository, do you want to add this remaining one Add fETH: Fractional ETH, xETH: Leveraged ETH, FXN: FXN Token,CLEV: CLever Token,CTR: Concentrator Token · Issue #19 · paraswap/community-token-list · GitHub to this proposal?

Moreover I’ve noticed that Paraswap token isn’t whitelisted on Optimism so I’ve created the issue: Add PSP: Paraswap (OPTIMISM) · Issue #24 · paraswap/community-token-list · GitHub

Anyway I think this list should be made definitive soon in order to avoid to much delay in the proposal.



Thanks Alb
Couldn’t the troopers have the upper hand for automatic, instantaneous additions?

We keep the discussion thread and each time a request is made, the trooper checks the token’s veracity and adds it.

1 Like

Hey @stikers I’m not sure that’s Troopers responsibility to ensure the tokens here are whitelisted, it would at least require validation from Troopers peers in order to avoid a Trooper to add a scam token.

So IMO I think the snapshot vote is quite essential here so the DAO acknowledges it all.

1 Like

That’s funny, because it was Albist who took the initiative to up the propal. He’s the one who added the contracts and checked the old ones.

Basically, he’s a trooper who’s just done the job I suggest troopers do :slight_smile:
Once again, the tokens added are often well-known tokens with easily identifiable contracts.

Maybe it’s time for troopers to take responsibility for certain tasks that can be simplified thanks to your knowledge and experience?

1 Like

You know Albist and I registered 90% of the issues regarding token additions like since a year? I created the first proposal in that sense. Of course we’re trying to help this process as well, presenting it like you do it looks like we’re doing nothing on this topic…

Checking the coin addresses is the responsibility of any member, the goal of a DAO is precisely to allow anyone to contribute equally. We’re accelerating the allowlist process but the ultimate validation needs to come from the DAO. The more people check a new proposal (in this case new tokens), the less probability it remains that an error was missed.

Moreover it goes against decentralisation where 4 arbitrate people could decide individually changes that could affect the project efficiency (ex: distributing more PSP on tradewashing…) and durability. And what if we disagree inside troopers?

So I don’t really understand why you’re a bit aggressively bringing this point, that’s exactly what we’re doing and it was never part of any Trooper engagement. We’re facilitating the addition of new tokens, but the final word belongs to the DAO, because that’s what the DAO is meant for.

1 Like

I don’t see where you got the impression I was being aggressive.
The DAO is not in the business of making useless votes. I think Oxy made a point of it when we were still together in the Troopers.

DAO doesn’t mean to vote for everything.
Mimic takes care of automating the reward distribution process, so I don’t think there’s a monthly vote on the transfer time for each currency?

Overzealous decentralization also leads to slowness and stagnation. A bit like the list that has never been updated, but which regularly crops up in discord discussions.

In my opinion, when a problem has been identified and we have the tools to fix it more quickly, then let’s do it?

The DAO has agreed to create a gov co to manage our revenue transactions and all the others for that matter.
I don’t see how giving recognized and trusted troopers the ability to update the white list is a problem.
I would add that gouv co is also hired to watch out for Paraboost and abuses. There’s no doubt that if someone had 600% of Paraboost thanks to a shitcoin you inadvertently added, they’d be brought to light very quickly.

I’m sorry if you were offended by my comments.

1 Like

thanks for cleaning the issues.

Proposal above was updated with $PSP allowlist request on optimism.

Regarding the remaining issue. I’m not familiar enough with the token to push to add it on the proposal.
The allowlist is a tool that allows only tokens that are supposed to be non-manipulable to be taken into account, to avoid abuse in terms of ParaBoost.
Unless pushed publicly by the community, I prefer to avoid adding tokens I don’t know.
But I am of course open to any public request to add a token.


Hey everyone, this is just a reminder to try to keep the discussion as on-topic and civil as possible. It’s very important to make sure that when introducing a non-automated element to something as essential to the staking system as whitelists , but let’s always try to remember the human in these discussions.

Following this proposal, I’ve taken some time to look at the github of where the token list is drawn for, and found an interesting way to go forward with this token update issue. The directory includes a list of tokenlist sources , a process to include new tokens and a potential process to include stablecoins.

Considering the openness of github, perhaps the easiest way to go forward with future inclusions might be to update this original script, explore which token lists to include, etc. and use this new script to give a more neutral source of tokens.

If we want maximal decentralisation a new proposal link could be made to put to a vote future pull requests created by the script. We could avoid the PIP format and lower the requirements to allow for agile implementation. Otherwise, the troopers/govco/other DAO member could be entrusted to requesting PRs for new tokens created from this script, but they can only work with tokens outputted from the script to ensure full neutrality.

What do you think? :slight_smile:

1 Like

My bad if I were a bit surprised at first, I know you’re thinking for the good of the DAO, and I was also worried for a potential centralisation.

As I don’t wanna add length to this (a bit off topic) discussion, it would be a pleasure to open another thread on this topic and try to optimize this flow with everybody and @0xYtocin ideas.

Cheers mate


I don’t know much about github, but only these three people are able to modifie the list at the moment?

1 Like

Forks and Pull requests :slight_smile: Fork a repo - GitHub Docs


I totally agree with both of you that we need to find a less bureaucratic solution for the DAO to update this allowlist database.

I’ll be honest, I didn’t fully understand the use of a scrypt to automate all or part of this process.
So I’m going to take a step back and let the relevant people have their say, potentially in a new research post or a new proposal.

If you’re OK with keeping this (nonetheless important) topic for later, I’ll update the proposal by adding the Github request for $CAPS and do a temp check this evening to launch a vote on Tuesday.
Some of the requests to add tokens are long overdue and I don’t want to fall further behind.

1 Like

Hello everyone,
proposal updated with the latest missing github issue.

This message is worth a temp check as I plan to post it on snapshot next Tuesday.
The temp check will be relayed to the discord at the end of the day.


Vote live on Snapshot: Snapshot


Hey guys,
looking for a contact to have an ETA for the allowlist update.


WHENNNNNNNNNNNNNNNNN ? Adding tokens is already a real hassle, but if nobody does it once the vote is over… I don’t know how we’re going to attract users to add volume.


A Pull Request on the Github is going to be needed to be able to execute this vote, similar to the last token list update

It might be good to use this to begin exploring ways to expedite token inclusions as discussed above!


Will ask on the discord for review of this PR: Pip47 by albist · Pull Request #27 · paraswap/community-token-list · GitHub

1 Like