Name: Token whitelisting process
Category: Governance, protocol
Scope: To establish a token whitelisting process governed by the Ren community
With host-chain to host-chain bridges coming online soon, a vast amount of new token assets can be supported by RenVM. To provide the best user experience for everyone involved (the users, third-party integrators, darknode operators, and the core team itself), the addition of new token assets has to be done at a measured pace so everything from the darknodes, the RenBridge, the Command Center and other supporting services have time to update and track the new assets that will be onboarded through RenVM. A decentralized governance process is necessary to manage and prioritize which tokens to get integrated with RenVM at any given time, and potentially which tokens to get removed for whatever reason if necessary.
There are many layers to what makes the Ren ecosystem successful. For example, RenVM by itself is not useful as an interoperability solution if there are no proper user interfaces to interact with it. It would not be comfortable if users had to manually connect to the RenVM network and generate a deposit address and then deposit to it and submit the right signatures to RenVM, and then getting the hashes back and then submit them to the right contract on Ethereum to mint the deposit. That’s why we have something like RenBridge that bakes all of that functionality into a simple interface that automates all of those steps.
It would also not be robust if there was no Command Center for darknode operators so they couldn’t easily manage their nodes and withdraw rewards.
So while RenVM could very rapidly add support for new tokens, there are a few other tasks that also have to be done to add these new tokens to the Ren ecosystem successfully:
- Each token’s contract need to be vetted to make sure there are no obvious exploits in them that could hurt user funds and hurt the reputation of Ren
- Each token needs a contract deployed per host chain (6+) so that the wrapped version can be minted there
- Darknodes need to update to a new release that supports the new tokens
- Adding the new assets to RenBridge
- The Command Center needs to display volume and stats for the new assets and allow DNOs to withdraw rewards for the added tokens
- Token logos for the wrapped tokens need to be created and we need to do pull requests to multiple token lists across the crypto ecosystem to make sure wallets and UIs can track the assets automatically
This doesn’t mean that RenVM won’t be able to support most tokens that community is in support for, it just means the initially selected will be highest priority assets first based on volume and what the Ren community values the most.
Initially the Ren team will add a first cohort of tokens supported through RenVM. But immediately after those are added and a proper pipeline for adding new assets is established, the Ren community will take over the governance of which assets to add.
The current draft for how this listing process will be managed is as follows:
- A person fills in this Typeform which asks for some basic details about the token like the contract address: https://renprotocol.typeform.com/to/Y2vKNVk4 (this info will be published on the forum for everyone to see, hopefully by an automatic service)
- A token that passes the base restrictions* would be added to the pool of tokens that currently is under consideration to be integrated with RenVM
- Each month, there will be a Snapshot governance vote, where DNOs would vote on the tokens they think should be integrated with RenVM. The top 5 tokens would then be added that month (the number 5 is arbitrary for now, it will later become clearer how many tokens can be added in one go)
- Rebase tokens are not supported by RenVM currently (rebase tokens that are wrapped in a stable ERC-20 format are supported though)
- Non-standard tokens deviating from the regular safe ERC-20 format, for instance using built-in transfer burn functions, might not be supported
The community might want to establish delisting criteria, e.g. a token which has not had any volume for X long length of time might be considered to be delisted as it only adds unnecessary work for the protocol to maintain.
It should be considered by the community whether something like a listing fee that goes to the Community Ecosystem Fund for integrating a token with RenVM makes sense in some situations (a listing fee that could go to liquidity bootstrapping that token on a new chain).
- Work out the token whitelisting process
- Vote on it
- If accepted, update the governance process