DLT & Blockchain Governance Design Patterns

About the patterns

This is intended to be a living document with frequent revisions and additions.

The following are adapted from the Media Enterprise Design Lab at medlab@colorado.edu under a Creative Commons 4.0 Share-Alike License. Their version can currently be found at https://medlabboulder.gitlab.io/democraticmediums/ and a related site is https://communityrule.info/templates/.

Why Design Patterns for Governance of DLTs / Blockchains?

Governance is by definition the collective[1] management[2] of emergent[3] issues. (See footnotes.) Humans have been doing this for millennia, and have been fighting over it the entire time.

Setting up governance means making a bunch of decisions about future decision-making. Often, clusters of specific decisions seem to support one another and “go together.”

Design patterns are a shorthand way to encapsulate clusters of decisions that (A) can work together reasonably well because they have before, under at least some conditions, and (B) are named in a way that invokes memories most people have of governance systems they’ve seen elsewhere, and should have some familiarity with.


When founders of a DLT system wish to tie it to an external legal system, one way is to invoke the “KYC Legal Anchor” sub-pattern. The founders declare that some class of stakeholders must undergo an identification screening (like banks do with KYC or “Know Your Customer”), and sign a legally binding contract that gives counterparties the right to sue.

Practitioners using this sub-pattern include VeChain and MediLedger.

Governance Patterns

One community member, the benevolent dictator for life (BDFL), holds ultimate decision-making power while seeking to represent a balance of the views and the best interests of the community as a whole.

As a blockchain project bootstraps, it is almost always going to start with this design, even if only for a few minutes as nodes are added and other design elements enabled.

The EOS Mainnet bootstrapped via the BDFL pattern for several minutes. The BDFL, known only as “the Anonymous Block Producer,” operated as the sole block producer (“BP”) — long enough to enable BP candidates to register themselves and allow token holders to cast votes for BPs. Once the needed minimum number of BPs were voted for, the BDFL handed control of the mainnet to the collective of elected BPs and “burned” his own account by nulling the public keys.

Activities are carried out through individual Roles and small groups called Circles, which have the ability to decide and act on matters in their domain. Representatives of Circles meet in a Council to coordinate efforts and determine the domains of each Circle. (See: Sociocracy 3.0, Holacracy)

Those who take initiative to do work for the community can decide how they do that work. If any community members hold serious concerns, they can start a proposal to halt what someone is doing.

An elected board of a given number of members determines policies and implements them, or oversees their implementation.

Agreements are implemented through ad hoc juries made up of randomly selected, qualified members. A community administrator oversees the process and has the capacity to remove community members.

All members have potentially equal voice in a direct democracy. Volunteer community administrators, who are invited by other administrators, carry out the community’s decisions.

An annually self-appointed board with a given number of members determines policies and implements them.

A version of this is the “Village Elders” pattern — the earliest adopters of the project meet periodically to make decisions, and later joining members defer to them based on experience and tenure.

Three distinct and countervailing entities carry out executive, legislative, and judicial functions, respectively.



Governance is the “collective[1] management[2] of emergent[3] issues.”

  1. Collective — every ‘governed body’ is a ‘collective’ in the technical sense that there are multiple stakeholders who simultaneously (A) need to make decisions that affect them all (‘collective decisions’) and (B) cannot easily get to unanimous agreement. If A is not true, people can easily opt out and decisions only affect those who agree to be affected. If B is not true, people can simply do the work of reaching unanimity and decide. When A and B are true, the group is thrown into ‘governance.’
  2. Management of issues — governance covers three distinct areas of decision making and decision execution: (A) making the decision, (B) carrying out the decision once made, and (C) tweaking the decision-making rules themselves. If an issue arises and the collective manages to make a decision and carry it out, then we can say they have “managed” the issue.
  3. Emergent — governance is about handling the unknown or unexpected, as contrasted with the routine and every-day work. For a DLT, determining the next block to add to the ledger is part of settled code. It’s deterministic. But deciding whether to change the size of the blocks, and if so to what new size, and to then carry out that change — that is likely to involve work for which there is not already settled code, trivial to execute. Not all emergent issues require governance, and not all governance is exclusively about handling emergent or new issues, but there’s a large overlap. Most emergent issues that transcend what the settled code can handle, will require governance to manage.

President of Becoming a Best Boss Training & Coaching