After recently launching our public beta of Zengo wallet, we received a lot of questions about our open-source policy. At Zengo, we believe in transparency; therefore we decided to dedicate this blog post to describing our open-source approach.

The open source dilemma

Giving the public access to code can be a double-edged sword as it provides equal access to both heroes and villains. There are stories of bugs and hacks in both open and closed-source projects.

To illustrate, sharing the source code of our app may help in convincing others that our app does not contain any malicious code or bugs. It also allows users to create their own clients. However, it can also help attackers find vulnerabilities, submit vulnerable code, or easily create fake clients to fool innocent users.

The promise that the eyes of the internet are overseeing the code is often irrelevant, as people are not necessarily incentivized to actually do it. This is even more relevant for young projects that have not yet gained many users.

A famous example of such issues is the “HeartBleed” vulnerability in the popular, open-source, OpenSSL cryptography library. It was introduced into the software in 2012 and, although the code was available online, the vulnerability was publicly disclosed only in April 2014.

Additionally, it is critical to screen contributions from the community in a timely manner and make sure they are beneficial. This can place a burden on our development team, who is currently very busy in building the product.

As open-sourcing our code is a step we cannot undo, we prefer to take a more cautious and conservative approach. Therefore, we decided to take a step by step approach, open-sourcing some of our work in the beginning and then gradually releasing more as our project grows and our confidence in our open-source procedures increases.

What is already open-source…

c (TSS), it was clear to us that releasing the cryptographic code would be of great value to the community. Therefore, everything related to our core cryptography is open-source and we plan to continue to keep it that way. Additionally, we are accepting contributions from external parties to this core cryptography.

You can check out our Github account and especially our core cryptography repositories (for example Curv, Multi-Party-ECDSA).

We have  additionally hired a third party company to audit certain portions of this code base

As we believe in the value of collaborative research, we have shared many research repositories that are not included in the product and we encourage contributions to them. The same goes for tools we have developed for own internal use.

What is not open source (yet?)

We decided currently to keep our app and server code closed-source and only have them audited by an external security company. It is important to note, that even if we had exposed our code, there is no good way to verify that the downloaded mobile app was indeed created from it.

To allow some scrutiny of the downloaded app, we intentionally did not obfuscate the code of the client and it can be reverse engineered by professionals.

Additionally, we are very open to suggestions; for example, if you are a certified professional and you want to privately audit our code, we would be happy for you to do so.

Conclusions

As with many other things in life, open-source is not a silver bullet. It has its own pros and cons, especially for relatively young projects.

We know that the initial instinct for many cryptocurrency users is to use a fully open-source wallet. This is definitely reasonable when using a free product from an unknown source. However,  Zengo is funded by prominent Venture Capital investors that conducted due-diligence on our technology and founders; additionally, we have conducted paid, third-party audits of our code.

Therefore, in order to maintain the hygiene of our code, we currently prefer to be conservative and pay for audits rather than to enjoy the benefits of the “Wisdom of the Crowd”: Our code is authored by Zengo employees and audited by trusted and professional third-party auditors.

This is the same path chosen by other company-backed wallets (e.g. Coinbase wallet).

As open-sourcing our code is a step we cannot take back, we prefer to take a cautious approach to it. We already released some portions of our code and intend to gradually release more and more of our software as open source as we gain more confidence in out process and more momentum within the community.