Bandwidth Contribution Mechanics

The bandwidth provisioning mechanism in Lume is based on the operation of a local network client that functions as an asynchronous resource scheduler and secure traffic proxy. After the application is installed, the device launches a resident module that continuously monitors system and network metrics: available throughput (Mbps), RTT, jitter, packet loss, bufferbloat, local bandwidth consumption, NIC load, as well as network environment parameters (connection type, NAT level, route quality).

Based on this data, the module calculates the Residual Bandwidth Window (RBW) — the actual range of bandwidth not used by local processes. The RBW is recalculated every 200–500 ms using sliding windows and Kalman filters, allowing for the exclusion of user load spikes and ensuring that only the guaranteed free channel is allocated to the network. The transmission never exceeds the RBW, and any local increase in traffic load immediately reduces throughput to zero.

Once the RBW is determined, the client initiates an encrypted multiplexed transport tunnel, built using a combination of TLS 1.3 + QUIC with forward secrecy support and a separate key for each session channel. All data is encapsulated into encrypted packets of fixed or variable size (depending on the side-channel protection policy) and proxied through distributed ingress nodes of Lume’s institutional partners. The traffic content is inaccessible to the client, as the application operates in blind relay mode — it only forwards binary frames without the ability to interpret them.

Each transmitted packet is assigned a set of metadata: timestamp, packet-size class, session-ID, region-tag, RBW-index, which are used by the system for validation. Nodes verify the packets' compliance with allowed parameters, then pass the aggregated data to an off-chain processor. There, the Proof-of-Bandwidth Contribution (PoBC) is generated — a cryptographically verified report on the actual bandwidth volume delivered, channel quality (mean RTT stability, variance), uptime coefficient, and the accuracy of RBW forecasts compared to real values.

The PoBC result is published in Solana as an aggregated record, tied to an anonymous node through a temporary identity-hash. No user data or network characteristics that could lead to de-anonymization are posted on-chain.

The reward calculation algorithm uses the formula:

Reward = f(Delivered Bytes, RBW Accuracy, Stability Index, Demand Multiplier)

Where:

• Delivered Bytes — the actual transmitted and confirmed traffic;

• RBW Accuracy — the discrepancy between the forecast and actual values (the lower the discrepancy, the higher the coefficient);

• Stability Index — the degree of channel stability (RTT deviation, retry rate);

• Demand Multiplier — the regional demand boosting factor, updated every 30–90 seconds.

The system also applies protection against manipulation: artificial lowering of local load, attempts to accelerate RBW profiles, traffic emulation, and other attacks are detected by pattern analysis. When anomalies are detected, the node is “throttled” or temporarily excluded from calculations.

Thus, the mechanism weighs the actual contribution of the device to the network — strictly measured, securely transmitted, and cryptographically confirmed — without access to user activity and without the risk of intercepting transmitted content.