Marc Hulty defines governance as "the processes of interaction and decision-making among the actors involved in a collective problem that lead to the creation, reinforcement, or reproduction of social norms and institutions." From this we can conclude that everything gets governed, the question is whether governance is ad hoc or formal, explicit or implicit.

One of the ironies of decentralized systems is that they require better governance than most centralized systems. Centralized systems are often governed in an ad hoc way because the central point of control can easily tell all participants what to do. Decentralized systems, on the other hand, must coordinate across multiple parties, all acting independently in their own self-interest. This means that the rules of engagement and interaction must be spelled out and agreed to ahead of time, with incentives, disincentives, consequences, processes, and procedures made clear.

The Internet is an excellent example of this. All the computers that connect to the Internet, along with those that route messages between nodes, follow a set of procedures determined ahead of time that cannot be ignored by participants without loss of functionality. These procedures are called protocols and they are embodied in the code that participants in the network—both edge nodes and routers—execute.

Blockchain systems are no different. Their interactions are wholly or partially governed by protocols embodied in code. But these protocols are not emergent properties of the blockchain, rather they are designed by humans who write the code and agreed to by the humans who execute it. Without the design and agreement of humans, the blockchain does not function.

The Sovrin blockchain is a good example. There are two primary components of how Sovrin operates: the design of the protocols and the operation of the ledger. We can ask governance questions about each.

Sovrin's code is open source—specifically it is the Hyperledger Indy project under the umbrella of the Linux Foundation. This means developers from around the world collaborate to design and build the code that makes Sovrin work. Their decisions are governed in the way of most open source projects: rough consensus and running code with pull requests accepted by a core set of developers who manage the code base. Code embodies the rules that make up the Sovrin protocol. Since the protocol is a critical component of Sovrin governance, how decisions are made about the code is a key component of ensuring Sovrin is governed well.

But with the Sovrin blockchain there is another kind of governance that is not embodied in the code. Sovrin is built on a public permissioned blockchain. This means that anyone can use the Sovrin ledger, but consensus is achieved by a known set of validator nodes. Validators perform a similar function on a permissioned ledger than miners perform on a permissionless ledger—ensuring that each copy of the ledger records the same data in the same order¹. Since Sovrin’s validators are part of a known group, we should also examine how this group of validators is selected, organized, and governed.

Decisions about how code is architected, which code is run by validator nodes, and how those nodes operate are made in accordance with the Sovrin Trust Framework, a document that specifies how the Sovrin Network is governed. The Trust Framework is Sovrin’s constitution, defining the operation and organization of the network, and is where the final authority for the Sovrin Network lies. In fact, Sovrin can be said to have a constitutional governance model. The Sovrin Foundation is an international, non-profit organization that represents the collective interests of all Sovrin identity owners. Sovrin Foundation exists to administer the Trust Framework. The Sovrin Foundation clearly and openly identifies the actors in decisions and the processes they use to reach those decisions and ensures they are made consistent with the trust framework.

Sovrin’s Trust Framework is based on a set of shared goals consistent with establishing a global public utility for privacy-respecting, self-sovereign identity. In One from Many: VISA and the Rise of the Chaordic Organization, Dee Hock writes:

In the constructive sense of the word, governance can be based only on clarity of shared intent and trust in expected behavior, heavily seasoned with common sense, tolerance, and caring for others as fellow human beings. This is not to say that contracts, laws, and regulations do not serve a purpose. Rather it is to point out that they can never achieve the mechanistic certainty and control we crave. Rules and regulations, laws and contracts, can never replace clarity of shared purpose and clear, deeply held principles about conduct in pursuit of that purpose.

In the case of Sovrin, that shared purpose and deeply held principles are contained in the Sovrin Trust Framework. The Trust Framework lays out the purpose of Sovrin as providing a global public utility for self-sovereign identity that adheres to a set of thirteen principles²:

• Independence and Self-Sovereignty
• Guardianship
• Diffuse Trust
• Web of Trust
• System Diversity
• Interoperability
• Portability
• Security by Design
• Privacy by Design
• Accountability
• Openness
• Identity for All
• Collective Best Interest

Sovrin embraced these principles to meet the needs of identity owners and protect their data, privacy, and autonomy. These principles guide both the technical development of the Sovrin code and the operational rules for stewards, the trusted organizations who operate validator nodes and connect to the ledger in a transparent way.

Some have pointed to the permissioned structure and the existence of the foundation as a reason for distrusting whether it is truly a decentralized public network. To those people I say, “Look at the Trust Framework and tell me where it falls short.” Often this question is just a knee-jerk reaction to how Sovrin splits governance between code and agreement. There’s nothing magic about code when it comes to governance. It can automate things but it has no special properties when it comes to resisting accumulation of power or autocratic tendencies. Even in permissionless blockchains, change is proposed by the developers and accepted (or not) by miners. These are people coming to agreement or not based on the principles they hold dear.

Sovrin’s Trust Framework makes those principles explicit by providing a documented public agreement (consensus) about them. The process for amending Sovrin’s Trust Framework is also public. The stewards running validator nodes agree (or not) by accepting or rejecting changes. This is the same process we (and other public blockchains) use for managing code changes. It ensures that Sovrin continues to be public and open to all. There is no point of centralization in Sovrin because no single entity can force other participants to bend to that entity’s will. Sovrin is technically, politically, and geographically decentralized to achieve diffuse trust, which enables diffuse control.

Others might wonder how the Trust Framework governs the code that Sovrin runs. While it’s true that Sovrin code is open source and anyone can make contributions, those contributions still have to be accepted by the maintainers of Project Indy to be incorporated in the codebase. Further, the Indy code is not automatically transferred to Sovrin validators to run, but is subject to review by Sovrin’s Technical Governance board and the Stewards themselves.

Those reviews ensure that only code consistent with the Trust Framework is run by validator nodes. These reviews also put appropriate pressure on Project Indy contributors and maintainers to adhere to Sovrin Trust Framework principles, since not doing so could lead to a fork of the project (although not the ledger), with Sovrin developing its own branch of the Indy codebase to protect its interests. Recent events in the blockchain space show that this is not inconceivable, but it would be disruptive and costly to the ultimate success of Project Indy. This neatly aligns incentives between Project Indy and Sovrin. Make no mistake; Sovrin will take decisive action if our principles are threatened.

Participation in Sovrin is open to all. As I wrote in Is Sovrin Decentralized?: anyone can create identifiers. Sovrin does not have "identity providers" because they are entirely unnecessary; identity owners are empowered to carry their own claims. Furthermore, any organization who will publicly agree to the Trust Framework and meets its requirements is welcome to become a Sovrin Steward.

This is the ultimate point: no single entity owns or controls Sovrin, not even the Sovrin Foundation. The Sovrin network is a global public utility that we all own, collectively, just like we all own the Internet. And the governance model of the Trust Framework, along with governance of the open source Hyperledger Indy code run by all Sovrin stewards, has been carefully designed to reflect this. All of this is captured in the Sovrin Trust Framework which is developed and published under an open public process available to all.

The public and open nature of Sovrin supports an unprecedented level of autonomy, privacy, security, and control by the people and organizations using Sovrin. We welcome you and your organization to join us in this important work.

Endnotes:

1. There are many reasons for using a permissioned model, as spelled out in the recent Sovrin Foundation white paper, but one of the most important is cost. Simply put, if the cost of using a ledger can be kept very low, then it will enable people to use a different cryptographic identifier for each relationship, thus reducing correlation risk and increasing privacy. Any blockchain-based identity system must be carefully architected to take advantage of the blockchain without sacrificing the privacy of the participants in the system. If writing transactions to the blockchain is expensive, as it typically is in permissionless ledgers, people are more likely to reuse identifiers (or hashes) and increase the risk of unwanted correlations.
2. See Section 2 of the Trust Framework for a detailed discussion of these principles.

Thanks to Steve Fulling, Drummond Reed, Timothy Ruff, Jason Law, and Daniel Hardman for helpful discussions on this topic that improved the post and made it more clear.

Photo Credit: Bees and Honeycomb from Phil Windley (CC0)