> For the complete documentation index, see [llms.txt](https://aetherservice.gitbook.io/about/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://aetherservice.gitbook.io/about/product-vision-and-distributed-infrastructure/decentralized-network-architecture.md). # Decentralized Network Architecture ## Client Layer — User-Side Network Node The Aether user application operates as an autonomous background microservice that enables participation in the network by utilizing a controlled portion of the user’s unused internet bandwidth. Rather than functioning as a traditional application, it behaves as a system-level network node designed to operate continuously without interfering with normal user activity. The architecture is composed of four core subsystems that collectively manage resource allocation, task execution, secure isolation, and contribution measurement. The first subsystem, the **Bandwidth Monitor & Resource Profiler**, is responsible for continuously analyzing the state of the user’s network connection. It measures uplink and downlink utilization in real time and determines how much capacity can safely be allocated to the network without impacting user experience. This process is based on a combination of system-level network APIs, local throughput sampling, jitter and packet-loss analysis, and historical usage patterns. All computations are performed locally, and no external traffic content, DNS queries, or user activity is ever inspected, ensuring strict separation between monitoring logic and personal data. The second subsystem, the **Secure Task Router (STR)**, acts as the primary validation and routing layer for incoming network tasks. STR verifies cryptographic task signatures, ensures that requests originate from authorized sources, and filters them according to predefined task categories and system constraints. It also evaluates geolocation compatibility and node capability before assigning tasks, ensuring optimal distribution across the network. By performing pre-execution validation and routing decisions, STR serves as a critical security boundary that prevents unauthorized or malformed requests from reaching the execution layer. The third subsystem, the **Encrypted Proxy Engine (EPE)**, is responsible for isolating and executing institutional network traffic through the user node. Each task is processed within a temporary, sandboxed session that is fully separated from the user’s local environment. The engine uses encrypted tunneling and session-isolated sockets to ensure that data streams remain contained and cannot interact with the file system, memory, cookies, or any persistent local storage. Once the task is completed, the session is immediately destroyed, leaving no residual data. This design ensures that institutional traffic is fully separated from user activity while preserving anonymity and system integrity. The fourth subsystem, the **Local Proof Collector (LPC)**, aggregates and records non-identifiable performance metrics related to node participation. These include data transfer volume, connection duration, stability metrics, latency distribution, and failure rates over time. Rather than storing raw data, LPC converts all measurements into aggregated cryptographic representations, ensuring that no metric can be traced back to an individual user. This data forms the foundation for downstream verification and reward calculation. ## Verification Layer — Proof-of-Bandwidth & Task Integrity The verification layer is responsible for validating both the authenticity of network contributions and the integrity of executed tasks. It ensures that all reported bandwidth usage and task execution data reflect real, verifiable activity rather than simulated or manipulated behavior. At the core of this layer is the **Proof-of-Bandwidth (PoB) framework**, a mechanism designed to cryptographically validate the volume and quality of network resources provided by each node. PoB operates through time-bound measurement windows, session hashing, and cross-validation techniques that verify consistency between reported and observed network behavior. It also incorporates IP and ASN uniqueness analysis, Sybil-resistance models, and internal control requests that serve as integrity checks. Together, these mechanisms make it infeasible to simulate or artificially inflate bandwidth contribution without detection. Complementing this system is the **Task Integrity Module (TIM)**, which ensures that all executed tasks remain valid, untampered, and compliant with institutional requirements. TIM verifies cryptographic signatures from verified institutions, checks payload consistency, and ensures that no modifications, rerouting attempts, or injection behaviors occur during task execution. It also monitors for anomalous traffic patterns such as replay attempts, overload injection, or packet manipulation. This module serves as the primary defense layer against malicious behavior, including MITM and replay-based attacks. The third component of the verification layer is the **Reputation Scoring Engine (RSE)**, which constructs a multidimensional performance profile for each node. This profile is derived from metrics such as connection stability, uptime consistency, traffic predictability, rejection rates, and geographic value based on network scarcity. The resulting reputation score directly influences task allocation priority, reward multipliers, and access to higher-value institutional workloads. Over time, this system naturally differentiates between high-quality and low-quality nodes, ensuring efficient allocation of network demand. ## Blockchain Settlement Layer — Solana Smart Contract System The settlement layer is built on the **Solana blockchain**, providing a high-performance environment for processing rewards, recording contributions, and maintaining system-wide state with low latency and minimal transaction costs. At its core are the **Reward Ledger Contracts**, which aggregate Proof-of-Bandwidth data and calculate reward distributions based on verified contribution metrics. These contracts manage token emissions, record task pricing adjustments, and maintain immutable on-chain records of node participation. Data is stored using Program Derived Addresses (PDAs), ensuring secure and deterministic state management across the network. The **Reputation Registry** complements this system by storing hashed representations of node reputation scores. These records are updated after each verification batch and serve as a dynamic input for resource allocation and reward weighting. Importantly, this registry does not store sensitive identifiers such as IP addresses or ASN-level data, preserving privacy while maintaining verifiability. The **Institution Verification Contracts** are responsible for managing the identity and authorization of participating organizations. These contracts handle whitelisting, revocation, and key management for institutional participants, ensuring that only verified entities can generate valid network tasks. They also maintain on-chain records of expired or revoked credentials, preventing unauthorized traffic injection into the system. Settlement is executed through a batch-based orchestration process. Aggregated Proof-of-Bandwidth data is submitted to the network, validated through oracle-assisted checks, and then processed by smart contracts that distribute rewards and update reputation states. This layered approach ensures both scalability and consistency in state transitions across the system. ## Reward & Governance Layer The reward system is designed to align economic incentives with real network demand and node performance. Token distribution is calculated through a dynamic model that reflects both contribution quality and external demand conditions. The **Aether Token Distribution Engine** determines rewards using a composite formula that incorporates base contribution rate, Proof-of-Bandwidth score, geographical multipliers, reputation weighting, and real-time demand factors. This ensures that nodes operating in high-demand regions or providing high-quality, stable connections receive proportionally higher rewards. The incentive model is adaptive and responds to real-time network conditions such as peak usage periods, institutional load fluctuations, geographic scarcity, and task complexity. When demand exceeds available supply in specific regions, the system automatically increases rewards to incentivize additional node participation, maintaining equilibrium across the network. Governance is handled through a decentralized **Governance Hub**, where high-reputation participants are granted voting power over key protocol parameters. This includes decisions related to reward structures, onboarding of new verified institutions, parameter adjustments, and protocol upgrades. Over time, this mechanism transitions the network toward a self-regulating model where contributors also participate in its evolution. --- # 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: ``` GET https://aetherservice.gitbook.io/about/product-vision-and-distributed-infrastructure/decentralized-network-architecture.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.