Name: Spinning out RenBridge
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.
As of this writing, the Ren community finds itself embroiled in debate between three funding proposals 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.
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.
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. 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.
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.
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.
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.
zeroDAO could be used to expedite these transfers for users and RenEVM apps in the same way. ↩︎