Sovereign Stack Model (SSM) — Comparative Reference

What the Sovereign Stack Model is and isn't

The Sovereign Stack Model is not a generic networking model. It is an opinionated model of the layers at which architectural choices about digital sovereignty get made. That framing distinguishes it from TCP/IP (which models the working internet) and from OSI (which models networking layers for pedagogy and standards development).

The model collapses lower layers — physical media, data link, IP-layer routing — into a single L1 because those layers are largely commoditized for sovereignty purposes. It elaborates the upper layers because that is where adopters' sovereignty commitments actually live: identity, community data, governance, federation, application paradigm.

Explicit mapping to OSI and TCP/IP. SSM L1 absorbs OSI L1–L3 and TCP/IP L1–L2 — the physical, link, and routing substrate — because those layers are commoditized for sovereignty purposes. SSM L2 (Transport / Channel) is a direct analogue of OSI L4 / TCP/IP L3. SSM L3 (Overlay Network) has no OSI or TCP/IP analogue; it sits above the routed internet rather than at the same level, and it is optional — systems that don't use overlay networks pass through it. SSM L4 through L9 zoom into what OSI calls the application layer (L7) and what TCP/IP calls Application (L4): they exist because that is where sovereignty decisions live.

The trade-off is intentional. The model has high resolution where adopters need it (six layers above transport, where most decentralization-relevant decisions get made) at the cost of lower resolution at layers most adopters don't decide about (physical and IP-layer infrastructure).

How the three models relate

TCP/IP, OSI, and the Sovereign Stack are three ways of carving the same architectural ground for different purposes.

TCP/IP optimizes for the working internet — minimal layers, focus on what implementers actually build to. OSI optimizes for pedagogical and standards-development clarity — more layers, more granular separation of concerns. The Sovereign Stack optimizes for digital-sovereignty decision-making — different layers entirely above the transport substrate, focused on where adopters' sovereignty commitments actually live.

None of the three is "more correct" than the others. They answer different questions. A network engineer debugging an issue reaches for TCP/IP. A standards body designing a new protocol reaches for OSI. An adopter trying to decide which decentralized stack to bet on reaches for something like the Sovereign Stack.

Where the analogues are clean and where they're not

Direct horizontal analogues are clean for the transport layer — TCP/IP Transport, OSI L4 Transport, and SSM L2 Transport / Channel all agree on what transport is. Below transport, the three models carve differently but share the territory.

Skewed (diagonal) analogues appear in two places. OSI L3 Network and TCP/IP Internet are absorbed into SSM L1 — the Sovereign Stack collapses the IP-routing substrate into a single foundational layer rather than separating physical, link, and network routing. SSM's L3 Overlay Network is a different concept entirely (overlay networks built on top of the routed internet, not the routed internet itself). Similarly, OSI L6 Presentation is mostly absorbed into SSM L4 Data & Semantic, since the Sovereign Stack treats data format and data semantics as integrated rather than separately layered.

For the third major asymmetry — OSI L5 Session having no Sovereign Stack analogue — see the dedicated card below.

How SSM differs from generic capability mapping

There are two ways to organize a description of what a complex system does. One is capability mapping — identifying the discrete capabilities a system provides and laying them out as a graph or hierarchy, with relationships between them. The other is layered modeling — committing to a small number of ordered layers, each with a defined role, and placing capabilities within them. SSM is the latter.

Capability mapping has real strengths. It captures complexity faithfully, accommodates new capabilities easily, and doesn't force commitments where they aren't yet warranted. The cost is that each map is bespoke — comparison across maps is hard, and the lack of overarching structure makes capability maps difficult to use for decision-making.

SSM commits to a layered structure with a defined schema: nine numbered layers, each with a specific role, and entities placed at their primary home layer (sometimes spanning multiple). The cost of this approach is that some information gets lost — particularly cross-cutting concerns and capabilities that don't fit cleanly into a single layer. The benefit is that comparison becomes possible: two architectures can be examined for what they place at L5, what they place at L8, what they leave empty.

That comparison is the purpose. SSM is designed for adopters trying to choose between decentralized stacks, contributors trying to understand where their work fits, and researchers trying to identify gaps in the landscape. All three benefit from a shared layered vocabulary in ways that a bespoke capability map cannot provide.

The methodological choice is intentional and load-bearing. SSM trades faithfulness for legibility — choosing structure that enables comparison over structure that captures every nuance.

Properties that don't belong at any single layer

Some architectural properties cut across layers rather than living at one. Immutable history, content addressing, Merkle-linked audit trails, versioning, and replayable state are protocol-level choices that may be implemented at L4 (Data & Semantic), L5 (Identity & User Sovereignty), L6 (Community Data & Governance), L7 (Peer Coordination), or L8 (Federation) depending on the protocol. None of these properties has a single layer where it always lives.

The layer at which a protocol implements such a property is itself a sovereignty-relevant architectural commitment. Content addressing implemented at L4 produces verifiable data structures that any layer above can rely on. Implemented at L7, it produces a peer-coordination substrate with built-in tamper-evidence. Implemented at L8, it produces federation with cryptographic accountability between instances. These are meaningfully different architectural worlds, even though the underlying technique — hashing content to address it — is the same.

SSM does not pull these concerns into a layer of their own because doing so would obscure exactly the choices that matter most. A reader encountering content addressing in an SSM placement should ask: at which layer does this protocol implement it, and what does that placement commit the architecture to? The same question applies to immutable history, audit trails, and versioning. The cross-cutting nature of these properties is a feature of the model, not a gap.

A note on language: when an entity description mentions one of these properties, the property is being implemented at the entity's primary layer unless otherwise noted. Entities that implement cross-cutting properties at multiple layers — common for integrated runtimes — surface this in their entity profile rather than in the layer model itself.

Where this model came from

The Sovereign Stack Model emerged from collaborative work across three overlapping working-group communities, each contributing complementary framing.

The Collaborative Technology Alliance (CTA) is a coalition of organizations and individuals working on prosocial, decentralized, and commons-oriented technology. OpenHaven is CTA's peer-to-peer technologies breakout group — the same project under a working name — and is the primary site where this model is maintained and refined as new entities surface and the taxonomy evolves. DWeb (the Internet Archive's Decentralized Web project, including DWeb Camp and DWeb Working Groups) provides a broader convening space for decentralized-tech practitioners and contributes the social-and-political framing of "digital sovereignty" that motivates the model's upper layers.

The model is attributed to this collaborative effort rather than to any single organization. As the entity catalog grows and new architectural patterns emerge in the ecosystem, the model is expected to evolve through the same working-group process — with revisions surfaced for community review rather than imposed unilaterally.

Versions and contributors

The Sovereign Stack Model is a working artifact developed through iterative drafts and community review.

V1 (2025) was produced by the World Wise Web working group with contributors Brad deGraf, Josh Field, Day Waterbury, and Brandon Nørgaard.

V2 (2026) was presented at the Internet Identity Workshop XLII (IIW 42), where it received feedback that informed subsequent revisions.

V3 (current, 2026) incorporates revisions from the V2 review cycle and ongoing input from the broader Collaborative Technology Alliance, OpenHaven, and DWeb communities.

Feedback is welcome. To suggest revisions, raise an issue, or contribute to future versions, contact Brandon Nørgaard at brandon@civicenlightenment.org.