REN, Republic Protocol

You've heard about global and local fee markets, but how are they relevant to general-purpose Bitcoin bridges? 🧵

In single-threaded runtimes like the EVM, transactions are executed sequentially, forcing users to compete for priority access to state. In general-purpose Bitcoin bridges, threshold signers' collateral can be limited, forcing users to compete for priority access to liquidity.

The problem is that it doesn't make sense for all users to pay the same fees. Some are more valuable to the bridge — or are more sensitive to fee changes — than others. This leads to an inefficient fee market.

E.g., arbitrage becomes less rational as gas prices go up because of an NFT mint bloating the mempool. Similarly, providing productive liquidity for traders that generate MEV becomes less rational as the continuous fee rises to disincentivize unproductive liquidity elsewhere.

Ideally, fees would remain low for productive liquidity and rise exponentially for unproductive liquidity.

Check out the framework below to read more about this optimization problem. link.medium.com/nPMPKCGf4Fb And stay tuned to hear how we'll be addressing it in Ren v2.

Happy New Year, fRens 🎊 Let's kick it off with some new research: a framework for dApps to operate their own Bitcoin bridge. link.medium.com/8dxk0tzY0Fb

Think of how CEXs operate their own Bitcoin bridge. Now extend that to dApps, app chains, rollups, and restaking layers. Now add mesh security and fast transfers between them all via Lightning.

Token communities could secure their own users' BTC, issue their own app- or chain-specific wrapped BTC, share economic security with other communities, offer local fee markets for users, and internalize those fees for themselves.

We think this could improve decentralization, economic security, and sovereignty over Ren v1 and existing solutions by enabling new revenue streams for token holders, better security and optimized fees for users, and incentivizing more native experiences for BTC in DeFi.