ARC: Proposal to add support for renBTC

Hello Aave community,

I humbly submit this proposal to add support for renBTC.

Ren Project Background

Ren Project developed and launched RenVM, a byzantine fault-tolerant protocol that provides ECDSA threshold key generation and signing via sMPC, which allows RenVM to securely manage (ECDSA) private keys of different assets like Bitcoin, and wrap these assets on smart-contract chains like Ethereum. Since launch, RenVM has processed $847m (77.8k BTC) in total volume of Bitcoin going to and from Ethereum (figures are at time of writing and are growing). renBTC comes in at 2nd place for BTC on Ethereum making up roughly 19% of the supply (22k BTC), with wBTC at 74% (89k BTC). In addition, there is over $200m (18,299 BTC) in liquidity locked in Curve pools between the Ren and sBTC pools.

renBTC is a tokenized representation of BTC on the Ethereum blockchain. It is implemented as a standard ERC-20 contract, and backed 1:1 with real BTC locked in RenVM, a decentralized custodian. It is redeemable at any time for real BTC. Individuals can acquire renBTC by minting it with real BTC via the RenBridge.

In addition, Aave is one of the original members of the Ren Alliance and currently supports the Ren token itself ( Given 1) renBTC’s price peg to BTC and 2) the ease at which users are able to swap between BTC, wBTC, and renBTC through the Renbridge,, and the Curve pools, the price of renBTC can quickly and easily be arbitraged to the price of BTC supporting a healthy lending and flash loan market.

RenBTC is currently supported by:

  • Curve
  • Yearn Vaults
  • Uniswap + Mooniswap
  • Uma Protocol
  • Cream
  • Huobi
  • Pillar
  • Loopring
  • VirgoX

renBTC is in the process of integrating with:

  • Akropolis Delphi
  • Polkadot/Acala Network
  • Cosmos/Terra
  • Solana
  • Binance Smart Chain
  • Bancor
  • And many more (See Ren Alliance and Ecosystem updates in Ren’s Medium)

About RenVM

RenVM is a byzantine fault-tolerant protocol that provides ECDSA threshold key generation and signing via sMPC. What makes RenVM unique is that it does all key management and rotation using its sMPC based protocol that the team has pioneered. The state, inputs, and outputs of all programs that RenVM runs (e.g. ECDSA private keys) are kept hidden from everyone, including the Darknodes that power it.

This allows RenVM to securely manage (ECDSA) private keys of different assets, making it possible to mint or burn tokenized representations of these assets on external blockchains in a trustless, permissionless, and decentralized manner.

One of the core features of RenVM is bringing BTC to Ethereum (i.e renBTC). renBTC serving as collateral within the Aave ecosystem is the sole focus of this application, although RenVM also supports renBCH and renZEC.

(Citing the MakerDAO Improvement Proposal that passed

I’ve pasted the TL;DR for RenVM from the Ren Wiki below:

RenVM is a decentralized crypto asset custodian that:

  • enables universal interoperability between blockchains: anyone can use RenVM to send any asset to any application on any chain in any quantity.
  • has robust security: large bonds, large shard sizes, and continuous shuffling make RenVM extremely difficult to attack, even for irrational adversaries. In the unlikely event of a successful attack, RenVM can restore lost funds.
  • is scalable: as more assets are locked into the custody of RenVM, the algorithmic adjustment of fees allows RenVM to automatically scale its capacity to meet demand.
  • provides an optimal user experience: users can interact with multiple assets, applications, and chains with only one transaction.

The benefits of onboarding renBTC for Aave include:

  • Diversification of BTC assets as currently Aave only supports wBTC.
  • Increased adoption of Aave usage by renBTC users.
  • Increased Total Value Locked (Market Size on Aave’s dashboard) with renBTC users depositing their assets as collateral.
  • If renBTC is onboarded and subsequently, RenJS is integrated into Aave, Aave/renBTC users will have the abilities to directly 1) deposit/lend BTC into Aave in a single BTC transaction and 2) pay-off/withdraw real BTC in a single Ethereum transaction. An example of a RenJS integration is with Curve (

Big thank you to @MaxRoszko for providing comments, edits, and additions during the drafting process of the proposal.

Relevant Ren Project documents below:


Particularly being able to natively deposit and withdraw real BTC in one transacion to and from Aave is what excites me. Aave could be the first decentralized money market that directly integrates Bitcoin.


It has processed almost one billion $ without any lost funds, critical bugs and flaws. I believe it does deserve the second spot in terms of wrapped Bitcoin and should be integrated with Aave.


Native BTC is a great idea! renBTC = no crash, no major bugs, no any downtime.
RenVM is new technology in this space but it works over 4 months without any complications.


renBTC is the second highest TVL of btc on ethereum and has been running with 0 issues for 3+ months. Nearly $1b volume in those months as well as a quarter billion in value locked.

Money talks! RenBTC would be a great addition to AAVE.


Would use. And my BTC-only holder mates would use as well.


Been a user of ETHlend since 2017 lending and borrowing :innocent: and am currently using AAVE with WBTC and other tokens even Ren .For me as a user of the protocol using renBTC would be preferential .wbtc always has the custodial risk which should not be ignored moving to allow people to deposit and borrow renBTC would place less risk on the system . It Would also allow no delays in getting BTC into AAVE also as with WBTC people need to get kyc to mint and unmint . also eliminates the risk of WBTC diverging in price against BTC for a borrower for example if bitgo stopped allowing more WBTC to be minted and is a large amount lent out you could see a price change on WBTC against bitcoin this is a risk I have had to allow for when I am borrowing WBTC. renBTC can be minted and unminted at will so this issue is eliminated .

So in my opinion adding renBTC would increase the amount of btc in our system
Would make our system more resilient to centralised risks
Make the user experience better

$16,844,179.41 of Ren us currently in use in our system one of our biggest none stable coin markets so a real show of faith in AAVE from another community. Ren as a protocol has been live since June with near 1 billion of total volume of minting and burning BTC without any down time I think its time for AAVE to add support for renBTC due to its success over many months and the value it will bring to us and the cross community support we have already seen from the ren community using the AAVE protocol .


renBTC has been live for 4 months without issue. Natively deposit and withdraw real BTC in Aave will be a real advantage, I fully support this proposal.


disclosure I own KEEP tokens and TBTC

RenVM is currently in its sub zero phase. It is not currently a decentralized custodian, it is a federated network that currently only consists of the REN team members.

However assuming that team successfully progresses along the road to decentralisation there is a risk with the collateralisation and economic security model.

“RenVM targets a bonded value that is 3x greater than the locked value, because above this threshold it is irrational to attack RenVM (the loss of the bond is greater than the gain of the attack).” —

The collateralisation model is based on staking 100,000 REN tokens.

If REN was currently open source and decentralised this collateralisation model would present a great risk

Value Locked $241,151,788
Value Bonded $28,232,590

For REN to be safely collateralised it would need $723,455,364 of collateral. It currently only has 3.9% of the collateral required to satisfy its requirements for safety.

If REN was currently decentralised this would make for a 25x return for darknodes to collude to steal funds.

The liquidation of the REN bonds would be visible onchain. This has the risk of a cascading effect. If the market price of REN drops as a result of stollen funds this would further reduce the collateralisation of the network and great increase the incentives to collude to steal funds.

1 Like

disclosure I own KEEP tokens and TBTC

This is an important update from the team.

“Open-sourcing the related codebases comes as part of our broader commitment to incrementally open-sourcing the entire RenVM implementation. We believe taking these steps gives the community the opportunity to see/verify critical parts of the implementation and find/report vulnerabilities responsibly, without simultaneously exposing RenVM to an undue amount of risks or incentives to leverage vulnerabilities instead of disclosing them.”

RenVM as a system has not been audited.

Only three of the repositories that make up RenVM have been open sourced an audited by Trail Of Bits.

As the amount of assets in REN increases so does the incentive for a malicious user.

It is also worth noting that the REN testnet “Chaosnet” is no longer operational for security researchers.

1 Like

There are multiple centralized assets currently listed on Aave (including wBTC, which Ren cofounded with Kyber and BitGo), it always comes down to risk management. RenVM is being decentralized over time in a slow fashion exactly to keep the risks low and the users safe. More non-team members will be added to the permissioned core over the coming months, and later down the line it can be completely voted out by Ren governance, with only public nodes remaining and securing the network.

This is again not necessary at this stage size as a permissioned core is securing the network. The network won’t go fully decentralized unless the bonded values and custodied values have been balanced, and this can easily be done by changing the fees for mint and burns, making burns cheaper to reduce TVL, and increasing minting fees to reduce incoming TVL. Of course there are many other things being done to improve the collateralization ratio, such as more integrations which will generate more volume and increase the bonds’ value.

There is a testnet for RenVM for developers to work with. Also check my above comments to @state for your other concerns.


Disclosure: I’m a Ren Darknode owner and have the most to lose (and benefit) from RenVM’s security model.

A few clarifications are in order:

Regarding centralization risks:

RenVM uses secure multi-party computation (sMPC) to power its network of nodes (collectivity called RenVM). What makes RenVM unique is that it uses sMPC and this essentially allows for a (one) private key to be broken up into small pieces, amongst all the nodes, that then collectively come together and sign an ECDSA key (i.e. a BTC private key) whenever they are requested to mint and burn assets (BTC, renBTC, etc). A very important aspect of sMPC is that no one node knows the private key, the info is hidden from everyone, including the nodes themselves.

These 13x randomly geo-distributed (Greycore) nodes use sMPC to keep the key safe. Nodes are run by the team at the moment, expanding to others at the inception of Mainnet Zero. Sharding (the use of multiple private keys), also comes in the next phase.

What does it really take to make RenVM insecure? From the team’s post security and decentralization.

"A malicious adversary would need to successfully compromise 5+ machines without being noticed. Even then, the adversary would not have root access to the machine, and would not be able to read that nodes’ shares of the MPC-generated private key.

Of course, until we progress further through phase sub-zero, the Ren team could collude internally. The team has obvious and strong incentives not to do so: we would be throwing away years of hard work and reputation, we would be legally pursued, have no way to spend the inevitably blacklisted assets, and we would lose all future value that can be captured by successfully progressing RenVM into its final autonomous design. Although the team is temporarily maintaining control over RenVM, we see this as a necessary step in the early days of the network to keep it maximally secure."

Regarding Audits

The RenVM team has undertaken numerous, progressive audits of the RenVM codebase. When Chaosnet was launched it was specifically promoted by the team as an unaudited, pre-production implementation released for testing purposes, reference to this language is below:

“Anyone with 10,000 REN can participate, but with the understanding that this is an unaudited, pre-production version of RenVM.” Link:

So, ChaosNet was never meant to be audited, it was promoted as unaudited, and everyone engaging with that system understood this to be the case. Chaosnet is no longer operational. RenVM is now on mainnet.

RenVM is an audited implementation. In fact, RenVM has had 5 Audits to date (Smart contracts, sMPC algorithm, sMPC code implementation, Hyperdrive 2x) , with more to come, 4 of which can be found here:

RenVM is one of the most well-audited platforms in the young DeFi ecosystem. And the team has consistently taken security extremely seriously as indicated by their slow road to mainnet (key security audits needed to be completed first before they launched), their careful auditing of all aspects of the code, and their commitment to progressive decentralization that puts users first in terms of ensuring they do not fall victim to programming and user errors that put their BTC and other assets at risk.

Regarding Undercollateralization

The collateralization ratio is not relevant at this stage given that the protocol is in the SubZero phase.

Work is underway by the RenVM team to further refine this aspect of the protocol, subject to governance given what we have seen regarding key early-stage use cases for RenVM.

The security model referenced above and the greycore, as well the inherent safety features in RenVM make attacking it exceedingly difficult.

More information can be found here:


disclosure I own REN tokens

All of your arguments were addressed several times and even the REN core team has commented, I just want to give some extra insights.

The team recently confirmed that they aim to be fully decentralized by the end of this year. Of course, no one can guarantee that this will really happen, but we are at least not talking years. You might already know this article (, but still I want to highlight that the team has chosen to be not fully decentralized in this stage, as they want to guarantee network safety at any time. And by being on the mainnet for 5 months without a single incident, they have been successfully doing this so far.

Another argument from your side was the bonded value is not able the secure the network. That would be correct if REN were already fully decentralized. But the team is currently backing up the network. In addition, there are already several ideas to solve this problem and one of them has to be rolled out before full decentralization for sure!

About the step-by-step open-sourcing, I can only say that this is also part of the team’s strategy and that they are well aware of this. Would you write software with new technology and release it without having previously consolidated your position on the market? In addition, the most critical parts of REN have already been fully open-sourced.

In summary, all of your arguments are already being addressed actively by the core team and they aim to solve them by the end of this year.


First, we familiarized ourselves with the RenVM specification and the codebases. After that, we performed manual review on the implementation, concentrating mainly on the logic inside of mpc and shamir.

Yes exactly.

Trail of Bits did an audit for REN from August 3 - 17 2020 where they reviewed

created 30 Mar 2020 (153 commits)

created 4th Jun 2020 (47 commits)

created 7th Apr 2020 (34 commits)

These are parts of RenVM not the whole system.

There is a testnet for RenVM for developers to work with.

I must have missed it in my review, can you please provide a link to how I can run RenVM on the testnet.

The team has been very clear that the full RenVM system has not been open sourced.

You can’t run RenVM on testnet because the full implementation is not yet public.

Once again they’ve been very clear about the rationale and reasons for this multiple times.

The code will be progressively open sourced once it has been tested and audited in production.


disclosure I own KEEP tokens and TBTC

This is not unique to REN I would encourage you to also look at Keep Network.

I was concerned when I read that REN has 9,000 BTC in a single wallet controlled by the team.

Please link me to an audit of RenVM as a system not the components. An audit of the implementation of parts of the system is not the same as an audit of the system as a whole.

Fast forward to when REN is ready for phase 1, how does the collateralization problem get fixed?

1 Like

Appreciate your points of concern. I understand that the portion of the code that has the greatest weight for security is in the sMPC audit. I believe there are currently ongoing audits for additional parts of the code (those from the community, please correct me if I’m mistaken).

For those curious about RenVM’s decentralization plans, please refer to the official medium article that @berni posted. RenVM is being rolled out in progressive stages per Andreessen Horowitz’s guidelines on Progressive Decentralization.

Ren has communicated their approach openly from the start and believes it is the safest and most prudent way to protect users’ funds. There are trade-offs of course (remaining more centralized in the beginning), but Ren believes this is more prudent than releasing an untested protocol into the wild from day one (as we’ve seen with recent releases of tBTC, YAMs, etc.)

Great question! We are debating these exact topics and the proper path forward in the Ren Telegram and Ren Forum. Please feel free to come and offer your constructive criticism to contribute to Ren’s planning for even greater security and stability. :slight_smile:

As a high level summary, Ren has multiple levers (Mint %, Burn %, and Continuous % fees) that can be adjusted to 1) affect volume and 2) affect intrinsic Ren token value (which would increase bonded value aka TVB). Ren is also working with multiple organizations part of the Ren Alliance to increase number of integrations (see original post)

In addition, currently, you need 100k Ren tokens to spin up and operate a dark node (which adds to the TVB). There are also ongoing discussions in the forum to create pools of $Ren token liquidity that would receive portions of darknode fees (at an appropriate % that would be fair to both dark nodes and stakers). This would also increase TVB and increased locked $Ren allowing for a more stable price.

Again, thanks for pointing out your concerns! Hopefully, I and other commenters have helped address your concerns or at least the plans and discussions in place to control for those concerns.

At the end of the day, our audience is the Aave community, so I invite those outside of the Ren and Keep ecosystem to offer their thoughts as well.


Huge support for this AIP and, fully agree with this comment, direct integration (a la curve) would be preferable than just adding renBTC.


Good point, we do need a full and direct integration like it is on curve.


You don’t run RenVM yourself, like you wouldn’t run the Bitcoin blockchain yourself, since it is a network. Join the Telegram channel and ask to be invited to the Dev chat, and you’ll get info on how you can mint testnet renBTC on Kovan.