Original topic illustration: ChainView BTC866 original topic diagram · ChainView BTC866 Editorial · CC BY 4.0
Separate upgrade milestones
Research, specification, implementation, testing, client release, and activation are separate milestones. A merged commit does not mean mainnet has adopted the change. Identify the reported stage, then inspect activation conditions in the specification and release notes. Record the network and trigger height or timestamp so testnet progress is not confused with mainnet deployment.
Protocol changes and client fixes
A client update can fix performance or security without changing consensus. A protocol upgrade may require compatible releases from several independent clients. Check supported versions, known issues, database migrations, and dependency compatibility. On Ethereum, execution and consensus clients must form a supported pair; one headline version cannot describe every operational setup.
Verify adoption with evidence
Node-adoption percentages depend on measurement. Public scans see reachable nodes, not necessarily economic weight or validator stake. Explorer activity can show a feature in use but cannot establish universal service readiness. Cross-check network observations, client documentation, and platform support notices, recording sample times and the limits of what each dataset can see.
Actions for ordinary holders
Many upgrades require no transfer or recovery-phrase entry from ordinary holders. Update a wallet through its verified distribution channel when necessary, and read the custodian notice for hosted balances. Claims that users must send funds to migrate mainnet deserve independent verification. Protocol maintenance does not require disclosing private keys to support staff.
Conditions behind performance claims
Throughput claims need transaction types, block parameters, hardware conditions, and duration. A benchmark peak is not everyday public-network capacity. Lower cost for one operation does not imply every fee falls. Compare execution, data availability, and settlement costs separately, including failed transactions, congestion, and latency rather than selecting only the most favorable number.
The post-activation review
After activation, operators should inspect synchronization, logs, resource use, peer connections, and API responses. Users can check balances and confirmed transactions. Preserve versions and block heights before reporting problems. Avoid blind database rollback or duplicate payment attempts: migrated data structures may not support downgrading, and an interface error does not prove a transfer failed.
Worked review example
Suppose version 2.0 is available but activation requires a future block height. The worksheet should say software available and activation pending as separate facts. After the height is reached, inspect actual blocks and node behavior rather than a countdown alone. If ordinary wallet users need no action, cite the official explanation in the user-impact column. Never replace that evidence with a community migration link. These invented version details illustrate the difference between release and activation; they make no claim about a current upgrade. Recheck any wallet instruction against its supported distribution channel and preserve the date on which you verified it.
