Governing Infrastructure That No One Owns

How irl.coop bootstraps a member-controlled cooperative from a single account and hands it over to the people

There's a paradox at the heart of building member-owned digital infrastructure. To create a system where no administrator has unilateral power, someone has to go first. Someone has to provision the servers, mint the cryptographic keys, create the initial data structures, and wire everything together — before any governance exists to authorize those actions.

This is the bootstrapping problem. And it's not just a technical inconvenience. It's a question of legitimacy. How do you build a cooperative that members genuinely own and control, when the thing they're supposed to own has to be built before they arrive?

This post describes how irl.coop solves it — and the governance architecture that makes member control real rather than rhetorical.

Why This Is Harder Than It Looks

Most "member-owned" platforms solve the governance problem with a terms of service and a promise. The servers are still run by a company, the data is still stored in proprietary systems, and membership means the right to vote in occasional polls. The infrastructure itself remains under centralized control.

irl.coop is attempting something different: genuine cryptographic sovereignty, where member control is enforced by math rather than policy. All configuration — including the secrets that run the infrastructure — lives as encrypted data in a decentralized data layer called Ceramic. Access to those secrets requires satisfying cryptographic conditions evaluated by a threshold network called Lit Protocol. No one person, including the founders, can unilaterally decrypt a member's data, change infrastructure configuration, or provision services without authorization from the appropriate governing body.

This design creates real bootstrapping dependencies. Map them out and you get circles:

The mail server needs an authentication provider to verify users. The authentication provider needs the mail server to send verification emails. The provisioning service that configures both reads its configuration from encrypted data streams. Those streams need cryptographic keys to exist before they can be written. The keys need to be registered in a root network stream. The root stream needs to already exist.

Every service depends on something that depends on something else. None of them can start first.

The Resolution: True Primitives and a Ceremony

The way out of a dependency circle is to find the things that have no dependencies — the true primitives — and build upward from there in strict sequence.

For irl.coop's stack, the true primitives are exactly four things: physical infrastructure (servers, networking, DNS), read-only access to an Ethereum-compatible blockchain, access to the Lit Protocol threshold network as a client, and a single master secret. Everything else derives from those four in a defined sequence we call the bootstrap ceremony.

The Master Secret

The ceremony begins with generating a single master seed — a BIP39 mnemonic — using a hardware-isolated process. This seed is the cryptographic root of the entire system. From it we derive the founding wallet used to mint cryptographic keys, and the initial credentials for services that need to start before encryption infrastructure exists.

The seed is held by the founding member — the single person who conducts the ceremony. It is used exactly once: to derive the founding wallet and initial service credentials. After the ceremony transfers control to the infrastructure subgroup, the founding account retains no special privileges. The seed should be stored securely offline (a hardware key or encrypted cold storage) not because it grants ongoing authority — it doesn't, after the transfer — but because it is the recovery path if the ceremony needs to be replayed from scratch on new infrastructure.

This is the only moment in the entire system where a single person holds undivided authority. It's deliberate, brief, and immediately followed by its own dissolution.

Stateless Infrastructure First

Some services have no dependencies above the physical layer. These start first, configured entirely from environment variables derived from the master seed — no encrypted streams, no cryptographic key infrastructure, no authentication server:

A Postgres database for the orchestration layer's operational state
MinIO for raw object storage
IPFS as the content-addressed layer for the data stream network
Ceramic, the decentralized data stream network, starting fresh with no streams

These services start dumb. They get smart in subsequent phases.

Minting Founding Keys

With an Ethereum-compatible RPC available and Lit Protocol reachable, the ceremony mints three programmable keypairs (PKPs — Programmable Key Pairs, a Lit Protocol primitive that allows keys to be controlled by on-chain logic rather than a single holder):

The bootstrap PKP is a temporary key used only during the ceremony to author initial data streams before permanent governance exists. It is destroyed at the end of the ceremony.

The infrastructure PKP is the runtime identity of the provisioning service — the key it uses to decrypt secrets and apply configuration changes. It's initially controlled by the founding wallet, then transferred.

The subgroup PKP is the cryptographic identity of the infrastructure subgroup — the governing body that will own and operate the network. It's created now but handed over in the final phase.

Building the Root Stream

With keys minted and Ceramic running, the ceremony creates the root network stream — the cryptographic trust anchor for the entire network. Every piece of data in this stream is encrypted using Lit Protocol access conditions: rules that determine who can decrypt what, evaluated dynamically against live on-chain and on-Ceramic state.

One field is intentionally left unencrypted: the infrastructure PKP's public address. Every node in the network needs to know which PKP to trust as a legitimate infrastructure agent without having to decrypt anything first. This is the public trust anchor — the one piece of information the network agrees to share openly.

The Provisioning Sequence

The NestJS orchestration service starts in a special bootstrap mode, reading from the local ceremony manifest rather than encrypted streams. It provisions services in strict dependency order, breaking each circular dependency by sequencing:

MinIO and Postgres are provisioned first — they have no application dependencies. Stalwart, the mail server, starts next with local authentication only, deliberately sidestepping the authentication circular dependency. The NestJS OIDC provider starts with Stalwart already running. Stalwart's configuration is then updated to use OIDC. The loop is broken by sequence rather than architecture.

All configuration written during this phase — service stream IDs, encrypted secrets, provisioning state — is committed to Ceramic streams as it's created, building the encrypted configuration layer that will govern the system going forward.

The Transfer: Making Governance Real

The ceremony's final act is the most important. The founding account, which has built everything and holds all temporary authority, transfers control to the infrastructure subgroup — a formal cooperative group within irl.coop — and removes itself.

This transfer is not a policy change or a terms update. It's a series of on-chain and on-Ceramic transactions that are cryptographically irreversible without the subgroup's own governance approval:

The root stream's controller changes from the bootstrap PKP (now destroyed) to the subgroup PKP. The infrastructure PKP's permitted signers change from the founding wallet to the subgroup PKP. The subgroup PKP's permissions are transferred from the founding wallet to a Lit Action — a piece of code running on the Lit threshold network — that enforces the subgroup's governance rules before allowing any signature.

After the transfer, the founding account's privilege inventory looks like this: it cannot sign with the infrastructure PKP, cannot sign with the subgroup PKP, cannot update the root stream, cannot decrypt any service stream secrets, cannot decrypt group governance data. It retains the same access any network member has: the ability to read publicly disclosed information and request membership in groups through normal channels.

The founding account becomes a regular member. The infrastructure becomes governed.

The Governance Architecture

The infrastructure subgroup's governance isn't a static set of rules. It's a state machine that evolves as the cooperative grows, enforced by the Lit Action that controls the subgroup PKP.

Four Phases of Governance

Solo Development Phase covers the period when a single member is building and maintaining the infrastructure — expected to last up to six months. Rather than pretending governance exists when it doesn't, this phase acknowledges the reality: one person is making all decisions. The constraint is that every action is cryptographically logged to a Ceramic stream. Every provisioning decision, every configuration change, every secret rotation is a signed, timestamped, content-addressed commit that future members can audit in full. Constitutional changes — transfers of root authority, changes to governance rules themselves — are locked and cannot be performed unilaterally.

Founding Phase begins when a second member joins. At two members, unanimity is required for all decisions. This phase is brief by design.

Stable Phase begins at three members: simple majority (2-of-3) governs all decisions. This is the primary operating mode for the early cooperative.

Scaled Phase begins at four members and beyond. Quorum is calculated as ⌊n × 0.6⌋ + 1 — always slightly above simple majority. The formula scales automatically as the subgroup grows, with no governance amendment required.

Inactivity Escalation

A governance system with no fallback is a fragility. If subgroup members become unreachable, the infrastructure doesn't need to be ungoverned — it escalates to a broader democratic body.

If no signed governance action is recorded for 30 days, subgroup members receive a warning. At 30 days of inactivity, a cooperative-wide membership vote is automatically triggered. The infrastructure PKP is suspended for new provisioning actions — critically, existing services continue running, because suspension is governance-only and not infrastructure-destructive. The full irl.coop membership votes on whether to ratify existing members, appoint new ones, or restructure the subgroup entirely.

This mechanism ensures the cooperative always has a legitimate path to restore governance without requiring the original subgroup to be reachable.

Verified Human Attestation

PKP-based identity solves one problem — cryptographically binding actions to a persistent identity — but not another: proving that distinct identities correspond to distinct humans. Without humanness verification, a single person could create multiple identities and satisfy governance quorums alone, quietly breaking every assumption the system makes about democratic legitimacy.

irl.coop's attestation system addresses this with a continuous, composable, member-controlled model that's fundamentally different from binary credential systems.

Methods and Weights

Rather than a yes/no "verified" flag, every attestation carries a weight. Different methods have different inherent trust weights, and those weights decay over time:

Biometric verification via World ID — where a person's iris scan generates a zero-knowledge proof of uniqueness without revealing biometric data — carries the highest weight. A verified World ID means, with high cryptographic confidence, that this is a unique human who hasn't already registered under another identity.

In-person social attestation, where a verified human physically meets and vouches for another person, carries high weight. Remote video attestation, conducted by any combination of verified members, a quorum, or a designated irl.coop node, carries medium weight depending on how many people witness it. Asynchronous social vouching carries lower weight but still contributes.

A member's total attestation score is the weighted, decayed sum of all their non-revoked attestations. Groups define minimum score thresholds for different participation levels — joining, voting, holding admin roles — and can require specific methods, minimum numbers of distinct attestors, or particular chain-of-trust depths.

The Chain of Trust

Social attestation follows a chain-of-trust model: only verified humans can vouch for others. This means attestation authority propagates through the network from humans who have already been verified, rather than from anyone who happens to hold an account.

An attestor's own score multiplies into the weight of their vouches. A vouch from someone with a score of 1.0 is worth more than a vouch from someone with a score of 0.4. This creates a natural hierarchy of trust that emerges from the network rather than being administratively assigned.

Graceful Degradation

When an attestor revokes their vouch — for any reason, including simply losing touch with the person — the system doesn't immediately invalidate the attested member's standing. Instead, the score is recalculated without that attestation. If the member drops below a group's threshold, they receive a notification and a grace period — typically 30 days — to obtain replacement attestations. This models how human trust actually works: relationships end, circumstances change, but a person's overall trustworthiness doesn't evaporate instantly when one relationship sours.

Member-Controlled Disclosure

Attestations are encrypted using Lit Protocol access conditions that the member themselves controls. The same attestation data can serve different disclosure levels depending on context:

A group membership check might only need to know "this member's score exceeds 0.5" — a simple threshold verification that reveals nothing about methods or attestors. A governance role assignment might need to know which methods were used. A deep trust context might require full attestation chain visibility. The member explicitly grants each disclosure level to each requestor, and those grants are enforced cryptographically.

Zero-knowledge proofs from World ID are a special case: they're public by design, because the proof itself reveals only uniqueness — nothing about the person's identity, location, or other attributes. The proof IS the privacy.

What All of This Adds Up To

The system being described here is unusual in a specific way. Most cooperative platforms govern their policies with cooperative structures while running their infrastructure with conventional administrative authority. There's a board that sets rules, but there's also a CTO who can access the database.

irl.coop is attempting to close that gap — to make the infrastructure itself subject to the same cooperative governance as the organization's decisions. The provisioning service won't act without governance approval. The secrets can't be decrypted without authorized PKP signatures. The configuration can't be changed without satisfying quorum rules enforced on a threshold network.

The bootstrap ceremony, the governance state machine, and the attestation system are three parts of the same answer to the same question: what does it mean for infrastructure to be genuinely member-owned, rather than just member-associated?

The answer, it turns out, involves a lot of cryptography. But the principle is simple. Power over the infrastructure should require authorization from the people the infrastructure serves. Not as a policy. As a proof.

irl.coop is a member-owned digital cooperative currently in development. The architecture described in this post is being actively built. If you're interested in the technical design, the governance model, or getting involved as an early member or advisor, visit irl.coop.

Written by

irl.coop

hello@irl.coop