January Development Update

Jan 24 · 4 min read

Welcome to the first development update of the year! It is already shaping up to be a busy one, so let’s dive right into what the development team has been working on.


Over the last month, we developed a new execution model for account chains, based on feedback from users. At the moment, when sending FIL and LUNA (and any other asset from an account chain), users need to attach a special payload to their transaction. Wallet support for special payloads turns out to be incredibly inconsistent, and users are getting confused. The new execution model gives a unique deposit address for every deposit and completely avoids the need for special payloads.

This makes the user experience on account chains all but identical to UTXO chains, and will help reduce confusion and reduce the risk of user error. We expect this to go live to production before the end of next month.

We also merged the newest version of Airwave, which has been under development for several months. This brings with it a number of substantial improvements: better and more predictable resource usage, better and more predictable performance, greater stability when running for long periods, and greater robustness when under attack. Once the next version of RenVM is released, users should notice their nodes will have an improved uptime, and will not need to wait as long before being seen as connected to the network.

Perhaps our most significant work on RenVM over the last few weeks has been aggregating the results of our latest Devnet deployment, and making improvements in preparation for the migration to Testnet. There will be a lot involved in this migration: finalising new features and improvements, bringing in external third-parties to get familiar with running nodes, building a secure and automatic upgrade process to reduce coordination, building backwards compatibility layers, transferring existing locked assets, and, of course, testing the absolute daylights out of it.

One of the biggest improvements has been an upgrade to the transaction model that unifies all of the different state transitions. This makes it easier to develop third-party clients (web apps, wallets, etc.) that can stay in-sync with RenVM with minimal resources and minimal uptime. This also opens the way for smart contracts to be deployed directly to RenVM. There is still a long way to go before this is possible, but this upgrade has been an important first step.


Preview of the next version of RenBridge

RenBridge is one the largest contributors of volume to RenVM: a lot of people use it to move BTC between different chains. This month, the next version of RenBridge finished testing with a subset of the Ren community. We have taken their feedback on-board and made the appropriate fixes. It is now almost ready for release to the general public.

With this new version:

  • you can send BCH, BTC, DOGE, ZEC to both Ethereum and Binance Smart Chain,
  • you can bookmark transactions, allowing you to easily share them and come back to them later,
  • you can see your transaction history for both Ethereum and Binance Smart Chain,
  • and many other user experience improvements.


There has been an overwhelming amount of interest in the Multichain, and a lot of questions regarding which chains will be admitted into RenVM proper, and at what time. This month, we publish the Multichain Requirements, which detail the technical, business, and community requirements before a chain can be supported by RenVM. Standard guidelines like this are an important first step to handing these decisions over to the community.

Over the last month, we have also made improvements to the Multichain infrastructure, with the aim to release an open-source version of our Kubernetes environment. This will allow anyone to easily run the entire cluster of nodes (and to see how we run ours). At the moment, node operators that wish to run their own Multichain nodes must do so manually. This will allow anyone to easily run the entire suite of Multichain nodes.

Supporting Libraries

Pack is a library used by multiple parts of the RenVM codebase for encoding and decoding dynamically typed messages. This is critical to correct, efficient, and Byzantine-resistant message passing between nodes. This month, it was updated to support more powerful encoding features and more tests.

Airwave is the peer-to-peer networking library designed for Byzantine networks. This month, we introduced support for peer discovery, and began working on large-scale network tests that span the entire globe. We believe that, soon, it will be ready to undergo auditing.

Asylo is now under active experimentation. Our intent is to deploy the Multichain and RenVM itself into Asylo-supported enclaves. Once we have demonstrated this capability in a proof-of-concept, we will deploy it to Testnet and eventually Mainnet, dramatically decreasing trust, increasing permission-less access, and pathing the way for more scalable decentralisation of the network. Read this blog for more.

Looking Forward

The development team has hit the ground running in 2021, with lots of exciting developments just around the corner: the next version of RenVM (introducing the Greycore and the next step towards Phase Zero), the next version of RenBridge (introducing support for new assets and chains), and Asylo (introducing secure and verifiable nodes).

Until next month,
— Loong, CTO

About Ren

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

Website | Docs | Telegram | Announcements | Twitter | Reddit | Github

Ren Project

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

Ren Project

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


Written by


Building an open protocol that facilitates the permissionless and private transfer of value between any blockchain | CTO at Ren

Ren Project

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