Flux v9: A Decentralized Cloud for Autonomous Compute

Fluxers! The new Flux whitepaper is out. It is called Flux v9: A Decentralized Cloud for Autonomous Compute, and it is not a refresh of the old one. It is a 423-page technical description of the network as it is actually deployed today, plus a specification of the architecture it is being rebuilt into — and a 16-page short paper for anyone who wants the argument without the appendices.

Both documents are public, together with the scripts that produced every measurement in them. Let’s go through what is in there.

Three documents, one standard

You can read it in whichever form suits you:

• The short paper (16 pages): what Flux is, how it works, what changes in v9, and what it is for.
• The full paper (423 pages): the complete technical survey, with provenance for every claim.
• The combined PDF: the short paper first, the full paper behind it, each with its own bookmarks.

All three are written to the same rule, and it is the rule that makes the document worth your time: every claim carries a provenance citation, and every claim about deployed behaviour carries a source-code citation. If the paper says FluxOS does something, there is a line of FluxOS you can go and read.

On top of that, claims are tagged on two independent axes. Maturity — shipped, in progress, planned, or vision. Provenance — read from code, from roadmap material, from design intake, or inferred. You always get both, so you always know whether you are reading about something that runs today or something that is intended.

That tagging is what makes the document usable as a reference rather than a brochure. Whatever you are evaluating — running a node, deploying an application, building a product on the platform — you can see at a glance which parts are running today and which are the architecture being built toward, and you can follow either one down to its source.

What the network actually is, measured

Everything below was retrieved from the network’s own public interfaces on 3 September 2026, and anyone can run the scripts in the public repository and get current equivalents.

• Nodes, all tiers: 6,489
• Cumulus / Nimbus / Stratus: 3,247 / 1,615 / 1,627
• Collateral locked: 88,514,500 FLUX — about a fifth of everything ever issued
• Applications deployed: 1,195
• On specification v8: 873 (73.05%)
• Scientific-simulation deployments: 27

That last line deserves a pause. Twenty-seven deployments on Flux are doing real protein-folding work, on roughly 9% of the fleet’s committed CPU. Flux is not a proposal for a decentralized cloud with science on it. It is a general-purpose cloud that already has science running on it, and into which AI is arriving as one workload among several.

The bet the paper makes

The central argument is short enough to state in a paragraph, so here it is.

Every major cloud is built for a human with a card and an account. Flux is being rebuilt for a caller that is a program — one that provisions capacity, pays for it, and releases it with no human anywhere in the loop. It can do this for one narrow and decisive reason: on Flux, paying is a signed transaction, not a billing relationship. A program can hold a key. It cannot hold a corporate account.

The second half of the bet is about the shape of the fleet. The thing that centralises frontier AI — sharding a single model across many accelerators that have to be wired together — simply does not apply to a model that fits on one device. And the models most people actually need fit on one device. A dispersed fleet with a great deal of memory is a structurally sensible home for exactly those.

What changes in v9

The paper puts dates against the changes rather than gesturing at them, and each is labelled planned rather than shipped until it lands:

• July 2027, at block 3,787,502: operators stop being paid purely by new issuance. A fifth of every application payment flows into a pool that pays them instead.
• Ten parallel-asset chains become two.
• The shielded pool is retired.
• A collateral-weighted vote can remove an application.

Reproduce it yourself

The public repository ships the measurement scripts alongside the PDFs — the live API snapshot, the fleet and concentration analysis, aggregate network capacity, per-chain parallel-asset liability, the PNR settlement series, and a cross-section consistency check that verifies the numbers agree with each other.

Two snapshots are deliberately left out of the repository. listzelnodes.json carries the IP address of all 6,479 nodes it captured, and globalappsspecifications.json carries tenant application specifications including contact strings and environment variables. Both come from public endpoints, but committing them to a public repository would aggregate and persist third-party operator and tenant data in a way the live API does not. Run the measurement script and you will get current equivalents.

Read it

Start with the short paper if you want the argument in one sitting, and the combined PDF if you want to be able to follow any claim down to its source. Both are linked from runonflux.com/whitepaper.

If you find something in it you think is wrong, we would rather hear it than not. The whole point of citing every claim is that the claims can be checked.