Filecoin Solstice: What Is the Block Reward Paying For?

One reward, more than one job

Filecoin has crossed its Solstice upgrade boundary. At 13:05 UTC on October 19, 2026, CoinYQ’s read-only check of the public GLIF Mainnet RPC returned network version 29 at epoch 6,470,291 and the released v19.0.1 reward actor code. The announced boundary was epoch 6,470,279 at 12:59:30 UTC; 13:05 is our observation time. The change behind nv29, FIP-0118, poses a practical question: what job should a newly minted block reward pay for?^{[1][2][9][10]}

Update — October 19, 2026: Filecoin Status posted the Solstice maintenance as completed at 13:59 UTC. This is the publication time of the official completion notice, distinct from the on-chain observation above. The notice does not establish economic effects or successful migration for every user.^[1]

The change first separates storage content from the weight assigned to new storage sectors. Under the released rules, every new sector gets the maximum quality-adjusted power, or QAP, irrespective of what it contains. DataCap and verified-registry writes stop. The old route that linked a higher sector weight to verified allocations no longer determines the weight of new sectors.^[2][5]

Ten times the weight is not ten times the storage

QAP is a protocol accounting weight. The released actor code gives a sector with the full-power flag ten times its raw size in this calculation. A 32 GiB sector therefore has 320 GiB of quality-adjusted power, while still representing 32 GiB of physical sector capacity. This is arithmetic applied to a weight, not evidence that more customer files appeared, that ten copies were made, or that downloads became faster.^[3][5]

Existing sectors do not all jump to the new weight at the transition. They retain their recorded power; eligible sectors can use a separate upgrade path. Raising that weight can require additional pledge collateral and an adjusted daily fee. The distinction matters when reading a network chart: a change in weighted power can reflect a rule change or a sector upgrade rather than an equal increase in stored data.^[2][3]

A small new branch in the reward budget

The Mainnet bootstrap parameters start the consensus stream at 95% and the service stream at 5%. The consensus weight follows a linear decline toward 50% over nine protocol quarters. These quarters are fixed epoch windows, counted from activation, rather than calendar quarters. During the first, bootstrap quarter, the service weight grows with the part leaving consensus, reaching 10%. The percentages divide newly minted block rewards; gas rewards still go to the winning miner.^[4][6]

After that bootstrap phase, an additional five-percentage-point service increase requires the relevant quarter’s qualifying Filecoin Pay volume to meet the specified target. A missed target leaves the service weight unchanged. It cannot exceed the portion available after consensus. If consensus keeps declining while the service share does not grow enough to fill the gap, the unallocated remainder is burned. A larger service budget is therefore not simply promised by the passage of another quarter.^[3][4]

Who receives the service share?

The service stream is for registered Service Orchestrators: organizations that develop paid demand through such work as integrations, customer onboarding and service infrastructure. It is not a payment automatically sent to everyone storing a file or holding FIL. The reward actor accrues the allocated amounts; a separate claim step pays the registered recipients. Accrued entitlement and a completed withdrawal are separate records, and neither alone shows how the money was subsequently spent.^[3][6][7]

Payment volume also needs a careful reading. The input comes from qualifying Filecoin Pay settlement events, but an off-chain indexer computes the figures, including the specified currency conversion. Orchestrators post their values; a verification window allows governance to correct them before they bind. Later distribution uses these bound figures. Calling the whole measurement process an automatic on-chain verdict on customer demand would leave out the reporting and review work.^[3][8]

The next useful evidence is a record of service

Solstice’s reporting runbook asks orchestrators to distinguish accrued rewards from claimed rewards and to disclose how funds were used. That gives readers concrete questions for later quarters: which qualifying settlements were counted, how were those figures checked, what was actually withdrawn, and what service work followed? A changed allocation rule can make those questions more visible; it cannot answer them before the activity happens.^[7][8]

The change is best read as a new way to fund two different jobs: keeping the consensus system running and developing paid services on it. The observed nv29 and reward actor establish that the transition occurred. This article explains the released rules; it does not measure customer growth, individual payouts or investment returns. Demonstrating useful demand will require the records produced afterward.^{[3][8][9][10]}