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.

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.”

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.

A Framework for Application-Specific Bitcoin Bridges was originally published in Ren Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today, we’re thrilled to introduce the Ren Foundation, an independent organization dedicated to the research and development of trustless blockchain interoperability.

The Ren project has had the same mission since its inception in 2017: to enable the movement of value between blockchains. It’s based on a shared conviction that bitcoin is our generation’s most promising protection against secular, global currency debasement and that it must be utilizable in decentralized finance to accelerate its mass adoption. For example, if the best monies are those most capable of being sold,¹ and bitcoin should be salable without needing to trust a third party, then bitcoin needs trustless interoperability between blockchains and deep liquidity in decentralized exchanges to be a better, more salable money.

Ren v1

The first version of Ren became the first widely-used interoperability protocol with support for bitcoin. It facilitated over $13 billion in cross-chain volume between 5 UTXO-based and 12 account-based blockchains, including the largest EVM chains, Solana, and Cosmos chains via Kava, allowing bitcoin holders to participate in DeFi for the first time.

It also laid a foundation to test ambitious ideas and assumptions about protocol design, user experience, and economic security. Ultimately, it grew too quickly to progressively decentralize in a responsible manner. But, as with most v1s, the data was crucial to our research and understanding of the design space and will motivate future iterations.

When Alameda Research acquired the initial development team and later filed for bankruptcy, the project lost its development funding, revealing the risks of public good software developed in part by private corporations. Like v1 of the protocol, this experience equated to a v1 of governance, which motivated the community to establish legal entities of its own to steward the advancement, growth, and stability of the project into the future.

Ren Foundation

As a first step, the community formally voted to establish the Ren Foundation. Its purpose is to support research, development, growth, and awareness of the Ren protocol, implementations of the Ren protocol, and its third-party developer and application ecosystems. It was incorporated as a non-profit Cayman Islands foundation company on April 13, 2023, and its formation materials have been open-sourced to ensure incentive alignment with the community.

The Ren Foundation’s immediate focus is on research and development of Ren v2. While most interoperability projects lack support for Bitcoin due to its scripting limitations, the Ren Foundation intends to double down on it. We believe the first step toward accelerating the mass adoption of bitcoin as a global revolution in monetary policy is through a state-of-the-art interoperability protocol that’s designed to meet the trust and security needs of bitcoin users and decentralized financial markets.

We intend to research and develop open-source software but do not intend to run it; the protocol will be community-run from day one should the community choose to do so. While we intend to be active in the community, we do not intend to participate in or exert control over protocol governance, though we will assist in developing the protocol governance apparatus and issue a new governance token. To borrow from the Yearn manifesto, this token will govern the Ren protocol, but not its contributors. As an independent contributor to the project, we will strive to align with the community but encourage individuals to self-organize and build alongside us. In time, we will expand our focus to nurture an inclusive ecosystem for contributors and integrators.

Directors

The first director is David Perkins. He raised a 285K USDT grant from the Ren community to develop the first decentralized staking protocol designed to generate more rewards for node operators without taking fees from other stakers. He was previously a software development lead at Cafe X and has won first place prizes at four hackathons, including TechCrunch Disrupt.

Over the coming months, we will be introducing additional directors. They will help steer the project, advance its underlying technologies, make strategic decisions, develop the wider ecosystem, and push boundaries.

Join us

If our vision of iterating on the state-of-the-art in bitcoin interoperability resonates with you, we are looking to provide funding for motivated researchers and developers to help Ren unlock the next level of bitcoin adoption. We’ve been heads down on our immediate focus since June 1, 2023 with multiple developers from the previous development team as well as some new ones. R&D is already well underway.

If you are a backend or protocol engineer with strong experience in Go and system design and have a general understanding of blockchains and p2p networks, please reach out. If this does not apply to you, but you’re a developer interested in contributing, please feel free to reach out as well.

There is a lot to look forward to. We hope you’ll join us on our mission.

Onward,

David Perkins, Director

¹ Alden, Lyn. “What is Money, Anyway?” March 2022, https://www.lynalden.com/what-is-money/.

About Ren

Ren is an open protocol that enables the movement of value between blockchains.

Website | Twitter | GitHub | Discord

Introducing the Ren Foundation was originally published in Ren Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

Early last year, Alameda acquired Ren in a partnership with the previous Ren leadership, to secure long-term development funding. Alameda has since been funding the development team on a quarterly basis. Last week, the FTX Group, which Alameda falls under, commenced Chapter 11 proceedings. Therefore, the Ren development team only has funding until the end of Q4.

The goal of the Ren team has always been to launch an open-source and community-run version of the Ren network, and work towards this goal culminated into what we call Ren 2.0. It is a new architecture based on Geth with our new MPC implementation of FROST, which enables deployment of EVM-based applications on Ren with native multichain support for all blockchains integrated with Ren, and supports all bridging features Ren 1.0 offers as well. The switch to FROST as the MPC protocol lays the ground for a truly decentralized MPC network, as it is scalable to thousands of nodes, which if deployed would make it the most decentralized cross-chain platform live in the Web3 world.

A Ren 2.0 testnet is about to be deployed to showcase its capabilities, but there is additional work to test, harden and audit the new architecture, as well as finish new node client interfaces and general developer tooling, which would not be fully ready by the end of Q4. As such, to get to the Ren 2.0 stage where we have a fully open-source and community-run cross-chain network with its own independent incentive structure, the Ren development team would need to secure additional funding.

Next steps

Funding

To get to the Ren 2.0 stage with full community control, the Ren development team will need to secure additional funding. This is currently being explored in a manner that would also benefit the Ren community the most. As talks with investors proceed, we will share the opportunities that are the most promising to the community. Through ongoing discussions with the community on which opportunity seems the most promising, when ready, a formal governance proposal would be proposed to the community. If approved, the situation would be fully resolved and would move us forward. If rejected, the community would need to lead to another round of discussions and proposals, until final decisions are made.

Sunsetting Ren 1.0

When announcing Ren 2.0 back in August, it was outlined how the Ren ecosystem would transition from Ren 1.0 to Ren 2.0 in a safe, slow, methodical manner, to ensure the safety, integrity, and continuance of the Ren ecosystem without disruptions. But given that Ren 1.0 was run under Alameda leadership which is now in bankruptcy proceedings, the Ren development team believes it is best to sunset the Ren 1.0 network and launch Ren 2.0 earlier than previously intended, to ensure the Ren ecosystem’s safety and integrity, at the tradeoff of a shorter disruption of service. While the Ren 1.0 network has remained and still remains fully safe and operational, marking this event as the end of the Alameda’s involvement in the project by sunsetting Ren 1.0, safeguards the reputation, integrity, and hence long-term prospects of the Ren ecosystem.

We believe roughly these following steps are the safest course of action for the Ren ecosystem:

• Disable minting through Ren 1.0, while keeping burns enabled (bridged assets are always backed 1:1)
• After 30 days, shut down Ren 1.0

In parallell to the above:

• Deploy Ren 2.0 on testnet
• Test and harden the Ren 2.0 testnet together with the community
• Deploy Ren 2.0 on mainnet

We will additionally be transitioning away from the renproject.io domain which has been owned by Alameda. All current sites will be hosted on IPFS and control will be transferred over to the RenDAO moving forward.

How can you help?

The Ren development team is incredibly proud of the achievement of Ren 1.0, which has processed ~$13 billion in cross-chain volume since launch, enabling the liquid movement of assets between chains, all the while remaining 100% secure with no hacks.

The future is even brighter, as Ren 2.0 would be a paradigm shift in terms of the possibilities available to build truly native multichain applications, on the most secure and decentralized cross-chain platform in crypto. The Ren development team is fully committed into bringing this next evolution of the multichain future alive, and would be nothing but passionate and excited to do so, if the community chooses to support us.

We therefore encourage the Ren community to now more than ever engage in the discussions regarding funding and incentivizing Ren 2.0 deployment and its following ecosystem growth. Make your voices heard and propose your best ideas! With your help, we can transition to a fully community-run Ren network, and leave Alameda behind us.

And if anyone wants to reach out to the team directly, you can find us on Discord or DM us on Twitter!

Onwards and Upwards,

Ren Team

About Ren

Ren is an open protocol that enables the movement of value between blockchains.

Website | Docs | Discord | Announcements | Twitter | Reddit | GitHub

Moving on from Alameda was originally published in Ren Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

The main development focus continues to be on Ren 2.0 — the next stage of Ren — that will enable truly native multichain applications, as well as MPC support for EVM contracts. Moonbeam was also added as a new host chain, and Optimism and Arbitrum testnets were migrated to Goerli.

Ren 2.0 updates

Development of Ren 2.0 and writing out extensive documentation for it will continue to be a key priority for the rest of the year as well as early next year. Big news this month regards Ren 2.0’s leveraging of Geth, which will massively reduce the complexity of building out the Ren 2.0 stack, accelerating its development.

Execution and State

Ren 2.0 will be using an EVM layer for all execution logic and state management, based on Geth. The main benefits of this design is the massive reduction of complexity for the system, compared to implementing a new fully-fledged blockchain from scratch. Ren 2.0 can launch much earlier, and safer, by leveraging the heavily tested Geth codebase, and benefits from all the continued development and testing being done on Geth in the future. This month the focus was on translating the current bridging and fee management contracts used in Ren 1.0 from Golang to Solidity.

Darknode 2.0

The new node client that will power Ren 2.0 is being significantly code refactored to improve performance, support the new RenEVM chain, and to future-proof the design so that features added to different modules of the client, like the MPC layer, can be done with minimal worry for side-effects across the modules. That will ensure that upgrades in the future can be done with minimal changes, and safer.

Research

The team is researching ways to further improve the new MPC protocol, particularly when it comes to the security and design of the key management. One feature being explored now is ‘resharing’, which is the ability to let a new set of nodes be able to take over the key management of a previously generated key pair, without compromising on security. This feature would allow Ren to provide users and builders consistent gateway addresses, significantly improving UX and protecting against user mistakes, as opposed to generating new keys (and thus new addresses) at each epoch when validators enter and exit the network.

Ren integrates Moonbeam

We are excited to announce that Ren now supports direct bridging to and from Moonbeam for every asset that Ren supports, such as $BTC, $ETH and $USDC!

Moonbeam is an Ethereum-compatible smart contract parachain in the Polkadot ecosystem, mirroring Ethereum’s Web3 RPC, accounts, keys, subscriptions, logs, and more, and extends the base Ethereum feature set with additional features such as on-chain governance, staking, and cross-chain integrations. With Ren supporting it, you can now bridge BTC, DOGE, ZEC as well as tokens and assets from the 10+ other smart contract chains Ren supports directly to Moonbeam.

Start bridging here: https://bridge.renproject.io

Ethereum L2 Goerli transitions

As the Kovan network was deprecated by the Ethereum community recently, Ren migrated its Ethereum testnet to the Goerli network. Optimism and Arbitrum, two L2 networks on Ethereum that Ren supports, also migrated their testnets over to Goerli. So this month Ren’s testnet support for Optimism and Arbitrum was also successfully migrated to Goerli.

Onwards and Upwards,

Ren Team

About Ren

Ren is an open protocol that enables the movement of value between blockchains.

Website | Docs | Discord | Announcements | Twitter | Reddit | GitHub

Ren Development Update | October 2022 was originally published in Ren Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

We are excited to announce that Ren now supports direct bridging to and from Moonbeam for every asset that Ren supports, such as $BTC, $ETH and $USDC!

Start bridging here: https://bridge.renproject.io

What is Moonbeam?

Moonbeam is an Ethereum-compatible smart contract platform for building cross-chain connected applications that can access users, assets, and services on any chain. It’s a parachain on Polkadot and a highly specialized Layer 1 chain that mirrors Ethereum’s Web3 RPC, accounts, keys, subscriptions, logs, and more, and extends the base Ethereum feature set with additional features such as on-chain governance, staking, and cross-chain integrations. By uniting functionality from Ethereum, Cosmos, Polkadot, and more into a single platform, Moonbeam solves today’s fragmented user experience — unlocking true interoperability and paving the way for the next generation of applications. And with Ren supporting it, you can now bridge BTC, DOGE, ZEC as well as tokens and assets from the 10+ other smart contract chains Ren supports directly to Moonbeam.

Build cross-chain apps on Moonbeam today

Third-party developers can now build Cross-Chain dApps on Moonbeam with the RenJS SDK. You can get started below 👇

https://renproject.github.io/ren-client-docs/ren-js

Ren Token contract addresses on Moonbeam

Verify the token contracts on this page, by selecting ‘Moonbeam’ in the dropdown menu in the Gateway contracts section: https://renproject.github.io/ren-client-docs/contracts/deployments

Looking forward

We are very excited to have Moonbeam integrated with the Ren ecosystem, as it connects the Polkadot ecosystem for the first time to the large network of ecosystems Ren already supports, opening up a major asset pathway within the crypto ecosystem as a whole. And it already houses major DeFi protocols such as Curve and SushiSwap, as well as Moonbeam native projects, all fitting for the Ren ecosystem to integrate with and grow liquidity on. The Moonbeam integration is another key step in connecting all blockchains with Ren, ultimately allowing the fluid movement of liquidity throughout the crypto ecosystem. Make sure to follow Ren on Twitter for any relevant updates.

Onwards and upwards,

— Ren Team

About‌ ‌Ren‌ ‌

Ren‌ ‌is‌ ‌an‌ ‌open‌ ‌protocol‌ ‌that‌ ‌enables‌ ‌the‌ ‌movement‌ ‌of‌ ‌value‌ ‌between‌ ‌blockchains.‌ ‌

Website‌‌ ‌|‌‌ ‌Docs‌‌ ‌‌‌|‌‌ ‌Discord ‌|‌‌ ‌Twitter‌‌ ‌|‌‌ ‌Reddit‌‌ ‌|‌‌ ‌GitHub‌ ‌

Ren integrates Moonbeam was originally published in Ren Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

The primary focus this month has been the continued development and preparation of the launch of Ren 2.0, involving lots of testing, porting old features to work with the new MPC algorithm, and adding new surprise features! We have also finished our support for Moonbeam and undergone a Ren testnet migration from Kovan to the Goerli network.

Ren 2.0 updates

DKG

Distributed key generation (DKG) is a core component in allowing a set of nodes to generate a key pair, such that the public key is output publicly, while the private key is distributed amongst the nodes through secret sharing. The initial implementation of Ren’s DKG protocol is in its final stages of testing. The focus will now shift to integrating it into the new Darknode client, as well as increasing its robustness in such cases where nodes go offline for any reason, which is expected in a decentralized network.

All bridging transaction types integrated with new MPC algorithm

Minting and burning, as well as the recent host-to-host transaction type, have successfully been integrated with the new FROST algorithm in the new Darknode client! This will ensure that the ecosystem transition between Ren 1.0 and 2.0 will be as smooth as possible.

NFT support

Surprise! The team has quietly added support for NFTs to Ren 2.0. This will open up Ren to a whole new host of applications and developers who can use Ren. Support for minting and burning NFTs is currently undergoing testing, and will be detailed in future posts.

Chaos testing

Finally, Ren 2.0 has been undergoing continuous thorough testing in a local environment. Over the coming month we will be deploying Ren 2.0 to testnet and starting the work on the next set of features including key rotation and fee management.

Moonbeam deployment

Moonbeam, an Ethereum-compatible smart contract parachain on Polkadot, has been integrated into Ren! RenJS support is already live, so developers can already begin utilizing Ren’s support for Moonbeam both on testnet and mainnet. Verify the token contracts on this page, by selecting ‘Moonbeam’ in the dropdown menu in the Gateway contracts section: https://renproject.github.io/ren-client-docs/contracts/deployments

Integration into RenBridge is soon complete with a separate announcement when that is live.

Goerli transition

The current Ren testnet (including contracts such as the Darknode Registry) have been migrated from Kovan to Goerli, given that the Kovan network has been deprecated by the Ethereum community.

This means that integrators using the Ren testnet will need to make a few small changes so that your application is pointing to the new network and contracts. Instructions for doing so can be found on this link.

Onwards and Upwards,

Ren Team

About Ren

Ren is an open protocol that enables the movement of value between blockchains.

Website | Docs | Discord | Announcements | Twitter | Reddit | GitHub

Ren Development Update | September 2022 was originally published in Ren Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

The month of August has been historic for Ren with the announcement of Ren 2.0 and the progress made since then, which will take the protocol to the next level in terms of security, efficiency, and developer tooling. The first Cosmos chain — Kava — was also integrated into Ren, and work was begun to support more non-Ethereum stablecoins, which will open up more bridge routing pathways and support more use-cases. Finally, the process to begin auditing the upgraded Ren gateway contracts has begun. This will ultimately enable the earliest assets such as $renBTC to migrate to the new version that supports the burn-and-mint functionality, allowing direct any-to-any-chain bridging for Bitcoin, Dogecoin and more.

Ren 2.0

This month we announced the next iteration of Ren in this emergent multichain world. Ren 2.0 is an open protocol, enabling novel multichain application development with EVM support — leveraging Ren’s robust bridging technology for a new world of opportunities. Check out the announcement blog for more details: https://medium.com/renproject/introducing-ren-2-0-43025b3d5d6

Ren 2.0 boasts improved security, support for generic application logic on top of Ren, an improved MPC algorithm that’s more scalable and able to support more signing schemes, and optimized tokenomics to further align incentives for ecosystem participants.

Since the announcement, work has been done to add RenEVM support for the Darknode CLI, and the new FROST MPC algorithm has been undergoing testing and improvements to enhance its robustness, and been integrated into the new Darknode client. Documentation is currently in works, and the Chaosnet deployment is expected to come up soon, with a demo currently being prepared.

Ren integrates Kava

We are excited to announce that Ren supports direct bridging to and from Kava for every asset that is supported, such as $BTC, $ETH and $USDC!

Kava is a lightning-fast Layer-1 blockchain featuring a developer-optimized co-chain architecture that combines the two most used permissionless ecosystems — Ethereum and Cosmos — into a single, scalable, network. With Ren supporting it, you can now bridge $BTC, $DOGE, $ZEC as well as tokens and assets from the 8+ other smart contract chains Ren supports directly to Kava and back.

With Kava integrated, it opens up not just a direct Bitcoin bridge to Kava, but 8+ chain bridges from the largest EVM chains and L2s, as well as Solana, directly to Kava, and as a result the Cosmos ecosystem at large! This massively expands interoperability for the whole crypto-finance ecosystem, as assets and liquidity can now move fluidly from almost anywhere to anywhere else, without needing to interact with centralized exchanges.

New stablecoin integrations

Work has begun to integrate a new cohort of tokens, this round focusing on non-Ethereum stablecoins, such as Polygon and Avalanche USDT and USDC. This will open up for better and more liquid pathways for cross-chain trading as arbitrary tokens can be routed through liquid stablecoins before swapping into the destination asset on another chain. These additions will be live in September.

Contract upgrades undergoing audits

The process for getting the latest gateway contracts audited has begun. Among other features, the latest gateway contract support the burn-and-mint functionality which enables direct bridging of renASSETS between chains without having to burn it to the source chain before minting it to the destination chain. When these upgraded contracts have been audited and deemed sufficiently secure, the earliest assets such as $renBTC and $renDOGE will migrate to the upgraded contracts, which finally will enable burn-and-mint for those assets as well. This will make $renBTC a premier routing asset between chains given its high liquidity across many chains.

When the deployment of Chaosnet starts, the Ren community and node operators will need to work closely together and coordinate to ensure smooth sailing. If you have not already, join the Community to stay up to date and ensure you are ready for the Multichain Future.

Onwards and Upwards,

Ren Team

About Ren

Ren is an open protocol that enables the movement of value between blockchains.

Website | Docs | Discord | Twitter | Reddit | GitHub

Ren Development Update | August 2022 was originally published in Ren Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

Today we are excited to introduce the next iteration of Ren in this emergent multichain world. Ren 2.0 is an open protocol, enabling novel multichain application development with EVM support — leveraging Ren’s robust bridging technology for a new world of opportunities.

Background

The Ren protocol has reached great technical maturity since it was first announced at the end of 2018. Initially supporting BTC, BCH, and ZEC on Ethereum mainnet, the protocol now supports a plethora of assets across smart contract chains such as Arbitrum, Polygon, Solana, and more. This multichain support enables interoperability between the largest and most active ecosystems throughout the crypto space. Adding to this, two significant upgrades were deployed recently:

1. Support for direct bridging of renASSETS between smart contract chains, making it faster and cheaper than ever to bridge.
2. Support for generic tokens being moved between those smart contract chains, such as stablecoins, and native assets like ETH.

In terms of adoption, the protocol has crossed $12 billion in all-time volume, and the ecosystem has key integration partners in Varen, ZeroDAO, and more, offering unique cross-chain services powered by Ren. Catalog will also prove to be a key liquidity bootstrapper for the Ren ecosystem as it starts to move through its phased rollout over the remainder of the year.

With integrations wrapped up for Optimism, Kava, and Moonbeam, we have begun gearing up for the next version of Ren — Ren 2.0.

Overview

Ren 2.0 will be the network that powers Ren ecosystem growth throughout this exciting new chapter we’re about to embark on. Its primary advancements will be decentralization and security, supporting generic application logic on top of Ren, an improved MPC algorithm that’s more scalable and able to support more signing schemes, and optimized tokenomics to further align incentives for ecosystem participants. These are extensive upgrades to our core technology. Hence, they will be deployed to a new network. The existing Ren ecosystem will continue to operate as is but should eventually migrate to Ren 2.0. This blog will provide an overview and roadmap for Ren 2.0.

Security

Ren 2.0 will be decentralized at launch, meaning anyone with enough REN to spin up a validator will be part of the execution nodes that secure and run the network. It will use the Flexible Round-Optimized Schnorr Threshold (FROST) signing scheme to allow for greater scalability with such a large and decentralized network. Usage of FROST allows for greater scalability as it significantly reduces network overhead during signing operations. Since it is an extension of Schnorr, there is also no restriction on the safety threshold. The implementation is currently in progress and can be tracked here.

There are also ongoing discussions around custodian fees (demurrage) which will be formalized through the governance process to align incentives better to secure the network.

Open source

The secret sauce that makes up Ren 1.0 was gradually open-sourced, like MPC, Shamir, Airwave, Hyperdrive, and the Multichain infrastructure. With Ren 2.0, all code will be open-sourced from day one, such as the new Darknode client and the new FROST signing scheme, opening Ren up to a larger community of contributors worldwide and evolving Ren into a decentralized public goods multichain infrastructure, governed by the RenDAO and node operators.

RenEVM

RenEVM is an Ethereum-based plugin for Darknode that allows arbitrary programs to be deployed on top of the Ren blockchain to leverage any asset supported by Ren. This will mean that Ren will not only support minting and releasing assets between blockchains but also smart contracts that can power any kind of application, cross-chain specialized or not. Native cross-chain trading, lending, and derivatives can all run on top of Ren and access liquidity from every blockchain Ren supports, creating a richer DeFi ecosystem for users.

RenEVM will use a proof of authority consensus model, allowing any participants from the pool of Darknode operators. Darknode operators will earn a share of the fees for all activity on RenEVM, incentivizing a large and secure network.

The native gas asset in this execution environment will be REN. In a similar design to Ethereum, we initially propose to have 50% of the transaction fees burned, to introduce deflationary pressure into the protocol. Detailed proposals on the tokenomics for Ren 2.0 will be published on the Ren Forum.

Check out the RenEVM progress here and join the Community to keep up with updates.

Roadmap

The first major components of Ren 2.0 to be released will be RenEVM and the FROST implementation. These are the key prerequisites for releasing Darknode 2.0. Both components are near completion, with the current focus being on testing.

Towards the end of the year, the new Darknode client that will power Ren 2.0 will be released on Chaosnet — a pre-production environment that will allow the community to purposefully put the network under stress and incentivize its corruption in real-world conditions.

As the Chaosnet is battle-tested and confidence on the security and liveness of the network reaches a sufficient level, the Ren 2.0 Mainnet rollout will begin. It will run in parallel with the current Ren 1.0 network initially, with limits on TVL that gradually will be lifted. When the Ren network operators, community and ecosystem have reached sufficient confidence about the safety and soundness of the new architecture, the networks will merge, completing the full transition to Ren 2.0.

With the transition to Ren 2.0, Ren will have undertaken its most extensive upgrades so far, laying the foundation for the Multichain future — a boundless and open space powered by a decentralized multichain infrastructure. If you are a builder and would like to know more and get involved, or just generally interested, join the Community!

Onwards and Upwards,

Ren Team

About‌ ‌Ren‌

Ren‌ ‌is‌ ‌an‌ ‌open‌ ‌protocol‌ ‌that‌ ‌enables‌ ‌the‌ ‌movement‌ ‌of‌ ‌value‌ ‌between‌ ‌blockchains.‌ ‌

Website‌‌ ‌|‌‌ ‌Docs‌‌ ‌‌‌|‌‌ ‌Discord ‌|‌‌ ‌Twitter‌‌ ‌|‌‌ ‌Reddit‌‌ ‌|‌‌ ‌GitHub‌ ‌

Introducing Ren 2.0 was originally published in Ren Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

We are excited to announce that Ren now supports direct bridging to and from Kava for every asset that Ren supports, such as $BTC, $ETH and $USDC!

Start bridging here: https://bridge.renproject.io

What is Kava?

Kava is a lightning-fast Layer-1 blockchain featuring a developer-optimized co-chain architecture that combines the two most used permissionless ecosystems — Ethereum and Cosmos — into a single, scalable, network. With Ren supporting it, you can now bridge $BTC, $DOGE, $ZEC as well as tokens and assets from the 8+ other smart contract chains Ren supports directly to Kava and back.

Build cross-chain apps on Kava today

You can now build Cross-Chain dApps on Kava with the RenJS SDK. Get started below 👇

https://renproject.github.io/ren-client-docs/ren-js

Ren Token contract addresses on Kava

Verify the token contracts on this page, by selecting ‘Kava’ in the dropdown menu in the Gateway contracts section: https://renproject.github.io/ren-client-docs/contracts/deployments

Looking forward

We are excited to have Kava integrated with the Ren ecosystem, as it opens up not just a direct Bitcoin bridge to Kava, but 8+ chain bridges from the largest EVM chains and L2s, as well as Solana, directly to Kava, and as a result the Cosmos ecosystem at large! This massively expands interoperability for the whole crypto-finance ecosystem, as assets and liquidity can now move fluidly from almost anywhere to everywhere, without needing to interact with centralized exchanges. Powered by Ren, this poises Kava to become a major DeFi hub between the EVM and Cosmos ecosystems. Make sure to follow Ren on Twitter for any relevant updates.

Onwards and upwards,

— Ren Team

About‌ ‌Ren‌ ‌

Ren‌ ‌is‌ ‌an‌ ‌open‌ ‌protocol‌ ‌that‌ ‌enables‌ ‌the‌ ‌movement‌ ‌of‌ ‌value‌ ‌between‌ ‌blockchains.‌ ‌

Website‌‌ ‌|‌‌ ‌Docs‌‌ ‌‌‌|‌‌ ‌Discord ‌|‌‌ ‌Twitter‌‌ ‌|‌‌ ‌Reddit‌‌ ‌|‌‌ ‌GitHub‌ ‌

Ren integrates Kava was originally published in Ren Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.

We are excited to announce that Ren now supports direct bridging to and from Optimism for every asset that Ren supports, such as $BTC, $ETH and $USDC!

Start bridging here: https://bridge.renproject.io

What is Optimism?

Optimism is a low-cost and lightning-fast Ethereum L2 blockchain, that pledges to uphold the values of Ethereum by producing infrastructure that promotes the growth and sustainability of public goods. Optimism has a native bridge to and from Ethereum, but with Ren supporting it, you can now bridge BTC, DOGE, ZEC as well as tokens and assets from the 7+ other smart contract chains Ren supports directly to Optimism and back.

Build cross-chain apps on Optimism today

You can now build Cross-Chain dApps on Optimism with the RenJS SDK. Get started below 👇

https://renproject.github.io/ren-client-docs/ren-js

Ren Token contract addresses on Optimism

Verify the token contracts here: https://renproject.github.io/ren-client-docs/contracts/deployments

Select ‘Optimism’ in the dropdown menu in the Gateway contracts section.

Looking forward

We are excited to have Optimism integrated with the Ren ecosystem, as it is home to both OG DeFi protocols like Synthetix, Uniswap and Curve, as well as Optimism native DeFi protocols like Perpetual Protocol and Velodrome, all fitting for the Ren ecosystem to integrate with and grow liquidity on. The Optimism integration is another key step in connecting all blockchains with Ren, ultimately allowing the fluid movement of liquidity throughout the crypto ecosystem. Make sure to follow Ren on Twitter for any relevant updates.

Onwards and upwards,

— Ren Team

About‌ ‌Ren‌ ‌

Ren‌ ‌is‌ ‌an‌ ‌open‌ ‌protocol‌ ‌that‌ ‌enables‌ ‌the‌ ‌movement‌ ‌of‌ ‌value‌ ‌between‌ ‌blockchains.‌ ‌

Website‌‌ ‌|‌‌ ‌Docs‌‌ ‌‌‌|‌‌ ‌Discord ‌|‌‌ ‌Twitter‌‌ ‌|‌‌ ‌Reddit‌‌ ‌|‌‌ ‌Github‌ ‌

Ren integrates Optimism was originally published in Ren Protocol on Medium, where people are continuing the conversation by highlighting and responding to this story.