Jeff Emmett

Most arguments about decentralised governance are arguments about ballots: who gets one, how they are weighted, how the count is protected. That is the smallest part of the problem. A vote tells you something about a group at one moment and says nothing about whether the thing being voted on will do what its sponsors claim. The part I keep working on is everything around the ballot: what the institution measures, whether a proposal is simulated before it is enacted, who can run that simulation, and what the institution is obliged to do when the outcome disagrees with the forecast.

This is old ground, which is the useful thing about it. Stafford Beer's viable system work described organisations as regulators with sensors, models and actuators decades before anyone put a treasury on a blockchain, and Elinor Ostrom's design principles are not moral advice but an empirical account of which feedback structures survived centuries of use in real commons. A great deal of what DAOs have discovered since 2016 is a partial rediscovery of both, usually without the parts that made them work: monitoring, graduated sanctions, and a way to revise the rules without a crisis.

Computer-aided governance is the practical version. Observe the system, ask a question that has an answerable form, map the causal structure, model it, present the model in a form a non-modeller can argue with, debate it, enact something, then keep monitoring — and expect to go around again. Model-based institutional design is the same commitment stated as engineering: an institution has a specification, the specification can be wrong, and finding out that it is wrong should not require the institution to fail first.

The limit is worth stating plainly. A model is a claim about the world made by whoever built it, and a simulation only its designers can run is an authority claim wearing a lab coat. Publishing the model, its parameters and its failure modes is part of the governance, not an engineering afterthought. That is why the models on this site are open, and why I would rather ship a simple mechanism people can audit than an elegant one they have to trust.

A mycorrhizal network moves carbon and nutrients between organisms that are not related to each other, routes more of it toward whatever is currently scarce, holds reserves through the season when nothing is growing, and quietly abandons connections that have stopped carrying anything. There is no centre, no ledger and no price. Local rules, applied at every junction, produce an allocation that a central planner would struggle to match — and the network's own structure is the memory of which routes worked.

MycoFi, the book I wrote with Jessica Zartler and Sadie Morris, works through what that implies for economic design. The sharpest contrast is monoculture against permaculture: one currency optimised for one kind of exchange, against many currencies suited to the exchanges actually happening in a place — mutual credit between businesses that trust each other, demurrage on money that should circulate rather than sit, community currencies where the national one is scarce. Monocultures are efficient right up to the point where the single crop fails.

The governance side of the same idea is institutional neuroplasticity: whether an organisation can still change shape after it has succeeded, or whether success has hardened it into the form that happened to work once. Myco-mutualism asks the narrower question of what it takes for exchange between unlike parties to be worth repeating, which turns out to be most of what a commons needs to settle.

I try to be careful here. Biology does not validate a mechanism; a fungus is not a proof. What it offers is a structure worth testing and a set of questions a market usually forgets to ask: what does this economy hold in reserve, where does surplus go when things are good, and what happens to a connection that stops carrying anything. The answers still have to come from a model and a deployment.

Ostrom's first design principle is a boundary: a commons needs to know who its members are. The corollary gets less attention. A boundary only means something if crossing it in the other direction is possible, and in a digital commons that depends entirely on whether your identity, your documents and your relationships can move. Interoperability is usually filed as an engineering concern. It is a constitutional one.

rSpace is where I work on that. Data is local-first: documents are conflict-free replicated types held on your device and encrypted before they sync, so the server stores ciphertext and acts as a peer rather than a gatekeeper. Identity comes from a passkey on hardware you own, which derives the keys, the DID and the wallet rather than storing an account somewhere on your behalf. If the host disappears, the data does not.

Underneath sits a holonic data model. Every item is a small content-addressed document that can carry a reference to its own definition, so a peer handed a kind of object it has never seen can resolve the definition and install what it needs to interpret it — the loop Ceptr specified years ago and almost nobody closed. The practical payoff is that dozens of apparently different collections collapse into one store with an axis, links and a lens over it, and a document written in one application stays legible in another.

The economic layer is built the same way. rFlows models funding as sources, funnels and outcomes with conservation enforced at every tick, so every unit is accounted for and rate changes are gated by conviction rather than by an administrator. Alongside it, the issuance layer treats cash, credit, equity, insurance and reputation as coordinates in one issuance space instead of separate products. And the least glamorous part of the work is the part most likely to matter in twenty years: keeping the P2P Foundation's 41,500-article wiki online with public dumps anyone can mirror, so the research record does not depend on my hosting bill.