> For the complete documentation index, see [llms.txt](https://hyper-performance-edge-computing.gitbook.io/hyper-performance-edge-computing-hpec-dao-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://hyper-performance-edge-computing.gitbook.io/hyper-performance-edge-computing-hpec-dao-docs/documentation/getting-started/quickstart.md). # Architecture Architectural Overview HPEC DAO is designed as a **layered autonomous infrastructure system** that separates capacity, intelligence, and governance. The architecture replaces traditional cloud primitives (servers, instances, DevOps pipelines) with **autonomous service layers** governed by a DAO and executed on decentralized infrastructure. At a high level, HPEC DAO is composed of: * A decentralized compute network (HyperCycle Node Factories , ANFES , HyperAIBox´s) * DAO-governed infrastructure abstraction (CMHPEC) * Autonomous service layers (ANaaS and AaaS) * Node Factories as the unit of execution and economics *** ### Core Architectural Principles HPEC DAO architecture is built on the following principles: * **Decentralization over centralized control**\ No single entity owns or operates the network. * **Autonomy over manual operations**\ Agents execute workflows without continuous human intervention. * **Outcome-based services over resource-based access**\ Clients consume results, not infrastructure components. * **Non-custodial operation**\ Protocol keys and authority remain with operators, not platforms. * **DAO governance over corporate ownership**\ Rules, incentives, and authority are enforced by governance, not contracts. These principles shape every layer of the system. *** ### Service Stack Architecture HPEC DAO operates as a vertical service stack: ``` Client / Organization ↓ AaaS – Agents as a Service ↓ ANaaS – Autonomous Node as a Service ↓ Node Factories ↓ HyperCycle Network ``` Each layer has a clearly defined role and responsibility. *** ### HyperCycle Network (Base Layer) The HyperCycle network provides the **sovereign decentralized compute layer**. It consists of independently operated nodes that: * Execute compute workloads * Participate in protocol-level coordination * Maintain sovereign operator identities * Earn protocol-level rewards HPEC DAO **does not custody or impersonate** HyperCycle nodes.\ It builds services *on top* of this sovereign network. *** ### CMHPEC – Infrastructure Abstraction Layer **CMHPEC (Clustered Modular Hyper Performance Edge Computing)** is the abstraction layer that allows decentralized nodes to function as a coherent service network. CMHPEC is responsible for: * Registering Node Factories * Orchestrating capacity across nodes * Routing workloads * Enforcing governance-defined boundaries * Exposing infrastructure as service capacity CMHPEC **coordinates infrastructure** — it does not own it. *** ### Node Factories A **Node Factory** is the fundamental execution and economic unit of HPEC DAO. A Node Factory is a logical grouping of nodes operating under: * Shared governance rules * Defined economic parameters * Declared Node Operator Authority Node Factories may include: * HyperAIBoxes * Oracle / state nodes * Edge or gateway nodes * Specialized compute nodes Each Node Factory is: * Economically productive * DAO-governed * Independently operated * Composable within the network *** ### ANaaS – Autonomous Node as a Service ANaaS is the foundational infrastructure service layer. It transforms raw decentralized nodes into: * Autonomous compute capacity * Redundant execution environments * SLA-driven infrastructure outcomes ANaaS provides: * Compute, storage, and networking * High availability and redundancy * Secure access and isolation * Outcome-based guarantees Clients never manage nodes directly.\ They consume **capacity and reliability as a service**. *** ### AaaS – Agents as a Service AaaS operates on top of ANaaS and provides **autonomous intelligence**. Agents are responsible for: * Planning tasks * Executing workflows * Monitoring performance * Handling recovery and scaling * Escalating only when required Agents are: * Modular and role-based * Scoped by permissions * Bound by DAO-defined rules * Auditable through logs and state AaaS removes the need for traditional DevOps and manual operations. *** ### Separation of Custody and Authority A core architectural rule of HPEC DAO is the strict separation between: * **Custody** – ownership of private keys and protocol credentials * **Authority** – permission to operate infrastructure on behalf of a DAO domain CMHPEC and HPEC DAO: * Never custody private keys * Never perform protocol signing * Only recognize declared Node Operator Authorities This ensures: * Sovereign operation * Human accountability * Zero protocol custody risk *** ### Architectural Outcomes As a result of this architecture, HPEC DAO delivers: * Autonomous infrastructure execution * Decentralized but coordinated operations * DAO-governed service guarantees * Scalable, composable Node Factories * Infrastructure as a yield-generating asset The system scales by **adding nodes, factories, and agents**, not by centralizing control. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://hyper-performance-edge-computing.gitbook.io/hyper-performance-edge-computing-hpec-dao-docs/documentation/getting-started/quickstart.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.