Imagine a village with a single Community Chest - a shared fund where everyone’s contributions go (work credits, taxes, donations). From this Chest, the community decides to support broad areas of village life:
-
Dedicated Domain Allocation (DDA)
- The Council meets and agrees how to split the Chest among “domains” such as Infrastructure, Food & Supplies, Health & Safety, Education & Culture, and Transportation.
- Each domain gets a fixed percentage (e.g., 30% for Infrastructure, 20% for Food & Supplies, etc.), always totaling 100%.
- If villagers feel a domain needs more or less, they propose adjustments (possibly via conviction voting where the longer and stronger the support, the more sway it carries).
-
Dependency Graphs & Weights
- Within each domain, committees further divide their slice among sub-domains or projects - again by simple percentage weights.
- For example, the Infrastructure allocation might be split 60/40 between “Buildings & Roads” and “Water & Power.”
- Those sub-slices can then be split further (e.g., “Building Repairs” vs. “New Construction”), using exactly the same weight-based rules.
- This “fractal” process works identically at every level: percentages always flow down the tree, ensuring clarity and consistency whether you’re at the village level or the smallest working group.
-
Self-Curated Registries
- At the leaves of this funding tree sit registries - on-chain rosters of people doing the work.
- Each registry (say, the Repair Crew) votes internally on who belongs and how to reward them: full-time villagers might get 1× credit, half-timers 0.5×, with multiplier for months of service.
- This keeps each group accountable to its own standards, while the Chest only needs to know the overall percentage flowing to that registry.
How It All Fits Together
- Community Chest (DAO Treasury): The single source of truth, holding all funds.
- DDAs (Domains): Top-level “budget accounts” like in town-ledger accounting - allocate the Chest by domain.
- Dependency Graphs & Weights: A recursive budgeting rule: every node (domain, sub-domain, project) splits its share by percentage.
- Self-Curated Registries: Department-level “expense accounts” where members and payments are governed by those doing the work.
By modeling our village’s funding as a nested dependency graph, we achieve:
- Transparency: Every villager can trace coins from the Chest down to each carpenter or gardener.
- Flexibility: New committees or projects slot in naturally - just assign weights under the relevant domain.
- Democracy + Meritocracy: The whole village adjusts domain budgets, and each working group fine-tunes its own rewards.
In short, this fractal funding model turns a simple Community Chest into a scalable, transparent, and self-governed system - perfect for a small village or a global DAO alike.
Potential Weaknesses & Unanswered Questions
As with any governance design, there are areas to watch closely and questions to explore:
- Cognitive & Administrative Overhead: Tracking and voting on multiple percentage rebalances could overwhelm contributors.
- Budget Drift & Inertia: Established splits may become entrenched, and conviction voting might reinforce outdated priorities.
- Registry Fragmentation & Gatekeeping: Self‑curated groups risk becoming closed circles, making it hard for newcomers to join.
- Adjustment Frequency & Process: How often should domain budgets be rebalanced? What parameters (decay rate, thresholds) govern conviction voting?
- Registry Onboarding & Exit: What’s the exact on‑chain mechanism for joining, leaving, or dispute resolution within registries?
- Emergency Fund: Is there a rapid‑response allocation for crises, and how do we prevent its abuse?
- Tooling & UX: What dashboards or interfaces will make this system accessible to all participants?
We’d love to hear your thoughts:
- What do you see as the biggest risks or gaps?
- Which questions matter most to you?
- How would you tweak the model to address these challenges?