Every task can be done in multiple ways involving different trade-offs. Therefore, use your best judgment aligned with the following engineering priorities (in order of importance):

Correctness and readability

• Correctness means: safety (no accidental loss of funds) and security (robustness against sophisticated intelligent attackers). For tests, it means completeness (checking all essential paths and conditions).
• Readability means: ensuring the code is not only correct but understandably correct to observers.

These are the baseline values that are applied by default to any code we create. We expect new features to always be tested and reviewed, and we value maintainability and technical debt management.

At times, there may be compromises: we may release a feature sooner than it’s fully tested, or we may cut some corners and release 80% of functionality if allows us to achieve a significant advantage in an area currently considered important. In such cases, it is always expected to be caused by a very specific and explicit business need. Otherwise, we would love people to spend enough time preparing a polished solution.

There are, however, areas that are considered critical code: anything that defines the security of the protocol and user’s funds. This includes, for example, cryptography, ZK circuits, smart contracts, and compilers. In these areas, no compromises are allowed: releasing unfinished or undertested features may have drastic consequences. We are building critical financial infrastructure. One disaster can be lethal for the business. Think airplanes. It took Boeing 100 years to build trust and reputation, and only two crashes within one month to lose 25% of its trust and market value.

Resilience

Our systems should always be available for users. It may come in different forms:

• We aim to have 100% uptime for our servers.
• We should have no unexpected breaking changes for developers who depend on our code.
• We should not sunset services that are still in use.

More often than not, the ability to be resilient is caused by the proper design of the feature. Thus, we value time spent on writing specs and discussing designs for new features before they are released. “What happens if?” is a good question to ask yourself when you start working on something new.

Smoothness

We are creating a product for people to use. And we want our users to seamlessly interact with our systems. Users, in our case, are not only people who interact with our deployments or run our programs but also the developers who use our tooling and libraries in their workflows, so accessibility comes in very different forms and on different levels. For example:

• The interfaces should be clean.
• The actions users do must have understandable consequences.
• The code we provide should be documented.
• The tutorials should be up to date.

This principle applies internally too. Clunky tooling makes it harder to develop a good product and flaky tests extend the feedback cycle.