Entity Types

A formal specification defining message formats, routing rules, and interaction patterns that enable nodes to communicate, coordinate, and exchange messages in a distributed system without prescribing how implementations are built or what applications are constructed on top. The specification exists independently of any particular toolkit, SDK, or runtime environment — multiple independent parties can implement it from the document alone. Distinguished from P2P Platform by the absence of an integrated application development environment: a protocol defines what nodes say to each other, not how developers build software that speaks it. Distinguished from Integrated P2P Runtime by the fact that the protocol is separable from its implementation — the wire format, the reference implementation, and any developer tooling are distinct artifacts that can evolve independently. Distinguished from P2P Infrastructure by the fact that a protocol defines communication rules rather than operating a live node network; infrastructure services run nodes that implement protocols and expose them to users or applications. Distinguished from Decentralized Storage Network by the absence of a storage incentive or compensation model — a protocol may specify how data is routed or replicated, but does not itself provide persistent storage capacity as a service. Distinguished from Decentralized Data Protocol by the layer of contribution: a P2P Protocol's defining concern is how nodes communicate, route, discover one another, or coordinate — the wire-level and messaging-level mechanics of distributed interaction; a Decentralized Data Protocol's defining concern is how data is named, addressed, synchronized, and reconciled once communication is established. A given system may implement both, but the two contributions can evolve as separable specifications and a P2P Protocol does not become a DD Pro merely by carrying data. Characteristic features of known members include: an independently publishable specification document; message format and serialization definitions; routing, discovery, or synchronization rules; and the expectation that conformant implementations interoperate without coordination between implementors.

A foundational system that provides reusable infrastructure, developer tooling, and runtime services for building decentralized applications, where the platform itself is built on top of one or more external protocols rather than defining its own wire format. The platform's value is in what it adds above the protocol layer: identity management, data synchronization, storage abstractions, SDK access, and composable services that would otherwise require each application to implement independently. Distinguished from P2P Protocol by the presence of an application development layer: a platform is something developers build on top of, not something they implement from scratch. Distinguished from Integrated P2P Runtime by the separability of the platform from its underlying protocol — the protocol can in principle be implemented by other tools, and the platform's abstractions could theoretically be rebuilt over a different transport. In an Integrated P2P Runtime, no such separation exists; the protocol is defined by and for the runtime. Distinguished from Decentralized Application by scope: a platform's primary artifact is developer infrastructure, not an end-user product. Applications are built on top of the platform; the platform itself is not the application. Characteristic features of known members include: an SDK or API through which developers access platform capabilities; a defined protocol stack that the platform implements on behalf of developers; identity and/or storage services shared across applications built on the platform; and support for multiple independent applications coexisting on the same network.

A technology in which the data model, synchronization protocol, security architecture, and application development environment are co-designed as a single, inseparable whole. The protocol does not exist independently of its development environment — there is no separating the wire format from the toolkit that implements it, because the two were designed together and each presupposes the other. Developers do not build applications that use the runtime; they build applications that run within it, with the runtime governing data structure, peer interaction, and security guarantees as a unified whole. Distinguished from P2P Protocol by the presence of an inseparable development environment: a P2P Protocol can be implemented by any party working from a specification document alone, and the resulting implementations interoperate. An Integrated P2P Runtime cannot be separated from its implementation — the toolkit is not a convenience layer over the protocol but a constitutive part of what the protocol is. Distinguished from P2P Platform by the directionality of the relationship between protocol and platform: a P2P Platform is built on top of an external protocol it did not define; an Integrated P2P Runtime owns and defines its protocol as an intrinsic consequence of its design, such that no other runtime could implement "the same protocol" in any meaningful sense. Distinguished from Decentralized Application by the fact that an Integrated P2P Runtime is developer infrastructure, not an end-user product — its primary artifact is an environment in which applications are built, not an application itself. Distinguished from Extensible Decentralized App by the fact that an Integrated P2P Runtime's defining contribution is the unified protocol-plus-environment architecture, not the extensibility of any particular application running within it. Characteristic commitments across known members include: user-sovereign data ownership, meaning the user's data is theirs by architectural guarantee rather than policy; decoupling of application logic from data storage, such that data persists and remains accessible independently of whether any specific application continues to exist; and an integrated identity model baked into the protocol layer rather than added on top, so that identity is not a service the application calls but a property of every data object in the system.

An end-user software product designed to perform specific, bounded tasks using decentralized protocols, with a defined boundary between the application and the infrastructure it runs on. Users consume the application's functionality; they do not extend, compose, or reprogram it as part of ordinary use. The decentralized architecture enables the application to function without relying on a single controlling server or organization, but this architecture is an implementation choice rather than an exposed surface the user interacts with. Distinguished from Extensible Decentralized App by the presence of a meaningful separation between using the application and building upon it: a Decentralized Application has users on one side and developers on the other, and extension or customization, if supported at all, requires crossing that boundary deliberately. Distinguished from P2P Platform by the fact that the primary artifact is an end-user product rather than developer infrastructure — a Decentralized Application does not provide an SDK, a shared protocol layer, or services for third-party apps to build upon. Distinguished from Integrated P2P Runtime by the fact that the application is built on top of an external protocol or platform rather than being inseparable from one. Characteristic features of known members include: a defined user-facing function (file sharing, messaging, publishing, coordination); a deployment that functions for end users without requiring them to understand the underlying protocol; and a clear distinction between the application layer and the protocol or platform layer beneath it.

A decentralized application in which the boundary between application and platform is dissolved by design: using the application and building upon it are the same act rather than separate activities. The application is not merely configurable or plugin-capable — extension, composition, and customization are intrinsic to its architecture, such that the path from end user to developer is a continuum rather than a threshold to cross. The application's data model, building blocks, and interaction surfaces are exposed by default, not opened up as a secondary developer feature. Distinguished from Decentralized Application by the presence of designed extensibility at the architectural level: a Decentralized Application has a meaningful boundary between using it and building on it, and that boundary is intentional — the application's architecture does not invite users to extend it. An Extensible Decentralized App treats that boundary as a design failure to be eliminated. Distinguished from P2P Platform by the primacy of the working application: a P2P Platform's primary artifact is developer infrastructure, and applications are built on top of it as separate things; an Extensible Decentralized App is itself the working application, and its platform-like properties emerge from within it rather than pre-existing beneath it. Distinguished from Integrated P2P Runtime by the level of the contribution: an Integrated P2P Runtime's defining characteristic is a unified protocol-plus-environment architecture at the infrastructure layer; an Extensible Decentralized App's defining characteristic is a user-facing application that happens to dissolve the user/developer boundary. An Ext D App typically runs on top of a protocol, platform, or runtime — it does not define one. Characteristic features of known members include: user-composable building blocks that allow non-developers to assemble new functionality within the application's own interface; an exposed data model that other applications or agents can read from, write to, or build upon without requiring access to the application's source code; a design philosophy in which no hard boundary is drawn between consuming and creating within the same environment; and a primary artifact that is immediately useful to end users while simultaneously serving as an extension platform.

Operational node networks that provide foundational transport, routing, privacy, or access services that other protocols, platforms, and applications build upon. The defining characteristic is that P2P Infrastructure is a running service rather than a specification: it consists of live nodes operated by volunteers or incentivized participants, and its value is delivered by the network's existence rather than by the document that describes it. Typically designed to function under adversarial conditions — censorship, surveillance, traffic analysis, or targeted blocking — as a core design requirement rather than an afterthought. Distinguished from P2P Protocol by the layer of operation: a P2P Protocol specifies rules that implementations follow; P2P Infrastructure runs those rules as an always-on service that other systems connect to. A given piece of infrastructure typically implements one or more P2P Protocols, but the protocol and the operational network are distinct artifacts. Distinguished from Decentralized Storage Network by the primary function delivered: P2P Infrastructure provides transport, relay, routing, or access circumvention — the movement of data rather than its persistent custody. A DSN stores data on behalf of users for retrieval later; P2P Infrastructure moves data between endpoints without necessarily retaining it. Distinguished from P2P Platform by the absence of an application development layer: P2P Infrastructure does not provide SDKs, identity services, or developer abstractions — it provides a substrate that developers may build on, but does not facilitate that building. Characteristic features of known members include: a live network of volunteer or incentivized relay/routing nodes; design for censorship resistance or traffic obfuscation; operation as a shared resource consumed by diverse applications rather than a single-purpose product; and degraded-but-functional behavior under active network interference.

A communication architecture in which users connect to independently operated servers (instances), and those servers maintain direct peer relationships with one another to route messages, share content, or coordinate activity on behalf of their users. Portability of identity and content across server boundaries is a design goal: users on one server can interact with users on another without any central intermediary. Distinguished from P2P Protocol by the presence of a persistent server layer between the protocol and the end user — clients do not speak the protocol directly to all peers but rather delegate to their home server, which speaks the protocol on their behalf. Distinguished from centralized platforms with APIs by the requirement that any conformant server implementation can federate with any other, without permission from a central authority. Distinguished from Decentralized Storage Network by the focus on communication and social interaction rather than persistent data storage capacity. Characteristic features of known members include: a server-to-server protocol distinct from the client-to-server protocol; independently operated instances that implement the same specification; user identity anchored to a server (with or without portability mechanisms); and a governance model in which no single operator controls who can participate in the federation.

A formal specification for describing, structuring, or linking data in ways that are interpretable across systems, applications, and organizations without requiring shared implementation. The primary artifact is not a communication mechanism but a shared meaning layer: vocabularies, ontologies, schemas, or graph models that give data portable, unambiguous semantics regardless of where it is stored or what system reads it. Distinguished from P2P Protocol by the fact that a Semantic & Data Protocol does not define how nodes communicate — it defines what the data they exchange means. A P2P Protocol may adopt a Semantic & Data Protocol for its data model without becoming one itself. Distinguished from Identity Protocol by scope: an Identity Protocol defines how identifiers and credentials are established, verified, and exchanged; a Semantic & Data Protocol defines how any data — including identity data — is structured and interpreted, and is not specific to the identity domain. Distinguished from Decentralized Application by the absence of an end-user artifact: a Semantic & Data Protocol is consumed by developers and protocol designers, not directly by users. Characteristic features of known members include: a vocabulary or schema specification that can be adopted independently of any particular implementation; machine-readable definitions enabling automated interpretation or inference; design for interoperability across heterogeneous systems; and use as a shared layer beneath multiple higher-level protocols or applications.

A formal specification defining the rules, formats, and interaction patterns by which decentralized identifiers are created and resolved, credentials are issued and verified, authentication is performed, or trust is established between parties — without prescribing how those rules are implemented in software. Like a P2P Protocol, an Identity Protocol is primarily a document that independent parties can implement from scratch; its value is in enabling interoperability across implementations rather than in providing a specific tool. Distinguished from Identity Toolkit / Platform by the level of abstraction: an Identity Protocol defines what conformant systems must do; an Identity Toolkit provides the software that does it. A developer reads an Identity Protocol to understand the standard; they install an Identity Toolkit to implement it. Distinguished from Identity System / Design by scope and novelty: an Identity Protocol is typically a formal specification submitted to or emerging from a standards process (W3C, IETF, DIF, ToIP), whereas an Identity System / Design proposes a novel end-to-end architecture — a new way of thinking about identity problems — that may or may not yet have a corresponding formal specification. Distinguished from Semantic & Data Protocol by domain specificity: an Identity Protocol is concerned with who parties are and how that is established; a Semantic & Data Protocol is concerned with what data means, applicable across any domain including but not limited to identity. Characteristic features of known members include: a specification document defining identifier syntax, resolution mechanisms, credential formats, or exchange flows; a conformance model against which implementations can be tested; a focus on interoperability across independent issuers, holders, and verifiers; and design for operation without a central authority controlling identifier registration or credential validity.

Developer infrastructure that implements one or more Identity Protocols and exposes their capabilities through SDKs, APIs, or frameworks, enabling application developers to build identity-enabled features without implementing the underlying specifications from scratch. The primary artifact is working software for developers — libraries, services, or platforms — rather than a specification document or a novel identity architecture. Distinguished from Identity Protocol by the layer delivered: an Identity Protocol is a specification; an Identity Toolkit / Platform is its implementation, packaged for reuse. A single Identity Protocol may have multiple competing Toolkit implementations. Distinguished from Identity System / Design by the absence of architectural novelty as the primary contribution: an Identity Toolkit primarily makes existing standards accessible and usable, rather than proposing a new model for how identity should work. An Identity System / Design may ship tooling, but its defining contribution is the novel architecture; the tooling is secondary. Distinguished from P2P Platform by domain specificity: an Identity Toolkit / Platform is purpose-built for identity, credential, and authentication use cases, even if it could in principle support other data types. Characteristic features of known members include: SDK or API surface exposing DID resolution, credential issuance, verification, or authentication; conformance to one or more published Identity Protocols; integration guides targeting application developers rather than protocol researchers; and reusability across multiple applications and deployment contexts without modification.

A novel end-to-end architecture that proposes a fundamentally new approach to one or more core identity problems — how personhood is established, how trust is delegated, how credentials are structured, or how identity persists across contexts — rather than implementing or extending an existing standard. The defining characteristic is that the primary contribution is an architectural idea: a new model for how identity should work, which may or may not yet be formalized as a specification or implemented as a toolkit. Distinguished from Identity Protocol by the nature of the contribution: an Identity Protocol operates within an established paradigm (DID methods, VC formats, OAuth flows) and defines precise interoperability rules; an Identity System / Design questions or replaces the paradigm itself, proposing why the existing approaches are insufficient and what a better structure would look like. A novel Identity System may eventually produce Identity Protocols as its ideas mature, but at the point of classification the architectural proposal precedes or supersedes the specification. Distinguished from Identity Toolkit / Platform by primacy: an Identity Toolkit's primary value is software that developers use; an Identity System / Design's primary value is the architectural insight, which tooling may or may not yet embody. Distinguished from P2P Protocol by domain and intent: an Identity System / Design is specifically concerned with identity, trust, and personhood, not communication or data exchange in general. Characteristic features of known members include: a white paper, thesis, or architectural document articulating the novel approach; explicit critique of or departure from existing identity paradigms; proposed mechanisms for personhood verification, trust establishment, or credential lifecycle management that are not reducible to extensions of existing standards; and the expectation that implementations, standards, and tooling will follow from the architectural insight rather than precede it.

A formal specification whose primary realization is one or more on-chain deployable contracts or cryptographically-enforced registries, such that once deployed, the standard and its enforcement mechanism become the same artifact. Unlike a P2P Protocol — which is a specification that independent parties implement separately — a Smart Contract Standard becomes operational through deployment: the running contract is not an implementation of the standard but the standard itself, instantiated as shared permissionless state on a blockchain that any participant can read or write according to the contract's rules. Distinguished from P2P Protocol by the deployment model: a P2P Protocol is implemented by many independent parties who run their own nodes; a Smart Contract Standard is deployed once (or as a small number of canonical instances) and thereafter exists as a shared on-chain artifact. Distinguished from Decentralized Application by the abstraction level: a Smart Contract Standard defines shared infrastructure — registries, interfaces, or data structures — that other applications build upon, rather than delivering end-user functionality itself. A Decentralized Application may implement or interact with a Smart Contract Standard without being one. Distinguished from Decentralized Storage Network by the absence of storage capacity as the primary offering: a Smart Contract Standard enforces rules and maintains shared state; it does not provide distributed storage for arbitrary user data. Characteristic features of known members include: an EIP, ERC, or equivalent specification document defining interface, storage layout, and behavioral rules; a reference implementation deployable to a compatible blockchain; permissionless read and write access by any conformant participant; and design as shared infrastructure rather than a standalone application — the standard is most valuable when multiple independent applications or agents adopt it as a common layer.

A decentralized network in which distributed node operators provide persistent data storage capacity to users or applications as the network's primary function, with node participation sustained through cryptoeconomic incentives, volunteer contribution, or cooperative governance. The defining characteristic is persistent custody: a DSN accepts data, stores it across multiple nodes for durability, and makes it retrievable later — the network's core value is that data placed in it continues to exist and remain accessible over time, not merely that it can be routed or relayed in transit. Distinguished from P2P Infrastructure by the primary function delivered: P2P Infrastructure provides transport, routing, or access circumvention — it moves data between endpoints without necessarily retaining it. A DSN retains data as its core service. The two can coexist — a DSN may use P2P Infrastructure for node-to-node communication — but the DSN's defining commitment is to data persistence while P2P Infrastructure's is to data movement. Distinguished from P2P Protocol by operational reality: a P2P Protocol specifies how storage or retrieval should work; a DSN is the operational network that runs those specifications, with live nodes, economic models, and storage guarantees. Distinguished from Decentralized Application by the infrastructure orientation: a DSN provides storage capacity consumed by other applications and protocols, rather than delivering end-user functionality itself. Characteristic features of known members include: a node operator role distinct from the end user, with incentives or governance mechanisms for sustaining participation; storage proof or audit mechanisms ensuring operators actually retain the data they claim to hold; retrieval guarantees ranging from cryptoeconomic enforcement to best-effort; a compensation or incentive model (token rewards, fiat payments, one-time endowment, or volunteer) as a first-class design concern; and design as shared infrastructure rather than a single-purpose application.

A formal specification defining how structured data is named, addressed, replicated, synchronized, and retrieved across a peer-to-peer network, where the protocol's primary contribution is to the data layer — content addressing, mutability semantics, sync algorithms, conflict resolution, and the lifecycle of data once it exists — rather than to the transport, communication, or coordination layer beneath it. The specification exists independently of any particular toolkit, SDK, or runtime environment, and multiple independent parties can implement it from the document alone. Distinguished from P2P Protocol by the layer of contribution: a P2P Protocol defines how nodes communicate, route, discover one another, or exchange messages at the transport or messaging layer; a Decentralized Data Protocol defines how data — once communication has been established by some other means — is structured, named, versioned, and reconciled across peers. A given system may implement both kinds of protocol, but the contributions are separable artifacts evolving on independent schedules. Distinguished from Semantic & Data Protocol by scope and operational concern: a Semantic & Data Protocol defines a vocabulary or schema layer that gives data portable meaning across heterogeneous systems regardless of transport or storage; a Decentralized Data Protocol is concerned with the operational mechanics of how data lives and moves on a peer-to-peer substrate — replication, content addressing, sync, mutability — independent of what the data means at the semantic level. The two are complementary: a Decentralized Data Protocol may carry semantically-typed data defined by a Semantic & Data Protocol without itself becoming one. Distinguished from Decentralized Storage Network by the absence of operational infrastructure as the primary artifact: a DSN runs live nodes providing persistent storage capacity to users, with cryptoeconomic, volunteer, or cooperative governance sustaining participation; a Decentralized Data Protocol is the specification that any party may implement to participate in such a network, but does not itself constitute one and does not require an incentive model. Distinguished from Integrated P2P Runtime by the separability of the specification from its implementation: a Decentralized Data Protocol is a document that conformant implementations can be written from independently, and the resulting implementations interoperate; an Integrated P2P Runtime co-designs the data model, sync protocol, and development environment as a single inseparable whole. Characteristic features of known members include: a content-addressing or self-certifying naming scheme; a defined synchronization or replication algorithm (range-based set reconciliation, gossip, CRDT merge, DAG-based event propagation, Merkle search trees); explicit mutability semantics (append-only, mutable-via-versioning, CRDT-mergeable, last-writer-wins); independence from any specific blockchain, storage incentive model, or transport protocol; and adoption across multiple independent applications as a shared data substrate.

A formal specification defining how value is issued, accounted, valued, and circulated among participants in a decentralized network, where the protocol's defining contribution is the monetary logic itself — the rules governing issuance, accumulation, settlement, valuation, and federation — rather than the communication, data, identity, or smart-contract substrate on which it may be implemented. The specification exists independently of any particular implementation, and multiple substrates (mutual-credit ledgers, agent-centric runtimes, blockchain contracts, federated server networks, institutional infrastructure) may realize the same protocol. Distinguished from Smart Contract Standard by substrate independence: a Smart Contract Standard is realized through on-chain deployment such that the running contract and the standard are the same artifact; a Decentralized Monetary Protocol defines monetary logic that may be implemented on-chain, off-chain, agent-centric, or institutionally, and implementations on different substrates can interoperate at the monetary-logic level. A Smart Contract Standard like ERC-3643 may instantiate aspects of a Decentralized Monetary Protocol, but the protocol is conceptually prior and substrate-independent. Distinguished from P2P Protocol by the layer of contribution: a P2P Protocol defines how nodes communicate, route, and discover one another; a Decentralized Monetary Protocol defines how value flows once communication is established. A given monetary protocol may run over any P2P Protocol or federated transport. Distinguished from Decentralized Data Protocol by primary concern: a Decentralized Data Protocol governs how data is named, addressed, replicated, and reconciled; a Decentralized Monetary Protocol governs how value claims are issued, transferred, valued, and bounded — the data layer is incidental rather than constitutive. Distinguished from Identity Protocol by domain: identity protocols govern who participants are and how identifiers are resolved; monetary protocols govern how value moves among identified participants, and typically depend on but do not define identity infrastructure. Characteristic features of known members include: a specification of how units of account are issued (peer-to-peer, algorithmic, deliberative, commitment-pooled, or otherwise); rules governing accumulation, decay, or convertibility; a defined coordination or valuation mechanism; explicit federation logic where multiple instances interoperate; and design as a substrate-neutral specification that multiple independent implementations may realize.