Sovereign
Accountable Commons

Purpose: Organizations incorporated in distributed app code instead of legal codes enabling new patterns of self-governance and mutual sovereignty.

Overview

Stage of Development: Waiting for Holochain development to reach Alpha 0.1

We believe you can’t claim to truly have a distributed technology solution, until the governance of the technology follows a distributed architecture.

Whether a cryptocurrency, new commons, platform cooperative, or whatever, no matter how good the intentions of its original creators, if control of the evolution of the technology isn’t tendered to the same community using the tech, the whole system is fundamentally subject to someone else’s control.

The controversial Ethereum hard fork in response to DAOhub is an example of this issue. The behind the scene battles in the Bitcoin community about block size and scaling strategies is another. No matter how fair it seems you’ve made the rules of a game, if some select group gets to change those rules at their pleasure, then fairness is not actually guaranteed.

Core Concepts

A Sovereign Accountable Commons (SAC) is akin to idea of a Decentralized Autonomous Organizations (DAO) on Ethereum but the underlying technology is fundamentally different, as SACs are built on Ceptr and Holochains.

Sovereign:

An SAC runs as a collectively distributed application. As long as at least one person wants to run it, it can’t be shut down. Two or more nodes running it make it a collective. It’s algorithms set availability and redundancy based on size and scale of the network.

Everybody in a group is an equal peer, subject to the same rules, processes, and procedures, because everybody is running a copy of the same instruction set. This “code as law” applies to holding of assets, management of assets, interactions, transactions, governance, releasing new versions of “code as law,” and every aspect of ongoing operation of the SAC.

Mutually Sovereign: Because each participant holds copies of their own assets, they can “take their toys and play elsewhere” (also known as forking), inviting others to bring theirs along as well. Yet since assets are typically stored in a DHT with redundancy, the group also maintains a copy. The group cannot threaten to withhold value which was generated by a participant in order to coerce them to continue to participate. Individuals cannot coerce others or the group, by threatening to take (digital) assets that they’ve shared.

Accountable:

SACs have membranes to membership. They can set whatever intake process or criteria they choose in allowing new members. This may frequently include validation of identity to whatever threshold the group requires. It could be that being vouched for by a couple friends is enough, or more formal credentials may be required.

When participating in an SAC, every contribution, communication, or action is signed by its initiator. There is always a trail of evidence left by your actions.

You interact with the group, by interacting with your copy of the group’s rules and commit any changes to your own local chain, which synchronizes, shares its updates, and processes interactions or transactions with other group members. All interactions in the group context are constrained to the coded validation rules that every node of the DHT enforces.

Ceptr is designed to support multiple inter-operating distributed reputation and currencies via Intrinsic Data Integrity (data structures with cryptographic assurance to prevent alteration once stored). An SAC should be coded to measure the activities treasured by the group.

Commons:

All data and assets shared into the commons are held in common. They are not (by default) held in identical copies of a globally ledger, but rather in shards of a Distributed Hash Table (DHT) with algorithms to assure adequate redundancy and availability.

Authors (contributors, signors, or parties to a transaction) always keep a local copy of whatever they’ve put into the commons, signed to their own chain(s). The commons also keeps copies of whatever has been published to the validating DHT.

Some Key Technical Differences from DAOs

Ceptr enables distribution of reliable shared process. Therefore consensus and data verification are byproducts which serve to validate that a node’s processing has not become corrupted. Corruption is tracked and compromised nodes are blacklisted from further access.

Cells each carry instructions (in the form of DNA), not a record of the actions of every cell, which enables them to construct whatever future actions are needed. Language is carried by all language speakers as the processes to decode and encode the meaning of language, rather than a global ledger of every sentence everyone has spoken which needs some kind of crazy consensus to be committed into our brains. Ceptr is structured the same as the patterns of collective intelligence found in nature.

Usage is highly scalable because it is constructed via a fractal localized architecture instead of having the bottleneck of a global ledger which requires consensus about interactions and data which simply should not require any consensus to be validly committed. There’s no wasted processing power from Proof of Work or undesirable Pareto Effects from Proof of Stake.

For information that actually needs wider spread validation or consensus, it is done by high agreement threshold of randomized peers (via hash) making it virtual impossible to corrupt data. Even if you control many nodes, the original contributors will have their signed and valid copies which can expose data corruption and enable network immune response.

For the needs of most communities and commons, we believe Ceptr’s approach will prove to be many orders of magnitude superior to blockchain consensus on global ledgers in terms of composability, adaptability, reliability, and storage and processing efficiency.

Keywords

  • commons
  • distributed
  • decentralized organizations
  • mutual sovereignty
  • blockchain
  • accountability
  • reputation
  • cryptocurrencies
  • DHT
  • DAO