RFC-000-023: Token whitelisting process

Requests For Comment | RFC
1

Name: Token whitelisting process
Category: Governance, protocol
Status: Draft
Scope: To establish a token whitelisting process governed by the Ren community

Overview

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.

Background

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.

Details

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:

  1. 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)
  2. 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
  3. 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)

*Restrictions

  • 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

Delisting criteria

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.

Listing fees

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).

Next steps

  1. Work out the token whitelisting process
  2. Vote on it
  3. If accepted, update the governance process
7 Likes
2

There’s a lot to unpack here but I want to call out one of the most consequential pieces aside from the actual UX for new tokens, which is the contract audit.

Is there an internal auditor @ Alameda that we can rely on or a firm that can be retained to do this? Perhaps someone in the community does this professionally.

This part we absolutely do not want to rush or skimp on in any way.

2 Likes
3

As a few have already stated elsewhere, relying on audits already done by groups such as MakerDAO and Aave is going to save us a lot of work. The team will also take a look at the contracts.

But also something important to note is that compared to these other projects where people are collateralizing and borrowing real money, in the RenVM case that isn’t that big of a worry as there is no value that can be extracted from RenVM by collateralizing a random token, only funds wrapped to another chain. In the end the token holders are the ones at risk holding some sketchy token. But I don’t think we want to enable sketchy stuff in general, and get our reputation mixed in up in a renSKETCH token exploit through the contract owner on Ethereum pulling something with the SKETCH contract, making renSKETCH holders on another chain rekt.

1 Like
4

Who is the “person” in this case? Presumably an interested party - i.e., a community member of the token proposed to be whitelisted?

Perhaps the precedent Typeform to be completed might extend beyond basic details and provide information on the token itself, the nature of the project to which it belongs, and so on? This is the approach taken with regards to whitelisting projects on Bancor and works well - not least because it helps voters contextualise their voting decision. I’ve also learned about new and interesting projects in that way!

3 Likes
5

Is there a benefit to doing this via Typeform, rather than having a subsection of the forum for new token proposals? This would allow the community to participate in due diligence or express their support/opposition at the earliest stage.

Speaking for myself, I would be happy if support for a token was added in epoch n and I could not claim rewards until epoch n+3. Fee revenue for new tokens is unlikely to be immediately significant and this would let integrators get to work sooner rather than later.

Do these contracts need to be deployed to each chain individually, or could there be a RenVM smart contract which can deploy to each of the host chains?

3 Likes
6

Open to everyone, can be a Ren community member also ofc.

7

I agree with this, think something similar to the multichain requirements would be nice, it makes it very clear what requirements renVM expects of projects who wish to be included and enforces a certain level of dedication from the projects side.

I would be against listing fee altogether BUT I am in favour of demanding a certain level of bootstrapping from the interested parties side, maybe that’s what you meant. Similar to multichain requirements mentioned above.

How would this work? basically disable minting for that token/coin and wait until everything has been burned? I like it, we need a way to gracefully remove as well.

In general very good post and definitely something that needs to be discussed imo, there are way too many in the telegram chat thinking this is a simple process and we should add everything possible so a nice guideline is a must imo to avoid never-ending questions.

1 Like
8

Yepp, minting would be disabled in RenVM but people could still release tokens back to the native chain, and maybe after some time and/or when there is only dust left, burning would be disabled as well.

9

Are you suggesting to charge a 0% fee for a limited amount of time to incentivize usage?

10

I suppose that excludes RUNE until the “tx.origin” vulnerability has been fixed

1 Like
11

No, I was referring to Max’s comment about claiming via CC not being immediately available. In that scenario I imagine the rewards accruing until the CC is updated to allow withdrawals. Decoupling “adding tokens to the protocol” from “adding tokens to CC” is worthy of consideration IMO.

1 Like
12

Out of curiosity which tokens will be supported initially?

13

Not decided yet, sometime in August we should know! :slightly_smiling_face:

14

@MaxRoszko any thoughts on my questions from last week?

15

The Typeform is only for better UX for the person submitting, and the submission will go straight to the forum, so there is no loss for the community to do due diligence here.

Each token needs their own token contract/address, that is unavoidable. The process for deploying these on multiple chains in parallel can be made fairly automated though.

1 Like
16

On the community call you mentioned that stable coins will be among the focus for the first cohort. I’m sure the team is mindful of this, but just want to mention that not all stable coins are without controversy. If there is any chance that they might be contested by the community, they should probably be deferred to the community whitelisting process.

edit: grammar

17

How do we see this working in practice?

If an audit has already been done by a different group such as MakerDAO or Aave, they pass automatically. If there is no audit yet, the team will perform an audit and give the green light on the forum before they can be added to the governance vote?

18

Please correct me if I’m misinterpreting this

  • All tokens that are added through the Typeform and pass the base restrictions enter in the pool
  • A Snapshot vote will be created that contains all tokens in the pool
  • DNOs can vote on a token (or mabye multiple?)
  • The 5 tokens with the most votes will be added in the coming month
  • The rest of the tokens stay in the pool, and will be part of the next Snapshot vote

Makes me wonder, should there be a way to cull tokens from the pool?

I can see it grow faster than they can be implemented, or tokens passing the base restrictions that have no chance of passing the vote because the community does not think it will result in any meaningful volume.

Or we can cross that bridge when it becomes a problem.

1 Like
19

Hit 2 birds with 1 stone. Have the new partner purchase REN in the open market by selling their tokens and then bootstrapping renToken with LPs earning REN by being an LP in renToken liquidity pools.

4 Likes
20

Not necessarily, always good to have a quick check and if some new exploit is commonly known that some old token has that needs to be considered ofc.

Someone needs to review the token contracts beforehand, the core team can handle that initially but would be good if we can get to the stage where that is perhaps done by some other group so the core team can focus on core RenVM development.

MakerDAO for instance has tons of different groups specialized on certain components of the whole system.

DNOs can vote on multiple, distributing their voting power.

Very good question if tokens should be culled, because there might be limits on platforms like Snapshot where you can’t fill it up with hundreds of voting options, and it makes voting harder because more tokens to choose between, so if you have any suggestion that would be very interesting to hear!

2 Likes