Skip to content

Glossary

A reference for the vocabulary used across this whitepaper. Each entry gives a one-line definition, a short expansion, and a link to the full concept page. Terms are grouped by domain.

Sphere’s terminology is overloaded by design — “circle”, “sphere”, “engine”, “network” all carry weight. Use this page to anchor what each word means in this project, distinct from how it might be used elsewhere.

Foundations — identity, trust, the graph

A decentralized social network that models human relationships as a directed graph with typed, weighted connections, rather than as flat “friend” or “follower” lists.

The substrate everything else in Sphere runs on. Entities (users, groups, algorithms) connect through directional, multi-typed relationships (“knows”, “trusts”, “is member of”) that carry meaning and permissions. Replaces the one-dimensional friend/follower projection of mainstream social media with the richer graph that human interaction actually has.

Identity

A service that maps an account to a person — ideally one-to-one, in practice often pseudonymous with optional verification layers.

The hard problem at the foundation of any decentralized social system. True 1-to-1 identity (one account = one person) is technically impossible to enforce in a fully decentralized network, so Sphere treats pseudonymity as a first-class option, with optional verification layers via Social Tokens. Identity recovery is handled through one’s network rather than a central authority.

Ego Network

The view of the social graph from one individual’s perspective — their friends, their subscribers, their reachable neighborhood.

Every user experiences Sphere from their own position in the graph; the ego network is that personalized slice. Used for content discovery, trust calculations, and privacy management — the difference between “who you trust” and “who the network as a whole trusts” is the difference between an ego-network query and a global one.

Social media reimagined so that storage and distribution of user information is fully controlled by the user.

A consequence of the trust-based network applied to media: instead of a platform owning your posts and deciding who sees them, you (or a node you trust) host your data and grant fine-grained permissions based on connection type, sphere membership, or trust score.

Groups — circles, spheres, tribes

Circle

A simple group structure with one of four standard governance models: autocratic, representative, pure, or virtual.

A circle is a system entity that holds members and can act in the network like an individual. Every circle defines procedures for creation, dissolution, member addition/removal, and collective signature. The four default types cover most simple group dynamics; anything more complex is a Sphere.

Sphere

A composable super-group that can contain sub-circles and sub-spheres, enabling hierarchical organization without centralized control.

The “advanced” tier above Circle. A sphere’s defining feature is its aggregatable property: sub-groups act as members for outer-level procedures while running their own internal governance. This lets one sphere combine different governance models at different scales — and the combination itself can be modified by procedures running inside the sphere.

Tribe Unification Protocol

A protocol for merging duplicate communities (e.g. two subreddits covering the same topic) into a single coherent group.

A tribe is an irreducible group organized around genuine shared interest, creativity, or life circumstance. Without unification protocols, tribes fragment across communities; with them, formal set-theoretic operations (full unification, split unification) can combine, divide, or restructure groups without losing internal governance.

Governance — engines, procedures, voting

Governance Engine

An abstracted representation of a governance structure — formalized as an activity graph of entities, objects, procedures, and connections — that can be executed on a decentralized network.

The central innovation of Sphere. A governance engine takes any decision-making process (a simple vote, a parliament with courts, a constitutional convention) and represents it as a structured graph that can be automated. Crucially, governance engines can modify themselves: the procedure for changing the engine is itself a procedure inside the engine.

The Four Elements

The building blocks of every governance engine: Entities (actors), Objects (data), Procedures (decision steps), and Connections (links between the other three).

Every governance structure in Sphere reduces to these four primitives. Entities act, objects store state, procedures transform inputs into outcomes, and connections wire them together. Anything you can describe as a governance process — a vote, a court trial, a budget allocation — can be expressed as a graph of these four element types.

Procedure

A single step in a decision-making process — initiated by a member or triggered automatically, collecting inputs and producing an outcome.

The unit of governance action. Procedures are the third of the four elements; the catalog of procedure types (proposal, vote, election, referendum, recall, audit, …) is itself a Sphere artifact called Democratic Procedures. New procedure types can be added to a running engine through the engine’s own amendment procedures.

Democratic Procedures

The catalog of procedure types available within governance engines — proposal, vote, election, referendum, court, recall, council, committee, assembly, petition, and many more.

A non-exhaustive list of decision-making patterns, each a building block that can be combined into larger governance structures. Includes core procedures (vote, election), judicial procedures (court, conflict resolution), organizational structures (council, committee), community engagement (assembly, town hall), and strategic processes (budget oversight, constitutional amendment).

Decentral Voting Systems

Cryptographic voting protocols (e.g. “Stille Post” votechains) that preserve voter privacy while keeping aggregate results verifiable.

Voting is the elementary procedure inside most governance engines, so its cryptographic foundations matter. A votechain passes through the network in a traceable but private way, using techniques like homomorphic encryption and zero-knowledge proofs so that individual votes stay secret but the final tally is provable.

E-Democracy

The application of governance engines and decentralized voting to real-world democratic processes — citizens deciding between elections, not only at them.

Where the governance machinery meets actual public policy. Open research questions: peer-reviewing democratic outcomes, scaling direct democracy through delegation, integrating with existing state structures, and preventing manipulation by well-resourced actors.

Trust & value — tokens, contracts, value objects

A contract between humans, stored and executed on a decentralized network — with the social aspect lifted above the numerical layer of traditional smart contracts.

Smart contracts on blockchains usually deal in numbers and tokens. Social smart contracts deal in agreements — including agreements about complex material facts that need human judgment to verify. They’re voluntary (unlike state law), backed by Social Tokens for reputation, and have built-in dispute-resolution protocols.

A trustless token structure for tracking attributes (trust, reputation, verification) tied to an account.

Two layers. Layer 1 is peer-to-peer: trust, recommend, like, mistrust — signals exchanged directly between users, weighted by the strength of the assertion. Layer 2 introduces third parties: Checked tokens (signed by an investigating party) and Judged tokens (signed by a randomly selected jury). The deeper into reality a claim reaches, the more elaborate the verification needed.

Value Object

A formally defined value (e.g. “transparency”, “privacy”) with a legal description and AI training data attached, used as a voting subject in value-based decision systems.

Instead of voting between candidates or proposals, you vote between values. Each value object carries its own description — including references to existing law and to specific cases — so the abstract preference becomes machine-readable. The same object can also serve as training data for AI Alignment.

Value Network

A governance framework built around value-based voting: people vote on values rather than representatives, with weighted and destructive voting modes.

The most abstract layer of Sphere governance. Voters express both preference and confidence by distributing weights across value objects. Destructive (negative) voting allows expressing strong opposition. The output is a population-level value distribution that can drive policy, AI training, or further governance decisions.

Weighted Voting

A voting mode in which each voter distributes a fixed weight (votes or percentage) across the available options, expressing preference and confidence.

A core mechanic of Value Networks. Acknowledges that not everyone has equal expertise in every field; lets voters allocate their attention proportionally. Combines naturally with destructive voting for expressing strong opposition without abandoning the voter’s other preferences.

AI Alignment

The challenge of ensuring AI systems act in accordance with human values — and Sphere’s proposal to address it through democratic Value Networks.

Conventional alignment (training on human text, RLHF) is unlikely to hold at superhuman scales, and there’s a parallel risk: a small group capturing alignment authority and pointing AI at their interests. Sphere’s response is two-fold: keep the technology open-source and distributed, and use governance engines to derive alignment targets from broad democratic input rather than from a handful of labs.

Applications

QuestBoard

A token-funded bounty system that pays open-source developers for implementing requested features.

A user describes a feature they want and locks funds in a smart contract. Other users can add to the pot. A developer accepts the quest, builds the feature, and on verification claims the bounty. Disputes go to arbitration, with Social Tokens tracking past behavior. Extensions: democratic redistribution of a percentage of every quest, crowdfunded project pots, and eventually real-world tasks where completion can be verified.

Open-Source Development

The model of collaborative software creation that Sphere both runs on and tries to fund: open-development, open-test, open-contribute.

Open-source has long had a funding problem; its developers carry critical infrastructure but are rarely paid for it. Sphere proposes that decentralized networks reward the development of their own software through built-in mechanisms — turning networks that produce value for their users into networks that also produce value for the people maintaining them.

Decentral University

The decomposition of “university” into its core functions (research, teaching, accreditation, identity, certification) and the rebuilding of each on decentralized protocols.

Universities bundle research, teaching, accreditation, identity verification, and document signing into a single physical institution. Each function can be unbundled: research and peer review through Decentral Knowledge Verification, accreditation through verifiable Social Tokens, identity through Sphere’s Identity service, etc.

Decentral Knowledge Verification

Decentralized peer review and fact-checking, using social tokens for tracking reviewer credibility.

How does knowledge get validated without centralized institutions? This concept (still in early exploration) sketches network-based peer review where reviewers earn or lose Social Tokens based on the quality of their reviews, with Governance Engine procedures handling disputes and conflicting evidence.

Sphere Localization

Cryptographic “places” — privacy-preserving alternatives to GPS for organizing local activity and community.

Rather than sharing exact GPS coordinates, users can prove membership in a geographic zone without revealing precise location. Places themselves can be managed automatically, by a designated person, or democratically through a Governance Engine — local community governance without surveillance.

Architecture & principles

Sphere Protocol

The set of cryptographic protocols spoken by Sphere nodes across three layers (blockchain, network, application).

The communication standard that makes a Sphere a Sphere. All nodes implement it; layered consensus mechanisms (the blockchain layer’s own consensus, “Proof of Chain” at the network layer, “Proof of Convergence” at the application layer) compose into a system that provides certainty about both stable and gossipy information.

Node

A piece of software running the Sphere stack — comes in three flavors: Blockchain Node, Light/User Node, and Full/Admin Node.

Light nodes handle P2P routing and run on end-user devices. Full nodes maintain the network and earn credits for processing and storage. Blockchain nodes host block drivers that interface with one or more chains. Users are encouraged to run their own nodes for data control and credit accumulation.

Three-Layer Architecture

Sphere’s stack: a blockchain layer (block ledgers as ground truth), a network layer (P2P routing and gossip), and an application layer (the user graph and plugins).

The architectural breakdown. Block drivers at the bottom let nodes plug into different chains; the network layer above handles routing, gossip, and synchronization; the application layer hosts the actual trust graph and any plugins built on top of it. Modularity is enforced so different Sphere variants can interoperate.

The Five Principles

Sphere’s foundational design constraints: Decentralization, Transparency, Ownership, Trust, and Cooperation.

Not slogans, design constraints. Every Sphere component is supposed to be evaluated against them. Decentralization: no central authority. Transparency: explain and visualize everything. Ownership: you own your time, attention, data, and algorithms. Trust: you choose who to trust. Cooperation: everyone builds the system.

Cross-cutting terms

Activity Graph

The data structure underneath every governance engine — a graph whose nodes are entities, objects, and procedures, and whose edges are connections.

The formal model of a governance engine. Reasoning about an organization in Sphere usually means reasoning about its activity graph: who can trigger which procedures, what data flows in and out, how the structure modifies itself.

Selective Involvement

The principle that not every member of an organization needs to participate in every decision — involvement should be appropriate to expertise and stake.

A counterweight to “pure democracy”. Maintaining a complex structure through unanimous votes on every change doesn’t scale; concentrating all decisions in one role is centralization by another name. Sphere’s governance engines are designed to occupy the spectrum between those extremes by routing different decisions to different subsets of participants.

Centrality

A graph-theoretic measure of how well-connected a node is — degree, betweenness, closeness, eigenvector. Used in Sphere to measure (de)centralization.

Decentralization isn’t binary. The “mean decentrality” of a network gives a quantitative read on its power distribution, and individual centrality measures highlight which nodes are structurally important. Pareto’s 80-20 tendency is the natural baseline; explicit structural measures may be needed to keep it from running away.

Pseudonymity

Operating under a stable but unverified identity — Sphere’s default for most use cases.

Given that 1-to-1 identity is hard to enforce decentrally, pseudonymity is treated as a first-class option. Users build reputation under their pseudonym through Social Tokens; optional layers (Checked, Judged) add stronger verification only when the use case requires it.