Every design decision in Prometheus Protocol stems from unwavering adherence to core principles. Below are our most fundamental philosophical positions.
Credit points are a measure of contribution, not tradable currency. Once credit points become exchangeable for money, the entire system slides into speculation and arbitrage. The non-exchangeability principle ensures credit points always reflect genuine production contribution — how much valuable work you did, that is how many credit points you receive. No one can acquire false credit through hoarding, speculation, or trading. This principle is the fundamental boundary that separates Prometheus Protocol from every "points economy" and "token model."
In Prometheus Protocol, every device possesses a unique, verifiable identity. Devices are not anonymous black boxes — they are named participants with complete track records joining production. Machine identity ensures the truthfulness of capability declarations, the traceability of execution records, and the locatability of quality issues. Without machine identity, decentralized trust cannot be established — because the foundation of trust is "knowing who you are and knowing what you can do."
Decentralization does not mean absence of governance. Prometheus Protocol implements democratic governance through rotating orchestration committees: members are elected by ecosystem participants, regularly rotated, and responsible for protocol upgrades, dispute arbitration, and emergency decisions. The committee holds no permanent power — every session's decisions undergo transparent auditing. This is not a variant of "elite rule" but genuine rotational democracy — power belongs to the ecosystem, not to any fixed group.
Ethics guardians are Prometheus Protocol's automated safety layer. Every task must pass ethical review before publication: does it involve harmful production? Does it violate worker rights? Does it breach fundamental ethical standards? Guardians are not a human committee — they are automated checks encoded in the protocol, ensuring the system never becomes a tool for harm under any circumstances. Ethics is not a post-hoc remedy but a front-line defense.
Existing production collaboration systems suffer from seven systemic blind spots. Prometheus Protocol's design aims to eliminate each one:
Each blind spot represents a form of systemic oppression. Prometheus Protocol does not make incremental improvements — it fundamentally redesigns the logic of production collaboration.
The Prometheus Protocol ecosystem is a self-growing, self-balancing production collaboration network. Below is its architecture, roles, and evolutionary path.
Prometheus Protocol consists of three complementary protocol layers forming a complete production collaboration system:
The three layers are independent yet tightly coupled: without TCDP there are no trusted participants, without DTOP there is no efficient collaboration, without PCSP there is no fair return.
Participants in the ecosystem exist as different node types:
Each node type fulfills its role, collectively forming a collaboration network covering everything from micro to macro.
A complete production collaboration data flow goes through these stages:
The entire process from registration to settlement is transparent, traceable, and fully automated — no intermediary manually intervenes at any stage.
The Prometheus Protocol ecosystem does not emerge overnight; it follows a natural growth path:
From point to surface, from local to global — every ecosystem expansion builds upon previously validated success.
Below is the complete flow of a production task from publication to settlement in Prometheus Protocol.
The requester submits a production task to the network. The task includes product specifications, quality requirements, delivery deadlines, and budget range. This is the starting point — all subsequent stages revolve around this task.
DTOP (Distributed Task Orchestration Protocol) receives the task and decomposes it into independently executable sub-tasks based on product specifications. Decomposition follows the minimum executable unit principle — each sub-task can be completed by a single node, with clear dependency relationships and composition order between sub-tasks.
Decomposed sub-tasks are published to the entire network. Nodes verified through TCDP submit bidding proposals for matching sub-tasks based on their capability declarations. Bids include pricing, delivery commitments, and quality guarantees. Multiple nodes can compete for the same sub-task — the best proposal wins.
DTOP composes winning nodes for each sub-task into a complete production line. Composition is not static — if a node fails mid-stream, DTOP immediately re-bids and replaces it, ensuring the production line never breaks. Dynamic composition is the core mechanism of system resilience.
Each node executes its sub-task in sequence according to the composition plan and dependency order. Upon completion, nodes submit intermediate or final products along with execution records. The entire process is monitorable in real time — requesters can track progress.
After production, all execution records and outputs are submitted to PCSP (Production Contribution Settlement Protocol). PCSP verifies whether each stage's contribution is genuine, whether outputs meet specifications, and whether delivery was within deadline. Only verified contributions enter settlement.
Verified contributions from each stage are automatically converted to credit points and distributed to corresponding nodes. Settlement requires no manual approval — the protocol automatically calculates based on pre-agreed contribution measurement standards. Credit points are non-exchangeable for currency, but determine a node's reputation and future task priority in the ecosystem.
Task Publication → DTOP Decomposition → Network Bidding → Dynamic Composition → Execution → PCSP Verification → Automatic Settlement
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ Task │ │Decompose │ │ Bidding │ │Compose │ │ Execute │ │ Verify │ │ Settle │
│ Publish │───▶│ Sub-tasks│───▶│Select │───▶│Production│───▶│Production│───▶│Contrib. │───▶│Credits │
└──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘
Requester DTOP All nodes DTOP Each node PCSP PCSP
Prometheus Protocol is a decentralized production collaboration protocol composed of three complementary sub-protocols: TCDP (Trusted Capability Declaration Protocol) ensures the authenticity of participant identities and capabilities, DTOP (Distributed Task Orchestration Protocol) handles task decomposition, allocation, and monitoring, and PCSP (Production Contribution Settlement Protocol) records and settles every production contribution. Together they form a production collaboration system that operates without a central platform.
Credit points are not currency. They measure your contribution level to the ecosystem, not a tradable commodity. Credit points cannot be exchanged for any other form of currency or asset — this is the protocol's fundamental principle. Once credit points become exchangeable, the system slides into speculation and arbitrage, and credit points no longer reflect genuine contribution. Credit points derive their value from reputation: nodes with high credit points are more competitive in task bidding and have greater voice in ecosystem governance.
TCDP ensures the truthfulness of device claims through multi-layer verification. First, devices must register to obtain unique machine identity identifiers. Second, capability declarations must include verifiable proof data — such as historical production records, third-party test results, or real-time capability tests. Finally, declarations undergo cross-verification by other nodes across the network. False declarations are flagged, and declarants lose reputation credit.
Prometheus Protocol prevents monopoly at three levels: At task allocation, DTOP's bidding mechanism ensures no node can monopolize tasks — all qualified nodes bid equally. At governance, the orchestration committee's rotating system ensures no fixed group can long control decision-making. At settlement, PCSP's public ledger ensures value distribution is transparently visible, and any unreasonable extraction is automatically detected. The protocol's design philosophy: dispersed power, transparent information, automatically enforced rules.
Individual operators first register as freelance operator nodes. By declaring their professional skills and available time through TCDP, completing identity verification and capability proof, they can begin participating in network-wide bidding. The protocol has no entry barriers — as long as you can prove your capability, you can participate. You can start with individual sub-tasks, accumulate credit reputation, and progressively take on more complex work.
The protocol distinguishes between public and private data. Capability declarations and execution records are public — this is the foundation of trust. However, specific production process parameters, client business information, and operator personal data are private, shared only within necessary execution stages and protected by encryption. The protocol follows the minimum disclosure principle: only publish information necessary for building trust, never over-expose privacy.
Prometheus Protocol does not require existing platforms to immediately integrate, but designs gateway nodes as transitional bridges. Gateway nodes can convert existing platforms' capabilities and task formats into protocol-compatible formats, enabling gradual interfacing. Long-term, the protocol aims to replace intermediary platform functions — but this process is gradual, not disruptive. Hybrid operation phases are entirely feasible.
Ethics guardians are automated check mechanisms encoded in the protocol. Every task must pass guardian review before publication: checking whether the task involves harmful production (e.g., manufacturing dangerous items), violates worker rights (e.g., unreasonable working hours), or breaches fundamental ethical standards (e.g., discriminatory requirements). Guardians do not make human judgments — they automatically execute based on a predefined ethical rule set. The rule set is regularly updated by the orchestration committee through a fully open and transparent process.
Prometheus Protocol is currently in the specification draft phase. This guide helps you understand the protocol's design logic and intended operation, but there is no runnable code to install or test yet. The steps below describe the intended protocol flow, designed to help you build an understanding of the complete loop.
Prometheus Protocol consists of three interconnected sub-protocols:
Together they form a complete loop: declare capabilities → match tasks → prove contributions → receive settlement.
Each sub-protocol solves one core problem:
We recommend starting with Design Philosophy to understand the principles behind the protocol, then diving into the technical details in the whitepapers.
TCDP declarations are expressed in JSON. Below is a laser cutter declaration example (specification draft phase; format may change):
{
"tool_id": "TCDP-HK-LC-001",
"name": "Laser Cutter Alpha",
"type": "laser_cutter",
"capabilities": {
"material": ["steel", "aluminum", "acrylic"],
"max_thickness_mm": { "steel": 20, "aluminum": 30 },
"precision_mm": 0.05,
"work_area_mm": [1500, 1000]
},
"location": { "lat": 22.3, "lon": 114.2 },
"trust": { "certificate_issuer": "PrometheusCA-v0.1",
"reputation_score": null }
}See the full declaration example on the Specification & Implementation page. The complete JSON Schema definition is still being designed.
A complete production task will go through these stages:
See the detailed flow diagram on the Flow page.
The protocol is still in draft phase, but you can start thinking about future participation:
The most effective way to participate right now is to read the specifications and give feedback. Send your thoughts to suke@ezuhe.cn.
Owns smart manufacturing equipment, wants to connect to decentralized production networks in the future.
Current Focus: TCDP declaration format, capability description methods
Operates independent tool nodes (e.g., personal 3D printers, small CNC devices), wants to participate in decentralized production.
Current Focus: DTOP bidding mechanism design, PCSP contribution proof process
Wants to contribute to protocol development, improvement, and extension.
Current Focus: Whitepaper design review, specification feedback