For a Chia farm owner, a consensus upgrade means more than a new application version. It affects node compatibility, wallet operation and the storage plan. In autumn 2026, current official documents matter because early discussions of the next format contained different timing expectations. This analysis uses pages checked on October 18 and does not report a future activation as already completed.
What the current FAQ states
At the time of checking, Chia’s official FAQ specifies activation at height 9,562,000, expected in November 2026. It also describes a 256-day transition for the old format and the need for compatible software. Block height is the activation condition; the calendar month is an estimate. Recheck those details before maintenance. [s0]
That distinction is practical. Relying only on an old calendar announcement can mean preparing for the wrong moment. Block production and later official clarification can alter the calendar estimate. Record the source, checking date and actual state of the local node in the plan. An old discussion screenshot does not replace current transition instructions, even when its author previously explained other network behaviour correctly.
What changes in Proof of Space
Chia uses storage space together with proofs of time. Its next-generation Proof of Space explanation discusses a new organisation of plots and proof processing while retaining the overall role of the time component. This changes a particular mechanism rather than turning a disk into an ordinary computational miner. Obtain exact requirements from the documentation for the relevant version. [s1] [s2]
A plot contains specially prepared data. Farming accesses those data under network rules; creating the plot is a separate operation. “Performance” can therefore mean preparation speed, response timeliness or stable disk servicing. These metrics cannot be merged into one universal figure. Faster plot creation alone does not demonstrate that the farm will operate well after preparation finishes.
Do not begin by deleting every old plot
Treat the transition as a change to a working storage system. Establish software compatibility, hardware requirements and the official migration sequence first. Then assess free capacity and preparation time. Removing the old set before validating the new process eliminates a comparison point and can create lengthy downtime. A transition mechanism calls for a schedule rather than an automatic reaction to a headline.
A useful start is a small controlled stage within the official procedure. Validate creation, file recognition and service operation. Another person’s benchmark is not a promise for this hardware. Processor, memory, temporary storage, interfaces and concurrent work can change timings. Plan from measurements of the actual installation and the available maintenance window, leaving room to correct a problem before proceeding.
Node, farmer and wallet have separate roles
An interface can make several functions look like one application. The node validates the chain and exchanges data; the farmer works with prepared plots and proofs; the wallet tracks information relevant to its user. Updating one part does not automatically establish that every other part works. Understanding those roles helps locate a fault without unnecessarily replacing the whole setup.
After updating, separately check synchronisation, recognised storage, timely responses and wallet state. One green indicator is not a complete validation. Multi-machine installations also require role compatibility and an update order. A service left running for a long time may still use an older version even when the main window displays a newer number. Check the components actually running, not merely the downloaded installer.
Drives and temperature still matter
A format change does not remove normal disk-operation requirements. Know which devices are connected, what errors the system reports and whether cooling is adequate. An interface or power fault can resemble a software issue. Replotting alongside normal farming changes CPU, memory and storage activity. Validate the combined workload rather than only each stage separately under ideal conditions.
Before maintenance, retain configuration information and understand recovery. Backing up service data does not mean publishing secrets or handing them to an unknown migration tool. An official software update and importing recovery secrets into a third-party website are different actions. Disclosing a recovery secret to another person is not a normal technical requirement of a plot-format transition.
What readiness looks like
Readiness means a known compatible software version, understood hardware, an up-to-date schedule and a tested sequence. Include free space, maintenance time and monitoring. Define how an error will be detected and how to stop the next stage before it affects the entire installation. This approach is useful for any lengthy data migration, including a Chia farm running several tasks concurrently.
This article does not promise XCH returns or calculate an equipment purchase. Its subject is the operational side of the officially documented transition. Before making an actual change, reopen the current Chia pages and compare them with the installation. A plan tied to verified rules and network height is more useful than rushed replotting based on an old calendar note.
