RFC-000-047: Spinning out RenBridge

[DavidPerkins]

Name: Spinning out RenBridge
Status: Draft
Scope: Fund the deployment and development of Ren 2.0 by committing to a layered security model and offering a new token that would be used to secure RenBridge’s signer chain.

Overview

As of this writing, the Ren community finds itself embroiled in debate between three funding proposals^[1] that would all impose a tax on Darknode operators and, at best, modestly reduce the security of Ren 2.0. This RFC reintroduces a new kind of security model first proposed in RFC-000-039: 2FA for App Chains and explores how this model could fund the deployment and development of Ren 2.0 and increase its security without inflating REN or diluting Darknode revenue.

Instead of being secured by Darknodes alone, wrapped assets like renBTC would be secured by a 2-of-2 multisig scheme shared by a threshold of Darknodes and a threshold of third-party nodes bonded by a new RenBridge token. This would isolate the bridge’s TVL from attacks on RenEVM, allow more funds to be locked safely, and generate more revenue.

A new RenBridge token creates an opportunity to raise funds without needing to print REN to raise short-term capital. To avoid diluting revenue, each current Darknode operator could be airdropped the same number of RenBridge tokens as they currently have bonded in REN, which would allow them to operate the same percentage of RenBridge nodes as Darknodes. The remaining supply would go to new investors and the Ren Foundation.

Layered Security Model

The layered security model allows apps to custody their own multichain assets (like BTC, ERC20s, etc.) with an extra layer of security provided by RenEVM. Why would they want to do this?

First, it isolates risk. If RenEVM’s TVL became bloated relative to the total value bonded by Darknodes, it could increase the risk of attack on RenEVM and affect the security of all RenEVM apps. Layering security between Darknodes and RenBridge nodes, which would require corrupting two different sets of nodes secured by two different tokens, would isolate the bridge-related TVL from the rest of RenEVM and reduce the risk of it being stolen.

Second, it allows apps to safely lock up more value. RenBridge could safely scale its own TVL up from zero without contributing to a bloated TVL that would increase the risk of attack on RenEVM. This also allows RenEVM to scale its TVL horizontally over many apps by far more than it could by scaling vertically on its own, which would generate more revenue for Darknodes and provide stronger security for apps.

Graphic adapted from Why Solana?

Third, it allows apps to internalize more revenue for their own token holders that would otherwise be leaked to RenEVM and other bridges. While Darknodes would share revenue with RenBridge nodes for RenBridge transactions, giving third-party applications a revenue stream for token holders is ultimately in RenEVM’s long-term interests.

Implementation

RenBridge would be responsible for securing, minting, and releasing all wrapped assets on external chains. While the application would be deployed on RenEVM, Darknodes and RenBridge nodes would each perform their own MPC to generate a signature as part of their 2-of-2 multisig scheme.

If a RenEVM app (“Acme”) wanted to mint renBTC on a host chain, it would need to send its underlying BTC to the RenBridge gateway address.^[2] Acme would levy a burn fee while RenBridge nodes would levy a mint fee, each split with Darknodes. Any minting and burning of renBTC or other wrapped assets by either end users or other RenEVM apps would generate revenue for Darknodes and RenBridge nodes.

Safety

If a corrupted threshold of Darknodes were to forge a release signature or produce an invalid state transition that tried to release assets, RenBridge nodes could simply reject that state transition and refuse to provide their own signature.

Likewise, if a corrupted threshold of RenBridge nodes were to forge a signature to steal assets without witnessing a valid state transition on RenEVM, Darknodes wouldn’t honor it.

Darknode operator benefits

Conducting an ICO for a new RenBridge token would obviously not require printing any REN. And while a new network of RenBridge nodes means that Darknodes would be sharing their revenue, that doesn’t necessarily mean that Darknode operators would.

To prevent Darknode operators from being diluted of their RenBridge revenue, they could be airdropped the same number of RenBridge tokens as they have bonded in REN. This would let them operate the same percentage of RenBridge nodes as Darknodes and earn the same percentage of RenBridge revenue. If 20% of REN were bonded in Darknodes, then 20% of RenBridge tokens would be airdropped to current operators. If an operator bonded 1% of that 20%, then they would be airdropped 1% of 20%. The remaining 80% would be left to investors and the Ren Foundation.

Ultimately, the goal would not only be for Darknode operators to collect an airdrop and circumvent inflation and revenue dilution, but to enjoy a net increase in revenue thanks to a more secure and decentralized RenBridge.

Legal

Disclaimer: I am not a lawyer and this is only my interpretation.

External RenBridge token investors would expect their funds to be used exclusively in the interests of RenBridge. So how could those funds be used to fund the deployment and development of Ren 2.0?

There would only be a breach of trust if funds were used in a way that were not essential to or outside the scope of RenBridge. As part of the layered security model, all Ren 2.0 code would be essential to RenBridge. It would just be the case that Ren 2.0 were developed to be generic enough for other applications, which would still be in RenBridge token holders’ interests based on the proposed implementation above.

The only “not essential” use of capital that I can think of would be salaries for non-developers working on Ren-specific operations, designs, etc. But the Ren Foundation could fund those salaries by itself through a more modest inflationary policy.

---

1. A revenue-based fundraise, an inflationary fundraise, and an inflationary fundraise that withholds revenue to buy back and burn REN ↩︎

2. zeroDAO could be used to expedite these transfers for users and RenEVM apps in the same way. ↩︎

[ALPHA]

I vote for this! Perfect

[JAVB1]

Massive fan David, strongly support your vision here. Sounds like funding is taken care of, DNO’s won’t suffer dilution and Ren 2.0 gets even more decentralized. What more we want! Great stuff!

[Amaguq623]

nice work on this.
question, more on optics – term ‘bridge’ seems to be relating to a hackable weakness in the marketplace. Is there a better token name that would relay the value of the Ren Project as a total platform?

[r3lik]

Big fan of this well thought out proposal, David!

A few questions about some of the implementation details:

@DavidPerkins

Instead of being secured by Darknodes alone, wrapped assets like renBTC would be secured by a 2-of-2 multisig scheme shared by a threshold of Darknodes and a threshold of third-party nodes bonded by a new RenBridge token.

The 2 of 2 here is really some “t of n” TSS for both Darknodes and RenBridge Nodes?

@DavidPerkins

The layered security model allows apps to custody their own multichain assets (like BTC, ERC20s, etc.) with an extra layer of security provided by RenEVM

How would this work? Are you saying that assets like BTC, which today are held in a single multi-sig wallet controlled by Ren and trusted partners (I think), would be split up by application?

Thanks again for your thoughtful work!

[DavidPerkins]

Exactly. Assets would be secured by a 2-of-2 with each party a t-of-n.

[JohnAnthony]

A brilliant solution. I endorse David’s proposal seems to be the best of all so far.

[martign0]

I like this idea from the technical point of view, but I am really concern that could be seen as other way to inflation. The total marketcap could be perceived as the sum of both tokens.

The idea is protecting current DNO thru the airdrop but that could be also accomplished by sharing with DNO part of the inflation that is being currently proposed.

Unless…. Could the additional token bring any value in terms of security? What would be different by bonding Ren in both (RenEVM & RenBridge) than having a different token with its own tokenomics for renBridge???

[shiny]

Some thoughts,

If voted on and implemented, how much extra development time would this incur (of course approximately). How much complexity does this introduce that while providing extra security in one way, can open doors in other areas to attack

I think if airdropping to darknodes, the nodes should commit to a certain extended lock up period to prevent gaming the system. Otherwise you will get the double whammy of a number of nodes deregistering, selling their tokens, as well as selling the new renbridge tokens. Maybe even a weighted airdrop with nodes electing longer lock up periods getting a larger share of the airdrop (and even current nodes given a share of it based on time registered as well). I am not just trying to get more tokens for myself, but wanting to put these tokens in the hands of those interested in long term health of Ren.

Performing this investment round first would be good, and based on results we could then determine how much inflation of Ren tokens would be necessary to provide adequate long term resources. With Ren being used as gas in the new network, I think some inflation without any deflation is acceptable as demand for Ren token will be higher for gas fees and we still need adequate supply for nodes.

[Wake_222]

I like the idea the only question is whether you can find investors.
Why would anyone invest in the Ren Bridge Token instead of investing directly in the Ren Token?

[Amaguq623]

there will be a significant amount of deregistration anyway. It’s an uncertain transition period which will scare people off.

I could certainly commit to some time period, although just a small fish in the pond here, but I’d do it to see a bigger reward on the back end (if this project can correct itself). You will still have the same core DN owners that have hundreds of nodes. Granted, if we see two thousand nodes deregister in the next 7 days, then it’s basically a bail from everyone, although that would just make the value of Ren token almost zero if everyone sold out at once.

Large amount of uncertainty at this point in time.
I still think Ren is cool as hell idea for defi, so I’ll probably ride this out one way or another.

[hosermage]

I’m in support of this, thank you David. This seems similar to parachain or subnet concept, where there’s a primary chain sharing/guaranteeing security of the subnet/parachain. The renbridge is essentially a specialized app on its own subnet with its own tokenomics and TVL. DNO’s being the OG of Ren serve as the primary umbrella of security.

I have a question on tokenomics though. The current ren tokeonmics are simple which is why its great. Bonded darknode operators get a cut of mint/burn fees. Will renbridge cannibalize fees from DNOs? If there will be a split of fees, wouldn’t this simply be another form of inflation with extra steps?

[Renindy]

Fully support the proposal. Well done David, really appreciate the effort and though put into this

[Elmante]

Great RFC. Wise, smart ideas. I vote for this

[MaxRoszko]

Important to note that if this approach is taken, the community would need to find and choose someone appropriate to lead fundraising for the spinoff, as the Ren dev team can’t lead it (although we would be happy to help with the technical side after a raise). It would also significantly alter the roadmap for Ren 2.0 due to technical changes needed, likely delaying Ren 2.0 by months.

[ALPHA]

Well, your points are valid but can be sorted even if the REN 2.0 is delayed for months. What is most important here is the core concept of this proposal is much stronger and better than all other ones. Again I vote for David proposal.

[valerio_mc]

Hi Max,
I really appreciate all the work the team is doing and I can’t imagine the kind of pressure you’re working under on.
However in a context like this time is essence and clear / transparent communication is fundamental to build trust.

Your proposal is Ren2.0 oriented, however a lot of details and roadmap is mssing. If you combine this uncertainty with the lack of communication, trust in the current team is at risk. Why are you saying “the Ren dev team can’t lead it”? Why don’t you explicitly report the legal implication / commitment the Ren Dev Team has / had with Alameda?

David proposal, as of now, is the only solid and well explained proposal we’ve seen so far. However, if Ren2.0 deployment is further delayed, I would opt in for the immediate inflation proposed in Max RFC.

[Wake_222]

@MaxRoszko

Important to note that if this approach is taken, the community would need to find and choose someone appropriate to lead fundraising for the spinoff, as the Ren dev team can’t lead it (although we would be happy to help with the technical side after a raise). It would also significantly alter the roadmap for Ren 2.0 due to technical changes needed, likely delaying Ren 2.0 by months.

People, wake up. How long are you going to think about your own wallets?

• We’ve seen on Twitter that curve is interested in Ren 2.0, which is a very good sign. That there is simply trust, but that will also change at some point in terms of time.
  There are too many interesting solutions and if you only look at yourself and is like in a tunnel, it may well be that you end up losing almost everything.

• We have recently heard statements from zeroDAO where they themselves said if it takes any longer than the current roadmap which claims to have Ren 2.0 on the mainnet in Q1 23 they will have their own solution.

• You have to decide if you want the best for your own wallet in the short term or if we want the best for Ren 2.0 in the medium and long term in terms of volume and adoption.
  Which in the end will bring much more than no dilution but a low Ren price

• David’s idea is good but that you can always add later currently the focus should be 100% on development and funding for that.
  We should look to hire additional developers.

• The team has come up with a proposal that is the best for Ren 2.0 and development. Whether we like it or not we should accept it so that together we can have the best success.
  The community alone brings nothing and the team alone brings nothing.
  It is a togetherness.

[MaxRoszko]

@valerio_mc

Your proposal is Ren2.0 oriented, however a lot of details and roadmap is mssing.

With the inflation approach, the roadmap is basically what was announced in the Ren 2.0 announcement.

The changes are that the Ren 2.0 merge is no longer needed given that 1.0 will already have been sunsetted. There would also be a slight delay given the current situation, but it’s still the same roadmap, get testnet out in the next months and then work and test it until a mainnet version is safe to go live.

If this spinoff RFC is chosen, then the Ren dev team does not know when Ren 2.0 could be live, it would likely delay everything by many months as it would require further technical developments to Ren 2.0. It’s also an open question who would lead that fundraising and how long that itself would take, as the Ren dev team cannot do it.

Regarding missing details for RFC 046: the point of that RFC was to start the discussion on a way forward that the dev team found realistic and viable, with details to be settled together with the community.

[Ingalandia]

I do like most of this idea and appreciate the thought you put into this.

However 2 tokens I think would introduce unnecessary complication for traders and investors.

IMO people won’t know which asset to invest in as a speculator and may shy away from it.

I think this same idea, but with inflation of REN + an airdrop to DNOs would end up being a simpler path in the long term.