Progressive Node Rewards: When Usage Starts Paying the Machines

Fluxers! On 1 July 2027, at block 3,787,502, the way Flux node operators get paid changes. This article explains exactly what changes, why that particular block, and — importantly — what it does not change.

If you run a node, this is the single most consequential item on the roadmap.

How operators are paid today

Today an operator’s income is new FLUX, minted every block. The applications running on the network contribute nothing to it.

Sit with that for a second, because it is the thing worth fixing. Someone pays to run an application on Flux; that payment does not reach the machine running it. The machine is paid out of issuance, by the protocol, regardless. Usage and reward are disconnected.

That is a normal place for a young network to start — you have to pay for capacity before you have demand for it. It is not a good place to stay.

What Progressive Node Rewards does

Under PNR, consensus takes 20% of every application payment on arrival and pays it into a pool. That pool drips into operator rewards over a rolling window of 86,400 blocks — thirty days. The other 80% goes to the Foundation address that already receives application payments today.

Two details make this trustworthy rather than merely stated:

• The split is applied by consensus at the address — not by software a tenant runs, and not by software a node runs. Nobody is asked to be honest about it.
• The pool balance is committed in every block and recomputed by every validator, so it cannot be misreported.

This is a revenue-layer change, not new issuance. It moves where operator income comes from — from minting, toward the workloads themselves.

Why that block number

Block 3,787,502 is not a round number somebody liked. It is the block at which the parallel-asset mining allocation is exhausted, computable today from the emission schedule. The calendar date of 1 July 2027 follows from that height at the thirty-second block target.

The timing is deliberate in a way worth naming. One of the two rules the roadmap holds itself to is that operator income never falls first — anything that reduces what operators earn ships only after its replacement is live and paying. PNR activating exactly where the parallel-asset allocation runs out is that rule expressed as a block height.

Why every node in a tier draws the same share

One design decision in PNR is worth explaining, because it is deliberate and it is not what people expect. Every eligible node in a tier draws the same share of the pool, regardless of which applications happen to be placed on it.

The reason is that Flux places applications on a first-to-claim basis. If the reward followed placement, that claim would become a race with money attached to it — and a hosting network does not want to reward grabbing work fastest. It wants to reward being reliably available to run it.

A flat share within a tier keeps the placement decision about capacity and fit. It also means an operator’s income is predictable: you know what your tier earns from the pool without having to guess which workloads land on you this month. For anyone sizing a node investment, predictable beats lottery.

Which is why attestation comes first

Pairing a flat reward with a strong eligibility standard is what makes the whole design work, and that standard is getting stronger: attested execution means a node can prove what it is actually running. This is why that work is sequenced as a precondition for PNR rather than as a follow-on to it.

It arrives in two layers. The first is already 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 fails.

The second is in design: a bonded attestation network in which nodes stake collateral on claims about what they serve, and lose that stake 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.

What has to land before it

PNR needs the application specification to carry a payment memo that binds a payment to the application it funds — that is what makes revenue attributable at all. That field arrives with version 9 of the specification, enforced at block 3,050,000, expected late October 2026, with existing applications migrated automatically in the same quarter.

The sequencing there is deliberate too: the enforcement height is set to follow the implementation rather than precede it, so the schema lands first and the placement path adopts the new fields before anything is enforced against them.

How it ships

The stated sequence is testnet, then a pilot on a real product, then mainnet — with per-tier before-and-after examples published to operators before activation, so no operator is surprised by their own numbers.

That follows the second roadmap rule: nothing irreversible ships before its gate. Contracts wait for audits, chain changes wait for testnet.

The full mechanism, with citations, is in the Flux whitepaper at runonflux.com/whitepaper, and the delivery sequence is on the roadmap. If you operate nodes, the before-and-after examples are the thing to watch for.