When a blockchain project says a bug is fixed, the correction may be finished in one place and unfinished in another. Developers can repair the code before operators install it. A network can activate new rules while some computers still run an older release. Public details may also remain private until the rollout is far enough along to limit abuse. “Fixed” therefore needs a date and an object: the code was corrected, the network activated the correction, or affected operators adopted it.
The gap between a released patch and its installation on affected systems is commonly called the patch gap. SecurityWeek reported in July 2025 that an upstream gap can begin earlier, after one developer fixes a flaw but before downstream vendors integrate the change into products. The publication also described Project Zero’s 90+30 policy: vendors have 90 days to fix a reported bug and 30 days for adoption when the correction arrives before the deadline. That is one research team’s disclosure schedule, not a universal blockchain timetable. Code correction, update distribution, and installation can therefore have separate dates.
A Fix Can Have Several Dates
Several events can sit behind the word “fixed.” A weakness may first be reported privately. Developers then write and test corrected code. Node operators install the update, and a blockchain may activate the change at a predetermined block height, a numbered point in the chain. Technical details can become public before or after those steps. Validators are computers that check transactions and help maintain the network’s shared history.
Polygon’s August 27, 2026 security review described two coordinated network upgrades that were rolled out privately, validated on the Amoy test network, activated on Polygon’s main network, and disclosed after the validator fleet was protected. An August 31 report titled “Polygon Disclosed 10 Bugs After Quietly Fixing Them First” described 10 distinct fixes and stated: “Technical details reached the public only once the entire validator fleet was already protected.” Readers can find out more from reports about crypto news at AlphaWire. Polygon’s notice also said that nodes running earlier software beyond the activation heights had already fallen out of consensus. Their operators needed to upgrade and roll back to a point before the upgrades, so the nodes could resynchronize and rejoin the current network.
During a coordinated upgrade, validators must begin following the new rules at the agreed activation point. A machine that misses the change can continue running without participating in the current network. Its operator may need to install the new release, roll its stored data back to a point before activation, and synchronize again. For the active network, the flaw may already be closed. For that operator, the repair is still work waiting to be completed.
Released Code Is Not Yet Active Protection
A software project can label a release as patched as soon as corrected code becomes available. That label says nothing by itself about how many operators have downloaded it, restarted their software, or reached the activation point. In a conventional application, protection may begin when the update is installed. In a blockchain protocol, protection may begin when the network reaches the activation point and participating nodes enforce the new rules. Release time, installation time, and activation time can all differ without any party using the word inaccurately.
The part of the system affected by the flaw changes which date deserves attention. A wallet-interface flaw may be fixed when a provider deploys new software to its own service. A validator flaw can depend on independent operators installing a release. A rule change may remain dormant until a scheduled block height, even when every validator already has the required code. Reports that name the affected component and the completed action leave less room for confusion than a headline that says only “resolved.”
Disclosure and Protection Follow Different Clocks
Security teams sometimes withhold technical details while a correction is being distributed. Early disclosure can warn exposed users and invite outside scrutiny, but it can also give attackers a map before enough systems are protected. Delayed disclosure can reduce that window, although it leaves the public with less information about the response while deployment is underway. Neither sequence proves that every affected machine has updated. A project can publish full details after network activation and still have lagging operators outside the current network.
A failed first attempt can add another date. In July 2025, Reuters reported that Microsoft’s initial SharePoint patch did not fully close the vulnerability and that further updates were required. A release announcement was therefore evidence that a correction had been issued, not proof that the underlying exposure had ended. Later testing, a second release, or an activation problem can also change the status of an earlier blockchain fix.
Questions That Make “Fixed” Specific
A complete report identifies what changed, where it changed, and when the protection became effective. It separates the private report date from the code-release date, the deployment or activation date, and the public disclosure date. It also states whether operators must take action. “No user action required” describes a very different outcome from “upgrade immediately,” even when both reports say the flaw has been fixed.
When a report uses that word, check which statement it supports: corrected code exists; the active network is enforcing it; affected operators have installed it; or technical details are now public. Evidence for one does not automatically establish the others. A precise report may support all four, but each needs its own action and date.
