Open tooling. Hidden operations.

open_code

Operational secrecy trumps openness of tooling.

 

Rationale

Our team at Moonstream has a deep belief in free software, in openness, and in transparency.

We have carried out all our development, research, and planning in the open. Most of our code bases are licensed either under the Apache License, Version 2.0 or the MIT License. We continually publish open datasets under Creative Commons Licenses.

In the past three months, Moonstream has evolved beyond an analytics product into a tool for blockchain projects to manage and secure their on-chain economies. Over a billion of dollars have flowed through our platform. This value will reach the billions, the hundreds of billions, and even the trillions.

Our customers and, more importantly, our users trust us to treat this value with the utmost discretion and security. We bear this responsibility and we accept this responsibility.

The quantities we are transacting have come with their share of attacks against our platform. Attacks that we have successfully defended against, and that we continue to defend against.

Attackers have the advantage of secrecy over builders. Those of us who are building real things on the blockchain must be open about what we are creating. That is the only way to earn our users’ trust. Those attacking the things that we build have the luxury of being able to operate from the shadows, making their attacks known only after they have been successful. What’s more, the attackers extract maximum benefit from the openness of the builders.

For example, in the recent Wormhole attack (where the attacker made off with over $300M), it seems as if the attacker became aware of the Wormhole vulnerability after the fix was pushed to GitHub but before it was deployed.

Defaulting to a position of openness is not a rational, reasonable, or secure way for builders to handle the capital that our users are trusting us with.

We are revising our policy on free software:

  1. We will continue to develop all of our tools in the open as free software. This includes moonstreammoonwormMoonstream DAO contractslocustBugout, and more.
  2. We will stop releasing any code or documentation that pertains to our operations as free software. This code will be developed in private and in secret.
  3. Whenever our need for secrecy comes into conflict with our desire for openness, we will default to the side of secrecy.
  4. We will no longer openly share information about our operations with anyone not on our team.
  5. We will treat anyone persistently seeking information about our operations as a potential attacker. If you do not know how we run our operations, you do not need to know.

Revisiting this policy

There are conditions under which we will revisit this policy.

If there comes into existence a consortium of builders who wish to collaborate on security, we may consider opening up portions of our operational code and knowledge base only to that consortium.