> For the complete documentation index, see [llms.txt](https://incogai.gitbook.io/incogai-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://incogai.gitbook.io/incogai-docs/incog-docs/network/hardware-layer.md). # Hardware Layer ## Overview The INCOG hardware layer defines the physical and firmware infrastructure through which node operators contribute relay capacity to the mesh network. Unlike software-only relay deployments (which run on general-purpose servers or cloud instances), the INCOG hardware layer specifies dedicated routing hardware optimized for continuous, secure relay operation in residential and small-office environments. The hardware layer serves several purposes beyond raw relay capacity: it enables a class of participants who lack the technical sophistication to manage server infrastructure, it provides verifiable hardware-backed attestations that are harder to forge than software-only attestations, and it creates a distributed physical presence for the relay network in diverse geographic locations that would not be achievable through data center deployments alone. *** ## Hardware Certification Program ### Certification Framework The INCOG hardware certification program defines compliance standards for relay hardware. Certified hardware: * Has been verified to run authentic INCOG relay node software * Meets minimum performance specifications for relay operation * Supports the cryptographic operations required by the relay protocol * Implements secure boot to prevent unauthorized software modification * Has received a hardware attestation certificate embedded at manufacturing time Certification is issued to hardware manufacturers or hardware integration partners who demonstrate compliance with the certification specification. The certification process involves: 1. Hardware design review against the specification 2. Firmware and secure boot chain audit 3. Cryptographic subsystem verification 4. Extended relay protocol compliance testing 5. Issuance of manufacturer certificate embedded in hardware security element ### Minimum Hardware Specification **Processor** * Dual-core ARM Cortex-A or equivalent at minimum 1.0GHz * Hardware cryptographic acceleration for AES-GCM, ChaCha20, and SHA-256 * Memory protection unit (MPU) for execution environment isolation **Memory** * 512MB DDR minimum; 1GB DDR recommended * Memory encryption where supported by architecture **Storage** * 4GB eMMC or NAND flash for OS and relay software * Dedicated hardware security element (SE) with 256KB+ secure storage for cryptographic key material **Network** * Gigabit Ethernet WAN port * 100Mbps guaranteed relay bandwidth capacity * Hardware MAC address (cannot be spoofed) **Security** * Secure boot with INCOG manufacturer root certificate * Hardware random number generator (TRNG) for cryptographic key generation * Hardware security element for isolated key storage (e.g., ARM TrustZone-based or discrete SE) * Tamper-evident enclosure design **Power** * Passive cooling design for continuous 24/7 operation * Maximum 15W power draw at full relay load * Watchdog timer for automatic recovery from software hangs *** ## Secure Boot and Firmware Integrity ### Boot Chain Verification The hardware boot chain is anchored in the hardware security element, which contains the INCOG root certificate of authority. The boot chain: 1. ROM bootloader (immutable in silicon) verifies the first-stage bootloader using the root CA 2. First-stage bootloader verifies the second-stage bootloader 3. Second-stage bootloader verifies the OS kernel 4. OS kernel verifies the relay daemon software signature 5. Any verification failure halts boot and triggers a fault indicator This chain ensures that only software signed by the INCOG protocol authority (using a key held in hardware security modules with strict operational controls) can run on certified hardware. ### Firmware Update Security Firmware updates are delivered through a signed OTA mechanism: * Updates are signed by the INCOG software signing key * Signatures are verified by the hardware boot chain before application * Updates are applied atomically with rollback capability if the new firmware fails to boot successfully * Update channels are authenticated to prevent man-in-the-middle injection of fraudulent updates ### Anti-Tamper Design Certified hardware is designed to resist physical tampering: * Security element key material cannot be extracted through JTAG or other debug interfaces * Persistent memory is encrypted with a key derived from hardware identity * Physical tamper detection (if supported by hardware design) triggers key material erasure *** ## Hardware Security Element Integration ### Key Storage Architecture Cryptographic keys are stored exclusively in the hardware security element (SE), isolated from the main processor's accessible memory. This architecture means: * The relay node's long-term identity keypair never exists in software-accessible memory * All cryptographic operations using the identity key are performed by the SE, returning only the result (e.g., signature, ECDH output) * Extracting the identity key requires physically compromising the SE, which is designed to be extremely difficult and detectable ### Attestation Architecture The SE enables hardware-backed attestations of relay activity. An attestation produced by certified hardware carries a certificate chain that links: 1. The attestation signature → node identity key (stored in SE) 2. Node identity key → hardware manufacturing certificate 3. Hardware manufacturing certificate → INCOG hardware root CA This chain allows the reward verification system to distinguish attestations from certified hardware (carrying full reward eligibility) from attestations from software-only nodes (which carry reduced reward eligibility pending additional cross-validation). Hardware attestations provide stronger Sybil resistance properties: generating a hardware-backed attestation requires physical hardware with a valid manufacturer certificate, raising the cost of Sybil attacks. *** ## Home Router Deployment ### Setup Process The INCOG home router is designed for non-technical users. The setup process: 1. **Physical connection**: Connect the router to an existing home router's LAN port or directly to a modem. No network configuration changes are required to the existing router. 2. **Power on**: The device boots, connects to the INCOG setup service, and downloads the current relay software configuration. 3. **Registration**: The user scans a QR code on the device to link it to their on-chain INCOG account through the INCOG mobile or web interface. 4. **Activation**: After holder verification, the node registers in the relay directory and begins accepting relay connections. Total setup time target: under 15 minutes for a non-technical user. ### Network Configuration The home router node is designed to operate behind NAT without requiring router configuration changes, using UPnP port mapping for automatic firewall traversal where available. On networks where UPnP is disabled, the setup interface guides users through manual port forwarding if desired, or the node operates in relay-only mode (accepting connections from already-established circuits rather than new circuit initiations). ### Resource Management The home router node is designed to operate with minimal impact on home network performance: * Relay bandwidth is configurable, with a default cap of 50% of available upstream bandwidth * CPU usage is throttled to prevent impact on other network devices * QoS policies can be configured to prioritize household traffic over relay traffic * Scheduled relay participation allows operators to restrict relay operation to specific hours ### Monitoring Interface A local web interface (accessible from the home network) provides: * Real-time relay statistics (current circuits, bandwidth usage, uptime) * Monthly reward estimates based on current performance * Network health status * Configuration controls for bandwidth and scheduling * Firmware version and update status *** ## Data Center and Cloud Deployments ### Virtual Hardware Profile Software-only deployments (running on cloud instances or self-managed servers) can participate in the relay network under a reduced reward tier. Virtual deployments: * Cannot produce hardware-backed attestations (SE not available) * Are subject to enhanced cross-validation requirements for throughput verification * Receive a reduced base reward multiplier reflecting the lower Sybil resistance they provide * Are fully capable relay nodes in terms of routing protocol compliance Despite reduced reward eligibility relative to certified hardware, software-only deployments are valuable contributors to the network's routing capacity and are included in the relay directory alongside certified hardware nodes. ### Colocation Hardware Participants deploying certified INCOG hardware in colocation facilities receive full hardware-attestation reward eligibility while contributing higher-availability connectivity than home deployments typically provide. Colocation deployments are particularly valuable as exit nodes, where stable IP addresses and professional network connectivity improve circuit quality. --- # 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://incogai.gitbook.io/incogai-docs/incog-docs/network/hardware-layer.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.