Consensus Engine

If we’re not going to rely on third parties to tell us what to think, we need to build a system to help us come to consensus without them.

The consensus engine is an attempt to implement a service using the decentralized primitives of the system.

This service features:

  • consensus seeking for small groups
  • predefined set of consensus mechanisms
  • ability to define new mechanisms from scratch or by composing existing ones

Consensus in life

Consensus mechanisms are fundamental to human interaction. They’re how we make most important decisions. Almost all human interaction can be viewed as a kind of consensus:

  • chat
  • handshake
  • the use of language
  • legislative bodies
  • bitcoin
  • voting
  • coin toss
  • fist fight
  • property lines
  • traffic right-of-way

These mechanisms have some similar properties:

  • inputs
  • mutually agreed upon interaction pattern
  • consensus definition
  • outputs

We should be able to allow individuals to make new consensus mechanisms by defining these properties.


Each of these are consensus mechanisms that could be implemented using the system.

Normal conversation

One of the simplest consensus mechanisms types is just a casual exchange of messages without any particular order or restrictions.

In this case the consensus mechanism would be all participants agreeing that the conversation is over. If the interface had a “close” button, then the exchange’s consensus mechanism could be that all participants have each toggled it to the “clicked” state.


  • Initial message to start the conversation

Interaction pattern:

  • participant sends a message to the group
  • participant replies to an existing message or send a new message

Consensus definition:

  • majority of participants mark the conversation over


  • final set of all branches of conversation

Private conversation

Same as a normal conversation, but the exchange is deleted when it ends.

Because participants know each other in person, they can be reasonably confident that the retention rules will be followed.

Topic discussion

This type of consensus requires three inputs: a topic, a group of participants, and commentary on it. Outputs from the conversation are pairs of messages and their respective consensus results.

Let’s say that you want to see what your friends think about some idea related to climate change policy. You initiate a “topic discussion” conversation with the people you want to be involved:

  • select “policy debate” exchange type
  • choose the topic “Climate change solution”
  • comment “more nuclear power generation is good”

Each user is given the opportunity to agree, disagree with a posted rebuttal statement, or acknowledge the message without agreeing or disagreeing. The process then repeats for every subsequent rebuttal statement until all participants have considered every message.

When the chosen threshold of participants hold the same opinion about some message, consensus about it has been achieved, and it is marked as “resolved”, and added to the outputs of the conversation.

After the exchange ends, because it is a public debate, the outputs are shared with friends.

Rough process outline:

10 participant “policy debate” with 70% consensus threshold: title - climage change solution comment - more nuclear power generation is good

  • agreement was 6/10 (no consensus)
    • rebuttal 1: nuclear is too expensive - vote 3/10 -> exported consensus
      • rebuttal 1 rebuttal 1: nuclear is not too expensive if it’s a modern design - vote 9/10 -> exported consensus
    • rebuttal 2: it’s not politically tenable to build new nuclear power plants - vote 8/9 -> exported consensus
      • no rebuttal
    • rebuttal 3: pizza tastes like fruit if it has fruit on it - vote 2/2 (no consensus)
      • no rebuttal

In this case, the consensus was:

  • nuclear power isn’t too expensive
  • modern designs of nuclear plants are cheaper
  • it’s not politically tenable to build nuclear power plants

There is one item that failed consensus and had three comments: “nucler power is good.” Statements or rebuttals that don’t achieve consensus represent opportunity for future exchanges. Maybe the idea was poorly stated, some bad tradeoffs were made, it was simply incorrect, or was otherwise controversial.

Someone can use this “nuclear power is good” comment (with failed consensus) in a new exchange, set the consensus threshold, and comment like “we will never use nuclear power for more than 10% of our energy”, and the cycle continues.

Trade of goods

If you want to send someone money for a one-time exchange, consensus involves:

  • one party receives a bitcoin address and requested amount
  • the requested amount is sent to the bitcoin address
  • the sender of the money confirms that they received the product/service

Shop of goods

The Trade of goods mechanism can be utilized multiple times in a more complex form of consensus designed to offer an array of goods or services for sale.

  • consensus input is a list of items, amounts, and addresses
  • consensus outputs are the agreed-upon list with one less item, and the consensus output of a Trade of goods consensus

Elected servant

Outputs of this type of consensus are decisions about votes. In theory, the elected official must use these as inputs in their decisions on a vote in order for citizens to continue to trust them.

  • voters get hard data about how the politician will make good decisions before they vote.
  • all “constituents” must be met in person and officially declared in advance of the election.
  • users are a direct part of the candidacy. it is essentially they that are being elected.
  • basically just an algorithmic change from the current standard of elected officials just consulting advisors at will.

Composition of consensus channels

An important part of implementing consensus as a core feature is the ability to compose it. This allows the chaining of multiple consensus results together as inputs to others, and assembling arbitrarily complex interactions between them.


In order to automate some parts of interactions, you interact with a machine controlled counterparty, called a maid.

You can participate with a maid in virtual consensus in order to achieve some goal or generate some needed input.

Anyone can “spawn” maids in their own cluster, and use them as needed for any part of consensus.

They run on your personal nodes, executing a virtual machine language that dictates their behavior.

Your maids can interact with your friends' maids.

Dead man’s switch

It’s possible to implement a dead man’s switch using a maid and consensus! This is a very mechanical kind of interaction, because it achieves consensus if and only if it doesn’t receive any message in some time interval.

The maid essentially wakes up every so often and checks to see if a message has been sent to them by the participant. If the message hasn’t been received, consensus is achieved and the output is a message which is routed into another consensus channel.

E.g. I create a dead man’s switch maid, and then tell it to send the consensus message to my custody maid.

Custody maid

A custody maid’s goal is to act if you are ever taken into someone else’s custody or otherwise incapacitated.

This is a special “contingency consensus” where the inputs are a dead man’s switch signal, you, a maid, and messages sent between the two.

The messages are used to establish contingency plans with the maid that will govern its actions when triggered.

When the dead man’s switch output is received, the maid may send messages to some list of your friends. Based on their responses, it could distribute your will, send further instructions to your friends, distribute money, or anything else.

Other consensus mechanisms

  • Proposal for employment
  • Law change
  • Judgement