Atributos

Can users move between servers keeping their identity/data. Key differentiator between protocols.

Whether and how the protocol's design enables, limits, penalizes, or prohibits the accumulation of monetary holdings by participants. Encodes a structural design choice distinct from policy-level redistribution.

The current operational scale of the infrastructure in terms of nodes, users, or traffic volume.

What types of entities can have identities in the system

Whether the protocol natively embeds asset ownership and value transfer at the packet or message level, or whether value is handled externally.

Identity management system provided by the platform

How users prove control of their identity when authenticating

The underlying protocol(s) or technology stack this protocol builds upon

Ability to reach consensus even when some nodes are malicious or faulty

The risk that a protocol, standard, or tool could be taken over, co-opted, or substantially controlled by a single entity — typically a company, a well-resourced foundation, a state actor, or an individual — in ways that undermine its open, decentralized, or community-governed character.

Freeform rationale supporting the Capture Risk score. Address each factor in order of weight: Governance & Legal Control (who controls protocol decisions and the process for changing them, and who holds IP, trademarks, and licensing — including whether they could unilaterally relicense or restrict access); Regulatory/Jurisdictional Exposure (whether state or regulatory pressure could force co-option); Funding & Key-org Dependency (dependence on a single funder and how that shapes direction, and whether a single person or org is a realistic single point of failure for continuity); Forking Viability (how realistic an independent fork would be if capture occurred); Track Record (observable history of decisions that favored a controlling party over the community). Not every factor needs equal treatment — weight the prose toward what most drove the score.

Ability to maintain identity even if services are shut down or accounts banned

Specific features enabling multi-user collaboration

Support for real-time simultaneous editing by multiple users

The primary interaction pattern the application supports, describing whether users must be online simultaneously for the core use case to function.

Which regulatory frameworks or compliance standards the system addresses

Whether content is addressed by cryptographic hash rather than location

How the protocol handles valuation and the calculation problem — the problem of aggregating dispersed information about preferences, capabilities, and scarcities into actionable signals.

Economic model for using the identity system

Geographic location where the primary development team or organization is based

Specific Conflict-free Replicated Data Type libraries implemented or supported

Protocols used for issuing, presenting, and verifying credentials

What types of verifiable credentials or claims the system supports

The file formats and data structures supported for import, export, and storage

Ability to export and migrate data to other tools

Where user data is stored and who controls it. Privacy and ownership implications.

The underlying data model and storage architecture

How the standard is instantiated in practice — is it a per-chain singleton (one canonical deployment per blockchain network), permissionlessly deployable by anyone (many instances may exist), factory-deployed (a root contract spawns child instances), or off-chain verifiable (the standard defines cryptographic formats that don't require on-chain deployment at all, such as DID methods or VC schemas)?

How applications built on this platform can be deployed

A concise summary of what the tool does and its primary purpose

Full description of the current state of development and availability

Current state of development and availability

SDKs, APIs, and tooling provided for application developers

Which specific DID method(s) the system supports for creating and resolving decentralized identifiers

How content is discovered across federated network. Affects discoverability and centralization risks.

How users find and connect with other users or join shared spaces without relying on a central directory or server.

End-to-end encryption support ensuring only sender and recipient can read data

How node operators are compensated for providing storage. This is structurally different from anything in P2P Pro because storage networks require explicit economic incentives to function — unlike relay nodes which are often purely volunteer.

Whether features that provide economic flows, possibly in the form of tokenomics, micropayments, resource deployment, and/or financial irrigation methods are included

The blockchain platform, protocol family, or runtime environment for which the standard is natively designed. Identifies the chain or chain family within which the standard has authoritative status and primary adoption.

How servers federate and share data. Distinguishes federation architectures.

How multiple instances of the monetary protocol relate to one another and to external monetary networks. Distinct from the existing Federation Model attribute, which describes federated server protocols (ActivityPub-style); this attribute describes monetary network composition.

Primary source of financial support

Amount of funding raised

Where the protocol sits on the spectrum from accepting the existing monetary game (operating within fiat/banking infrastructure), modifying it (introducing parallel structures designed to coexist), or replacing it (designed to displace the existing system at scale).

Whether governance and decision making features are included

Which decentralized identity specifications and standards are supported or implemented

The primary service this infrastructure provides to the network or to higher-layer applications and users.

What's needed to run a participating server. Affects decentralization potential.

Third-party integrations and extensions available

Ability to work with other platforms, protocols, or standards

Who creates new units of account within the protocol and on what basis. Distinct from Permissions (which governs access to the protocol) — this attribute governs the creation of monetary units within it.

How cryptographic keys are generated, stored, and managed

Whether knowledge management features are included

Whether the primary data source resides on user devices with cloud as backup

The practical upper bound on simultaneous participants in a single session, conversation, or shared workspace, as constrained by protocol, CRDT performance, or network topology.

Whether media and publishing features are included

Availability of native or web-based mobile applications

Availability of platform-specific desktop applications

How the application handles degraded, intermittent, or absent network connectivity, including offline operation and sync-on-reconnect behavior.

What functionality is available without network connectivity

The original use case or domain from which the tool emerged

The logical network topology created on top of the physical network

The primary individual(s), organization, or company responsible for maintaining and developing the tool

The peer-to-peer networking architecture and consensus mechanism used

Access control model for managing data and resource permissions

Privacy-enhancing technologies and capabilities built into the system

Whether project management features are included

Whether features that support collective intelligence and healthy community dynamics are included

Standardization status. Affects long-term stability.

Whether the protocol operates on top of existing TCP/IP infrastructure (the vast majority of P2P protocols) or operates at the transport/packet level itself as a parallel or replacement layer.

The language or API used to query and manipulate data

How users can recover access if they lose keys or credentials

The the list of source documents and reference notes that support the information given in the other fields.

Whether the network provides any formal guarantee that stored data can be retrieved, and under what conditions.

How credentials can be invalidated or revoked

Support for formatted text with styling, images, and rich media

Compatibility with RDF, JSON-LD, SPARQL. Interoperability with semantic web ecosystem.

Whether features that help users synthesize information and derive insights are included

What control servers have over their users. Governance implications.

Cryptographic signature mechanism used for authentication and integrity

Support for programmable, self-executing contracts on the protocol

Whether social graph backend feature is supported

The license and availability of the project's source code

Primary programming languages and runtime environments used

The structural role or architectural layer the standard occupies within the broader smart contract ecosystem. Classifies the standard by what kind of interface or behavior it specifies, independent of its application domain.

The year when the project was first initiated or announced

How the platform handles data storage and replication

How node operators cryptographically prove they are actually storing the data they claim to store. This is the technical heart of what distinguishes decentralized storage from simple replication.

Whether the protocol's specification is bound to a specific implementation substrate or designed to run on multiple substrates. Critical for distinguishing Decentralized Monetary Protocol from Smart Contract Standard — a Smart Contract Standard is by definition bound to its deployment chain; a DM Pro may be substrate-neutral or substrate-specific.

The primary use-case domain the standard is designed to serve.

Business model and access terms for using the tool

The adversarial conditions this infrastructure is designed to withstand or the security/privacy guarantees it provides to users.

What the infrastructure operator or relay node can observe about the traffic passing through it.

What establishes trust in the identity system

Whether and how data stored or published through this protocol/network can be modified after initial creation.

How the protocol is typically used. Clarifies relationship to other protocols.

Primary application domain or user need addressed

The style and paradigm of the user interface

What kind of information the unit of account encodes — whether value collapses to a single rational scalar or supports multiple incommensurable measures, and whether the unit is rival or antirival in character.

How credentials and identity claims are verified

What domain the vocabulary describes. Defines the protocol's scope.

How the infrastructure's operational nodes are provisioned and who runs them.

What software can be used to manage the identity

Ability to run in web browsers

Ability to import data from traditional centralized services