The Decentralized Systems Landscape: Content, Identity, Consensus, and Compute

1. Introduction

The effort to decentralize computing has not produced one system or one field. It has produced four, loosely related and mostly studied apart. One set of systems moves content without a server: you fetch a file from whoever has it, verified by its hash, and the origin need not be anyone in particular. Another set carries social identity and publishing without a platform owner: your account, your posts, your follow graph live across independently run servers, or on relays, or in a portable repository, rather than inside one company. A third set lets mutually distrusting strangers agree on a single shared state — a ledger of who owns what — with no admission control and no trusted operator. And a fourth set runs computation that a relying party can trust without re-doing or being shown it: a contract that executes the same way for everyone, a proof that a computation was performed correctly, an enclave that attests to what it ran, a credential signed by an issuer you accept.

These four are rarely placed on the same page. A developer who has internalized how BitTorrent swarms distribute a file starts from scratch when reasoning about how a blockchain orders transactions, and again when reasoning about how the Fediverse federates a timeline, and again when reasoning about what a zero-knowledge rollup actually proves. The vocabularies diverge, the communities barely overlap, and the result is that the decentralized field is hard to see whole. This paper tries to see it whole — not by reducing the systems to one mechanism, but by mapping them on a small set of shared dimensions and reading the map for what it shows.

The dimensions are few and concrete. How is a thing addressed — by where it sits, by the hash of its content, by the key of its writer? How does identity work — is it a server-bound handle, a bare keypair, a portable identifier? How is access controlled — not at all, by a coarse public-or-private flag, by fine-grained permission? What posture must a participant hold to take part — must they stay online and serving, or can they go passive and still count? How is trust in a computation established — by re-running it, by checking a proof, by trusting hardware, by trusting a signature? And how decentralized is the system once it is actually deployed, as opposed to in its design documents? These six questions are enough to place every system in the field beside every other.

A pattern emerges when the systems are laid out this way, and it is the paper’s main observation. Each deployed system occupies one region of the field at a fixed posture, and pays the characteristic cost of that fixity. A BitTorrent file is available only while someone is online seeding it; the price of its swarm model is that the long tail of unpopular content simply disappears. A Mastodon identity is your server’s to keep or lose; the price of federation-by-server is that migrating means abandoning your posts. An on-chain contract is trusted because every node in the network re-executes it; the price of that trust is that running code this way is among the most expensive ways to compute anything. None of these is a defect — each is the cost of a deliberate choice to fix one posture — but the costs rhyme across the field, and seeing them lined up is most of what the map is for.

The stance of the paper is cartographic, not competitive. We describe what is in the field and place every system on the same axes; we do not grade them or argue that one beats another, because that is not what a map is for and because the systems are answering genuinely different questions. The compute cluster, in particular, sorts so cleanly that it gets its own small map: there turn out to be five ways the field establishes trust in a computation, and naming them is one of the more useful things this survey can offer.

We do locate one further point on the map, and we are deliberate about how. Across this series of papers we have developed a content-addressed, typed, capability-secured substrate — the entity system (see The Entity System; The Entity Core Protocol) — and it belongs on this map because it speaks to all four clusters at once. But we place it the way we place every other system: on the same axes, described rather than sold. Its distinguishing position, when plotted, is that it can move posture rather than fixing one, and that it spans regions a single deployed system tends not to. We are equally explicit about where it is not on the map at all — it has no deployed users where the incumbents have tens of millions, and the properties it leans on, content addressing and signed identity and key-based control, are prior art it shares with IPFS and Hypercore and Nostr, not things it invented. The contribution of this paper is the map, and the entity system is one point in it.

1.1. The Boundaries with the Other Views

This paper is a survey of the outside field, and it sits beside three companion papers that look inward at the substrate, so the seams are worth naming. The structural landscape — what primitives each existing system is built from, analyzed by the methodology this corpus develops — is Convergent Evolution; where that paper asks what a system is underneath, this one asks what it is like deployed, what people run and at what cost, and cites the structural account rather than re-deriving it. The view of the substrate as the operating system of one’s own machines is DEOS, and it hands off to this paper exactly where a private fleet of devices meets the wider network of other people’s fleets. The view of the substrate as something a developer builds an application on is Application Architecture. Those three are about running and building on the substrate; this one is about the field the substrate would join, mapped on its own terms.

1.2. What This Paper Covers

1. The deployed field, cluster by cluster: content distribution, social and identity, consensus and ledgers, and contractual and verifiable compute — each as a deployed reality, with the posture it forces and the cost it carries.
2. The dimensions of the map — addressing, identity, access, posture, compute-trust, and decentralization-in-practice — drawn across all four clusters, with the comparison table that lays the field out at once.
3. The compute and trust models — the five ways the field establishes trust in a computation, the richest single dimension.
4. The entity system as one point on that map — where it falls, where it spans regions, and where it is honestly not comparable.
5. Social convergence — the open question of what people actually adopt, which no amount of technical merit settles.

1.3. What This Paper Does Not Cover

The six primitives and the substrate they generate are in The Entity System, The Entity Core Protocol; the computational model in The Entity Church Architecture; the structural analysis of the existing-systems landscape in Convergent Evolution; the operating-system view in DEOS; the application-development view in Application Architecture; and the capability and security model the map refers to in Entity System Security Architecture. We assume those and do not re-derive them. We also do not attempt a complete census of the decentralized field, which is vast and moving; we map the systems that anchor each cluster and are most instructive, and we mark where currency-sensitive facts may have moved by the time this is read.

2. The Deployed Field

The map is easier to read after a walk through the territory. We take the four clusters in turn, describing each system as it actually runs — the posture it forces and the cost that posture carries — rather than as its specification promises. Throughout, we cite the structural analysis (see Convergent Evolution) for why a system has the shape it does, and concentrate here on what that shape is like to live with.

2.1. Content Distribution

The oldest decentralized success is moving bytes without a central server. BitTorrent (Cohen 2003) does it by swarming: a file is split into hash-verified pieces, and every peer downloading also uploads, so popular content gets faster as more people want it — the one place in this whole field where load is a help rather than a cost. Discovery moved from central trackers to a distributed hash table (Maymounkov and Mazières 2002), so a magnet link needs no server at all. The posture BitTorrent fixes is the online, reciprocating peer: content exists exactly as long as someone is seeding it. The price is the dead torrent — the long tail of content with no seeders is simply gone, the distributed hash table remembering who claimed to have it but not the bytes. BitTorrent has no identity and no access control; the infohash is an unscoped bearer token, and a private torrent is private only because a community gatekeeps a tracker and keeps the hash secret.

IPFS (Benet 2014) generalizes content addressing from a whole torrent to every object: content is chunked into a Merkle structure, each node named by the hash of its bytes, so identity and integrity are intrinsic and identical content is automatically one thing. It adds peer identity and a signed mutable-pointer layer, which BitTorrent lacks. But the posture is much the same: content lives only while a node pins it and stays reachable, and unpinned data is garbage-collected. IPFS is widely mistaken for permanent storage; it is content-addressed caching with opt-in pinning, and permanence is a service one buys or runs. In practice the network re-centralized in two familiar places — a handful of public HTTP gateways through which most consumption flows, and a few commercial pinning services on which persistence concentrates — a drift the project itself names and is working to counter. One nuance matters for the map: because content is self-verifying, any holder can serve it and a client can check what it received, so a passive store can serve trustworthy bytes; what it cannot do is announce itself, so discovery still wants a live provider.

Hypercore (the protocol that grew out of Dat (Ogden et al. 2017; Holepunch 2023)) inverts the addressing choice instructively. Where BitTorrent and IPFS address immutable content by its hash, Hypercore addresses a signed, append-only log by its writer’s public key — the unit is a mutable, versioned stream owned by a keypair, with full history and the ability to fetch only the ranges you need. This is the deployed system closest to a signed, identity-rooted, mutable model, which makes it the most demanding comparison for anything claiming those properties. Its fixed posture is single-writer (multi-writer is an add-on), and like the others its availability still depends on someone staying online to replicate from. Its real deployment is small next to BitTorrent and IPFS, but it is the clearest evidence that “content addressing versus nothing” is a false binary — signed mutable streams are a third, well-explored point.

2.2. Social and Identity

The second cluster decentralizes publishing and social identity, and its systems share one defining trait worth stating before the differences: all of them are public-broadcast-first. None was designed primarily for private, selectively shared, or finely permissioned content, and each is now retrofitting that, late and partially. That shared gap is the cluster’s most important single fact.

ActivityPub (World Wide Web Consortium 2018), deployed mainly as Mastodon, federates servers: thousands of independently run instances exchange signed activities, and the unit of the network is the server, not the user. Your identity is your handle at your instance, your data lives in that instance’s database, and the instance holds your keys and must stay online for you to exist on the network. The posture is “be, or be hosted by, an always-on server.” The cost is that your identity and your history are hostages of one operator: account migration carries your followers but not your posts, and if your instance shuts down, your reach and your archive go with it. Visibility is a coarse server-enforced flag, and direct messages are not end-to-end encrypted — the admins on both ends can read them.

The AT Protocol (Bluesky Social 2024), deployed as Bluesky, splits the monolithic server into a personal data repository (a signed, content-addressed tree of your records), relays that aggregate everyone’s repositories into one firehose, and application views that build the actual product from that firehose, with identity carried by a decentralized identifier. This is architecturally the most interesting of the three for our map, because the repository is signed and content-addressed and can therefore be mirrored and verified independently — the closest the deployed social field comes to “a passive store can serve you.” Its headline is portability and “credible exit”: because your identity is a portable identifier and your data is a signed repository, you can in principle move your hosting and keep your identity and your posts, which Mastodon cannot offer. Honestly assessed, the exit is more credible than anywhere else here and less credible than the marketing: the identifier directory almost everyone uses is operated by one company today, and while the protocol permits many relays and application views, few run at scale, so the experience is in practice gated on a handful of central services. Private and permissioned data is not shipped; it is an active design effort.

Nostr (The Nostr Contributors 2023) is the minimal design: a client signs an event and pushes it to relays, which are dumb store-and-forward servers that do almost no logic, and clients reconstruct a view by querying many relays and merging. Identity is a bare keypair, bound to no server — the strongest identity portability in the field, since you are the same identity on any relay and can abandon any of them. The cost is the mirror image of Mastodon’s: nothing guarantees your content survives, is found, or is recoverable. Relays prune and come and go; key loss is final, with no recovery or rotation in practice. Nostr is public-by-default, with private messages available through a layered encryption convention but no capability model — the choice is “encrypt to a public key” or “broadcast,” with nothing structured in between. Its topology is the most decentralized here, yet it re-concentrates on a few popular relays because that is where the audience is.

2.3. Consensus and Ledgers

The third cluster solves a genuinely hard and distinct problem: letting mutually distrusting parties with no admission control agree on a single shared state. Bitcoin (Nakamoto 2008) produces one global, append-only ledger that every full node independently holds and validates, ordered by proof of work and a heaviest-chain rule, with agreement that is probabilistic — a transaction is never provably final, only exponentially unlikely to reverse. This is the open-membership case classical protocols cannot touch, and it is a real achievement. Its cost is structural: global redundancy, where every node stores and re-validates all history, deliberately the opposite of partitioning; a throughput ceiling of a few transactions per second; and proof of work’s standing energy cost, which is the literal mechanism by which the right to extend the chain is made expensive enough to resist forgery. Ethereum (Buterin 2014) keeps the one-global-ledger model but, since moving to proof of stake, derives its Sybil resistance from staked capital and slashing rather than burned energy, and offers sharper, checkpoint-based economic finality. What this cluster is for is trustless agreement among strangers; what it is wrong for is personal, private, mutable, or high-volume data, where having every node on earth hold a copy is a category error.

Behind the blockchains stand the classical consensus protocols they extend. Paxos (Lamport 1998) and Raft (Ongaro and Ousterhout 2014) give a provably linearizable replicated log — all correct replicas agree on the same sequence of commands — under crash faults, assuming known membership, quorums, and an elected leader; Byzantine fault tolerant protocols (Castro and Liskov 1999) give the same under up to a third of the participants behaving arbitrarily, at the cost of more nodes and more rounds, still with fixed membership. These run the coordination services and replicated databases that much of the centralized internet quietly depends on. Their relevant trait for the map is the one the open ledgers relax: with known membership they are cheap and provably correct, but a node on the minority side of a network partition blocks rather than diverging — it stops, by design, to preserve consistency. That deliberate choice, consistency over availability under partition, is the axis along which the rest of the field — and the substrate we will place — chooses differently.

2.4. Contractual and Verifiable Compute

The fourth cluster is about running computation that someone else can trust, and it is rich enough that its organizing structure — five distinct ways trust is established — gets its own section. Here we name its members. Smart contracts (Szabo 1997), deployed at scale on Ethereum’s virtual machine and its kin, are deterministic programs executing on a replicated state machine, trusted because every node re-runs them and must agree on the result. Non-fungible tokens (Entriken et al. 2018) are, stripped of the hype, ownership records over a token on such a chain, whose referent — the image, the metadata — usually lives off-chain, frequently as an IPFS hash, tying this cluster back to the first. Zero-knowledge proofs and the rollups built from them (Ben-Sasson et al. 2018) establish trust a different way: execute off-chain and post a succinct proof that the execution was correct, so a verifier checks the proof instead of re-running the work. Trusted execution environments (Costan and Devadas 2016) establish it in hardware, isolating and attesting which code ran, trading correctness-by-redundancy for trust in a chip vendor. Secure multiparty computation (Yao 1982) and fully homomorphic encryption (Gentry 2009) establish confidentiality rather than mere correctness, computing over data without exposing it. And underneath all of them, decentralized identifiers and verifiable credentials (World Wide Web Consortium 2022; World Wide Web Consortium 2025) carry the trust-the-signature model into decentralized identity — a signed claim a verifier checks against an issuer it accepts, without re-execution or proof. The next section draws these five into one small map.

3. The Dimensions of the Map

The walk through the clusters surfaces a small set of axes that recur in every one of them. Drawn together, they are the map’s coordinate system, and they let a system in one cluster be compared with a system in another — which is the point of mapping the field as one thing.

• Addressing. By location (a server URL), by the hash of content (a content identifier, an infohash), or by the key of a writer (a public key, a decentralized identifier). Content and key addressing decouple a thing’s identity from where it sits, which is what makes verifiable re-hosting possible.
• Identity. Bound to a server (a Fediverse handle), a bare keypair (Nostr, most chains), or a portable identifier with indirection (the AT Protocol’s). The axis that decides whether leaving a service means leaving yourself behind.
• Access and capabilities. None (a bearer hash), a coarse public-or-followers flag, encryption to a recipient, or fine-grained per-resource permission. The cluster of social systems sits, almost entirely, at the public-or-encrypt end.
• Posture and persistence. What a participant must do to keep taking part and to keep their data available: stay online and serving (BitTorrent, a Mastodon server), keep republishing to live relays (Nostr), pin (IPFS), or — a possibility most of the field does not offer — park signed, self-verifying state somewhere passive and remain a participant.
• Trust in computation. The compute cluster’s axis, drawn out in the next section: re-execute, prove, attest, hide, or sign.
• Decentralization in practice. Distinct from decentralization in design. Nostr’s topology is maximally decentralized yet its traffic re-concentrates on popular relays; the AT Protocol is the least decentralized in practice yet the most coherent as a product; IPFS is decentralized in principle and gateway-mediated in fact. This gap is the axis the map is most useful for, because it is the one marketing most often elides.

The table places the anchor systems on these axes at a glance, with the substrate this series develops added as the final row — placed the same way, on the same axes, and taken up in detail in its own section below. It is a reading aid, not a scorecard; a cell that looks thin is the cost of a posture chosen for a reason.

Read down any column and the field’s range is visible; read across any row and one system’s whole posture is. The recurring lesson, stated once: a system that decentralizes one thing well usually does so by fixing a posture on the others, and the map’s value is making that trade legible rather than hidden. The substrate’s row is the visible exception — a movable posture where every other row fixes one, and a fine-grained capability where the field sits at public-or-encrypt — which is why it earns its own section rather than a single line: the row places it on the axes, and the section reads what the placement means.

4. Compute and Trust Models

The compute cluster rewards a closer look because it sorts so cleanly. Strip away the branding and there are exactly five ways the decentralized field gets a relying party to trust a computation or a claim. Naming them is, we think, the most useful single thing this survey produces, because once named they are visible everywhere.

Verify by re-execution. Everyone re-runs the code and agrees on the identical result; trust comes from redundancy. This is the smart-contract model: a deterministic program on a replicated state machine, metered so it must halt, its state and bytecode public. It buys the strongest property in the field — agreement among mutually distrusting strangers with no trusted operator — and pays the steepest cost, because running code that the entire network must re-execute is the most expensive way to compute, with no privacy and a hard throughput ceiling. It is trust by having the whole world watch.

Verify by proof. Execute once, off to the side, and produce a succinct cryptographic proof that the execution was correct; a verifier checks the proof, which is far cheaper than redoing the work. This is the zero-knowledge model, deployed at scale as rollups that execute transactions off-chain and post a validity proof on-chain. Two honest qualifications belong on the map: “zero-knowledge” in this usage usually means succinct, not hiding — the value is compressed verification, and the privacy property is often unused — and most production systems today still run a centralized sequencer and a permissioned prover, so the proof is trustless while the ordering and liveness around it are not yet. The direction of travel is real and the proofs are sound; the decentralization is partial.

Verify by attestation. Run the computation inside a hardware-isolated enclave that attests, cryptographically, which code it ran, so a remote party can trust the result without seeing the data. This is the trusted-execution model, deployed as confidential virtual machines on the major clouds. It uniquely offers confidentiality during computation, but its trust roots in the hardware vendor and its microcode, and the lineage has a long history of side-channel breaks — “secure,” with the threat model spelled out.

Privacy by protocol. A cryptographic protocol lets parties compute over private inputs while revealing only the output, with no trusted host at all — secure multiparty computation, mature in narrow high-value niches like threshold key custody — or compute directly on encrypted data — fully homomorphic encryption, the strongest confidentiality story and the least mature, still carrying large overheads. Trust here comes from the mathematics rather than from redundancy, hardware, or a signer.

Trust the signature. No computation is re-run, proven, or attested; a claim is trusted because it carries a signature chain to an authority the verifier already accepts. This is the oldest model — classical public-key infrastructure and certificates — carried into the decentralized field by decentralized identifiers and verifiable credentials (World Wide Web Consortium 2022; World Wide Web Consortium 2025), where a holder presents a signed claim and a verifier checks the issuer’s signature without contacting the issuer. It is the cheapest to verify and the model most of digital identity actually runs on.

These five differ along clear sub-axes: the scope of trust (everyone, a verifier, a hardware vendor, the protocol’s participants, whoever accepts the issuer), whether the computation is confidential, and the shape of the cost (redundant work, expensive proving, near-native plus attestation, heavy cryptography, a single signature check). A secondary axis cuts across all five — where the computation is replicated: globally on a chain, off-chain with on-chain verification, on a single attested host, or among a few protocol participants. Laid out this way, the compute cluster is not a pile of competing buzzwords but a small, legible space, and a system can be located in it precisely.

5. The Entity System on the Map

The substrate this series develops (see The Entity System; The Entity Core Protocol) goes onto the map like everything else — on the same axes, with its costs and its absences stated as plainly as anyone else’s, and described rather than sold.

On the addressing and identity axes it sits with the content- and key-addressed systems: entities are named by the hash of their content, identity is rooted in keys, and both are therefore independent of where a thing is stored. This is shared ground with IPFS, Hypercore, and Nostr, not new ground, and saying so is part of placing it honestly. Where it differs is the access axis, where most of the field sits at public-or-encrypt: the substrate’s unit of authorization is a fine-grained, attenuable, revocable capability that travels with the artifact (see Entity System Security Architecture), so private and selectively shared state is native rather than retrofitted. That difference is thrown into relief by the social cluster’s defining trait — those systems are public-broadcast-first and are adding permissioned data late and partially — which is the clearest evidence in the field that fine-grained capability is a real gap and not a solved corner.

On the compute axis, the substrate falls in the re-execution family by mechanism — computation is content-addressed and deterministic, so a result can be re-run and checked by anyone holding the inputs, or trusted directly by its hash (see The Entity Church Architecture) — but at a scope the compute map does not otherwise contain. Where a smart contract is re-executed by every node in a global network to reach agreement among strangers, the substrate’s compute is verified at peer scope: a party who cares re-runs it or trusts its hash, and there is no requirement that the whole world re-execute and no global ledger ordering one shared state. It is a new cell — deterministic, verifiable compute at local scope, access-gated by capabilities, with no global consensus — and its nearest neighbor is not a blockchain virtual machine but the reproducible-build, content-addressed lineage of Git and Nix, extended from artifacts to computation.

The trait that distinguishes the substrate across the whole map, rather than on any one axis, is posture. Every deployed system in the field fixes one: the online seeder, the always-on server, the pinning node, the full validator. The substrate’s posture is movable, because state is content-addressed, signed, and capability-rooted wherever it sits, so the same participant can be a live peer, or park its state on a passive store and go quiet, or poll when weak, or work offline and reconcile later — and a static host serving signed, self-verifying entities is a first-class participant, not a dumb cache. The field’s nearest approaches to this are instructive and worth crediting: IPFS’s verifiable gateways already let a passive store serve trustworthy bytes, and the AT Protocol’s signed repository can already be mirrored and verified. The substrate’s distinct position is the full range of postures as a property of one system, and that a passive participant is an authorized one, discovery and access included, rather than only a server of verifiable bytes. That movable posture also makes it scale-independent: with no posture forced and no central operator required, the substrate works as readily between two peers on a home network as across many, so its decentralization is a structural property rather than a deployment statistic — which is what the map’s practical-decentralization cell records for it, what its operation requires rather than how many run it.

What the substrate provides on the consensus axis must be stated with care, because it is the easiest thing in this field to overclaim, and the honest version is sharper. It provides convergence, not consensus. Peers reconcile a content-addressed version history by walking to a common ancestor and merging, surfacing conflicts as data rather than blocking on agreement; this yields eventual, partition-tolerant convergence whose single-valued result is guaranteed only when the merge is a proper join, and otherwise guarantees the weaker but still useful property that divergence is represented rather than silently lost. Strict linearizable consensus in the Paxos or Raft sense — one agreed log with bounded failover — is not provided. The primitives could be configured toward it, with a write capability serving as leadership and a quorum over published heads as commitment, but that is a sketch, unproven under a fault model and unshipped, and a single, totally ordered log arises directly only under a single writer, where the problem is replication rather than agreement. Nor does content addressing buy Byzantine agreement: it detects tampering with content, not lying about which version is canonical, so the substrate is partition-tolerant with cryptographic integrity, not a Byzantine fault tolerant protocol and not the trustless-among-strangers agreement that a blockchain exists to provide. It occupies the available, capability-scoped, offline-first, integrity-verifiable corner of the space — a different problem from the one consensus protocols solve, and strictly weaker than they are on the one problem they are built for.

Three absences round out the honest placement. The substrate is not zero-knowledge or succinct — re-running to verify is the opposite of checking a proof cheaper than the work. It is not confidential compute — it is public to whoever holds the inputs, with capabilities gating access rather than visibility during computation the way an enclave or a multiparty protocol does. And it has no deployed user base where the social and ledger incumbents have tens of millions; its richer model is unproven at the scale they have reached, and it carries operational questions — moderation, abuse, key compromise, revocation at scale — that capability-based and content-addressed designs raise freshly rather than inherit solved. And the map captures only the substrate’s outward, networked face: its role as the programming substrate that applications are built on Application Architecture and as the operating system of one’s own machines (see DEOS) are powers these axes are not built to show, so placing it among deployed networks is fair only with that limit named — it is being measured here on one of the several things it is. The point of placing the substrate on the map is not to crown it. It is to show that a system shaped as a substrate rather than an application lands not in one region but across several, and that this spanning is itself the interesting property — the same observation the companion papers make from the inside, that the substrate fits wherever you point it (see DEOS; Application Architecture), seen here from the outside, against the field.

6. Social Convergence

A map of technical positions is not a map of what people use, and the gap between the two is the decentralized field’s most honest open question. It is worth separating two kinds of convergence that the field’s discourse routinely runs together.

The first is protocol convergence: whether independent implementations of a system agree, down to the bytes, on what is valid. This is a decidable property, and for a well-specified protocol it is achievable and checkable — the systems in this survey that are precisely specified can be implemented compatibly by parties who never coordinate, and that is a real and provable kind of agreement. It is the kind this corpus reports elsewhere as settled for the substrate.

The second is social convergence: whether people choose to run a thing, build on it, bring others to it, and stay. Nothing technical forces it. The standing evidence is in the deployed-user numbers this survey has been careful to cite — the social and ledger incumbents carry user bases orders of magnitude larger than anything newer, including more elegant designs, and a system’s position on the map predicts very little about whether it will be adopted. Network effects, timing, funding, community, and accident do most of the work, and a better answer to a technical question loses to a worse answer with a head start more often than not.

This bears on every system in the field, and on the substrate placed among them, in the same way. A favorable position on the map — spanning regions, moving posture, controlling access finely — is a reason a thing could be adopted, not a reason it will be. The properties that lower the cost of leaving a system and starting in another, the portability and the absence of lock-in that several systems here pursue and the substrate shares, plausibly lower the activation energy for social convergence; they do not generate it. The cartographer’s honesty is to map the technical terrain accurately and to decline to predict the weather. What people run is decided in a space the map does not cover, and saying so is not a hedge — it is the one claim about adoption that the evidence actually supports.

7. Discussion and Conclusion

The contribution of this paper is the map: one field where the literature usually sees four, laid out on a small set of shared axes so that a content-distribution system and a consensus protocol and an identity scheme and a compute model can be read against one another. The map’s two most useful products are the five-way structure of the compute cluster — re-execute, prove, attest, hide, sign — and the recurring pattern across all four clusters, that each deployed system decentralizes one thing well by fixing a posture on the rest, and pays the characteristic cost of that fixity. Seeing the costs lined up is most of what mapping the field whole is for.

The one further point we placed on that map, a content-addressed, typed, capability-secured substrate, is instructive not for superiority on any single axis — its addressing and identity are shared prior art, its consensus is weaker than a real consensus protocol, it has no deployed users — but for spanning regions a single deployed system fixes one of, and for moving posture where the others choose one — which it can do because it is a substrate rather than an application. That spanning is the same property the companion papers describe from inside the substrate (see DEOS; Application Architecture), visible here from outside, against the field it would join.

This is a map of a moving field, and we have tried to date it honestly rather than freeze it. Several facts most likely to drift were flagged where they appear: the social protocols’ private-data and governance efforts are in active development; the zero-knowledge systems’ decentralization of sequencing and proving is partial and advancing; the deployed-user figures are volatile and were given as ranges; and the credential standards are newly ratified. A reader should re-check the currency-sensitive cells before relying on them. The structural account that explains why the systems have the shapes they do is Convergent Evolution, and is the companion to this deployed account.

We close, as the other papers in this series do, with the invitations a map makes available. A decentralized system that the six axes cannot place — one whose addressing, identity, access, posture, compute-trust, and practical decentralization do not locate it — would show the coordinate system is incomplete, and we would want to know which axis it needs. A participation posture the field forces that this survey did not name would extend the persistence axis. And a sixth way of establishing trust in a computation, beyond re-executing, proving, attesting, hiding, and signing, would extend the compute map and would be, of everything here, the most interesting thing to find. The field is young enough that all three are live possibilities, and a map’s purpose is partly to make its own gaps visible.