Prometheus Protocol Wiki: Architecture & Core Protocols

Prometheus Protocol Wiki: Architecture & Core Protocols This section is for Prometheus Protocol Wiki: Architecture & Core Protocols

This section is for the architects, the strategists, and those who need to understand not just the how, but the why behind the protocol's design. It outlines the core doctrines that govern our approach to digital sovereignty.

4.1 The "Sovereign Key" Doctrine The entire security model of the EmPower1 Ecosystem is built upon a single, foundational principle: the user's private key is the root of their digital sovereignty. This doctrine dictates a specific set of architectural trade-offs designed to empower the user while protecting them from both external threats and their own potential mistakes.

The Device Mesh Attestation Model

A user's identity is not a single entity; it is a constellation of trusted devices. We architect this trust through the Device Mesh.

Concept: A user's identity gains resilience and authority as they add more cryptographically linked devices (e.g., a phone, a laptop, a hardware wallet).

Architecture: When a new device is added, it must be "attested" to by one or more existing devices in the mesh. High-risk actions, such as authorizing a large transaction or initiating an identity recovery, can be configured to require signatures from multiple devices. This transforms the security model from a single point of failure (one device) to a distributed, multi-signature defense system. It is the digital equivalent of requiring two keys to open a missile silo.

Social Recovery: A Strategic Necessity

The greatest threat to a sovereign identity system is a lost key. While we cannot recover a lost key, we can architect a system for its secure regeneration. The Shamir's Secret Sharing (SSS) model is our chosen strategy.

Philosophy: It is a system built on distributed trust. It acknowledges that while a user may lose a single device, it is statistically improbable that they will simultaneously lose contact with multiple trusted friends or access to multiple secure locations.

Security: By splitting the key into shards, we eliminate the "honeypot" risk. A single compromised shard is mathematically useless. This is vastly superior to traditional "security questions," which are often based on publicly available information and represent a critical vulnerability. SSS is a protocol for resilience in an imperfect world.

4.2 The Consent & Permission Model In our ecosystem, consent is not a checkbox clicked once and forgotten. It is a living, auditable, and revocable cryptographic event.

The Consent Receipt

When a user grants permission for data access, the protocol generates a Consent Receipt. This is a signed, tamper-evident JSON object with a formal structure.

Specification:

id: A unique identifier for this specific consent event.

requester: The DID of the service or user requesting access.

grantor: The DID of the user granting access.

permission: A human-readable description of the permission being granted (e.g., "Read public profile").

constraints: A machine-readable object defining the limits of the permission.

type: time-based | session-based

expires: An ISO 8601 timestamp.

signature: The grantor's digital signature over the entire object.

Smart Contract Enforcement

While the SDK provides tools to verify consent receipts, the ultimate enforcement mechanism can be architected at the smart contract layer on the DigiSocialBlock. A dApp could be designed to only serve data if a valid, unexpired consent receipt is provided within the transaction. This moves consent from a "pinky promise" to a cryptographically enforced law of the application, fulfilling the ultimate vision of user-controlled data.r the architects, the strategists, and those who need to understand not just the how, but the why behind the protocol's design. It outlines the core doctrines that govern our approach to digital sovereignty.

4.1 The "Sovereign Key" Doctrine The entire security model of the EmPower1 Ecosystem is built upon a single, foundational principle: the user's private key is the root of their digital sovereignty. This doctrine dictates a specific set of architectural trade-offs designed to empower the user while protecting them from both external threats and their own potential mistakes.

The Device Mesh Attestation Model

A user's identity is not a single entity; it is a constellation of trusted devices. We architect this trust through the Device Mesh.

Concept: A user's identity gains resilience and authority as they add more cryptographically linked devices (e.g., a phone, a laptop, a hardware wallet).

Architecture: When a new device is added, it must be "attested" to by one or more existing devices in the mesh. High-risk actions, such as authorizing a large transaction or initiating an identity recovery, can be configured to require signatures from multiple devices. This transforms the security model from a single point of failure (one device) to a distributed, multi-signature defense system. It is the digital equivalent of requiring two keys to open a missile silo.

Social Recovery: A Strategic Necessity

The greatest threat to a sovereign identity system is a lost key. While we cannot recover a lost key, we can architect a system for its secure regeneration. The Shamir's Secret Sharing (SSS) model is our chosen strategy.

Philosophy: It is a system built on distributed trust. It acknowledges that while a user may lose a single device, it is statistically improbable that they will simultaneously lose contact with multiple trusted friends or access to multiple secure locations.

Security: By splitting the key into shards, we eliminate the "honeypot" risk. A single compromised shard is mathematically useless. This is vastly superior to traditional "security questions," which are often based on publicly available information and represent a critical vulnerability. SSS is a protocol for resilience in an imperfect world.

4.2 The Consent & Permission Model In our ecosystem, consent is not a checkbox clicked once and forgotten. It is a living, auditable, and revocable cryptographic event.

The Consent Receipt

When a user grants permission for data access, the protocol generates a Consent Receipt. This is a signed, tamper-evident JSON object with a formal structure.

Specification:

id: A unique identifier for this specific consent event.

requester: The DID of the service or user requesting access.

grantor: The DID of the user granting access.

permission: A human-readable description of the permission being granted (e.g., "Read public profile").

constraints: A machine-readable object defining the limits of the permission.

type: time-based | session-based

expires: An ISO 8601 timestamp.

signature: The grantor's digital signature over the entire object.

Smart Contract Enforcement

While the SDK provides tools to verify consent receipts, the ultimate enforcement mechanism can be architected at the smart contract layer on the DigiSocialBlock. A dApp could be designed to only serve data if a valid, unexpired consent receipt is provided within the transaction. This moves consent from a "pinky promise" to a cryptographically enforced law of the application, fulfilling the ultimate vision of user-controlled data.