Proposing the Satoshi Oath for developers

In a time that is rife with corruption scandals and disillusionment in existing financial and political institutions the blockchain has a set of properties that has made it so attractive for so many people across industries as well as across the political spectrum: decentralisation, immutability and neutrality. But in the messy real world that we inhabit, these properties are only a set of ideal values that people might strive towards or use to their advantage rather than features that are always and fully guaranteed by the architecture.

This much can be learned from the past few years of governance crises across the major blockchain projects (see for example the DAO / Ethereum hack and Bitcoin block size conflict). Somewhere along the line, someone is making decisions and writing code, somewhere there is someone with a different idea or version of decentralisation or neutrality, and not everybody has the same types of capacities to engage with and act in the system. That is not necessarily a bad thing. Disagreement and differences should not be repressed. But what this does mean is that the problem of governance, of power and authority is not simply resolved through technical architecture, it has just radically changed shape and character to include algorithmic processes and cryptographic proof.

The Satoshi Oath for developers is designed to draw out the edges and limitations of the technical architecture in guaranteeing these values and to help each person clarify what exactly they mean for each given project they might work on. It is a tool to think through how a project might relate to the people and environments that it affects and to think beyond code.

To do this, it takes each of these three central properties of the blockchain and adds two helpful concepts to start questioning how values like immutability, neutrality and decentralisation relate to the social contexts where they are being applied: Power, Change, Delegation, Disclosure, Dissensus and Exodus.

- Immutability is a central attribute of the blockchain to ensure trust in the system and integrity of the data. But not every situation can be anticipated: the world changes, systems need to adapt and data might be incorrect and even hurt someone (take the example of medical records, credit ratings or identity systems). There might be situations where the rule of immutability needs to be flexible, where the protocol or the data in fact does need to be changed. Ask yourself, who (or what) has the power to change the protocol in such a situation? What are the processes for this? What is the full range of people and environments that might be affected by this change? How will a non-technical user be made aware of changes that might affect them? In what ways can they influence this?

- Neutrality is an ideal that should be strived for but is never fully realised because all systems operate on a set of assumptions about how the world works, what people want and how they behave. A design is usually open for negotiation in the early days, before one version wins out over another and becomes normalised and possibly made into a standard. When these assumptions are encoded into a system they become automatically reinforced, invisible and harder to change. Ask yourself, what are the assumptions and behaviours that are delegated to the infrastructure to automatically reinforce? What needs to be disclosed in order for people to be able to understand, influence and possibly even change the assumptions of the system down the line? What languages (code or human-based) are needed for such explanations to make it understandable to those affected?

- Decentralisation could be said to be the most fundamental principle of blockchain technology. But in practice, one version of decentralisation might clash with another, and if it becomes compulsory to take part in a decentralised system, the system itself becomes an oppressive authority in its own right. — The only difference being that it is less obvious than centralised authorities of the past because power is executed across multiple actors in the network. Ask yourself, how does the system deal with dissensus? — Is it possible to disagree with the development of/changes to a system? How can it be expressed, by whom and with what consequences? Is exodus possible? — To leave the system entirely? And what are the different consequences for different types of users and contributors for disagreeing or leaving?

The Satoshi Oath for developers is a tool to make visible the informal social processes that are part of the infrastructure, to consider who or what benefits or who or what is left behind by different design decisions. A decentralised computer network does not guarantee decentralised power, transparency does not guarantee legibility and finally, code and cryptography does not guarantee neutrality.

You can read and sign the Oath on the Ethereum Blockchain. The text is hosted on IPFS.

If you are interested in the code, you can find it here: https://etherscan.io/address/0x49311a711ea4aff7fea3e0c32066e732fe4652ba#code

Join the discussion on Reddit: https://www.reddit.com/r/ethereum/comments/53sau2/proposing_the_satoshi_oath_for_developers/

Satoshi Oath for developers

Satoshi — name meaning clear thinking, quick witted, wise

When you are developing your own blockchain based application you are not just making another app or involved in another start-up, you are taking part in creating a new form of society. This oath is designed as a practical guide and a symbolic initiation into a community of developers with an expanded view of blockchain development. By taking this oath, you pledge to consider the full extent and range of the people and environments your work might affect, with special attention to the most marginalised and those not represented, and to consider each point below in the design and development of new applications.

The blockchain has its roots in Bitcoin, which was a response to corrupt centralized and opaque power structures that became explicit in the financial crisis of 2008. The core values that inspired its design are therefore decentralisation, openness and neutrality, but these values cannot be fully guaranteed by the technical architecture alone and must be considered for each project that is undertaken. A decentralized computer network does not guarantee decentralized power; code and cryptography does not guarantee neutrality; openness does not guarantee legibility.

IMMUTABILITY is essential for decentralised trust, but change is inevitable and necessary: not every contingency can be anticipated, data might be incorrect or hurt someone, contexts change and protocols need to adapt over time.

CHANGE — I pledge to consider who or what has the power to determine change (in the protocol or data), and how to make this power visible and accountable.

POWER — I pledge to think of the full range of people and environments that might be affected by changes, and to consider how their voices might be represented.

NEUTRALITY is an ideal that should be strived for but is never fully realized because all systems operate on a set of assumptions about how the world works, what people want and how they behave. When these assumptions are encoded into a system they become automatically reinforced, invisible and harder to change.

DELEGATION — I pledge to consider the assumptions and biases of the app/platform I am developing and how these are delegated to and enforced by the code.

DISCLOSURE — I pledge to make these assumptions and biases visible in all the languages (code and human) necessary to make these understandable to all those who might be affected.

DECENTRALISATION is the most central attribute of the blockchain, but in practice, one version of decentralisation might clash with another. If it becomes compulsory to take part in a decentralized system, the system itself becomes an oppressive authority in its own right.

DISSENSUS — I pledge to consider the possibility of and consequences for disagreeing with decisions and developments of the system for all types of people.

EXODUS — I pledge to consider the possibility and consequences of leaving the system/platform/app for all types of people.

And beyond — I pledge to consider my limitations and seek advice from colleagues in other fields relevant to my work when needed.

JKB — distributingchains.info

Elias, B9lab