Skip to content

Tracking: PNR (July 2027) replaces issuance-based operator income and invalidates the earnings-projection model #207

Description

@2ndtlmining

What

Tracking issue — no action needed soon. Filed so the change is visible before it is urgent.

From block 3,787,502 (2027-07-01), Progressive Node Rewards changes where operator income comes from. Consensus takes 20% of every application payment on arrival into a pool, and that pool drips into operator rewards over a rolling 86,400-block (30-day) window. The other 80% goes to the Foundation address that already receives application payments today.

Why this is bigger than #202/#203/#205

Those are constants going stale — a number changes, the model stays. PNR changes the model itself. This site's entire earnings projection assumes operator income = block subsidy x tier share. After PNR, income is issuance plus a demand-funded pool component that:

  • depends on actual application revenue, which the site does not currently observe at all
  • is not proportional to what a node hosts — "every eligible node in a tier draws the same share of the pool regardless of what it runs" (deliberate, to stop placement becoming a race)
  • ramps over years: ρ goes 0.20 at activation → 0.25 (2027) → ... → 0.50 cap (2032-10-23)

At activation PNR is only 4.29% of operator income, so the projection stays roughly right for a while — this degrades gradually rather than breaking on a date.

Status

The whitepaper marks this planned, not shipped. It also records an accepted risk worth knowing: PNR activation and the parallel-asset emission cut were settled as simultaneous, superseding the roadmap's "PNR must be demonstrably paying operators first" ordering — so there will be no external evidence that PNR pays operators before PA mining rewards are retired.

What to watch

  • Whether the pool balance is exposed anywhere queryable (the whitepaper says it is committed in every block and recomputed by every validator, so it should be observable on-chain)
  • Whether ρ and the drip window land as consensus constants

Source

Flux whitepaper v9, §3.1, §7, Table 18, https://whitepaper.app.runonflux.io/

Related: #203, #205

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions