RFC-000-004: Onboarding new token support and blockchain integrations

Requests For Comment | RFC
1

Name: Onboarding new token support and blockchain integrations
Category: Protocol
Status: Draft
Scope: To kick off discussion about how we select new token support and blockchain integrations.

Overview

This RFC aims to initiate formal discussions with the community to determine the proper framework for analyzing and onboarding new blockchain integrations and collateral types in the future as the multichain is later launched. I understand that this is still months out as the Ren development team is currently fully utilized, but hopefully, this can help illustrate the opportunity ahead of us.

From what I’ve observed in many other protocols, the selection process appears to be relatively unstructured, arbitrary, and at many times, opaque. I hope with the Ren Project, we can differentiate ourselves with a leading class framework. If we aim to be the de facto cross-chain interoperability bridge for the crypto world, it is imperative that we have a robust framework to provide the greatest value for our users and the protocols of the destination chains.

To do so, I hope to set a strong foundation of guiding principles in order to vet and prioritize support/integrations based on:

  1. Community interest
  2. Impact/potential market size
  3. Ease of implementation

I invite the community to voice their opinions on how we best fine-tune these criteria and the prioritization framework.

Background

At the onset of RenVM mainnet launch, we supported 3 renAssets, renBTC, renBCH, and renZEC. BTC was the obvious golden choice; however, I believe BCH and ZEC were selected to demonstrate the relative simplicity of integration of assets of similar nature of previous integrations. In other words, once the BTC was supported, BCH and ZEC support was relatively straightforward.

Since then, there have been many discussions of new coins and chains in Medium articles and the Github. I’ve listed them below, please let me know if I’ve missed any:

Tokens in Progress (TBC)

  • Dogecoin (DOGE)
  • Digibyte (DGB)
  • Filecoin (FIL)
  • Polkadot (DOT)
  • Acala Network (ACA)

Blockchains

  • Binance Smart Chain (BSC)
  • Polkadot (DOT)
  • Solana (SOL)
  • Cosmos (ATOM)
  • Terra (LUNA)

Other potential tokens

  • Stablecoins: (USDC, DAI, TUSD, etc)
  • Ripple (XRP)
  • Litecoin (LTC)
  • Bitcoin SV (BSV)
  • Dash (DASH)
  • Monero (XMR)

Details

To summarize the above Overview and Background sections, I propose that we align on criteria and consider establishing thresholds on those criteria.

1) New Token Onboarding

I hypothesize that users will find RenVM to be of greatest utility for:

  1. Store of value tokens with relatively high market cap.
  2. Communities open to interoperability
  3. Tokens adopted by dApps on destination chains

Drawing insights from our main data point: renBTC, renBCH, and renZEC on Ethereum, mint/burn volume appears to be a function of market size, community interest, and destination chain dApp options.

F(Mint/Burn Volume) = Market size * Community interest * Destination chain dApp options

To support this function, ZEC market size is ~$733M while BCH is roughly 6.2x larger at ~$4.6B. However, there is actually 1.16x more renZEC volume than there is renBCH volume. I believe this to be the case as the BCH community has shown minimal interest in the Ethereum blockchain let alone any sort of interoperability solution while the ZEC community has recently become more interested. The key takeaway from this example: token-maxi communities such as BCH are less likely to utilize RenVM than relatively more open-communities with lower market size.

Finally, aside from BTC being the largest market size by far (~$200b), renBTC is also much more widely adopted in DeFi protocols allowing for more utility.

For reference, protocols such as Maker, Curve, and Aave appear to loosely use the following criteria for their own onboarding:

  1. Market size of token (in Ren terms: volume minted),
  2. Quantitative Risk: Token price volatility (for vault stability and Loan-to-Value ratios (LTV)), and
  3. Qualitative Risk: Smart contract and counterparty risk (because as tokens are onboarded, risk flows through the protocol).

In theory, protocols should adopt all renAssets as each renAsset (3) shares relatively similar low risks, but until then, (1) volume and (2) price volatility appears to be their largest deciding factors.

For the Ren community, it makes sense to assess factors that we can relatively control: community interest, market size, and ease of implementation. I’ve made a table below of an example of how we might assess and prioritize. Due to my lack of technical background, I’ll leave the last column blank.

Token Community Interest Market Size as of Oct 13 Ease of Implementation
USDT TBD (Likely high) $15.23B
XRP TBD (Interest shown) $11.62B
LTC TBD $3.28B
BSV TBD (Likely low as BTC forks tend to be maxi-type) $3.16B
USDC TBD (Likely high) $1.4B
DAI TBD (Likely high) $0.45B

2) New Blockchain integrations

As non-Ethereum based DeFi protocols are still in development/have yet to be widely adopted, it’s difficult to provide historical assessment. However, the high-level factors here should include

  1. Chain adoption measured by users and value and
  2. Security robustness/risks of the chain.

Conclusion

I hope the structure and examples that I laid out help the community in determining an appropriate framework for the vetting and prioritization of tokens and chain integrations in the future.

Outstanding thoughts:

  1. Section 1 Variable 2 above: Community interest can be stoked with a balanced outreach approach. These approaches should be based on facts and taken with a collaborative energy
  2. Section 1 Variable 3 above: renToken adoption by dApps on destination chains is something the Ren team and we as a community can further support. There are 3rd party governance proposals that we can create and support to garner wider RenVM adoption.
  3. Currently 0.63% of BTC is on Ethereum, ~20% of which is by RenVM. That’s 0.126% of BTC currently minted as renBTC (not including mint + burns that have removed renBTC)… If we were to capture 0.126% share of the coins I’ve listed above, that would be $48M in volume (not including mint+burns that have removed renBTC)
  4. Further on point 3: Total volume appears to be roughly 3.25x the circulating supply (981m vs 302m currently in RenVM). This means mint+burn of the 48M could potentially reach $156M additional volume for RenVM in just the 5 month period assuming similar rates of adoption.
  5. Points 3 and 4 do not even consider the upcoming cross-chain volume to come from the burn+mint mechanism.
  6. With the launch of the multichain, onboarding new assets may be much smoother/easier than many of us realize. We wait in anticipation for the launch and additional information. (This applies to the ease of implementation column)

Implementation

Nothing to implement yet. I believe additional information will come as the Multichain is released

12 Likes
2

I think it’s a good idea to develop an objective framework for a set of minimum integrations requirements.Its creates transparency within REN and also lets potential integrators know the terms up front.

It also gives ambassadors the information needed to proactively “sell” REN.

In addition to the factors stated above I think its important to also assess integrations based on:

  • An objective measure of project quality

  • Longevity of project / proven utility

2 Likes
3

First of all, I think this is a very nicely laid out proposal to help the community think about what priorities, it helps to establish value factors that can help the DN community organize their thoughts and direction. I do think however that the goal of true interoperability would be to bridge all chains, all assets, in every direction.

I think at this moment (10/2020), the clearest path has revealed itself, and that is RenVM needs to prioritize being the first to bring BTC and ETH to all blockchains. The faster and first to market we are able to accomplish these goals, the stronger footing we will have to raise fees and provide superior services to, and further attract developers to build new apps that utilize the RenVM network.

Other tokens are nice to move around but looking at the current volume through the network these communities are either unwilling or unaware that they are able to put their tokens to work in the DEFI world. Marketing and outreach can address this, but that is a separate matter.

2 Likes
4

Agreed. Being the/a primary choice for wrapped Bitcoin and Ether on all host chains is the largest opportunity. Stablecoins are potentially huge, but the various centralized entities can isssue their own on the chain if there is sufficient demand. Tokenizing the long tail of assets is a longer term goal and less immediately beneficial. There are likely many other large caps to bridge with a strong positive value, but smaller caps should wait until Ren is more decentralized in terms of development to not tax the team during these critical early months. In the future with open source contributions, other projects can build their own integrations to be reviewed and approved by Ren governance.

Even if the multichain platform makes the dev side easy to integrate, we need a review of the chain’s security.

1 Like
5

@preston, et al.

I agree fully with both of you. An analysis of our income shows and embarrassingly simple conclusion: BTC/ETH is all that matters.

I understand people feel passionate about other chains. However, if 99% of my money is coming from BTC<->ETH transactions why should I support those other chains?

We would probably see more income by advertising “Swap BTC for ETH with REN” on banner ads then from doing anything else.

I think @DeFiFrog also brought attention to an important point: Every new integration brings 2 risk:

  1. Each new integration possibly introduces vulnerabilities to REN

  2. Each new integration uses valuable REN developer resources.

One way to think of it: If you ran a local diner and 99% of your income was pizza / beer, would you: (a) Add more pizzas / beers to the menu? or (b) Add kale salad and soy drinks?

2 Likes
6

I like the analogy you use. To expand on it, imagine it is 2010. Some businesses see consumer taste preferences are changing. Some adapt to provide healthy goods… the organic craze sweeps in. Who laughs now? The restaurants with kale, soy, and cold pressed juices charging 3x your pizza for 1/2 the cost.

We need to think more than just what we are doing now. We should think what else can we do with RenVM? Do we want to turn Ren into an advertising shop that only focuses on BTC → ETH or do we want to think about the next steps? I hold the belief that companies survive through differentiation or cost efficiency. To my knowledge, RenVM doesn’t appear to have great cost reduction opportunities as it seems efficient (it’s code + distributed computing network), so let’s focus on expanding the menu and differentiating. Wbtc, sBTC, tbtc - none of them have the capabilities we have, yet. Let’s capitalize on that.

Also, this is different from a restaurant. Customers don’t have to choose one dish over the other. Customers can eat as much as their bags have coins that they want to use on other chains. We are not diluting our value by expanding our menu.

Yes, the revenue is clearly coming from BTC. However, it would be naive for us to assume that this would stay the same forever. We can always create the opportunity for larger parts of the revenue pie to be of other assets.

Finally, to this point, we should remember, respect, and align ourselves to the vision that the Ren team has set forth. To my understanding, the Ren team did not create RenVM to transact BTC on Ethereum full stop; they created it to enable universal interoperability… empowering multiple chains (multichain) and unleashing liquidity across each of them… allowing users to interact with dApps and innovations within other ecosystems aside from their own. That’s the beauty of interoperability.

(Also, as your comment appears to be monetarily focused, let’s not forget that stablecoins present a lucrative opportunity.)

1 Like
7

Can you expand upon the technicalities of that? So if someone has USDT (Tether) which is available on ETH, BTC (Omni / Liquid), and TRON blockchains. How does REN help out? I’m not disagreeing however just struggling to understand.

If someone had LINK and wanted USDT why would they choose anything but the ETH/ERC20 version?

8

Hypothetically and speculatively, Ren should be capable of enabling ERC-20 stablecoins in blockchains that don’t currently support it. (Substrate?)

9

I think we need to realise that what is so today will not be tomorrow. Integrating every chain worthwhile is an investment in the commerce those chains could potentially do in the future. There is no telling what a Polkadot or Cosmos would look like in 3,5,and 10 years.

Cross-chain transfer can be seen as just the base primitive of a much broader vision that could one day enable native smart contracts built right on RENvm. At steady state, dapps may be able to build and host value on Ren and access any chain the want for specialized computation or to transact for a period of time before retreating back to REN.

The proof of reserves collaboration with Chainlink leads me to believe there will be a lot to this relationship over the years. Imagine what the leading oracle/data providers and the leading facilitators of cross- chain transactions can do together?

1 Like
10

I agree with this view, we can’t predict which chain will be popular in the future. And i think the team is taking the right approach by building the tools to be able to add new chains easily.

Even if the new asset/chain being added doesn’t bring much volume, we are acquiring their community and developers by supporting their asset/chain. That might not work out all the time i.e BCH but i believe the # of assets we support could be good marketing material.

@DeFiFrog you missed celo, avax in blockchains in progress, and you doing a great job, i appreciate the work you put in as a community member

1 Like
11

I would like to add BitcoinZ to this platform. I have no coding experience. Is this possible for me to figure out myself? What should I learn in order to understand the instructions on the github?

1 Like
12

I strongly agree renUSDT should be looked into as we enter the phase of multichain soon. Especially in the future when one can freely move renXYZ tokens between chains.

For one to be able to use renUSDT token universally instead of worrying about which chain’s version they currently have I believe will remove alot of friction and boost volume. Not to mention the crosschain functionalities it will enable within DeFi.