PIP-47 - Updating Token Allowlist for ParaBoost #2
Abstract
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.
Means
We propose to add the following projects and their token addresses in the specified Paraswap-supported chains to the token allowlists.
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.
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
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?
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.
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.
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.
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.
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.
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.
