Page cover

High-Level System Architecture

Lume's architecture represents a multi-layered DePIN infrastructure designed to collect, distribute, and verify unused user bandwidth. Each component of the system interacts through verifiable, secure, and reproducible mechanisms, ensuring network reliability and scalability with minimal user involvement.

The system consists of four main modular layers: Client Layer, Verification Layer, Blockchain Settlement Layer (Solana), and Reward & Governance Layer. Each layer is optimized for independence, allowing the network to scale safely to millions of active nodes.

Client Layer — User-Side Network Node

The Lume user application is an autonomous microservice running in the background, providing network access through the unused portion of the internet connection. Its architecture includes four key subsystems:

1. Bandwidth Monitor & Resource Profiler

  • Continuously measures the current channel load (uplink / downlink).

  • Allocates a secure bandwidth limit that can be shared with the network without affecting the user's activity.

  • Uses a combination of:

    • system APIs (OS-level networking hooks),

    • local throughput sampling,

    • jitter/loss analyzer,

    • historical-usage model.

  • All data is processed locally — no user websites, packets, or DNS queries are analyzed.

2. Secure Task Router (STR)

STR processes incoming tasks from Verified Institutions, performs pre-validation, and determines whether the device can handle the specific network request.

Functions:

  • Task signature verification (ECDSA/Ed25519);

  • Task validation against the allowed request types list;

  • Filtering by geolocation and network resource availability;

  • Match-making: distributing tasks to nodes with optimal characteristics (bandwidth, stability, ping).

STR prevents illegitimate tasks and serves as the main security barrier.

3. Encrypted Proxy Engine (EPE)

EPE ensures isolated transmission of requests from Verified Institutions through the user.

Technical Properties:

  • Creates a temporary sandbox session for each task;

  • Uses TLS tunneling and session-isolated sockets;

  • Completely excludes access to the file system, cookies, or local memory;

  • Automatically destroys the container after the task is completed (ephemeral sessions).

Thus, institutional traffic is not mixed with the user's, and the user remains fully anonymous.

4. Local Proof Collector (LPC)

LPC collects technical metrics:

  • Maximum available speed;

  • Actual data transfer volume;

  • Duration of connections;

  • Connection stability;

  • Frequent-drop rate;

  • Delays by time of day.

Data is transmitted as aggregated hashes — no metric allows the identification of the user.

Verification Layer — Proof-of-Bandwidth & Task Integrity

This layer is responsible for verifying each client’s actual contribution to the network and the correctness of completed tasks.

1. Proof-of-Bandwidth (PoB) Framework

PoB is a mechanism that provably confirms the actual volume and quality of network resources provided by the user.

PoB includes:

  • Hashing batches of network sessions;

  • Time synchronization stamps (time-bound windows);

  • Verification of IP/ASN uniqueness;

  • Detection models for Sybil attacks;

  • Cross-validation with internal control queries.

PoB eliminates the possibility of "simulating" bandwidth.

2. Task Integrity Module (TIM)

The goal is to ensure that nodes perform only valid tasks.

TIM checks:

  • Verified Institution’s signature;

  • No modifications to the payload;

  • No attempts to intercept or reroute;

  • Anomalous traffic patterns (overload injection, time spoofing, packet padding).

TIM is used to protect the network from:

  • MITM attacks;

  • Replay attacks;

  • Fake traffic generation.

3. Reputation Scoring Engine (RSE)

RSE creates a multidimensional quality model for the node, including:

  • Connection stability;

  • Predictability of peaks;

  • Percentage of rejected tasks;

  • Geographical value (scarcity zones);

  • Uptime/downtime ratio;

  • Historical track record.

RSE forms the node’s "network profile," affecting:

  • Task priority;

  • Reward coefficient;

  • Access to more expensive tasks

Blockchain Settlement Layer (Solana Smart Contract System)

The settlement infrastructure is built on Solana, providing high throughput and low fees.

1. Reward Ledger Contracts

  • Track aggregated PoB metrics;

  • Perform token distribution;

  • Record task cost changes;

  • Create on-chain records of node contributions.

Contracts use PDA (Program Derived Addresses) for secure storage of aggregated buckets.

2. Reputation Registry

  • Stores hashed reputation data;

  • Updates after each PoB batch;

  • Used for dynamic resource distribution.

The data is aggregated and does not contain IP, ASN, or other sensitive information.

3. Institution Verification Contracts

Responsible for:

  • Whitelisting/revocation of organizations;

  • Storing their public keys;

  • Monitoring load limits;

  • On-chain record of expired or revoked keys.

This prevents the emergence of illegitimate "traffic setters."

4. Settlement Orchestration

The process occurs in batches:

  1. Aggregated PoB data is sent to the network;

  2. The oracle module checks network metrics;

  3. Contracts redistribute tokens;

  4. Reputation data is updated.

Reward & Governance Layer

This layer creates a sustainable economic model.

1. Lume Token Distribution Engine

Uses the formula:

Where:

  • RegionMultiplier incentivizes nodes in valuable geographical areas;

  • DemandFactor reflects real demand from institutions;

  • ReputationWeight increases rewards for stable nodes.

2. Dynamic Incentive Model

The model considers:

  • Peak hours;

  • Seasonality;

  • Institutional load;

  • Missing regions;

  • Task complexity.

The system automatically increases rewards where demand exceeds supply.

3. Governance Hub

Users with high reputation can participate in:

  • Voting on network parameters;

  • Reviewing rewards;

  • Selecting new Verified Institutions;

  • Approving protocol updates.

This brings the Lume architecture closer to a self-governed DePIN network model.

Last updated