What towns can learn from Ethereum governance

The largest working digital governance system in the world is not a government. It is Ethereum: a protocol securing hundreds of billions in value, changed several times a year, coordinated across thousands of contributors in dozens of independent teams. And it has never held a binding vote on a protocol change.

That last sentence is why it is worth studying. When people imagine digital democracy they imagine voting apps, and voting apps are mostly where civic tech goes to die. Ethereum quietly built something else: a machine for turning open proposals into implemented decisions, with legitimacy that does not come from counting ballots. We spent this week studying how it works in 2026, including the newest tooling around it, and the transferable parts are bigger than we expected.

No votes at the center

Strip away the jargon and Ethereum governance is three layers.

A legible proposal pipeline. Every change starts as an EIP, a public document with a fixed lifecycle: Idea, Draft, Review, Last Call, Final. Editors shepherd proposals through the pipeline, and their mandate is precise: they check completeness and format, and they explicitly do not judge the idea itself. Discussion is mandatory and happens in public forums anyone can read.

Rough consensus among implementers. A proposal ships when the independent teams who build Ethereum's software agree to build it, on public calls held every two weeks. Nobody tallies votes. Objections get resolved, not outvoted. The people who must do the work hold the practical veto, because a change nobody implements is just a document.

Exit rights. Node operators can decline to run an upgrade, and a community that fundamentally disagrees can fork and keep the shared state. That happened in 2016, and the credible threat of it disciplines everything upstream. Consent is real because leaving is possible.

Notice what is missing: token voting. Ethereum deliberately rejected rule by the wealthiest holders. Signals from the community matter, but they inform the process rather than command it.

The legibility turn

The most interesting recent development was not a new consensus rule. It was a website.

In 2025 the Ethereum Foundation launched Forkcast, a public site that gives every proposed change a plain-language page: what it does, what it means for ordinary users, for app builders, for operators, broken down by stakeholder group. It tracks each proposal's status in the pipeline. It publishes summaries and transcripts of every core developer call within about two hours. Each proposal gets a named champion, one accountable person you can actually ask. And the process itself got calendar discipline: each upgrade cycle picks at most one headline feature per layer, pitched in an open submission window with published dates.

None of this changed who decides. All of it changed who can follow. An expert process that outsiders can audit in plain language is a different political object from an expert process that outsiders must take on faith. Ethereum's governance became more legitimate in the last two years not by adding democracy theater, but by becoming legible.

There is a hard lesson attached. In July 2026 the Foundation dissolved the very team that ran the calls and maintained Forkcast, and as of this writing nobody has publicly said who maintains it next. Tooling that lives in one organization's org chart dies with the org chart. If the process matters, it has to be encoded somewhere an organization cannot take with it.

The mapping to a town

A German town cannot move formal decisions out of its elected council, and it should not. But look again at the three layers: Ethereum's core developers cannot bind node operators either. The model never required anyone to surrender authority. What it built is advisory infrastructure so clear and so public that the formal decision makers would be embarrassed to ignore it. That is exactly the gap in small-town democracy, where ideas die in unanswered emails and nobody can say what happened to last year's proposal.

So the mapping writes itself:

• Proposals become signed public documents with a lifecycle. Idea, draft, discussion, opinion signal, committed for decision, implemented. Anyone can check the status of anything, forever.
• Editors become AI agents with the editor's mandate. Check completeness, ask for missing pieces, merge duplicates, translate into plain language, park stale drafts. Never judge merit. This is the rare governance role that is genuinely safe to automate, because it is mechanical, neutral, and every action is signed and auditable.
• The implementer gate replaces wishful thinking. A proposal advances to the council only when someone who would actually do the work, the administration, the public utility, a Verein, commits a named champion. Ethereum calls this "client teams signal intent to implement." A town calls it honesty about capacity.
• Opinion signals stay signals. We already run private, verifiable opinion polls in Röbel. In this model they take the role community sentiment plays in Ethereum: a strong input the formal body sees, never a decision. That is not a legal workaround. It is the same design choice Ethereum made on purpose.
• Meetings join the record. Agenda published before, plain-language summary and transcript pointers published hours after. This is Forkcast's most copyable feature and no town does it.
• One headliner per cycle. A yearly Maßnahmenpaket with an open pitch window and one flagship project, chosen first. Scope discipline is not bureaucracy. It is respect for the fact that a small town, like a client team, has finite hands.

Why this lives on Nostr

Forkcast has to scrape forums, repositories, and call recordings into legibility after the fact. We get to skip that entire problem, because on our stack the record is born structured.

Röbel's public record already runs on Nostr: signed events on relays the community controls, mirrored between independent nodes, with proposal pointers in the record as of this week. On that substrate, every piece above is just another event type. A proposal is a signed document with a stable address. A status change is an immutable event citing who moved it and why. An AI agent is simply another keypair whose every output is signed, labeled as machine-written under the EU AI Act, and filterable by anyone who would rather not read it. Agents subscribe to the record instead of scraping it, which is what "AI-agent-optimized bureaucracy" actually means in practice: not agents deciding things, but agents doing the translation, tracking, and summarizing that used to require a civil servant's afternoon.

And the third Ethereum layer, exit, becomes something concrete: data sovereignty. Because the whole decision record lives in an open protocol rather than our database, a town that stops working with us keeps everything: every proposal, every status change, every meeting summary, portable to any operator or to self-hosting. We consider that a feature we sell, not a risk we carry. Infrastructure for communities that want to own themselves has to be judged by how easily you can leave it.

What happens next

We have written this up as NSP-12, the Public Decision Record, a spec in the Netizen protocol: the event grammar for proposals, transitions, meeting records, opinion signals, impact summaries, and yearly cycles, plus the agent roles and their bounds. Like everything in the stack it ships through the node installer, so any community, with or without us, can run the process. Röbel dogfoods it first: the grammar, then the editor agent, then Forkcast-style proposal pages on the public record, then the first real Maßnahmenpaket cycle.

Ethereum spent a decade learning that governance is not a voting problem. It is a legibility problem, an accountability problem, and an exit problem. Towns can inherit that decade for free.