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.
I’m opening this research thread to:
1/ gather and evaluate the requests to add tokens (check if it’s not already in the allowlist)
2/ once a list is settled, add Github requests here for devs to check.
3/ Once the check is done, create a proposal.
I think allowing this thread to fill up over a week or ten days would be sufficient, and would allow the actions required for these changes to be taken into account for the current epoch 3.
Feel free to add tokens you would like to see added in the thread replies or any other comments.
First tokens proposed according to discord feedback:
Hey there,
following discussion on the discord, we could simplify the integration of tokens in the allowlist via a systematic authorization for tokens entering the top 100 of the marketcap (as listed by coingecko).
This does not prevent one from proposing tokens that are not in the top 100 but this should decrease the need.
Also, although the entry in the allowlist is automatic, the top marketcap is dynamic and some tokens will leave it (permanently or not). It is proposed to vote to remove tokens from the allowlist when they are identified as not meeting the requirements.
The question arises as to how easy it is to observe and analyze the list.
Indeed we have to find a way to automate the listing of token on paraswap in order to always offer to the users a maximum of possibility of swap between X token.
However, I’m not sure of the interest to delist tokens that are no longer in the top 100 or for another reason Y.
Let me explain:
Outside of the top 100 there are a lot of tokens including one of the best (the PSP ^^) that are not in the top 100 but are still good products with a growing interest in trading these tokens. If we were to remove these tokens from Paraswap, we would automatically impute volume and actor who will no longer be able to perform swap on it. Is there a real interest for the protocol to delist a token? (for reasons of database overload or other) I am not a programmer so I ask the question
Because according to me, the more we will propose choice to our users, the better our retention of them will be and we will also be able to increase this base.
In my head, when I was transcribing the discord’s discussions, I was rather seeing the Blacklist or delist in extreme cases where the token/project has really dropped out.
That’s why I didn’t specify the “requirements”. We could imagine delist when they fall under a certain level of market cap.
Like automatic allowlist if top100 market cap, automatic delist if below top 400, 500, etc to be defined.
Manual maintenance of this list seems complicated, we would just have to find the right criteria to allow a dynamic and automatic evolution of the allowlist.
It looks technically feasible and I would prefer to favour the foundation over third parties where possible. We just need to know if the foundation has the capacity (in time) to make this type of change if the discussion goes to the proposal and the proposal is voted on.
Thanks for your feedback I understand better the part about removing a token.
Indeed, the reflection must turn around how we can automate the entry and exit of a token from the list in an automated way by defining the criteria upstream as you say.
Does this allowlist could not be maintained by the paratroopers?
The idea of automatic whitelist is good but it’s an optimism way to handle it The time to react to remove from it a token could be too long and exploited.
I would prefer to see paratroopers maintaining this list and have approvals access to the github repo that have this list (If 50%+ of the paratroopers approve the PR then it’s automatically merged)
If allowlist and blacklist are handled automatically via marketcap threshold information, wouldn’t that be faster than if this monitoring is done by humans?
(Still, these thresholds have to be well chosen)
It’s depends how far the list is and reliable.
But in the top 200 TVL token their is some “shitcoin” like Luna
The automatic way bring also more questions:
What will be the refresh rate (every hours, days, epoch?)?
Does it will removed all tokens not listed in the first X TVL?
At the end we can have a part of automatic refresh list using TVL rank and having manual whitelist list handled by the Paratroopers/Team for specific tokens like PSP (not in the top 500 TVL), etc.
I would also suggest to add into this list protocol’s tokens from partner (they bring user + paying fees would be logical to me to whitelist them)
The discussion on the discord was about using the coingecko data. You know better than I do if it can be a problem of responsiveness or not ^^
I saw it like this:
The system automatically adds all tokens that enter the top 100 market cap in the allowlist.
The system automatically removes all tokens below the top 150
The system makes this update on the first day of each epoch, so that the conditions for obtaining the paraboost are clear for each epoch to come.
I generally agree with you, automating the allowlist / blacklist :
It should be done with criteria that allow the integration of tokens in accordance with the social escrow (I put 100 and 150 in the example above but it is to be discussed).
Does not prevent from identifying and integrating tokens that do not meet the automatic criteria but that have an interest for the DAO / the protocol / the social escrow (your example of partners is very good).
Does not prevent the blacklisting of tokens that are no longer in line with the social escrow (whether they meet the criteria or not).
Basically 99% of the work is done by an automatic system whose thresholds are defined by the DAO.
Special cases raised by the DAO or the Paratroopers and which would be added or removed by going over the automated system.
A certain autonomy can be voted for the ParaTroopers so that they can make the PR of these particular cases without a vote of the governance.
I would see the proposal as :
1/ Voting the implementation of the automatic system for the allowlist / blacklist according to the marketcap (to be defined)
2/ Take advantage of the vote to add tokens in line with the social escrow but which do not meet the criteria of the system (partners, etc)
3/ Vote on the possibility that ParaTroopers can manage future special cases without a governance vote (special cases are in any case checked a second time by the foundation when it accepts the PR or not).
What do you think ?
(Of course I write a lot but the feasability needs to be confirmed)
I mainly agree with you.
I’m just scare that we are putting to much effort (dev + teams + gov) on it for something that can be handle by the ParaTrooper in less than 2 days by doing it manually as it is.
Honestly don’t know the work necessary to implement such automation.
Some feedback would be appreciated here to assess if it’s a dead end.
Thing is, I’m not sure it would be so easy for ParaTroopers to manually update the list (unclear for me on the method to use by hand).
Also, ParaTroopers purposes still need to be shaped more clearly, will they have the time for such purpose?
At least, at the moment, we have those two options:
Automation + Paratroopers for special cases
100% handled by ParaTroopers with delegated power to allow/blacklist without governance vote.
Yeah It’s something that should be discuss but seem logic to me. As soon the list is initialized it would not be a day to day job I think. But with the automatic way It could be boring to follow the blacklist tokens, and check at each refresh that they is nothing wrong.
following up on this as I’m finalizing the proposal to update the allowlist.
After checking, the Ethereum address is already in the list there: https://raw.githubusercontent.com/paraswap/community-token-list/master/src/sources/tokens/mainnet.json
So I won’t include it.
But the bnb address isn’t, so it will be included there. One doubt tho, is the low liquidity on bnb chain for this token making it eligible for the allowlist?
The time to react to remove from it a token could be too long and exploited.