What Actually Makes a Machine a Flux Node

Fluxers! What actually makes a machine part of the Flux network? Not a contract. Not an application form. Not a relationship with anybody.

It is a lock. An operator locks a fixed amount of FLUX as collateral, runs the node software, and from that point the chain itself decides whether the machine is eligible to host and to be paid. Leave, and the collateral unlocks. Misbehave in ways the chain can see, and it does not.

This article walks through how that works, what the network looked like when it was last measured, and what an operator gets for putting collateral behind a machine.

Three tiers, three collateral sizes

Measured on 3 September 2026, from the network’s own public interfaces:

• Cumulus — 1,000 FLUX collateral — 3,247 nodes — 3.67% of voting weight
• Nimbus — 12,500 FLUX — 1,615 nodes — 22.81% of voting weight
• Stratus — 40,000 FLUX — 1,627 nodes — 73.52% of voting weight

That is 6,489 nodes in total, with 88,514,500 FLUX locked across the fleet — about a fifth of everything ever issued. Each tier also carries a hardware floor, so collateral and capability move together.

The collateral is not a gesture. A fifth of the supply is genuinely immobilised behind the network’s ability to run other people’s software.

Why the tiers are shaped that way

Three tiers exist so that operators can join at the scale that suits them. Cumulus is the entry point and it is genuinely accessible: a thousand FLUX and a modest machine puts you on the network, which is why it is the most populous tier by some distance. Nimbus and Stratus commit more collateral and more hardware, and carry correspondingly more of the network’s heavier workloads.

Voting weight follows collateral rather than headcount, which is what ties influence to stake at risk. An operator who has locked forty thousand FLUX has more at stake in the network’s decisions than one who has locked a thousand, and the weighting says so. It is the same principle that makes the collateral meaningful in the first place.

What the nodes are actually running

On the same measurement date, 1,195 applications were deployed across the fleet, 873 of them (73.05%) on version 8 of the specification.

By census that is web services, blockchain infrastructure, and — the one people do not expect — 27 scientific-simulation deployments doing real protein-folding work on about 9% of the fleet’s committed CPU.

It is worth being precise about what that means. Flux is not a proposal for a decentralized cloud that might one day host real work. It is a general-purpose cloud that already has science running on it, into which AI is arriving as one workload among several.

Proving a node is what it says it is

Collateral proves an operator has something to lose. It does not prove the machine is running what it claims. That gap is being closed in two layers.

Shipped: ArcaneOS, the operating image nodes run, boots through a measured chain — Secure Boot, a pinned platform key, a hardware root, encrypted storage — and refuses to come up if any link in that chain fails.

In design: a bonded attestation network, in which nodes stake collateral on claims about what they serve and lose it if a challenger proves them wrong. The parameters are set, and the remaining work is the slashing construction — the part that has to be right before anything is staked on it.

This work pairs directly with the reward change coming in 2027. Under Progressive Node Rewards every eligible node in a tier draws the same share of the pool, which keeps operator income predictable and keeps application placement about capacity and fit rather than about who claims fastest. A strong eligibility standard is what makes that design work, and attestation is how the standard gets stronger — which is why it is sequenced ahead of the reward change rather than after it.

What operators get in return

Today, node income is new FLUX minted every block; applications contribute nothing to it. From 1 July 2027, at block 3,787,502, consensus begins taking 20% of every application payment into a pool that drips into operator rewards over a rolling thirty-day window. Usage starts paying the machines.

There is also a body of work aimed squarely at the risk operators carry by hosting other people’s software. The stated principle is worth quoting: defence as protection from harm, not veto over content. Behaviour, not content. In practice that means an application oracle showing what each application consumes and where its traffic goes — aggregate volumes, never content inspection; resource guardrails that throttle and flag an application exceeding what it paid for; an optional egress profile with connection-rate limits and outbound abuse detection; and an evidence pack that produces, in one click, a document showing which application ran, when, and on which address.

Check it yourself

Every figure above came from public endpoints, and the scripts that produced them are published with the whitepaper. Run them and you will get current numbers rather than ours.

Two snapshots are deliberately left out of the public repository: one carries the IP address of every node, the other carries tenant application specifications. Both come from public endpoints, but persisting them in a repository would aggregate operator and tenant data in a way the live API does not — so the script fetches current equivalents at run time instead. Looking after operators’ and tenants’ data is part of the job.

If you are thinking about running a node, start at runonflux.com/fluxnodes. If you want the full technical picture first, the whitepaper is at runonflux.com/whitepaper.