Theoretical Mechanisms
The machinery
under consideration.
None of this is built yet. This page explores the mechanisms that could support the scaffold: how a node keeps its records, how a federation could hold trust and shared resources without a custodian, and where software assistants could help. The node itself never depends on any of it.
The Problem It Solves
Federations fail when trust becomes personal.
Every voluntary federation in history eventually faces the same vulnerability: the records, the treasury, and the rules live somewhere controlled by specific people. When those people leave, die, or defect, the federation loses its memory and its money.
Blockchain infrastructure moves the federation's critical state — records, contribution proofs, treasury rules, governance decisions — out of any individual's control and into a shared, cryptographically verifiable system that no single party can alter or destroy.
This is not "Web3 for its own sake." It is a specific answer to a specific structural problem: how do decentralized nodes trust each other, share resources, and maintain records across time — without appointing a custodian?
What the chain holds
-
◈
Node Identity
Each node's cryptographic keypair, registered on-chain. Verifiable without a central registry.
-
◈
Contribution Proofs
Hashes of cycle records and contribution ledgers. Not the content — the proof that a specific record exists and hasn't been altered.
-
◈
Treasury Rules
Smart contracts that govern how federation funds are held, allocated, and distributed. Rules that execute automatically when conditions are met.
-
◈
Governance Decisions
Federation-level votes — changes to the base charter, admission of new nodes, amendments to treasury rules — recorded immutably.
-
◈
Exit Records
Node exits, membership changes, and dissolution records. A permanent audit trail that protects all parties.
How Records Work
The OS ingests decisions. The chain makes them permanent.
Every formal decision, role rotation, cycle completion, and contribution log produced inside a node is captured by the OS. At the end of each cycle, a cryptographic fingerprint of that record is anchored to the federation chain. The content stays local. The proof goes everywhere.
Step 1 — Live Capture
Decision is made in a node meeting
Any formal decision — a consent vote, a role assignment, a charter amendment, a contribution log entry — is recorded in the OS at the moment it happens. No manual transcription needed.
Step 2 — Signed Locally
Node keypair signs the record
The OS generates a structured record document. The node's private key signs it. This proves the record originated from this node and hasn't been altered.
Step 3 — Stored in Distributed Layer
Full record goes to IPFS or federated storage
The complete record — the actual text of decisions, contribution tallies, role changes — is stored in a content-addressed distributed storage network. It lives in many places simultaneously.
Step 4 — Hash Anchored On-Chain
A fingerprint is written to the blockchain
The content hash (a short cryptographic fingerprint) is written to the smart contract. Anyone can verify that a given document matches this hash. The record is now permanently provable.
Step 5 — Retrievable Forever
Even if the node is gone
If a node's local hardware is destroyed, the records exist in distributed storage and can be retrieved by any authorized party using the on-chain reference. The federation is the memory that outlasts any individual node.
Example: a cycle close record
The full record lives in IPFS. Only the hash and metadata go on-chain. Privacy is preserved. Proof is permanent.
The DAO
The federation as a DAO. Nodes as its members.
A DAO (Decentralized Autonomous Organization) is an organization whose rules are encoded in smart contracts — programs that execute automatically when conditions are met, without needing a human administrator to approve each action. A DAO is one candidate for the federation's coordination layer.
What the DAO governs
-
01
Treasury Allocation
How federation-level funds are held and distributed. Capital access programs, resilience buffers, infrastructure investment — all governed by smart contract rules that nodes vote on.
-
02
Node Admission
New nodes requesting federation membership submit their charter and three cycles of records. Existing nodes vote on admission. Rules for minimum standards are encoded in the DAO.
-
03
Protocol Amendments
Changes to the base OS protocol, the federation charter, or the treasury rules require a supermajority DAO vote. No single node can unilaterally change the shared standards.
-
04
Infrastructure Budget
Shared infrastructure — the record storage network, the communication layer, the OS development fund — is funded by the DAO treasury and budgeted by node vote.
How voting weight is earned
Voting weight in the federation DAO is not bought — it is earned through verified contribution. This is the key design choice that separates Mastermind City's DAO from speculative token governance.
Governance weight sources
- +Weight Completed cycle records submitted to federation
- +Weight Verified contribution hours logged and signed
- +Weight Training programs delivered to network
- −Weight Missed cycle submissions or inactive periods
- Cap No single node may hold >15% of total governance weight
- Never Capital buys no votes. Money contributed to the treasury is recorded and can earn a financial return, but never governance weight.
Treasury Architecture
How value flows through the federation.
The treasury would be a multi-signature smart contract that no single party controls. Distributions are triggered by verifiable on-chain conditions — contribution proofs, cycle completions, and DAO votes.
Inflows
Node Contributions
% of node revenue committed to federation treasury as a condition of membership. Rate set by DAO vote.
Training Program Revenue
Income from external-facing programs, retreats, and credential licensing flows to treasury.
Capital Partners
Aligned investors or grant sources contribute to the treasury in exchange for defined terms — no equity in individual nodes.
Network Services
Fees from external use of federation infrastructure, legal templates, or technical OS components.
Federation Treasury
Multi-sig smart contract. Governed by DAO. Auditable by all members.
DISTRIBUTION TRIGGERS
Automatic on cycle close + contribution proof. Discretionary via DAO vote. Emergencies via a time-limited multi-signature of guardians elected by member nodes, rotated like every other role.
Outflows
Contribution Rewards
Distributed to nodes proportional to verified contribution weight. Automatic on cycle close.
Capital Access
Preferred loans and matching funds for node-level projects. Governed by DAO criteria.
Resilience Buffer
Legal defense fund, emergency liquidity, and disaster recovery for member nodes.
Infrastructure
OS development, record storage network, and federation communication layer.
Software Assistants
Assistants that lighten the load, not replace judgment.
Small groups burn out on administration. AI assistants could carry some of that weight — summarising, routing, checking — so people spend their attention on each other and the work. The design constraint is strict: assistants support human agency; they never hold it.
Onboarding Guide
Explains the scaffold to newcomers, answers questions about roles and rhythms, and points people to forming nodes that match their interests.
Council Assistant
Prepares the monthly council: last cycle's record, open tensions, proposals waiting for a consent round, and how they relate to each other.
Record Keeper
Helps the Chronicler turn meeting notes into a clean cycle record, ready to be reviewed and signed by the node.
Ledger Helper
Keeps the contribution ledger tidy across hours, output, capital and materials, and flags gaps for the Steward to check.
Treasury Modeller
Models cash-flow scenarios and funding options so a node can see the consequences of a decision before making it.
Risk Flagger
Notices legal or regulatory questions in a proposal and routes them to a qualified human for review. It never gives the final answer.
Candidate Stack
Technologies being considered.
Candidates, not commitments. Chosen for alignment with the project's values: open source, minimal trust requirements, low operating cost, and offline-capable where possible. Builders are invited to challenge any of them.
| Layer | Component | Why | Status |
|---|---|---|---|
| Node OS | Tauri (Rust + Web frontend) | Cross-platform desktop app, tiny binary, offline-capable, Rust for crypto and P2P | Candidate |
| Node OS | Local SQLite / embedded DB | Cycle records and contribution ledger stored locally without server dependency | Candidate |
| P2P Mesh | libp2p (rust-libp2p) | Battle-tested P2P networking, NAT traversal, pub/sub for inter-node messaging | Candidate |
| Messaging | Nostr Protocol | Keypair-based, relay-optional, censorship-resistant inter-node communication | Candidate |
| Record Storage | IPFS / Filecoin | Content-addressed distributed storage. Records survive any single node failure. | Candidate |
| Blockchain | Base (L2 on Ethereum) | Low transaction costs, EVM-compatible, widely supported | Candidate |
| Smart Contracts | Solidity on Base | Node registry, contribution proof anchoring, treasury multi-sig, DAO governance | Candidate |
| DAO Framework | OpenZeppelin Governor | Audited, modular DAO governance contracts. Avoids re-inventing complex security-critical code. | Candidate |
| Identity | DID (Decentralized IDs) | Self-sovereign identity for nodes and members. No central identity provider. | Candidate |
| Frontend | Astro (static site) + Tauri shell | Lightweight, fast, works as both website and desktop app shell | Candidate |
Roadmap
Introduced in three phases.
Nothing here is needed to start. The first nodes run on paper, a shared document and signed records. Federation technology is added only when there are enough nodes for it to earn its complexity.
Phase 1 · First nodes
Local OS + Signed Records
- Cycle run on paper or a simple local app, fully offline
- Cycle records generated and signed by node keypair
- Contribution ledger tracked locally
- No blockchain required — just cryptographic signatures
- Records backed up manually or via simple cloud storage
- First nodes establish base patterns
Phase 2 · Several nodes
Federation + IPFS Records
- Nodes connect via libp2p mesh
- Records stored to IPFS at cycle close
- Hashes anchored to Base L2
- Node registry smart contract live
- Basic inter-node contribution tracking
- Manual DAO voting for key decisions
Phase 3 · A mature network
Full DAO + Treasury
- Treasury smart contract deployed
- Contribution-weighted governance live
- Automatic reward distributions on cycle close
- Capital access programs governed by DAO
- Full disaster recovery via distributed records
- Open to external nodes and federations
In Explicit Terms
The white papers.
This page describes mechanisms in plain language. The white papers set out the same ideas in explicit technical terms, for builders and reviewers.