Best General RenVM Questions | December 2019
*These questions are sourced directly from Telegram
Q: If I plan on building with RenVM, should I join the Developer Chat?
A: Yes, please join here: https://t.me/joinchat/IRgxOk3OGtoQt7lNtBEMBw
Q: How is zBTC (RenVM's shifted bitcoin), different than wBTC?
A: WBTC requires people to go through approved merchants (only merchants can mint/burn) and the reserves are held by a centralized entity (BitGo). KYC is also involved when dealing with merchants.
zBTC mint/burn, on the other hand, is completely permissionless and the funds are held in a trustless/decentralized network (RenVM). Anyone (dApps included) can mint and burn at any time.
Q: Just to clarify - when BTC is deposited to RENVM, that goes to a pool, so anyone can redeem the zBTC at a later date, not only the original minter?
A: That’s correct. Anyone holding ZBTC can burn it. At the moment of burning you specify a Bitcoin address and RenVM will send the appropriate amount of real BTC to that address.
Q: What other demo dApps have been built on RenVM Chaosnet besides ChaosDEX?
A: Roundabout | an experimental, permission-less, non-custodial way to transfer Bitcoin in and out of Ethereum using RenVM's Chaosnet. This is a great example of RenVM’s flexibility and one of the many apps it can facilitate: https://twitter.com/amcassetti/status/1202731973522817026?s=20
Q: Can you explain the models you guys are considering regarding the modified Fee Model for RenVM?
A: Yes so we are thinking through a few potential models but to be clear we’ll have plenty of time for stakeholder commentary via Github once formally proposed but the preliminary feedback is very useful for us, thanks! The two leading models at this time are:
Dynamic Fee Model. More locked funds = higher minting and lower burning fees. To the point where fees quickly scale to “infinity” at the point where “too much volume” is locked up in RenVM.
Let’s presume there is some maximum safe amount of value that can be locked up in RenVM, Max. Max is determined by the number of Darknodes and the value of REN but let’s ignore that for now and just think of it as a static value (for simplicity of exposition, then we will begin considering the finer details).
At 0 value locked up in RenVM the minting fee = 0% and the burning fee = infinity% (there’s nothing to burn). At 100% of Max locked up in RenVM the minting fee = infinity% (we do not want more to be minted otherwise we will exceed Max) and the burning fee is -x% (x being some kind of rebate paid to burners by reserving some of the minting fees as minting gets more and more expensive).
There is a curve that maps the minting/burning fee between these two bounds based on the current % of Max locked up in RenVM. Now, we need to consider what Max is and where it comes from. It’s obviously directly proportional to the value of REN locked up. There’s a few issues here: (a) do we need a price feed? (b) what happens if Max drops suddenly?
(a) possibly not. We can model and expected value of REN compared to the assets moving back and forth. RenVM already knows the fees it’s earning, so it can calculate what a “stable” value of REN is (not including speculation). It can use this calculation (based on fees alone) to determine the “value of REN denominated in the assets being shifted around”. That’s all you need for Max.
(b) you would expect to see arbitrageurs suddenly taking advantage of the burning rebate to bring the value locked back down to a safe level. But also, the neat thing about using REN as the bond is that the stable value of REN is determined only by the use of RenVM. You wouldn’t expect to see a sudden and drop in the stable value of REN if the system was being used enough that it had such a high locked value. (And if you were seeing this, because people were locking up assets and never unlocking them, moving to demurrage would completely remove this problem. Again though, encouraging builders to offer only native asset interfaces — eg always hiding ZBTC from the user — should prevent us from needing to move to a demurrage model.)
Continuous Fee Model: A per-annum fee for RenVM. At a rate of 1% per-annum, it is a reasonable estimate that RenVM could safely lock up the entire value locked up in DeFi right now (based on the current DeFi market conditions).
The effect this has very straight forward, your balance decreases at a rate of 1% per year. Burning 1 zBTC of your balance still gives you 1 BTC and locking up 1 BTC still mints 1 zBTC. Your balance just decreases constantly. A continuous time-based fee (eg charging 1% per annum) is more direct. People would be able to layer things on top of that if they so choose. For example: you could take the ZBTC (degrading at 1% per annum), and lend it on Compound (if you got back >=1% per annum you would have a non-degrading version of ZBTC). One key point is: whatever people choose to do RenVM would be well incentivised for safety/liveness.
- 1% per year is equivalent to 0.002% per day which would, from the user’s perspective, not be noticeable amongst trading fees & market inefficiencies.
- It’s not something that is a foreign concept. All custodians charge per-annum fees, and many banks charge fees on accounts (admittedly, not in %).
Hope that adds some more colour to the conversation, this information will be provided in detail in our new docs as a proposed change to the current static 10 bps fee. Everyone is encouraged to, at that time, put their feedback on GitHub so we can source analysis/criticisms/changes from the community before testing it out on Mainnet SubZero!
Q: Isn't it a security concern if people just leave BTC, etc.. in RenVM?
A: It is a completely valid security concern that BTC gets stays locked up in RenVM because people don’t want to keep moving back and forth across the boundary. This means Darknodes aren’t earning fees and the network becomes less secure. There’s a few things to consider here as mitigation:
- Ethereum won’t be the only destination chain that RenVM supports, and it’s goal is not to “pool” everything on Ethereum DeFi. There’s a bunch of other chains and movement must happen between them in order to share liquidity.
- There’s a level of education we need to provide to our community. Just like we’ve all tried to educate people that exchange wallets aren’t secure for long term holding, the same can and should be done for the RenVM community. When we discuss RenVM integrations with wallets, one of the key things that comes up is designing interfaces where the user is interacting with *real* BTC as much as possible. As a community, pushing for native first and interop second will help create inertia that this is the expected interface.
- See the above message about the upcoming fee improvements. There’ll be a formal description/analysis coming out for them, but TL;DR we are considering dynamic minting/burning fees. Higher minting fees as locked value goes up, and lower burning fees (even negative fees, resulting in rebates for the burner and still providing some fee for Darknodes).
- Most import: it is very hard to predict how people will behave at scale. This is part of the reason for having staged roll-out, the blog can be found here: https://medium.com/renproject/renvm-mainnet-release-plan-761f1c2c0752
Given our team/partners will run the semi-decentralized core of Darknodes that power consensus and execution during that phase; it provides us further room to safely refine and ultimately settled on the most appropriate economic model for RenVM and the stakeholders who utilize it. As the system reaches economic stability it is important that we as the Ren community all put forth our opinions about how we want our system to behalf. Fees not enough to make you feel incentivised? Speak out! This is everyone’s network. There are things like daily holding fees that can be implemented if it results in a better system.
At the end of the day, RenVM must remain flexible and willing to improve any aspect of itself to achieve its goals in the best way possible.
Q: Is it possible to know how many Bitcoins are locked up inside RenVM? And how do you check nothing has been lost/stolen?
A: You can query the Darknodes for this information and compare it to the total supply of zBTC on-chain. https://chaosnet.renproject.io has stats about what the Darknodes are responding to such a query. The data is stored in the Hyperdrive blocks so you can verify the amounts (actually UTXOs) have been voted on by 2/3rd+.
Q: Once the BTC private key is generated, how do you guarantee that the nodes that generated it will be up for withdraw? What are the parameters for the threshold?
A: The system has the same safety parameters as Tendermint: it is safe/lively up to 1/3rd adversarial (or offline) nodes. An emergency out-of-band recovery is possible with up to 2/3rds of nodes being offline. Darknodes will kick each other out if they aren’t doing the required work, and will “reshare” the threshold key to account for kicked Darknodes. More info can be found here, thanks! https://docs.renproject.io/ren/renvm/safety-and-liveliness