Name: 2FA for App Chains
Category: Protocol
Status: Draft
Scope: Increase Ren’s economic security by letting app chains provide a second signature on their own assets.
Disclaimer: I do not work for Ren Labs and have not confirmed the feasibility of anything below. These are just ideas.
Overview
This proposal introduces multichain wallets for app chains, which would be the third addition to Ren’s suite of multichain products alongside RenBridge and RenChain. Assets are secured by 2/2 multisigs shared between a gateway shard of randomly-sampled Darknodes and an app chain composed of third-party nodes. Safety is guaranteed unless 1/3 of the app chain and 1/3 of the gateway shard or 2/3 of the app chain alone are adversarial and coordinating. While Darknodes provide additional security, it is impossible for them to steal any assets.
Instead of renting security from third-party bridges, app chains could secure their own multichain assets and internalize that revenue for token holders. As each app chain scales its own value locked, more volume and fees accrue to Ren without increasing its TVL, making it an effective way to increase economic security across all of Ren’s products.
Graphic adapted from Why Solana?
Discussion
A multi-chain world full of tradeoffs creates a large design space for all kinds of interoperability. For example, smart contract applications run by a virtual machine cannot communicate with other blockchains and require a third party like Ren to do so. RenBridge and RenChain are designed for applications in this domain. In the Cosmos ecosystem, though, applications have a unique superpower: they control their own large-scale blockchains. How is this relevant to Ren? Well, RZL (Ren’s MPC algorithm) is specifically designed for use by large-scale blockchains.
This means that app chains could use RZL to secure their own multichain assets. Why would they want to do this? First, to guarantee to their users that assets are as safe as the app chain itself. Second, to internalize protocol revenue for token holders that would otherwise be leaked to third-party bridges.
“The real value of L1 tokens is just the MEV they can capture. So as an app developer, why are you leaking that value to some L1 token instead of capturing that as protocol revenue for your token holders? By having an app chain, you can internalize that MEV into your protocol.” - Sunny Aggarwal, EthCC[5]. Source
Why would Ren want app chains to secure their own multichain assets? In short, because it is volume that does not increase TVL. Since it would be impossible for Darknodes to steal assets, app chains would be strictly safer by layering their security atop Ren’s. So, this would look more like two-factor authentication for app chain wallets in which two decentralized custodians are safer than one but only one (the app chain) can convince the other (the gateway shard) to sign.
This security model would let each app chain safely scale its own value locked, regardless of how much value were already locked by Ren. If Ren were to take a fee on each mint and burn across many app chains without taking unilateral custody (TVL), it would strictly increase economic security for all of Ren’s products. The key would be to scale volume and fees horizontally across as many sovereign app chains as possible.
IBC vs. MEV
It seems like this product would create an opportunity cost for app chains to compose with IBC tokens minted by non-IBC bridges. If renting IBC tokens from non-IBC bridges leaks value that could now be internalized as protocol revenue by taking direct ownership of multichain assets, then a tradeoff may need to be made. I’d be interested to get people’s opinions here.
Safety
Safety is guaranteed under the following properties:
- That 1/3 of an app chain AND 1/3 of its gateway shard are not adversarial and coordinating
- That 2/3 of an app chain alone are not adversarial and coordinating
The first condition requires 1/3 of an app chain and 1/3 of its associated gateway shard to each reveal their underlying ECDSA private key and produce a cosignature out-of-band. Note that sampling into 1/3 of a specific gateway shard would be more expensive than sampling into any gateway shard, made even more expensive by the increased value accrual to REN from this product.
The second condition requires 2/3 consensus from the app chain to request a cosignature from the gateway shard. If this request is made in-band, the gateway shard will honor it and produce a cosignature.
Even if 2/3 of the Ren core (aka the coordination shard) is adversarial and coordinating, it cannot compromise any app chains. App chains can check their own wallet’s balance before minting and trust their own consensus before producing a release cosignature. And if it were possible to engage app chains in RNG as an additional source of randomness, Ren could prevent a corrupted core from manipulating shard selection. It might be in both Ren and app chains’ interests to decentralize that responsibility from the core.
Put simply, this layered security model is safer than either decentralized custodian acting alone.
Case Study
Source
Consider the now-defunct Compound Chain, which suffered from inadequate public infrastructure when it was attempted. If Compound Chain were to resurrect as a Cosmos SDK app chain with a Ren module, it would have consolidated interest rate markets for every native asset from AVAX to ZEC on its own chain with a multichain wallet that its own nodes would earn revenue for securing.
Conclusion
With a module built specifically for app chains, Ren could scale its economic security and become the default substrate upon which to build the best and most secure multichain experiences for all kinds of DeFi applications, whether they simply use Ren tokens, live on RenChain, or control their own app chain.
