Monthly Community FAQ

Monthly FAQs

Best General RenVM Questions | April 2020

Best General RenVM Questions | March 2020

Best General RenVM Questions | February 2020

Best General RenVM Questions | January 2020

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:

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 permission-less and the funds are held in a trust-less/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:

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:

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

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

  3. 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).

  4. 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: 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. 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!

Best General RenVM Questions | November 2019

*These questions are sourced directly from Telegram

Q: My Hardware wallet (Via MetaMask) is having some issues when interacting with ChaosDEX and the Command Center, can you help? A: Be sure MetaMask and the Hardware wallet are up to date, and then be sure your contract data is turned on!

Q: Why are there so many steps when submitting a trade for ChaosDEX? A: We purposely left those in there so developers could see what is happening in the background. For any real consumer-facing app that uses RenVM, these steps can and likely will be hidden.

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). zBTC mint/burn on the other hand, is completely permissionless and the funds are held in a trustless/decentralized network (RenVM).

Q: Can you tell us more about GAS Station integration? What is it and where does the GAS come from? If I do BTC/ZEC exchange-will this GAS be free for me? A: It’s not free, because Ethereum always needs gas. But, we can still hide the gas. So, if you trade BTC/ZEC, we take a little bit of the BTC/ZEC and turn it into ETH. Just enough to pay for gas. This way, as someone trading BTC/ZEC you don’t need any ETH. You’d don’t even need an Ethereum address of any kind! It’s all about user experience.

Q: What's the plan with SAI to MCD transition for RenVM? A: We’ll be taking the slower transition approach with regards to MCD. We’ll wait a week or so, see how everything goes, then provide an update (on specifics) for the community in the November Developer Update. In the meantime, there is no action required for those who have provided liquidity to ChaosDEX.

Q: Hi there, I was wondering if you had any more documentation on the ZKP setup you guys are using over sMPC. I didn’t find anything on it in your docs. A: ZKPs within RenVM are used to verify the compute done by each Darknode (they need to know they’ve done the correct compute, without revealing their secret shares to each other). We have partnered with AZTEC in order to be able to support privacy for tokens once they are on Ethereum. We are also beginning to explore the exact design of bridging ZEC (and other privacy tokens) to Ethereum without compromising privacy. It’s certainly possible, but the design is not settled. Their expertise certainly helps here.

Q: Loong, how come in your tweet you said the 100 transactions were mainly made of people testing BTC <-> DAI swaps, yet the command center shows nothing fee-wise for DAI? A: Because DAI doesn’t need to cross a blockchain boundary. DAI is also not counted in the Value Locked stats so in reality Value Locked is double that of what's shown.

Q: Why is the exchange rate on ChaosDEX so bad? A: With lower liquidity, the slippage is exaggerated. This is how Uniswap based exchanges are designed, for more info go here: you like to add liquidity, you can do so by going here:

Q: Btw, what is your current approach for ChaosDex? Will you somehow incentivize people to use it or you think it would be better for users just to get familiar with it and wait for the dapps from mainnet? A: Tough question. Ultimately, Chaosnet and ChaosDEX are about testing RenVM in the wild. But, lots of use is the best way to get that testing. We will continue to promote it, and also promote testing via the release of challenges (for people earn $ which is always effective). If it begins to gain significant traction we will also look at more serious support for it as a product. But, we plan more than anything to integrate with the existing DeFi apps and DEXs not necessarily compete.

Q: Can someone summarize or point to the definitions of "last cycle, current cycle, change next epoc, and subzero core" please? Just want a better understanding of the numbers they're reporting on the CC 🙂 A: RenVM breaks time down into discrete chunks, called epochs or cycles. This is the time increment at which everything happens: new nodes pending registration will finish registering and become active, existing nodes pending deregistration will leave the network, and payments earned will be distributed

Q: Is 0x a competitor or could they eventually use RenVM to bring cross-chain transactions to their tech? A: It’s more likely we would see integration with 0x. 0x in itself is not attempting to create cross-chain but could definitely benefit from it.

Q: I wonder why they don't make a docker image instead of having to implement each cloud service? A: A cloud provider environment is more-or-less identical to using Docker when you aren’t trying to do any kind of orchestration. Even with Docker, you’d have to have the CLI updated on a provider-by-provider basis because they each have different ways of turning on machines. The setup ultimately ends up more complex, because you need to configure UPnP and storage. And, you also end up paying a small (but noticeable) performance hit.

Q: It would be good to be able to see prices/stats without metamask. A: Yep, agreed! We’ll be adding that.

Q: Do or did ZKPs in Ren require a trusted setup ceremony as well? A: Yes, but we are also exploring using STARKs at the moment (which don’t need a trusted setup).

Q: I had some issues with signing Darknode contract previously. I had to unregister/register the ledger every time I wanted to sign a transaction. Now I sent some ether to a metamask account that doesn't use a hardware wallet and it worked. Now, I'm not sure where the DAI will go. I guess to the address that signed the transaction? A: It will go to the address that was connected at the time the transaction was initiated: eg the hardware wallet.

Q: For BTC withdrawals, how much collusion can be tolerated before it would be considered insecure? In the docs, it mentions The safety and liveliness of RenVM assumes that less than 1/3rd of Darknodes are colluding adversaries. Does this apply for BTC withdrawals? Or would it be a different number?

I guess it is an acknowledged issue that (b) must be less than (a) and the requirement for 2/3 of tokens would make the attack a lot harder to carry out. Suppose a single party obtains 1/3 of tokens, and obtains the private key for existing BTC deposit addresses is it possible for the tokens to be unbonded, sold after 3 months, then withdraw the BTC in the addresses? A: No, by that time, the current keys are rotated. The timings are such that any Darknode that is disbonded no longer holds shares of an active key. It’s worth pointing out, collusion in RenVM is a little harder than in some existing networks because the act of attempting collusion can cause your bond to be slashed. To collude, you need to reveal your shares of a secret. This share can be revealed to the blockchain by the person with whom you’re attempting to collude to slash your bond. So realistically, this collusion has to be between very few parties that trust each other.

Q: Seems GAS usage for RenVM trades are a bit higher than normal? A: The BTC to DAI swap does technically consists of 4 ERC-20 Transfers (per Etherscan), so the GAS cost is a bit more than a single ETH transaction. We have designed the ChaosDEX to be clear and easy to read, not optimized at all (for example, there are more ERC20 transactions than necessary). To be clear though, interop transactions are always going to need more “gas” than normal transactions. Because you need to pay BTC fees as well as ETH fees as well as RenVM fees. We believe we can keep these low enough that the value gain (being able to use BTC on DeFi) is still worth it.

Q: How safe are the Darknode contracts during Chaosnet? A: Darknode Registry contracts (the ones in charge of your REN during registration) have been audited previously by ChainSecurity. They’re being reviewed again right now, alongside all of the other contracts/consensus algorithm / sMPC algorithm. The risk is confined almost entirely to users, very little to behaving Darknodes (which is why we encourage people not to trade huge quantities on ChaosDEX in a single go).

Q: Given the security parameters of RenVM, is there a hard cap on how much can be locked in RenVM Chaosnet? A: At the moment, it’s not a hard limit. This is something enforced by the users (don’t shift if it’s not safe). This is a theoretical limit, it is a lower bound above which an adversary might be able to profit from attacking the network (if they pull the attack of perfectly)

Q: Is there a reason all the info on Darknode via the Command Center is public? A: It’s the blockchain. All this information is public, not displaying it in the UI might lead people to believe that some information is private that actually isn’t. This information actually needs to be public in order for the system to function as expected.

Q: What's the difference between ChaosDEX and RenVM Chaosnet? A: RenVM Chaosnet and ChaosDEX are very different things.

RenVM Chaosnet has no understanding of “what the application is” that it’s minting ZBTC for. It accepts BTC on Bitcoin and mints ZBTC on Ethereum (and vice versa). What happens while the ZBTC is on Ethereum is completely opaque to RenVM Chaosnet.

The ChaosDEX is an application. It’s deployed to Ethereum Mainnet and uses RenVM Chaosnet to gain access to Bitcoin Mainnet. When you transfer BTC to ChaosDEX what’s actually happening is:

1. BTC transaction is sent on Bitcoin. 2. RenVM Chaosnet sees it and creates an authorizing signature to mint ZBTC. 3. The user submits this authorizing signature to the ChaosDEX smart contract on Ethereum. This triggers a big (but single) transaction that does multiple things at once.

Let’s assume you are selling BTC. Then (a) mints ZBTC, (b) sends that ZBTC to the swapping engine inside ChaosDEX smart contract, (c) sends the resulting DAI to your nominated address. This is all one single Ethereum transaction so the user *feels* like they never touched ZBTC.

But, what if you’re buying BTC? Well, (a) sends the DAI to the swapping engine, (b) gets back ZBTC, (c) immediately burns the ZBTC (and RenVM automatically sees this and sends BTC to your nominated address). Again, this is all one single Ethereum transaction so the user *feels* like they never touched ZBTC. The reality is that ZBTC is still being used, but RenVM is designed to allow apps to hide it from users for the best possible UX.

At the end of the day, on Ethereum, smart contracts only ever see/interact with ZBTC. It’s RenVM that takes care of all the other messy non-ERC20 details.

Another way to think about it: RenVM has its own “WBTC” (called ZBTC), anyone can mint/burn it (unlike WBTC), and there’s no central custodian (unlike WBTC). It just happens to have some nice hooks so that all the minting/burning/interacting-with-DEX/DeFi can all be done in one go. I hope that helps!

Best General RenVM Questions | October 2019

*These questions are sourced directly from Telegram

Q: So what exactly is RenVM? A: Ren is an open protocol that enables the permissionless and private transfer of value between any blockchain. Ren's core product, RenVM, is focused on bringing interoperability to decentralized finance (DeFi).

What makes RenVM unique is that it does everything in secret using zero-knowledge proofs over an sMPC based protocol that the team has pioneered. The state, inputs, and outputs of all programs that RenVM runs are kept hidden from everyone, including the Darknodes that power it.

This allows RenVM to securely manage (ECDSA) private keys on different blockchains, making it possible to shift tokens between these blockchains in a fully trustless, permissionless, and decentralized way (i.e interoperability).

Technically speaking RenVM is a byzantine fault-tolerant protocol (with 1/3 malicious nodes) that does ECDSA threshold key generation and signing via sMPC. RenVM is not a product or an application in and of itself but is a network (and an accompanying SDK) that allows developers to bring interoperability to their DeFi applications.

Q: How was Devcon 5 for the team? A: Very productive, plenty of learning and networking. Quite informative for the team and future of RenVM as we received market validation along with some useful tips for improvement (of RenVM).

Q: If I ran a Darknode previously should I shut it down now? A: YES, we encourage all those who previously ran Darknode(s) to shut them down and prepare to run one on Chaosnet (if you so choose). Instructions for shutting down you Darknode can be found here:

Q: Will there be bug bounties for Mainnet and if so, how much? A: We haven’t yet made a decision about post-Mainnet bug bounties. If we have one though, it’ll be reasonably subjective, because you cannot predict the type (or severity) of a bug ahead of time.

Q: Per Vitalik on ETH 2.0: “Ethereum will soon lose the ability to execute transactions atomically. This could change the way developers and traders manage their dApps." Will this affect RenVM's ability to swap with ETH? A: In general, it will affect how devs need to integrate others’ contracts into their own. This applies to RenVM contracts just as much as others. But, nothing about the RenVM interop will need to change, and no changes will be needed by dApp devs beyond the ones imposed across the board.

Q: I'm planning to run the CLI on a Raspberry with a slim Linux distribution, will something like this be possible? A: Not currently, but after the release of Chaosnet, there’ll be a renewed focus on supporting tools for Darknode owners and third-party developers (right now, the core protocol is getting most of our attention). This will include some improvements to the CLI to make it much safer, as well as an even more locked down Darknode deployment (so that, in practice, even Darknode owners cannot access the machines).

Q: Has RenVM been submitted for a security audit? A: Yes, it has.

Q: What VPS provider will be next after Google Cloud? A: We will likely be implementing support for Vultr next.

Q: Is REN’s sole purpose to be bonded for Darknodes? A: Yes, that is REN’s sole purpose within our ecosystem, please check out this faq for more info on REN’s token econ:

Best General RenVM Questions | September 2019

*These questions are sourced directly from Telegram

Q: Given the RenVM Mainnet Roll-out Plan, what are the differences between how Darknodes participate in the P2P Network, Consensus, and Execution within RenVM?

A: An outline of each component and its role in RenVM system is outlined below: P2P Network The peer-to-peer network is used for two core purposes: peer discovery, and message saturation. Peer discovery allows Darknodes to learn about other active Darknodes in their shard, and in the network at large. Message saturation ensures that all messages sent around the network are seen by everyone.

Consensus The consensus engine is used to reach a strict ordering of transactions that go through RenVM. This ensures that the Darknodes powering RenVM are able to agree on what actions to take, and when.

Execution The execution engine is used to run secure multiparty computations. This is how actions in RenVM are ultimately taken. These actions involve generating private keys, signing interoperability transactions, and, in the future, running general-purpose application logic. And all of this in secret.

Q: All of this de-registering and re-registering for mainnet is a bit annoying, is it necessary? A: We do certainly understand the point as it's been discussed at length but registration for the RenVM Mainnet is a necessary component (applying automatic updates for current Darknodes to run RenVM is not technically feasible). This announcement is very much an administrative piece to ensure our community has plenty of time and notice to proceed at the speed they prefer. Chasonet is designed for testing and those willing to actively experiment, but certainly not mandatory and there is no pressure on the general community to be active during this period.

In summary for those who prefer to be less active, should de-register their current Darknode(s) and wait patiently for activation at the release of Mainnet SubZero, no other action is needed.

Q: How do I shut down my current Darknode(s)? A: Follow this instruction set explicitly and you won't have any issues:

Q: Is running a Darknode on Chaosnet useful for the team? A: By running a Chaosnet Darknode you are inherently helping us test. One of the core purposes of Chaosnet is to the real world incentives of RenVM. Running (and continuing to run) a Chaosnet Darknode says something about the incentives at play: they’re enough to get people running Darknodes. And this helps us! In fact, by not running a Chaosnet Darknode you’re also inherently helping us test. It’s telling us there’s something not quite right with the incentives.

Q: And what's the incentive for someone to collude and attack the network during Chaosnet? A: The ability to steal real BTC/ZEC/BCH, the want to help us test the network, the want to betray their fellow colluders and take their REN bonds, and of course, some (wo)men just want to watch the world burn.

Q: Is RenVM secure against quantum computing? A: The core of RZL sMPC is theoretical secure. This means that no amount of compute power can break it (making it post-Q safe). There are some parts of it that are not (zkSNARKs and some hashes that aren’t known whether or not they’re post-Q safe) but these are easy to replace (with zkSTARKs and some post-Q safe hashes).

RZL sMPC provides ECDSA signatures because that’s what it is used by Ethereum, Bitcoin, etc. Whatever solution they come up with, will be the solution that RZL has to be upgraded to use (the whole point of RenVM is not to tell other chains how to do things, and still provide interop; this means waiting on them to define their solution and then working with that).

In short, if a QC can steal funds from RenVM, it’s because it can steal funds from any Ethereum/Bitcoin/etc. private key.

Q: If I don't deregister my Darknode by RenVM Mainnet, will I lose my 100K REN? A: The REN bond is safe forever. You can deregister your Darknode from the legacy Mainnet whenever. We recommend doing it now, because it can take three days, and once Chaosnet rolls around that’s where our support focus will be.

Q: When shifting in funds, say a user doesn't have eth funds and this call fails const newSigResult = await ethSig.submitToEthereum (web3.currentProvider). what is the best way for that user to pick up where they left off if they leave the web page to get some ETH, and then come back? Should the app generates a new shift in the object, override the params and gateway address objects, re-submit to RenVM, and then make the above call again? Assume the transaction info such as original params and gateway address are stored in local storage so those will be available when the user comes back.

A: This is the approach we take. We store the RenVM tx in local storage and then when the user comes back we can construct the Ethereum tx and hand it to them for signing again. You can construct the RenVM tx locally and store it before asking the user to send their BTC to the gateway to protect against unexpected shutdowns. This way, you can recover from them leaving the app at any point in the process without loss of funds. (This also allows you to resend the RenVM tx in the event that the first send fails for any reason.)

Q 1: Could you elaborate on the proportionality of (a) Total value of bonded REN (b) Total value of assets under RenVM control? Does RenVM require (b) <= (a) at all times? RenVM would need an Oracle to determine the USD value of both (a) and (b).

A 1: The oraclisation is done by the Darknodes. Each of them assesses what they determine that value of (a) and (b) to be and if 2/3rds of them independently decide (b) can be increased then the network will be able to go ahead with the computation. We do require (b) < (a) but have not determined the exact ratio. Because Darknodes are randomly sampled (and constantly reshuffled) from the entire group, this value can consider the entire amount of REN bonded (not just the REN bonded by one shard).

Q 2: There's potentially an incentive-misalignment issue here: Darknodes would want to bypass the (b) < (a) limit in order to continue to process more tx's and collect fees.

A 2: True, but there’s also a natural incentive for Darknodes to want to keep the network secure. A hack would likely render their REN to drop dramatically in price and they’re REN will be locked for 2-3 months after deregistration. This is also true of users. They should be wary of keeping assets locked up when it nears the secure threshold. This can be encouraged by scaling down the burning fees/raising minting fees to encourage the movement of funds “in the right direction”

Q: Quick question: right now, a developer can choose to wait for 0 confirmations before minting zBTC on Ethereum when shifting in real BTC. Will the RenVM network require a minimum number of bitcoin confirmations, or is that always up to the application developer? If it's up to the developer, what if the developer chooses 0 confirmations, mints zBTC, and then double spends on the bitcoin network, invalidating that original bitcoin transaction? shouldn't that invalidate the zBTC that was already minted from the original 0 conf transaction?

A: The developer cannot choose. RenVM will wait for the appropriate number of confirmations. On Testnet, this number is currently set to zero because it makes testing easier. On Mainnet, there will be systems for people to take on the “confirmation risk” and provide float. Devs can also set it up so that people can deposit ahead-of-time. We are also exploring Lightning and similar concepts.

Q: I've noticed an increase of tx's made through RenVm, how tests are going on; have you met any unexpected obstacles?

A: We’ve encountered a few issues with nodes when they are rebooted/crash (we are constantly rebooting/crashing them to make sure the network continues to operate as expected under those circumstances). But, we have fixes in the work for all these issues and it hasn’t prevented us from being able to add new features (BCash and SegWit support has recently hit Devnet and will be arriving on Testnet soon).

Q1: If home chain = destination chain, then RenVM is effectively a mixing service? A: It can be used that way, definitely. But, it has to have a few more privacy features enabled, shifting alone won’t do.

Q2: RenVM mints Aztec notes for example? A: Yep, that’s the plan. But we need to wait until the Ignition ceremony before this can be done. It’s one of the next features in our pipeline though! BTC would “appear” on Ethereum with no known owner. And, if you wait an amount of time between getting the authorizing from RenVM and using the signature, then it would be impossible to trace it back to the request that went to RenVM.

Q: When I go to the Command Center, the page doesn't load? A: One has to be on the Kovan Testnet (on Metamask). To do this, select the top middle button on your Metamask tab and click Kovan Test Network (Purple circle). If you’d like to see it in action, submit a trade on our Testnet Dex Demo ( and see it proceed through RenVM via the Hyperdrive tab:

Q: Mixicles & RenVM: It seems like Mixicles could be used to preserve privacy features for on and off-chain settlements in a blockchain agnostic way. Wouldn’t this be seen as a threat as smart contracts could now replace a darkpool while maintaining the element of anonymity?

A: Mixicles (and all other ZK on-chain stuff I’ve seen) gives you privacy on the chain. So you can prove things have been done right (one of the things we like about public blockchains), without exposing any information about the thing (an issue with public blockchains). But, the prover still has access to the information. This rules it out for many kinds of private apps. RenVM gives you absolute privacy. You can do things with data, and prove things about data, without anyone anywhere ever knowing anything about the data. This is much more general.

Q: Can’t people just fork RenVM?

A: What ultimately prevents forks is the network effect. All projects that want to take decentralization seriously need to open-source their implementations. Almost by definition, a decentralized network is nothing but its community of people willing to work together; this is the very essence of “trust no-one except for the majority”. If you refuse to open-source you don’t have a community, you have hostages.

Building up momentum and creating a large network and community is incredibly valuable and not something that can be forked. Bitcoin is still Bitcoin, despite the large number of forks that have been created, and most of the time forks don’t overtake or outpace the original because there is too much inertia in the original community.

There are other, less philosophical, benefits too. Open-source code means you can get more feedback, people can help fix bugs, identify potential security issues, anyone can validate the implementation, people can build their own implementations (resulting in highly desirable “N versioning” which prevents a single bug compromising all nodes).

Best General RenVM Questions | August 2019

*These questions are sourced directly from Telegram

Q: So RenVM is essentially a BFT protocol (with 1/3 malicious nodes) that does ECDSA threshold key generation and signing? Is that right?

A: Yes, that's exactly what we have! We are exploring getting this to 1/2 and are confident it is possible, but the current implementation on Testnet is 1/3. Just today we also pushed an update that doubled the speed (and halved the bandwidth) of the sMPC signing algorithm.

Q: Have any tests been done on the speed of Interoperability?

A: The Testnet demo is live and open to the public, have a play with it and let us know about your experience (including speed). We have done some preliminary profiling; numbers look good so far. Fast enough for a single shard to keep up with Bitcoin.

The next version of RZL sMPC is under development and will introduce pre-computations that significantly increase the peak performance of RenVM from 10 TPS to over 100 TPS (these numbers are based on our initial conservative estimates).

Q: Currently, we see a quick performance of the swaps. When migrating to the mainnet (considering there will be real mainnet of say 250 Darknodes and real BTC, ETH, etc.) will it affect the speed?

A: Speed is a complex issue when it comes to RenVM. I'll try and break it down:

The biggest concern for speed is that RenVM needs to wait for a transaction to be confirmed on one chain before shifting the tokens to another chain. When working with Bitcoin this can take hours. -So latency is unavoidable (think of latency as how long a tunnel is) -So what about throughput (how wide the tunnel is)?

First, how to solve the latency problem. Well, we cannot actually solve it because we cannot change Bitcoin. But we can work around it by using "Universal Interoperability." In this model, a third party takes on the confirmation risk. While RenVM waits for the confirmation of a transaction on Bitcoin, the third party steps in and fulfills the Ethereum side of the transaction with BTC that has already been shifted previously. When the Bitcoin transaction is finally confirmed, the third party is refunded using the newly shifted BTC. This means the third party is taking on risk (the Bitcoin transaction may be shuffled away), so they charge a fee to cover this + their services. This means that the shift can be almost instant, and the only thing we need to worry about is throughput.

We believe we can get 10 TPS throughput, which is more than Bitcoin, so throughput isn't a problem (we only need to be as fast as Bitcoin). For other chains that are faster, we can introduce multiple shards. If one shard can do 10 TPS, then 10 shards can do 100 TPS.

I've described this process with Bitcoin, but it works for any pair of chains. Also, the third party cannot be guaranteed to step in (maybe they don't want to take the risk today) but if they do not, then the transaction will still go through but just at the slower speed. If the third party does step in, they're guaranteed to be refunded. So the introduction of "Universal Interoperability" does not introduce any central trust into the system.

Q: So Universal Interoperability is a partially centralized thing?

A: No because any third party can step in and provide the service. Further, the processes involved are all handled by smart contracts.

Q: Has there been a discussion of security in terms of sharding? Getting 1/3 stake and compromising a shard is obviously much easier than compromising the network, what's everyone's thoughts on that?

A: Yes there has; once you move to a sharding model, the risk of an attacker gaining control of a shard becomes a probabilistic problem rather than an absolute one (for example if you're sampling with replacement, in theory, a single attacker can corrupt the whole network).

Let's say an attacker owns enough of the network to have a 2^-1 chance of corrupting a shard (expected time to attack = ~2 days). If you are using a 20/20 multi-sig, where each shard controls one signature, then the chance of corrupting enough shards becomes 2^-20 (expected time to attack = ~2800 years).

In line with this example, the shard could be around N=24 (which would have a corruption chance of ~0.56) so each shard can be very fast (and shards would be running in parallel). Obviously we want to avoid multisigs (they're expensive and not all blockchains can support them) but this is mostly an example of the larger concept: requiring multiple shards to work together.

Q: Just got curious if the bug-fixing and developing has been overwhelming since the release of testnet? How do you feel it's been so far?

A: I wouldn't say overwhelming. It's definitely keeping us busy. Finding bugs and fixing them is actually very satisfying work; it reduces stress by increasing confidence, and this helps improve motivation and productivity.

It's also good to be able to revisit parts of the system and go about perfecting them. Often in software development, there is the adage "never optimize early". Well, the time has finally come to optimize (not just performance, but design, safety, etc.). Everyone wants the thing they build to be perfect, and being able to make that the focus is an awesome feeling.

Q: Is there a reason for having private repos?

A: It's important for the success of the network to maintain a competitive advantage, and important to avoid "day zero" bugs from people that find them but don't report (in the hopes to take advantage). We'll be getting the code (and our maths) reviewed and audited, and probably show it to first adopting groups so they can verify it themselves, and as Mainnet grows we will open-source everything, along with a Transperency Plan that outlines when and how repos will be open-sourced.

Q: My Darknodes still show the old command center. How do I view them on the new one?

A: The new Command Center is for RenVM specifically (and it's only viewable on RenVM Testnet); once we switch Darknodes over to the RenVM network, they will utilize the new Command Center.

To play around with it, put your MetaMask on Kovan Test Network. A video that a community member created can be found here:

Q: Digital Ocean (DO) sent me a message saying my VPS would be down for maintenance, is this an issue?

A: Nope, this is just part and parcel of using a VPS. From time to time, they need to do maintenance. They will inform you if you need to take action.

This is a real-world example of why it's crazy to expect a decentralized network to have all participants online all the time, and why you cannot "incentivize" being online by punishing being offline. It's unavoidable even when there are entire expert teams with years of experience on the job. The more nodes you have, the more likely any one of them is to experience an issue like this at any one time.

Your REN is not at risk if your Darknode does go offline. It is also unlikely that a Darknode that is offline due to these kinds of circumstances will remain offline long enough to be forced out of the network.

Q: Will the community darknodes be partaking in the RenVM Testnet, or are you using your own nodes to test it out, or is it a gradual deploy?

A: The team has about 24 Testnet Darknodes that power it. We may open these Testnet nodes up to a few groups in the Working Group, but no public participation of Testnet Darknodes will be pursued at this time.

Q: A couple of questions for the team: 1) Bonded REN value informs how much value can be securely shifted through RenVM at any given time. If bonded value drops below the threshold, are there any risks beyond incentive to collude which arise? is there any liquidation risk ala TBTCsigners? 2) Does RenVM enforce any time floors/ceilings on shifting/locking tokens? I assume anything like that would be enforced by a third party like Compound?

A: 1. There are collusion risks but we plan to mitigate this by having Darknodes able to "tell on each other" so if you are colluding with someone that you don't trust 100% you risk losing your bond so attacks only really make sense if you own all the colluding Darknodes (which, by definition, isn't really collusion it's buying up a bunch of REN). There is no liquidation risk. This is one key reason why we bond using REN, not another token; the "value of REN" is tied only to the use of RenVM. The safety of RenVM is predicated on the use of RenVM. RenVM is used = RenVM is safe

2. No time ceilings. We've been having discussions about how to keep Darknode well incentivized to maintain long-term deposits, but (a) most of RenVM's UX is built around handling the native token, not a wrapped version of it (how is a BTC maxi going to get a hold of ETH to use their ERC20 BTC?), and (b) payments will be paid out over time to RenVM not instantly so this creates a more stable income for the Darknodes instead of large but infrequent lumps of pay, (c) we got another trick up our sleeve that I'll be adding to the GitHub any day now, (d) if you have ideas about how to incentive Darknodes to maintain BTC that is being deposited long-term, please feel free to let us know! Q: Has there been a pattern established where third-parties could pay the gas for the eth transactions needed during shifting? For instance, would it be straightforward for an app dev to pay the gas for the user but add a small additional fee onto the RenVM transaction? They would pay the gas in ETH for the user in exchange for that value collected in BTC or zBTC?

A: This is going to be very straightforward for devs. We are designing examples as we speak to set the standard for doing this and therefore make integration as easy as possible. Q: Can a RenVM gateway addresses be reused? As in if a user creates a gateway address for 0.1 BTC, can they send exactly 0.1 BTC that address, mint zBTC, and then repeat that process again without creating a new gateway?

A: Currently no, a gateway can only be used once; but we are in the process of creating that feature and it should be ready within the next month or so.

Q: What’s the best way to set up a Darknode If I only have Microsoft? A: We do not formally support a Windows CLI as of right now, but we are adding Windows CLI support prior to Mainnet, so please do stay tuned.

Best General RenVM Questions | July 2019

Q: Is your Testnet Demo the new version of RenEx?

A: It’s just a simple Dex we created to showcase RenVM’s functionality. It is not RenEx, nor will we likely be pursuing the creation of a standalone DEX. This demo is based on a Uniswap liquidity model so automated market-making (testnet tokens). To be clear, we created this to showcase RenVM’s functionality (this demo will remain on tesenet only). It is not RenEx, nor will we likely be pursuing the creation of a standalone DEX.

Q: If someone wants to send BTC from one wallet to another privately, how exactly do they choose this option? Will it be a button they can click on their exchange or how exactly will a user interact with ren to privately send their transaction?

A: The actual BTC itself cannot be private. Once you’ve sent it to RenVM though, you can opt to have it “appear privately” on the other side. The initial shift is visible because the underlying Bitcoin network is not private, but once it gets shifted you could then use it privately. Also, if you’re using something like ZEC you will be able to do private interop in full because ZCash itself does support privacy in its own network.

Q: Can you explain the Privacy aspects of RenVM?

A: Privacy of the actual transaction through RenVM will come after the initial release of RenVM.

Firstly, we will continue to work with AZTEC and follow up with a release that can mint straight into private AZTEC notes (and vice versa). Secondly, we will work on allowing privacy tokens (e.g. ZCash) to move from one chain to another without anyone knowing how much was moved.

These two privacy features won’t be available from day one. They will be the result of lots of collaboration with a few other projects to ensure the security and correctness of our development. This takes time, so these features will be released one by one after RenVM hits Mainnet.

Q: Could you elaborate on how the address on the destination chain is deterministically derived from the address on the source chain? What is the reason behind this determinism?

A: The gateway is a Bitcoin script (or ZCash script, or equivalent on other chains). It contains a hash of all the data associated with the shift, and the script can only have its funds claimed by RenVM.

It is deterministically derived so that the user, third parties, and RenVM can all derive the same gateway without communication and so that when RenVM sees funds transferred to the gateway it knows exactly what its meant to do with those funds.

Q: For RenVM to work there certain # of block confirmation considerations on mainnet though? just wondering what the expected time to complete a deposit of bitcoin to compound would take (assuming reasonable gas prices)?

A: The # confirmations depends on the chain and must be set at the time the chain is admitted into the protocol. For Bitcoin, this is 6 confirmations. This obviously takes a long time and, while it’s not so bad for some use cases (lending, collateralization, etc), it’s very bad for dapps/DEXs.

So, we have the concept of Universal Interoperability. This allows a third party to provide two things (in exchange for a fee nominated by you):

(a) Provide gas so you don’t need to manage lots of different tokens, just the ones you’re actually using for the dApp.

(b) Provide speed by taking on the confirmation risk. The third-party sees you have (let’s say) 1 confirmation and is confident you’re not some supped up miner about to attack Bitcoin. They come in and provide the shifted BTC immediately to complete whatever action you were taking, and when the real underlying shift finishes they get the funds.

This can be done to greatly ease the user experience: gas and speed. Of course, we have designed it to remain trustless (If the third party doesn’t act then you can just spend the gas yourself can just wait and/or everything will still happen but at a slower speed).

Q: How many darknodes should we ideally have to achieve a secure network?

A: This is really dependent on the total amount currently being shifted between chains at any one moment. The best you can theoretically do with sMPC is 50-67% of the total value of REN used to bond Darknodes (RenVM will eventually work up to 50% and won’t go for 67% because we care about liveliness just as much as safety).

As an example, if there’s $1M of REN currently locked up in bonded Darknodes you could have up to $500K of tokens shifted through RenVM at any one specific moment. You could do more than that in daily volume, but at any one moment, this is the limit.

Beyond this limit, you can still remain secure but you cannot assume that players are going to be acting to maximize their profit. Under this limit, a colluding group of adversaries has no incentive to subvert safety/liveliness properties because the cost to attack roughly outweighs the gain. Beyond this limit, you need to assume that players are behaving out of a commitment to the network (not necessarily a bad assumption, but definitely weaker than the maximizing profits assumption).

Q: So do you think that the total value of bonded tokens could be an obstacle for 3rd parties to adopt interoperability layer?

A: Not for DEXs, since these don’t keep value locked up for long and have at least some time to rebalance when needed. For other longer-term lock-ups, it could be limiting but the fees brought in by DEXs and other dApps will help to increase the REN locked up and thus the limit. We also have a rollout plan in place that we’re working on with other projects to ensure that the limit is sufficiently high and secure during the early days.

Q: Anything currently planned with going from side chain to side chain (lightning to plasma or xdai for example)? Thinking it could speed the process up without worrying about block confirmations and expand the use cases.

A: We are focusing on the canonical first layer blockchains right now. There are some loose plans with some side chains, but we cannot speak too much to that at the moment. From a technical perspective, RenVM can do it, it’s just a matter of focus and core value (which comes from the largest liquidity chains, which are not yet any side chains).

Q: What will/is the scripting language for RenVM again? Is it Rust?

A: The general scripting platform won’t be available initially. This is a much bigger endeavor that the initial release of RenVM which will focus solely on interop. All scripting will remain in frontend apps and in smart contracts on existing blockchains.

Q: Hi Loong, is it possible to use privacy as an option in RenVM. Something like verge wraith protocol option to choose privacy. Let's say some institutions/exchange want to use RenVM for interoperability solution without privacy for regulations. This is possible now or any future plans?

A: Just another side note, privacy and regulation can play together very nicely. Private on the public chain doesn’t imply that an institution can’t reveal the underlying data to a regulator if required (just like a bank account these days doesn’t need to be seen by the whole world for a regulator to access an institution's records).

But better than that, we are entering an exciting era of cryptography that could allow people to prove beyond a computational doubt to regulators that they are doing all the right things, without ever having to reveal their underlying records. Thanks to the magic of zero-knowledge proofs and technology like RenVM.

Crypto, and to an even greater extent “secret crypto”, is an opportunity for regulators to do their jobs better. And it’s not like it enables criminals to do anything they aren’t already doing with cash. The “fud” around privacy being destroyed by regulators is because regulators don’t yet understand the maths, and what it can empower everyone to do. Anyone who claims “privacy means regulators can’t ensure you are doing things legally” either doesn’t fully understand how privacy in crypto can work, or is being malicious in intent.

Q: Can you give an example of how you envision regulators to use “secret crypto”?

A: Require all institutions to use private USD on the blockchain and generate zero-knowledge proofs about their activity to guarantee that no money laundering is happening, no book fudging is happening, only whitelisted addresses are being interacted with (or blacklisted addresses aren’t being interacted with), covering both national and international transactions, exchanges, guaranteeing the number of transactions made in different amounts, etc. Not something you can do with modern money systems. But it becomes possible with zero-knowledge based blockchains.

For example, recently in Australia, a royal banking commission found out banks weren’t doing things “the way they were supposed to” and failing to comply with AML based on amounts being transferred between different types of accounts (if I recall correctly). This could be made impossible to even do in a blockchain (if adopted fearlessly by regulators), let alone do and not admit to doing, and by using zero-knowledge systems the banks wouldn’t have to reveal all their inner workings publicly to achieve all of this.

Q: The current state of the most advanced sMPC is that it is so painfully slow that in no way it could be used practically for something like what Ren is claiming. If they solved this, it is extremely big.

A: For general computations, yes, this is true. Modern sMPC is algorithms are very slow. But, to start with we are not focused on offering general-purpose scripting, just the ability to interoperable between chains. This comes down to generating keys / signing with keys without revealing the keys. Even then, most modern algorithms are slow, and do not offer liveliness guarantees that suit decentralized networks.

This is where our key innovation lies. We haven’t invented some totally new form of sMPC (at its core, RZL is an extension of the classic BGW / SPDZ class of algorithm). We have improved these protocols to have simple, lively, and less data-hungry preprocessing phases that scale to hundreds of machines. Sample that from thousands, and you have very strong security.

If you're interested in more of the details, our main improvements have been around the way that multiplication can be done (specifically, avoiding needing Beaver triples and, when you cannot avoid needing them, generating them more efficiently than can currently be done).

As it stands, our algorithm works nicely for key generation and signing. It also works well for small “trusted compute bases” that you might want to keep secret. With a normal blockchain, you wouldn’t put your entire app on a smart contract because it’s not efficient. Likewise, when general-purpose programming is available, you wouldn’t put your entire application there. Just the parts you need to keep private between many parties.

Q: Is there any plan to publish work about this that could be peer-reviewed to ensure that your modifications maintain the safety and privacy guarantees of the class of algorithms you're deriving from?

A: Yes, absolutely. We are going to get the paper reviewed, and the implementation audited.

General RenVM Questions | June 2019

Q: Is the 'Testnet Demo' a new version of RenEx?

A: No, the demo is just a simple Dex we created to showcase RenVM’s functionality. It is not RenEx, nor will we be pursuing the creation of a standalone DEX at this time. This demo is based on a Uniswap liquidity model, so automated market making (of testnet tokens). To be clear, we created this to showcase RenVM’s functionality (this demo will remain on Testnet only).

Q: How difficult is it for existing dApp to integrate with RenVM? Let's say dYdX; how would they deploy and how much time is required to accomplish it?

A: It’s relatively simple. Existing smart contracts that support ERC20s will not have to change. Small adapter contracts will need to be deployed in front of the existing contracts, but most of these are the same and the Ren dev team is building several examples / helping others build theirs. Minor UI updates are also needed to show users a BTC (or ZEC or USDT) address to deposit their funds to and we have a JavaScript SDK to help with this. Our goal is to make it as simple as possible to integrate RenVM.

Q: How is RenVM "100x faster than atomic swaps"?

A: Atomic swaps are interactive so they require multiple steps one after the other and can take up to 24 hours to complete. At each step, one party has to wait for full confirmation before being able to begin. Ren is non-interactive and does not always have to wait for full confirmations.

Further, atomic swaps and RenVM are not really comparable. RenVM can do everything atomic swaps can (it’s also faster and requires no custom software from the user). But, it can do a lot more than that. RenVM allows smart contracts on one blockchain to exert control over tokens from other blockchains. This is not something atomic swaps can do. Yes, you can use this for swapping (and you’ll get a much better outcome than using atomic swaps) but you can also use it to collateralize loans, creating vesting contracts, store funds in escrow, collateralize the creation of DAI, and anything you can dream of programming into a smart contract (and anything that has already been built into Ethereum, because RenVM plugs and plays with existing contracts!)

RenVM is a full interoperability solution and will have the capability to interop privately too. Atomic swaps are only swaps, and they’re always going to be public.

Q: Has the Darknode Registration Cycle moved to four (4) weeks?

A: Yes, Darknode registration has moved to a four (4) week cycle. Any Darknode that is currently registered does not need to do anything, and will not be affected in any way. If one wants to register a new Darknode, this means that individuals must register and then wait up to four weeks before it will become formally active and start receiving rewards.

Our new Command Center will have a countdown clock and many other resources to make the registration process as simple as possible.

Q: How would RenVM source liquidity?

A: RenVM would facilitate the cross-chain swap of assets for the DEX itself; liquidity comes from the respective exchange participants. RenVM is a tool (ie. plug-in) that exchanges, lending apps, and other various DeFi applications (3rd parties) integrate to bring real cross-chain assets to their platforms. It is not a public exchange mechanism itself.

Q: Why are there Kyber & Uniswap GitHub repos?

A: The Uniswap and Kyber repos on our GitHub are us building adapters to these projects. We’ve made them public as part of our documentation to help other developers understand what it looks like to integrate RenVM into new/existing smart contracts.

Q: S, after interoperability layer (RenVM SDK) is deployed, Renex will work on top of Renvm?

A: Once the interoperability later is deployed, our focus will be on helping projects integrate and adopt it. Usage is important for supporting a healthy number of Darknodes, which is important for security (and thus its usability). After we have completed the rollout, we will look at upgrading RenEx.

Q: What are the main differences between Ren and Keep network?

A: From a non-technical perspective: they are tackling a different problem; custody of private keys and signing. Think of it like a hosted wallet service but not as centralized. I say “as” because the sMPC algo they describe cannot remain lively under the loss of one node, and only uses a relatively small number of nodes. RenVM explicitly tackles interoperability, can remain lively and scales to a larger number of nodes.

Q: If I exchange ETH for BTC using some RenVM solution, how does the asset transfer look like publicly? I send ETH from an address, it ends up where, and where is the BTC "stored" before it's sent to the address I put in as the receiving address? Can someone track this transaction so they can infer what my BTC address is, if they know my ETH address for instance?

A: Yes, for now, this will be traceable. When you “send BTC from Ethereum back to Bitcoin” you’re actually burning the BTC on Ethereum and associating a Bitcoin address with this burn. RenVM sees the burn, and reading the appropriate amount of funds to the associated Bitcoin address. Because this all happens on-chain without the assistance of ZPKs, it is traceable. Once we have the L1 interop working and deployed to Mainnet, we will be implementing the capability to do this all in zero-knowledge (and this is a key part of our collab with AZTEC).

Q: What assets will be initially supported via RenVM?

A: Right now we’re focusing on BTC and ZEC to ETH. After this, we will be expanding to other tokens based on the needs of projects that we’ve been engaging with.

Q: When you deploy smart-contracts to Renvm, will be privacy provided there?

A: We have yet to actually considered the privacy of contract deployers. This is certainly possible, but tricky to get right. Unlikely to be possible in the first iteration of RenVM.

Q? What kind of metrics are used to determine if a node is malicious? The issue is that in theory it is reserved for bad actors, but can you guarantee that a flipped bit or other ephemeral hardware error while running the legitimate darknode software would not trigger it?

A: Your Darknode can verify its own proof before broadcasting it. This can protect you against flipped bits. If you fail to broadcast a proof, you are just considered inactive (which doesn’t cause REN bond loss). Caveat: this is not currently done.

Q: I like the eth 2.0 idea where punishment is proportional to how many other nodes went offline at the same time .. it harshly punishes rogue cartels' mass shutoff while only mildly punishing an honest node that just failed?

A: Well, we haven’t actually committed to slashing. Just loss of rewards earned in that cycle. Slashing is reserved for provable misconduct, whereas going offline is just reward loss. There are a few models that deem this sufficient. A proportional slashing is an interesting concept though (it does make single nodes vulnerable to a DoS though).

Q: Bandwidth (communication complexion ("frequency") between nodes) in sMPC ~= O(multiplication circuit depth in sMPC). Local multiplication optimization can lead to global bandwidth reduction?

A: Yes, but possibly not for the reasons people might think.

Making local multiplication lower-latency shows us techniques that we can use to reduce the depth of any kind of CLA operation. Reducing this depth allows us to reduce the overall depth of any program involving CLA operations (pretty much all interesting programs). Depth is interesting because, when it comes to sMPC, the depth of a program is the number of rounds of communication required to execute the program. As Chomsky points out, the number of rounds of communication is ultimately the deciding factor when it comes to performance (reducing rounds does reduce bandwidth, but bandwidth isn’t usually the problem in decentralized networks; latency — proportional to the number of rounds — is the problem).

As a side note: multiplication in sMPC (including in RenVM, even though RenVM uses a unique kind of multiplication that is faster) doesn’t actually model itself as a circuit. It is just a constant number of local operations + one round of communication + bandwidth (and the latency of the local operations is minuscule compared to sMPC latency so we can essentially ignore it). The reason we care about low-latency multiplication on local machines is because we can use the same circuit techniques to build logical circuits that have logarithmic depth. For example, computing less-than-or-equal between two N-bits numbers in O(log N) depth.

Simply put, in all sMPC algorithms:

Arithmetic is 👍

Logic is 👎

But advances in low-latency hardware help us improve our sMPC algorithms such that logic is less 👎 than it otherwise would be.

Q: What are the issues with TEE/SGX?

A: This is a quote from researchers on this subject. Compromising SGX isn’t a speculative concern. It happens: “We demonstrate that instead of protecting users from harm, SGX currently poses a security threat, facilitating so-called super-malware with ready-to-hit exploits,” the researchers conclude in a paper, entitled Practical Enclave Malware with Intel SGX ( “With our results, we seek to demystify the enclave malware threat and lay solid ground for future research on and defense against enclave malware.”

General RenVM Questions | May 2019

Q: Is RenVM in competition with Cosmos/Polkadot/Aion, etc.?

A: No, we're actually big fans of these protocols and RenVM complements them quite nicely, as it can serve as ‘pegged zones’ and bring an elegant solution to the legacy blockchain integration issue they face.

In general, RenVM is bringing interoperability to Ethereum and the world of DeFi instead of asking DeFi projects to come build on their respective smart-contract protocol. Another way of saying it is, most current interop projects are creating a protocol standard and bringing other (new) blockchains into that standard. RenVM takes the other approach and brings itself to others (new and existing) blockchains.

For a more in-depth understanding of how RenVM work we encourage individuals to listen to this podcast:

Q: So is it right to think of RenVM as tackling some of the same problems a project like Aion is trying to solve? But in RenVM's take we have the advantage of privacy built in to the protocol?

A: The advantage of privacy is one aspect. The biggest aspect is that RenVM works with existing blockchains. We don’t have to wait for blockchains to implement our standard, instead, we can hook into them straight away. Furthermore, control is distributed to hundreds if not thousands of nodes instead of other naive solutions which are limited to 20 (and that’s not really decentralized)

Where RenVM wins out over other sMPC is that we have developed a new technique that makes the kinds of elliptic curve crypto that you need efficient and scalable and (most importantly) it works even if up to 1/3rd of the nodes try to abort the computation. All other solutions out there right now will fail if even a single node goes offline.

So not only is our solution the only one that is fast enough to be usable with a large number of nodes, it’s also the only one that can survive the kinds of faults that you would expect to see in a decentralized and Byzantine environment.

Q: How is Ren’s Interoperability solution different to that of WBTC?

A: The Ren interoperability solution is a standalone initiative developed in-house by the Ren team. It is a separate solution to that of WBTC.

WBTC utilizes a centralized custodian model. BitGo serves as the authority which mints and burns BTC to create WBTC and then distributes it via a set of Merchant's (ie. exchanges) to disseminate (RenEx being one of them). However, only BitGo has the ability to mint and burn. It is, therefore, a centralized, permissioned custodial model for wrapping BTC and bringing it into the DeFi Ecosystem.

RenVM’s removes the need for a centralized custodian, which mean anyone or any DeFi app can mint and burn BTC or any other digital asset, seamlessly. This allows DeFi applications to plug the RenVM solution into their existing smart contract infrastructure, which allows individuals to send real BTC, etc. to DeFi application; users never have to worry about minting or burning when interacting with a dApp. It is, therefore, a permissionless, trustless, system which allows for fluid movement of cross chain assets in and out of the DeFi ecosystem (ie. interoperability).

With this said, the WBTC model can utilize our decentralized custodian model, to mint and burn WBTC if they choose to allow a permissionless custodianship of WBTC. We will not show favoritism or preference, as our solution is permissionless, anyone who would like to utilize our interoperability capabilities, can do so. We helped build, and continue to support, the WBTC initiative because it allows the adoption of BTC on Ethereum today. As the ecosystem grows, we will, of course, see many different types of solutions for different use cases. Some people like, or even require, custodians and WBTC will continue to serve this part of the market. RenVM will open the way for truly permissionless and decentralized interoperability.

Q: How would RenVM compliment something like the Decred Atomic Swap exchange? Would it essentially become another aggregated order book that would interact with RenEx?

Atomic swaps demonstrate that exchange intermediaries are unnecessary, so it is natural to remove them. The server will only assist in the price discovery and order matching process, and it will be entirely non-custodial.

RenVM is a natural replacement for Atomic Swaps wherever they are being used. Its decentralized nature means that it is not introducing “intermediaries” that can interfere with the process. Interop using RenVM is faster than atomic swaps, it is non-interactive (parties do not have to be online all the time and cancelation cannot happen), and it is compatible with all wallets (no special software is needed by the user).

Q: Fee Model: So in summary, we get a percentage of what moves through RenVM and DAI if it's not a normal trade?

A: That is essentially correct (w/ some nuance); check out our fee model overview for more detailed information:

Q: Can you explain the new fee model’s intent? A: The focus of the changes to the fee model are two-fold:

First, the new contract ensures even distribution of fees to all actively participating Darknodes more consistently (instead of having to wait a month for a larger payment, everyone should see more frequent smaller payments). This comes as a direct result from feedback from all those that have been running Darknodes.

Secondly, to make it possible for more varied applications to utilize RenVM. To access its interoperable liquidity layer, but also to prepare for the general purpose scripting capabilities. This widens the use cases for RenVM drastically, increasing the avenues for fees to flow to RenVM (this supports more Darknodes which makes the system more secure which makes it able to handle more liquidity and the positive feedback cycle goes on). It comes at the disadvantage of not being as customized for the specific use case that is dark pools.

Q: The reason for choosing DAI seems based on the fact that is decentralized and that team is betting in its adoption, what is the plan if that adoption doesn’t occur. How the network can be affected if that adoption does not occur?

A: Governance is a tricky topic and not one that we have seen a reasonable solution to yet. But, if Dai fails to remain viable then we will change as needed. If there isn’t another decentralized stablecoin available at that time, there are other options (such as letting people pay in anything and just let the Darknodes make up their minds about what is acceptable; obviously lots of kinks that would need to be worked out but nothing that can’t be managed).

Q: Why did you use DAI instead of REN for the upfront payment to darknodes?

A: In addition to the points raised in our recent blog, this approach brings greater external value and therefore security to the network; instead of creating a circular value system where Darknodes need REN, to earn REN. REN could easily be used as the payment token along with its use as a staking mechanism. However if this was done, it would greatly increase the token velocity, which limits the scope of potential value capture of REN. Referring to Kyle Samani’s report from Multicoin Capital on New Models For Utility Tokens, by using another token for payments, REN becomes what Samani describes as a ‘work’ token, similar in function to other tokens such as REP. With a work token “increased usage of the network will cause an increase in the price of the token. As demand for the service grows, more revenue will flow to service providers. Given a fixed supply of tokens, service providers will rationally pay more per token for the right to earn part of a growing cash flow stream.” That is, the valuation can be estimated using a net present value (NPV) model (a multiple of the system cash flows).

This is in contrast to payment tokens (tokens used as money) such as Filecoin that are valued as a fraction of the revenue paid to the service providers. To explore this concept further, we encourage you to read Samani’s report if seeking to understand the thinking behind our design choices.

Q: 0.1% seems high and may incentivize forks. Maybe start with 0.01% and increment later (proportional to how much liquidity comes in). Liquidity is the strongest moat, needs to be bootstrapped well (recall how the 0.5% interest in MakerDao resulted in explosive growth in Dai (to long eth))

A: This is ultimately subject to what the Darknodes choose to accept. But, bootstrapping has to start somewhere and it has to start at a level where lower volumes (as the platform is adopted) can support a baseline number of Darknodes for security. It’s a bit of a chicken and egg problem, and we are approaching it by starting with higher fees than we anticipate long term.

Without a reasonable number of Darknodes, there isn’t enough security, so there would not likely be serious volume. On the flip side, once there is serious volume then lower fees are enough to sustain a reasonable number of Darknodes.

Q: Should/can Ren itself run nodes + subsidize initially to solve the chicken/egg problem? Maybe the smaller users/dApps can be spared fee at least initially? It is a fact that small fish won't pay for privacy, they just don't care. OTOH having such low-value tx's through the network increases legitimacy and trust for the big fish?

A: A smaller cut of larger amounts is definitely preferable. But larger amounts will not be safe to use with a low number of Darknodes. We will be running Darknodes ourselves once the interop layer is available, and there is a very specific rollout plan to help drive Darknode numbers to a secure and sustainable level whilst also adopting volume.

Q: It sounds like traders in a dynamic fee dark pool can pay fees in the tokens they're moving, which is great for them. But for Darknodes, that means fees will pay out in volatile assets just once per month. What are the arguments against swapping the dynamic fees for Dai? Sounds like a disconnect between the dynamic fee and much of what Tai discussed in his Medium about volatility.

A: It’s true that volatility is an issue for the dynamic fees. But the tradeoff in terms of (a) smooth user experience, (b) volume based payments even when volumes are private, and (c) not having to separate payment from work done is absolutely worth it. Darknodes will also ultimately be deciding what they’re accepting into the interoperable liquidity layer.

Q: Interoperability will come with a significant premium for traders then, in the order of tens/hundreds of thousands of dollars per block trade (relative to using a dark pool with decentralized matching and centralized settlement for pennies). You mentioned in the Wyre podcast that you've gotten feedback from desks. Have they indicated a willingness to pay in the order of a 10,000x+ private settlement premium?

A: A hypothetical dark pool would not be offering their services for free. They would be charging their own % either way (and this is typically higher than 0.1%).

RenVM is aimed at decentralized use cases. Decentralized dark pools, DEXs, DeFi apps etc. that what to charge X% can instead charge X-0.1% or if they don’t want to absorb the cost then the trader has an extra 0.1% fees (which I’ll touch on in a moment). The alternative is trusting a centralized settlement layer with your funds (and as we’ve just seen yesterday with the $40M+ Binance hack, this isn’t a good idea). It’s not just about the privacy of the settlement. It’s about the trustless nature of the settlement, removing counterparty risk, and being able to store your funds where you deem to be appropriate.

The 0.1% is a starting point to bootstrap things (and is subject to change). Before large volumes can be safely transacted we need lots of Darknodes which means we need lots of fees. In this initial phase, the volume will be lower and so fees need to be higher to sustain Darknode numbers. As volume grows, the fee can be reduced without resulting in the loss of Darknodes.

Q: Can a centralized dark pool using the matching engine then get away with paying pennies in fees for block trades?

A: It will pay for the work it consumes. The challenge is that allowing general-purpose scripting means that “forcing” dark pools to pay per volume at the order matching level is impossible. They could just defer to the general purpose scripting level and write the same functionality there.

If settlement was being done on RenVM, as oppose to order matching (or in addition to it), then the interoperable liquidity features of RenVM are being engaged which requires special instructions that cannot be built using general purpose scripting (in theory you could build them but they are so wildly inefficient that it’s not reasonable to use general purpose scripting in this way).

As it stands, the only known way to do private interoperable trades in a way that is decentralized, trustless, and unable to be canceled by either party (the precise needs of a decentralized dark pool but also a wide range of other financial applications) is to use something like secure multiparty computation and RenVM is the only solution that is efficient enough at curve cryptography to actually make this usable in practice.

Q: What would be the recommended fee model for a dark pool with non-monetary assets? For example, consider an exchange between two token identifiers representing shares in a prediction market.

A: Whatever the computations/data required to do that exchange are would dictate the minimum fee. Increasing that can be used to prioritize the work over other work.

Q: Requiring an upfront fee for limit orders isn't great UX. At the dark pool layer, why not return the fee for canceled orders? Is that different from a trader spamming the network with unrealistic orders using a dynamic fee?

A: This would allow people to attack the virtual machine by getting it do work that it isn’t being paid for. When using dynamic fees, the fee is an intrinsic part of the computation. With Dai fees, one has to come before the other and doing the compute first would allow an attack scenario where you request a heavy computation and then don’t pay for it.

Q: Hence my last question: how does that scenario differ from a trader spamming/pinging the network with orders that will never be filled in a dark pool using dynamic fees?

A: Because dynamic fees are only available for the movement of tokens. Order matching (the stage that comes before settlement and thus movement of tokens) is not in itself the movement of tokens and so requires Dai fees.

Q: Say for an unfillable limit order, is it in the realm of cents? Fractions of a cent?

A: That’s about what I’d expect. Just under 1c depending on the number of orders on the book (and we will continue to push that lower as we reduce the hardware requirements of Darknodes). Still 50-100x improvement over Ethereum in regards to cost and speed

Q: Then can a trader could just spam the venue?

A: The venue can implement its own spam protection. RenVM itself is permissionless so it can only use economic incentives to protect itself. Applications can apply their kinds of context-specific restrictions (KYC is an example of such a restriction, albeit not one around spamming)

Q: You say here that everyone should see more frequent smaller payments, but in the blog, it says payments will be once per month. Which one is correct?

A: Both are correct. Fees will be allocated to Darknodes more frequently (and this will be reflected in the DCC) but Darknodes will only be able to claim these fees at the end of each payment cycle.

Q: For example, theoretically if 4 weeks cycle starts 15th may all darknode which were registered will earn fees but if somebody registers a node 16th may his node will be off and he will be waiting half a month to earn fees, correct?

A: If you are not already registered and whitelisted before a cycle begins you will not earn fees in that cycle. The optimal behavior is register and whitelist on the last day of a cycle.

Q: What date new cycle will start?

A: Cycles are currently set to be 7 days in length so that Darknodes that are already registered are able to get whitelisted quickly. Soon we will move to 4 week period but certainly, let the community know when we make that switch via a formal announcement.

Q: If I deregister my Darknode with Pending Fees in my DCC will I lose them? A: Yes, The safest thing to assume: if you haven’t withdrawn the fees when you deregister then you will not get those fees if you deregister. It says “Claim again in 11 hours”. At the moment, the cycles are set to only one day, to ensure time for all Darknodes to correctly adjust to the new contract. But, a cycle will usually be 4 weeks. See the messages above about why.

Q: Do we have to manually claim pending fees to move them to withdrawable?

A: You can manually claim fees to move them to withdrawable. But your Darknode will do it automatically for you (assuming it has enough gas)

Q: Are the cycles ‘prorated’ so to speak? As I understand, a node needs to be active for the entire cycle in order to receive rewards? Does that mean if I deactivate a node after a cycle begins to downgrade my vps I am ineligible for rewards from that entire cycle?

A: Yes, this is done for three reasons.

The first is that you get a better $ per month overall by only having to claim your fees once per month (claiming requires gas, therefore costs a bit of money, a couple cents per month is okay but every day or even every payment is looking worse).

The second is that it enables a more even distribution of the fees over the course of the whole month.

The third, and the most important is that it forces stability. The security and liveliness of the network depend on people keeping their Darknodes running (this is just as important as having people running nodes). Having to wait a month is an economic incentive to maintain the Darknode for the whole month. Your hardware expenses are billed once a month and salaries are typically quoted once per month so this is the reason for the particular choice of four weeks (whole weeks are nice and it’s just under the one month cadence).

If you fail to maintain the Darknode sufficiently during a cycle the Darknode will not earn fees ever again (you will need to deregister and register a new one). In the latest version of the Darknode CLI there is now a command that will resize the hardware for you without causing much downtime (or needing to deregister and reregister).

Q: Are you still planning to Release 3rd Party tool for Darkpools in Q2?

A: We are aiming to put out dev tools but not for third-party dark pools. We will be releasing them for third-parties to use the interoperable features of RenVM as this is the more general feature. Simply said, cross-chain interop needs to come first, otherwise dark pools won’t be that useful.

Q: Wrt decentralized dark pools, I think you mentioned that RenEx is no longer being pursued as a formal product. 1) I know it's a "demo," but is it being deprecated? What should we expect from it going forward?

2) There are no other decentralized dark pools yet. Are you expecting most dark pool volume to come from new, upstart dark pools not built yet or existing dex's planning to add dark pool functionality?

A: As RenVM progresses and the interop layer makes its way to Mainnet, RenEx will be upgraded to make use of these new features (and by extension pay these new fees). We expect volume to come from some new applications being built by other teams and from integration into existing DEXs / DeFi.

Q: You seemed to insinuate yesterday that a prediction market dark pool should use the Dai fee model rather than the dynamic fee model. Assume an Augur market with YES and NO shares, where shares are represented by ERC777 tokens. They don't have an explicit monetary value outside of the Augur contracts. If a trade is made with these shares, then rather than Darknode operators manually having to cash in these shares for Dai on Augur, could there not be a RenVM<>Augur swapper that swapped the shares for Dai? Thereby making the dynamic fee possible for these assets? Darknode operators may be left with an assortment of YES and NO shares from various markets that are worthless unless they're redeemed for Dai in Augur. My question is: other than a RenVM<>Augur swapper, what would prevent a dark pool from using the dynamic fee model?

A: The settlement layer for RenVM only really comes into play for cross-chain settlements. In the case of Augur <> Dai this would just settle on-chain, unless you had explicitly built a script into RenVM to manage this secretly. In this case the movement of the fungible token would require dynamic fees but the movement of the NFT wouldn’t.

The biggest challenge is finding a way to express these fees in a way that is generalizable. We don’t want to embed a whole bunch of specific cases into the protocol. All these scenarios are subtly different and it is better to have one or two rules that captures most use cases optimally and some use cases sub-optimally than to have an indeterminate number of rules (every time someone builds an application we would be asking ourselves “how do we modify the fee rules to accommodate this?”)

I could imagine a way whereby Ren requires Dai fees to be dynamic by “estimating” the equivalent price of NFTs moves (i.e. transferring an NFT of equivalent value of $X would require X*0.001 Dai). But even this is specific to the use case of NFTs.

Q: will you be able to run a Lightnode client side, in the browser?

A: Not in the browser. The intent is that Lightnodes will be what the browser interacts with. The nature of SSL prevents Darknodes being able to be accessed directly by browsers (most block https => http content) because Darknode do not have their own domains and therefore cannot have SSL certs (and even if they could this requires a centralized authority to provide it). Lightnodes alleviate this by allowing developers to deploy them behind their application domain so that the browser can communicate with it over SSL, and then it can communicate with the Darknodes.

For more information, please read the docs available at and listen to our latest podcast here:

General RenVM Questions | April 2019

Q: Why is there no specified roadmap and timeframes for RenVM, can you unveil anything we can expect?

A: We’d really love to be able to give out timelines, but the nature of a lot of our work is very research heavy, requires reviews and audits, and lots of double, triple, quadruple checking of the underlying maths. This makes it very difficult to predict timelines precisely. We avoid giving out loose timelines because these get repeated throughout the community and the “looseness” doesn’t. This can result in a lot of confusion and misinformation about what will be coming and when. With that said, we’ve made extraordinary progress faster than we anticipated and hope to show off some awesome demos of the RenVM interoperability in action this quarter.

Q: What exactly is Hyperdrive?

A: Some applications that one might want to build on RenVM — especially those that focus on RenVM’s upcoming capability to perform instant cross-chain settlement that can plug straight into existing DEXs / dApps — do not need much state and can get away with the consensus that is implicit to secure multiparty computation (the thing that allows RenVM to run programs in secret but still be decentralized, trustless, and permissionless).

But, some applications might want state and this requires stronger consensus than those implicit to secure multiparty computations. So, we decided that RenVM should have an explicit consensus mechanism (the thing that allows blockchains to do what they do). There are some other subtle benefits to having this too. To this end, we built a modified version of the algorithm used by Tendermint (the blockchain platform used by Cosmos) and we are currently testing it. It is blisteringly fast and will only get faster with more testing and (hopefully) some signature optimizations in the future.

Q: What are some examples of not so obvious use cases for RenVM? How exactly projects may be able to utilize it?

A: Well other than being able to use it for interoperability, one of the ones that we find interesting (Note: we are not building this) is that someone could create a way for people to sign transactions / control their private keys using usernames and passwords (with password recovery) in a completely decentralized way. This improves the user experience because now you don’t need users to buy into wallets and learning about private keys; they get a system that they are familiar with.

Q: Will it be possible to build on top of REN an Ethereum mixer as Coinjoin is for BTC?

A: In theory, yes, this will be possible once we open it to developers to build their own scripts. But, we are focused on private interoperability this year. This means allows DEXs/DeFi on any blockchain to work with tokens on any other blockchain, and to do so in secret. Mixers may be able to leverage this technology (haven’t thought too deeply about it but it seems reasonable), but if not, then definitely once development opens to all.

Q: Will the Ren team subsidize Darknodes?

A: No, the most sustainable and transparent way forward is to only ever pay Darknodes for the work they do. We opened the Darknodes to be run by the community as soon as we could, even for the smallest amount of Darknodes. We were (and still are) eager to get our technology on the path to decentralization and to begin seeing the technology operate in the hands of others. This is a huge step in understanding the economics of the system in the real world, the limitations of the technology outside of a pristine controlled environment, to get real feedback from real operators based on real experience, but it also serves another important purpose for us: getting anyone and everyone as involved in the development of Ren as possible. We’ve already made so many improvements because of this approach and this feedback. Having our community be involved in Mainnet Beta is a step towards decentralization.

And this segues into another key point. This project is so young. Decentralization isn’t something that just happens. Right now, our dev team is working hard to make a protocol that can be truly decentralized but this is a long process. To ensure stability, to ensure fast and iterative responses to market needs, and to make sure the protocol is the most sustainable protocol for private and interoperable liquidity possible.

Q: Is the Ren team taking the “build it and they will come” approach for network growth?

A: No, we are not taking a “build it and they will come” approach nor are we building our solutions in a vacuum. We’ve discussed this in podcasts and will address it more in upcoming blog posts, but to make it clear. The focus on private and interoperable liquidity with RenVM (bringing the solutions we had to build for dark pools to all of the decentralized world) is an expansion of the protocol per direct market needs. We are ensuring the protocol is maximally utilized and above all providing real value to the Blockchain space. We are talking with projects and developers to use the private and interoperable liquidity features of RenVM but we cannot talk specifically about any project. For their own privacy, and to prevent unnecessary hype we like to wait until we have a larger announcement with lots of ironed out details.

Q: Have you developed RenVM because RenEx hasn’t succeeded as a product?

A: No, RenEx is a public facing demo of our technology and it is not being pursued as a formal product. Our core focus is an improvement at the protocol level. Further, we realized the problems we had to solve for the back-end of RenEx were the same problems that everyone else had. So why stop Ren at being just for dark pools? Let’s make it the protocol for private and interoperable liquidity for everyone. Projects get more value, the rest of the Blockchain ecosystem gets more value, huge problems in the space are solved, and the Darknodes earn more in the long run (driving the whole protocol to be more decentralized, more secure, and therefore more used, and this becomes a positive feedback loop).

Q: How is RenVM setup with regards to layer 2 on some of these protocols like Bitcoin and Ethereum? Swapping BTC on layer 1 will take you a while with 10 min block times and need to have a couple of confirmations to be safe. Waiting that much isn't great UX.

A: Clear documentation will come out about this soon. Everything happens on Layer 1 but we have a concept that’s somewhat analogous to “universal login” but for interoperability. This drastically speeds up the swapping of tokens. As for using Layer 2 networks directly, it’s something we have in our dev pipeline for when we have gotten the initial Layer 1 out there and being used in other projects.

Q: Does the team have a vision for security tokens in RenVM or is it too early to even consider these kinds of scenario: 51% as to belong to US citizens, therefore, transactions could be canceled at the settlement level if the transaction would not respect that rule?

A: RenVM is at a lower level. It’s much more akin to Ethereum itself than it would be to a DEX. I’m the scenario you’ve described, there are many avenues for working with securities on Ethereum and maintaining privacy and 51% held by US citizens. Exactly how this is achieved is irrelevant to the Ethereum core devs, all that matters from Ethereum's perspective is that it is flexible enough to model any kind of application you want (incl. securities). It would be crazy for Ethereum to introduce built in custom support for securities. It’s up to others to build that on Ethereum.

The same is true of RenVM. It offers privacy and interoperability, and will have it's very flexible scripting capabilities opened to developers. On this, people can build whatever solutions they want: DEXs, dark pools, lending, leveraging, securities, KYC, whatever you can think of. Our job is to make sure RenVM is safe, fast, and flexible enough for as many use cases as we can. On that last point, RenVM can do any kind of computation, so we can be fairly sure that any application you can dream up is possible on RenVM.

Q: I don't quite understand why Ren is partnered with AZTEC, what is different AZTEC from zk-SNARKs/STARKs? Key differences in anonymity of the entire transaction?

A: AZTEC provides on-chain privacy. Let’s say you want to swap ETH/ZEC then you need something on Ethereum (i.e. AZTEC) that can shield the ZEC transaction, otherwise, you would lose the privacy afforded by ZEC.

Don’t confuse anonymity with privacy. Anonymity is not explicitly provided by AZTEC (no hidden addresses), only privacy (hidden amounts). You can simulate anonymity with privacy by creating a bunch of dummy zero-amount transactions so you don’t know who was actually receiving the actual funds.

Q: Does RenVM use ZK-SNARK?

A: To an extent, but not for users. zkSNARKs/STARKs are needed for Darknodes to prove stuff to each other but this doesn’t really concern the user. It’s an implementation detail under-the-hood.

Q: I'm trying to compare and contrast secret-sharing-based (Ren) vs SGX based (Enigma) MPC. To me it boils down to: compute overhead (SGX) vs bandwidth overhead (Ren). Someone said that an SGX node is 10x more expensive, but what I would like to know is whether Ren will also have a similar cost bandwidth wise (due to message passing overhead inherent to secret sharing)?

A: Have a quick Google for “SGX Vulnerabilities”. They’re always being found and you are reliant on Intel to fix them. One is also reliant on Intel to design & manufacture them, and also to verify the enclave. So it’s quite centralized around this one party.

Q: Has as any dApps been implemented on RenVM? Can you report performance?

A: Our open development for RenVM (where people can build anything they like) is not available yet, and will not be an immediate focus for us. Our immediate focus for RenVM is private and interoperable liquidity. This starts will achieving decentralized cross-chain swaps between different blockchains so that DEXs, dark pools, and all kinds of DeFi can benefit from tokens outside their own blockchain’s ecosystem.

There is a substantial overhead to sMPC. It is orders of magnitude slower than a “no privacy” solution. However, this is always the trade-off with decentralization/privacy/security on one hand and performance on the other. Concretely, this question is difficult to answer because it very much depends on the application (arithmetic is much closer to normal performance than logic, for example) and it depends on how many Darknodes the application wants to distribute itself over. With that said, RenVM allows dApps to choose the balance that fits its needs best.

Q: So on RenVM one can build privacy-preserving multi-chain exchange with custom logic, but not arbitrary dApps, correct? (i.e. RenVM isn't Turing complete)

A: RenVM instruction set is Turing complete but we are not focusing on open development right now. Our primary focus is private and interoperable liquidity: ensuring DEXs, dark pools, DeFi app, and other dApps can access and control liquidity from as many blockchains as possible is our top focus, and then the privacy of this access and settlement is our next focus. This is done with precompiled RenVM scripts with specialized optimizations. After all this, we will look at opening RenVM for people to building any kind of private dApp.

Q: Is RenVM is going to support WASM?

A: It depends on exactly what the rule set is around how the WASM is interpreted and some other open questions (is everything secret by default, what about certain data types, is Turing completeness actually useful for blockchains). But, by the time we get around to this open development of RenVM we will be engaging the developer community more for their feedback and input.

Q: How do you see RenVM and Cosmos interacting, if at all?

A: We really like the Cosmos project. One downside to it, though, is that it only allows blockchains to interoperate if they are built specifically for Cosmos. So this leaves out Bitcoin, ZCash, Ethereum, etc. To support these, Cosmos needs what are known as Pegged Zones which is just a name for “insert the same interoperability problems that all other blockchains have here”. However, we see RenVM being able to act as Pegged Zones for Cosmos and bridge BTC, ZEC, ETH, etc into the Cosmos ecosystem which will be fruitful for both ecosystems.

Q: I'm skeptical of "1000 nodes on Tendermint" how is this possible?

A: These tests have been achieved over a local network, so are not inclusive of network latency that will be introduced. However, we haven’t yet finished optimizations, so we haven’t yet allocated resources to deploying 1000 nodes distributed around the globe. This performance is well within our desired bounds though, where it will not impede the performance of our sMPC.

Q: Will users be able to query the state of an application on RenVM without paying a fee?

A: To an extent but will depend on the type of query. There’s active and passive querying. Because querying secret data requires checks and balances/encryption/permission layers some querying requires a payment because Darknodes have to do non-trivial work. Some querying, on the other hand, doesn’t require non-trivial work and is free.

Privacy and Interoperability Questions | March 2019


Q: RenVM will provide zk-txs soon, will it be possible for all chains supported by Renvm? Should this be a problem for BTC txs?

A: We can do things such as bridge tokens over to Ethereum and have them transact privately from that point (bridged over and turned into an AZTEC note) - e.g. WBTC or other bridging methods. Anything that RenVM supports could have the possibility of being able to do this - including BTC.

That is - the zk-transactions will operate on Ethereum (AZTEC zkproofs aren’t possible to run on BTC), but in effect all coins will be able to be transacted privately because we will be able to bridge them over Ethereum as needed in the system.

Q: How does Zexe compare to Ren [in particular the comments on private exchange]?Zexe: Enabling Decentralized Private Computation - new academic paper from Sean Bowe of Zcash, John Hopkins, Cornell, and UC Berkley

A: [Analysing] their security and privacy parameters you’ll see that they cannot achieve the same types of privacy that Ren does:

- In intent based trading the maker must reveal their intent and only the terms are able to be discussed privately

- In order book trading only the identities are anonymous, exclusively, or the order book operator knows the details of the orders

This is because they are using variants of the crypto-primitives used by ZCash (an awesome project). While being able to maintain privacy from “the network at large” you cannot do so from the prover, who must know everything.

In general, this restriction applies to all computation done under the framework described by this paper (and in fact any known zero-knowledge compute system that doesn’t use sMPC). To simplify it a little: someone, at some point, must know a lot of information. This person does all the compute and then proves correctness without revealing the data they used. This is privacy in a decentralized network, but it is not decentralized privacy. You cannot combine the inputs of an arbitrary number of parties and do computations without someone knowing all of the inputs.To make it clear we are really excited about the possibilities of these types of approaches to privacy and are complementary to what we are trying to achieve (for example our collaboration with Aztec) but we are just pointing out that there are different use cases for different privacy technology approaches and sMPC is needed for privacy over multiple inputs.

Q: I have a question about the capabilities of transferring in zero knowledge. I've read the whitepaper and litepaper - is there more info on zk txs in Ren?

Is it possible to apply zk privacy to something like Bitcoin, such that users have the same privacy as zcash?

A: For completely zero-knowledge tx's on-chain, we are using Aztec Protocol technology. Aztec is Ethereum based - but what we can do is bridge tokens privately through RenVM into Aztec notes.

So for example using RenVM we can bridge Bitcoin into a Bitcoin Aztec Note and then inherently it would have similar privacy properties. But it is not possible to do this natively on the Bitcoin chain.


Q: How is Ren aiming to achieve interoperability using RenVM?

A: RenVM uses secure multiparty computations to take decentralized custody of tokens from a guest blockchains, and then authorizes the minting of these tokens to the host blockchain. A host blockchain is a smart contract capable chain - this allows all applications like DeFi on the host blockchain to use these tokens as if they were native to the host blockchain. For example: RenVM could take decentralized custody of BTC and then mint an ERC20 representation of BTC on Ethereum, allowing DEXs, dark pools, leveraging, lending, and collateral platforms to use BTC.

Essentially in concept it is like a decentralized WBTC.

Q: How does Ren compare to other interoperability approaches?

A: If you think about porting Bitcoin to another blockchain, the best you can do is a X-out-of-20 multisig. This isn’t decentralized. So while cosmos blockchains are interoperable with other cosmos chains (or, similarly, polkadot to other polkadot chains), they cannot easily interop with other blockchains that don’t implement their protocol. The best you can do is bridges or “pegged zones” and there’s a lot of trust there (pegged zones for BTC would cap out at 20 custodians, not even as much as EOS which is widely criticized for not being decentralized)

RenVM takes a different approach by letting 1000s of nodes take custody of a key (essentially creating up to an X-out-of-10000 multisig). All blockchains use private keys, and therefore all blockchains are compatible with RenVMs model without having to change. RenVM could even port polkadot chains to cosmos chains!

Q: Is there less friction/restriction using RenVM for interoperability than using another blockchain that specializes in interoperability? What are the trade-offs?

A: Interoperability at the protocol level (Cosmos / Polkadot) is the best way to do it, in theory, and Ren is a big fan of this approach and both of these projects. It’s fast, secure, and can tightly be integrated. But, there will never be just one blockchain protocol. Bitcoin isn’t going anywhere and it’s very unlikely to massively change itself to be compatible with these other protocols. Same with Ethereum, ZCash and many many others. RenVM acts as a bridge between all of these: it is the most general form of interoperability and is as decentralized as other blockchains (RenVM has the same safety and liveness properties as Tendermint — which is what powers Cosmos).

The main tradeoff is not having that protocol level integration which always allows for specialization and optimization.

RenEx and SwapperD Questions | March 2019

RenEx & Dark Pools

Q: Potential users have given feedback that they want completely private txs/trades, does this mean that they want even the transaction coming after order has succeeded to be private (i.e. the settlement)?

A: Yes, this is a large motivation behind our reasoning for developing out the ‘zk-transactions layer’ of Ren, and we have partnered with AZTEC Protocol to achieve this.

Aztec Protocol partners with Ren

Q: Is it possible to merge the order book with 3rd parties with RenEx or will it be separate?

A: Ultimately it is up to the dark pool operators but yes it is possible to share liquidity once multiple dark pools are running on Ren as long as they are using the same settlement method. Each operator needs to determine its compliance requirements, for example for RenEx to share its order book liquidity with another Dark Pool, that Dark Pool would have to meet the same KYC standards.

Q: Is there any way to determine the liquidity on a private dark pool? If I’m a trader looking to use one, how will I know that there’s enough liquidity to fill my order without excessive slippage?

A: It is a private order book, so one would not know ahead of time what orders/available liquidity is on there but traders can adjust their order parameters in such a way that if there is any slippage, the order won't fill.


Q: How is a new SwapperD wallet created? (How does SwapperD Mnemonic Phrase and Password work?)

A: Cryptographically secure mnemonic is chosen and the password acts as a path. Both are needed to access the private key (neither alone is sufficient). Both are needed to access the private key (neither alone is sufficient). The same key/method will be used for all blockchains stored in SwapperD.

The password isn’t stored anywhere. It, combined with the mnemonic, is used to generate a private key every time you need it. This is why SwapperD asks you for your password when you take actions.

Q: Is it possible to have hardware wallet integration with SwapperD? When would this be ready?

A: Yes this is possible but there is not an approximate date for this yet. It is a feature that we’d like to include in future releases of SwapperD

Q: It says you need password and the 12 word mnemonic to restore your SwapperD account but could you access the ETH wallet via MyEtherWallet with the 12 words?

A: No, you need the password. This is something that makes SwapperD secure: the password is never stored so even if someone gets ahold of your computer and your mnemonic, they still cannot access your funds.

You can access the BTC and ETH wallet as long as you have both the mnemonic and password you set the wallet up with.Q: Do you need to KYC to use SwapperD?A: KYC is not needed to use SwapperD, it is only needed for using RenEx.