I did have some ideas, but all the options I could think of make the process more complicated and involved, hence I added the note about only crossing that bridge when we have to.
With that being said, some options in no particular order:
- Every round there will be an additional snapshot vote to choose which tokens to cull from the pool. Additional conditions can be added here, such as only creating this vote if there are more than x tokens in the pool, and culling the top #y or z% of tokens based on the size of the pool. A minimum threshold can be added as well and the option to not cull anything.
- Tokens that do not receive any vote, or <x% of the vote can be culled. This can also be combined with a threshold of a certain number of rounds.
- Instead of tying it directly to the whitelisting process, a separate process can be added. This can be in the form of a standardized RIP that can be proposed at any time by anyone to cull one or more specified tokens from the pool. A simple yes/no with majority rule could suffice here.
Regardless of the process, with any culling of tokens from the pool we also need to think about how tokens (if ever) can be proposed again and reintroduced to the pool. Personally I think that culling tokens from the pool should not be the same as banning tokens from all consideration in the future. Tokens might simply be culled from the pool right now because we already have 30 tokens that are higher priority, however, due to different reasons the token might be better positioned several months/years later, at which point there should be a path to reconsideration.
The only viable option for reintroducing culled tokens to the whitelisting might be the regular RFC/RIP process. Let me try to explain my thinking as to why:
Basically for reintroducing tokens back to the pool there are two major flavors of process that I see, one is āalgorithmicā where the process simply states that if a token is culled from the pool it can only be reintroduced after x amount of time has passed, e.g. 6 months. The second is a social governance process, where a previously culled token can only return after passing a snapshot vote.
The second option opens up a host of other problems, every token that has been culled might want to immediately try to āappealā that decision through this process, additionally, if a token fails this vote as well we are back at square one when considering the process for reintroduction at a later point.
A fixed time-out period also has a major problem, namely that in exceptional situations the circumstances might have changed within a short amount of time as to justify short circuiting the fixed time-out period. In that case we are back to where it always comes down to in the end, which is that the pre-defined governance process can always be amended/circumvented with a new RFC/RIP process.
Hence we can keep this part simple and say that if a token is culled from the pool it does not qualify again for the automatic Typeform fast track process, but has to go through a manual RFC/RIP process to get in to the pool. Adding culled tokens to a āTypeform blacklistā here can also prevent spam from said tokens.