DISCLAIMER: I DID NOT WRITE THIS. THIS IS A MEDIUM ARTICLE WRITTEN BY DAVID PERKINS WHICH YOU CAN FIND HERE:
Also, this is NOT the direction RENv2 is going anymore- David just wanted to post it to let people know stuff is being worked on.
Post below if you don’t want to go on the Medium article above:
In this post, we’ll present a framework for token communities to operate their own application-specific Bitcoin bridge. They can secure their own users’ BTC, issue their own application- or chain-specific wrapped BTC, share economic security with a mesh of other communities, transfer BTC to other communities via Lightning, provide local fee markets, and capture those fees for themselves.
In short, think of how CEXs operate their own Bitcoin wallet, and extend that to dApps, but with fast transfers between them.
We think this is an improvement in decentralization, economic security, and sovereignty that allows for more optimized fees and incentivizes more of DeFi to support native user experiences for BTC.
Global fee markets
General-purpose validator bridges have similar shortcomings as single-threaded runtimes like the EVM.
One example is global fee markets. In single-threaded runtimes, transactions are executed sequentially, which forces users to compete for priority access to state. When a hot application bloats the mempool, gas prices rise for everyone on the chain. Conversely, in general-purpose validator bridges, if the collateral that validators need to bond is limited, that creates an economic constraint that forces users to compete for priority access to liquidity. When the bridge is undercollateralized — i.e. validators collateralize less value than they secure — the mint and/or continuous fees rise for all users on all chains connected to the bridge.
The problem is that it doesn’t make sense for different types of users to pay the same fees due to their differences in fee elasticity, particularly if some generate more fees (MEV) for the bridge than others. For example, arbitraging between DEXs in a single-threaded EVM suddenly becomes less rational as the cost of block inclusion goes up because of a hot NFT mint bloating the mempool. Similarly, providing bridged liquidity to a DEX on chain A that facilitates cross-chain volume from traders becomes less rational as the continuous fee rises to disincentivize unproductive liquidity on chains A-F. Ideally, the mint and continuous fees would remain low for productive liquidity and rise exponentially for unproductive liquidity. An application’s productivity would be measured as the ratio of MEV generated for the bridge to the amount of value it has locked in the bridge.
Leaving the door open for productive liquidity while taxing unproductive liquidity would allow the bridge to concentrate liquidity into its most productive applications; a more opinionated, economically optimized middle ground between general-purpose and application-specific.
However, fee markets can only be isolated (aka “local”) when the broader market for priority access is not saturated. If collateral can’t scale with locked value, then even productive liquidity could oversaturate the market and get hit with higher fees. This is analogous to L2 fees rising when L1 gas prices spike.
The issue for general-purpose validator bridges is that collateral scales with MEV, not necessarily with locked value. If locked value doesn’t generate commensurate MEV, that will be reflected in how collateralized the bridge is. In fact, this was the economic story of Ren v1 and will be of similar solutions.
Source: https://defillama.com/protocol/renvm
In parallelized runtimes like the SVM, priority access to state can be scaled by simply adding more cores. In single-threaded runtimes like the EVM, it can be scaled with L2s. In general-purpose validator bridges, priority access to liquidity can be scaled by extracting MEV. What might the equivalent of cores and L2s be for bridges? The framework below offers a proposal.
MEV
A second shared shortcoming is that the more MEV gets extracted by L1s and bridge tokens, the more gets leaked by applications.
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? — Sunny Aggarwal (source)
In Vitalik’s rollup-centric ethereum roadmap, he argues that having L2 projects with their own tokens, public goods funding mechanisms, and MEV can benefit the Ethereum ecosystem by contributing more credibly neutral funding for research and development; “a good strategic move for the long-term economic sustainability of Ethereum as a whole.”
Source: A rollup-centric ethereum roadmap - ethereum-roadmap - Fellowship of Ethereum Magicians
Perhaps a similar kind of symbiosis would be just as strategic for a general-purpose validator bridge. What would that look like? Perhaps the bridge could share MEV with its applications. Or what if applications could provide their own collateral to help scale economic security and priority access to liquidity?
Challenges
To scale and have local fee markets, we need to fundamentally rethink bridge architectures. For context, Ren v1 had one token community operate its own network (RenVM) that issued one wrapped BTC token (renBTC) for all chains and applications.
However, using the same wrapped BTC token everywhere makes it hard to isolate fee markets.
For example, suppose there were a smart contract for minting and burning that levied a fee based on which application the user were minting or burning the token into or out of. Minting renBTC directly into one’s account would not be very productive and incur a high fee by default, whereas minting it directly into a more productive application might incur a much lower fee.
The problem is that one could simply mint renBTC somewhere for the lowest possible fee before moving it elsewhere. Every application would need its own special smart contract to prevent this, which we can’t depend on, and which they have minimal incentive to do. Fees thus need to be enforced by a smart contract that cannot be circumvented, and that is the token contract itself. This means that in practice, local fee markets require local tokens.
Each token contract could maintain a whitelist of the application’s contract addresses that the token could be used in. The fees for minting, burning, and holding the token would be strictly based on the productivity of the application. But to use it in a different application, one would need to convert it 1:1 (minus fees, however small) to the other application’s token.
This presents a UX challenge. As long as applications lack an economic incentive to abstract these conversions in their frontends, users would have to convert them manually. So, how can we achieve local fee markets and incentivize applications to abstract the UX of local tokens?
Putting the pieces together
If applications earned some of the MEV they generated, it would only exacerbate the collateral issues because the only validators providing any collateral would be earning less in MEV.
One solution is for token communities to operate their own bridge. Since CEXs are applications, and their bridges are called “wallets,” we’ll refer to application-specific bridges as “wallets.” These wallets would secure their own users’ BTC and issue their own application- or chain-specific wrapped BTC, which would naturally enforce a local fee market.
In addition to (or in lieu of) the standard mint, burn, and continuous fees, developers could also optimize MEV extraction for their wallets by redistributing part of their underlying applications’ revenue to node operators. For example, instead of levying a mint fee for xBTC upfront, node operators could earn a percentage of the interest or LP fees accrued by xBTC lenders or LPs, respectively.
And since the wallet protocol would be chain-agnostic, it would be compatible with communities of any L1 or L2 application, application-specific blockchain (i.e. Cosmos chains), rollup (L2), or application-specific rollup (L3).
Using wrapped BTC in one application, and then moving it to another, however, would require transferring BTC from one wallet to another. Doing this onchain would obviously be slow and expensive. As a workaround, wallets could open Lightning channels with a subset of others and coordinate direct and multipath transfers between one another. For example, burning xBTC on chain A with certain inputs would prompt community X to transfer BTC to community Y, which could quickly produce a mint signature for yBTC on chain B.
Shared security
However, communities shouldn’t have to secure their own wallets alone. It takes time for users to trust new decentralized networks, which means limited MEV for and less security from node operators, who may need to be subsidized in the beginning.
Alternatively, communities could share economic security. They could rent it from global and/or local community “hubs” and eventually grow to rent theirs out too. For example, community X (representing application X on chain A) might share security with community A (representing chain A itself) and community B (representing a neutral, global hub). As more communities emerge across different ecosystems, more security would become available based on one’s needs and demands, regardless of which chains their underlying applications were part of. Whereas Cosmos’ mesh security (Interchain Security v3) allows Cosmos chains to secure other Cosmos chains, this would let Cosmos, Solana, Ethereum, L2, etc. communities all help secure one another. We might expect reverse auctions to emerge where communities bid to provide their economic security in exchange for the least MEV.
Communities could either be combined into the same set of operators or kept segregated. These are very different schemes, so it’s important to understand the differences.
Combining them into one set of operators would require a price oracle to determine the weight of a certain amount of collateral vs. another. And in the example above, if community A were large enough, they could overwhelm community X and take unilateral control of the signing threshold.
Instead, they can be segregated using a multisig with one (or more) key for each community. For example, suppose bridge X utilized a 3-of-5 multisig shared between 4 communities (X, A, B, and C). Community X could have two keys, while the others would have one. This scheme is more secure and fault-tolerant than any one network operating alone, because it requires a threshold signature from at least two communities while allowing up to two of them to go completely offline.
In this example, even if community A were to dwarf community X in economic security, community X would retain a larger stake in the scheme. And if community X were to become dishonest or go offline, the wallet could fall back on the other three communities to make progress.
Conclusion
In a world where every application has its own token, those tokens should be put to work. Application-specific Bitcoin bridges may not only provide more economic security where it’s needed and create new revenue streams for token holders, but optimize fees and incentivize developers to build first-class Bitcoin experiences into their applications. More tokens, more BTC.