Why Holochain Fits
Holochain fits this project when the problem is shared civic coordination among autonomous participants: membership, roles, decisions, evidence, agreements, stewardship, exchange, and federation. It is a weaker fit when the problem is payment execution, public filing, payroll, banking compliance, audited accounting, title, or legal enforcement.
Read What Holochain Is first if the terms source chain, distributed hash table (DHT), distributed network application (DNA), zome, or Holochain application (hApp) are still unfamiliar.
Fit Claims
Section titled “Fit Claims”| Holochain strength | Solidarity-economy need |
|---|---|
| Agent-centric records | Members, projects, stewards, sponsors, delegates, and reviewers need accountable authorship. |
| Local-first execution | Groups need to keep working without depending on one platform operator’s database. |
| Shared validation rules | Decisions and approvals need rule checks that peers can verify. |
| Modular DNAs and zomes | Land, housing, governance, finance, care, and data stewardship need different privacy and membership boundaries. |
| Peer-to-peer federation | Autonomous organizations need to coordinate without merging into one owner. |
| Public and private record placement | Civic records need provenance while sensitive evidence stays scoped, encrypted, private, or external. |
This is why the protocol frame starts with institutions, not features. A community land trust (CLT), fiscal sponsor, cooperative, mutual-credit network, or data cooperative should not have to become one software tenant to coordinate with others.
Fit By Concept Area
Section titled “Fit By Concept Area”| Concept area | Strong Holochain fit | Boundary to keep visible |
|---|---|---|
| Land and housing | Membership, stewardship reviews, lease references, waitlist state, board decisions, and record provenance. | Title, mortgages, leases, municipal filings, and fair-housing compliance remain external authority. |
| Governance and agreements | Roles, proposals, decisions, consent, delegation, agreement hashes, and federation records. | Legal sufficiency, entity filings, labor law, and enforceable contracts still need external systems or professional review. |
| Finance and exchange | Requests, offers, approvals, commitments, claims, mutual-credit entries, and export manifests. | Banking, settlement, tax, payroll, benefits, securities, and audited books remain outside the protocol. |
| Care and data | Consent, access rules, redaction state, care requests, data-steward decisions, and audit trails. | Medical, legal, regulated, or highly sensitive records should be minimized, scoped, encrypted, or kept outside Holochain. |
Design Consequence
Section titled “Design Consequence”The protocol should use Holochain where social truth and institutional memory need to be locally governed and peer-verifiable. It should use bridges when an external authority must execute or recognize the result.
That gives the architecture a simple discipline:
- define the civic record first;
- validate only what peers are entitled to see;
- keep sensitive evidence out of broad shared data;
- export stable bridge records to regulated systems;
- treat external systems as authoritative when law, money, title, employment, or public administration require them.
Read Next
Section titled “Read Next”- Boundaries and Bridges for the external-system split.
- Privacy and Data Placement for shared, private, encrypted, and external records.
- ValueFlows and Holochain Resource-Event-Agent (hREA) for economic coordination.
- FAQ for fast answers to common safety, reporting, recovery, and upgrade questions.