Two companion documents introducing the ethrive protocol — a peer-to-peer system where every participant (a person, a device, a group, or a program) owns a signed, append-only log of operations called a space. Spaces replicate between peers and converge eventually. No servers. No central authority.
⚠️ Experimental software. ethrive is pre-1.0 and under active development. APIs, wire formats, and on-disk layouts will change without notice, and the protocol has not been independently security-audited. Do not use it with real funds, production data, or anything you can't afford to lose. Provided as-is, with no warranties of any kind — see LICENSE.
If you'd like a softer entry point before reading either document, start here.
🎙️ Evicting digital landlords with ethrive (54 min) — a podcast-style conversation about the protocol, generated with Google NotebookLM.
Same story, two altitudes. Pick whichever fits the reader in front of you:
| Audience | Tone | |
|---|---|---|
| TECHNICAL.md 🎧 Audio version |
engineers, protocol implementers, architects | formal academic style; covers wire format, sync, authority modes (incl. threshold signing), and the handler extension model; cites prior art (Matrix, Scuttlebutt, IPFS, blockchains) |
| NON_TECHNICAL.md 🎧 Audio version |
everyone else | plain language, leans on everyday analogies (apartments, shared notebooks); opens with "where are your photos, really?"; includes a frank trade-offs section |
Both documents stand on their own. Readers new to distributed systems should start with the non-technical version; readers who want to implement ethrive or evaluate it as a protocol should read the technical one. Reading both is ~55 minutes and gives you the most complete picture.
A space is a signed, append-only log of operations, owned and replicated by a set of members. A single person is a one-member space. A chat group is a multi-member space. A DAO is a space whose members jointly sign with threshold cryptography. An application's data lives in a space the user controls. Replication happens directly between members through a vector-clock diff; there is no global ledger, no consensus round, no central authority, and no server. Every feature beyond membership and governance — chat, files, collaborative documents, RPC, profiles, settings, on-chain signing — plugs in through a single extension point called a handler. The result is a substrate on which applications can be built that are offline-tolerant by construction, user-sovereign by default, and composable across categories that earlier systems treat as unrelated problems.
These documents are the living whitepaper for the ethrive protocol — they describe the design intent. The normative protocol specification lives in a separate repository at ethrive-io/specs and will be released very soon; we are still thoroughly testing it before cutting the first version. If the whitepaper and the spec ever disagree, the spec wins — the whitepaper is an invitation, not a contract.
Please cite either document as:
ethrive whitepaper (
<TECHNICAL.md | NON_TECHNICAL.md>), ethrive contributors, 2026. Licensed under CC BY 4.0. https://github.com/ethrive-io/whitepaper
Both whitepapers are licensed under Creative Commons Attribution 4.0 International (CC BY 4.0). You may copy, translate, excerpt, remix, or redistribute them — commercial or non-commercial — as long as you credit the source. Full license text: LICENSE.md.
Typo fixes, clarifications, and translations are welcome via pull request. Protocol-level changes belong in the spec repository, not here — the whitepaper's job is to explain the shape of the protocol, not to define it. If you're unsure which side of that line a change falls on, open an issue and we'll figure it out together.