Crypto network upgrades: who needs to act and when?

A network-upgrade notice can sound like a software deadline for everyone who owns the native coin. Usually it is not. Blockchains coordinate several kinds of participants: client developers publish software, node operators choose whether to run it, validators or miners produce blocks, exchanges maintain deposit and withdrawal systems, application developers test behavior, and holders may simply keep the same balance through the change.

The responsibilities are different because each participant touches a different layer. A validator running an old client can fall onto incompatible rules at activation. An exchange must know when it can safely credit on-chain deposits. A decentralized application may rely on an opcode or gas assumption that changes. A person whose asset is already credited in an exchange database may have no technical task at all.

This guide builds a role-first reading method and applies it to 13 official mainnet milestones across Ethereum, Cardano, Avalanche, BNB Smart Chain and Arbitrum from March 2024 through July 2026. The milestones are historical records reviewed on 23 August 2026, not a live future calendar. The accompanying tracker exposes the same dates with filters for network, year and upgrade focus.

Do not ask only, “Does this coin have an upgrade?” Ask, “Which software or service do I control, and what does its official notice require?”

The upgrade language that changes the answer

Protocol upgrade

A protocol upgrade changes rules or capabilities implemented by network software. It may add transaction types, alter gas accounting, change consensus behavior, introduce cryptographic operations or modify governance. The word describes a broad family. The actual compatibility boundary appears in the specification and client release.

A holder does not install a protocol specification. A node operator installs a compatible client. A wallet provider may release an update if transaction construction or display changes. An application developer may review new functionality even when the old application remains compatible.

Hard fork

A hard fork activates rules that older software does not understand as valid. Nodes that have not upgraded can follow the old rules and separate from upgraded peers. That technical definition does not mean two economically meaningful coins will persist. Most coordinated mainnet hard forks are adopted by the relevant ecosystem and continue as the recognized network.

Ethereum's official upgrade notices make the distinction explicit: holders normally take no action, while nodes and validators must update. Cardano describes its hard forks as a precise collective evolution in which nodes switch at an agreed slot, not an automatic division into rival communities.

Soft fork

A soft fork tightens validity rules in a way that can preserve some backward compatibility. The operational details still matter. Miners, validators, nodes, wallets or businesses may need to understand new signaling or policy even when older nodes can continue recognizing upgraded blocks under the former broader rules.

The label alone is not a user instruction. Read the implementation and deployment method for the specific network. A generic explanation of soft forks cannot supply the activation height, threshold or software version.

Client release

A client release is software. It can include support for a future protocol activation, ordinary fixes and optional features. The release date is not necessarily the network activation date. Operators often install a compatible version days or weeks before the rules change at a block, epoch, slot or timestamp.

This separation prevents a common timeline error. “Version released on 20 May” and “hard fork activated on 30 June” can both be correct. The first gives operators preparation time. The second is when the network begins enforcing the new rules.

Token migration

A token migration changes the contract, denomination, network representation or asset issued to holders. It can require a swap, snapshot, conversion ratio or deposit deadline. This is not the default meaning of a network upgrade. An ordinary hard fork can preserve account balances and native coins without any token conversion.

If an announcement requires a token action, it should name the old and new assets, conversion method, ratio, eligible balances and deadline. “We support the upgrade” does not supply those terms.

Chain split

A chain split occurs when incompatible rules retain enough participants to continue as separate networks. A temporary fork can also occur accidentally while nodes converge. Neither event guarantees that an exchange will credit two assets or that the minority chain has working infrastructure and liquidity.

Balance snapshots and fork-asset distribution are exchange product decisions with their own conditions. A network upgrade notice is not evidence for a free token.

Start with your role, not with the coin

Why the holder's default answer is often “wait”

A blockchain balance is part of network state. When the recognized network moves through a coordinated upgrade, compatible nodes carry that state forward under the new rules. A holder does not need to send the asset to create the continuity. Moving funds immediately before a maintenance cutoff can add settlement risk without adding protection.

Ethereum's Dencun, Pectra and Fusaka materials each tell ordinary ETH holders that no action is required unless a wallet or exchange gives additional instructions. BNB Chain's Pascal guidance says ordinary users do not need to act. Those first-party statements are more useful than a generic social post telling every holder to “upgrade coins.”

Why the operator has a real deadline

Node software validates blocks under encoded rules. If the network activates new rules and the local client does not know them, the node can reject the recognized chain or follow an incompatible chain. It may stop serving accurate data, miss validator duties or feed stale information to an application.

The operator therefore cares about client name, minimum compatible version, configuration, activation point and rollback or incident channel. Ethereum requires both execution and consensus clients for validators. Avalanche's Etna notice required AvalancheGo 1.12.0 or later. BNB Chain's Lorentz and Maxwell notices named mainnet node releases.

Why a developer may need testing without an emergency migration

An upgrade can add capabilities while preserving existing contracts. Developers may choose to adopt account abstraction, new cryptographic precompiles or cheaper data paths, but old user balances do not automatically move. Other changes can break assumptions: a shorter block interval affects time-based application logic, and a transaction gas cap affects unusually large deployments or multicalls.

The correct developer response is scope review and testing, not a universal redeploy. Identify the included proposal, locate any backward-compatibility warning and reproduce the application on the supported testnet.

The upgrade lifecycle: five dates that should not be merged

1. Proposal

A proposal describes a possible change. It may be an Ethereum Improvement Proposal, Cardano Improvement Proposal, Avalanche Community Proposal, BNB Evolution Proposal or governance action. Proposal status does not prove inclusion in the next mainnet upgrade. Scope can change through review.

Readers should not label a proposal date as a mainnet upgrade date. A roadmap item is even less definite when its exact specification and activation point remain under discussion.

2. Testnet activation

Testnet activation lets client teams, operators and application developers exercise the rules before mainnet. A successful testnet fork is evidence of progress, not evidence that mainnet has already changed. Testnets can reveal issues that delay or modify deployment.

When an exchange notice cites a testnet event, users should confirm whether the exchange is pausing a test environment or production transfers. The same upgrade name can appear multiple times because different testnets activate on different dates.

3. Mainnet-ready release

Client teams publish versions suitable for the mainnet fork. A network with multiple independent clients can list several compatible releases. Recommended versions may change after the original announcement if performance or stability fixes appear.

Operators should recheck near activation rather than saving the first version table indefinitely. The package must also come from the authentic repository or release channel. Fake upgrade software is a high-value route to validator keys and infrastructure.

4. Activation

Activation is the protocol boundary: a block height, epoch, slot or timestamp. Human-readable time is convenient but can be estimated when it depends on block production. The on-chain identifier is the precise reference.

A timeline should attach the upgrade to the mainnet and identifier. “Pectra on 7 May” is incomplete for an operator; the official notice identified Ethereum epoch 364032 and a UTC time. A holder normally only needs the service window communicated by their provider.

5. Post-activation confirmation

Activation is not the end of operations. Nodes must remain in consensus, blocks must finalize, indexers must catch up and exchanges must reconcile their wallets. A provider may keep transfers paused after the scheduled fork time while it observes stability.

“Upgrade complete” can mean the network activated successfully, while “deposits reopened” can occur later. Record both if user access matters.

Why exchanges pause deposits and withdrawals

An exchange deposit is not credited when a transaction is merely broadcast. The venue watches its node, detects the transaction and waits for its confirmation policy. A withdrawal moves the other direction: internal controls authorize an on-chain transaction through the venue's wallet infrastructure.

A hard fork changes the rules those nodes enforce. Pausing around activation limits the number of transfers caught between software versions or uncertain finality. The venue can upgrade nodes, verify the recognized chain, reconcile balances and then restore service.

Trading can remain open without contradicting the pause

A centralized exchange trade normally changes internal ledger balances. It does not produce an on-chain transaction for every matched order. Deposits and withdrawals depend on network connectivity; spot trading can continue inside the platform. The two statuses describe different systems.

This does not mean every product remains open. Staking, earn, margin or derivatives can have separate operational rules. Read the affected-services list rather than extending “trading unaffected” to the whole platform.

Reopening may not have a fixed time

Notices often say transfers will resume when the upgraded network is stable. That wording is more honest than a guaranteed reopening time because finality, node sync or chain participation can differ from the scheduled activation. The provider may publish a separate reopening notice or update its status page.

If funds are needed at a specific time, complete the transfer before the cutoff with enough margin for confirmations. Do not aim for the final minute. A transaction can be valid on-chain yet reach the exchange after its automated crediting system has paused.

An alternative network is not automatically a substitute

A token can exist on several networks. Choosing another withdrawal network changes the destination representation and contract. The receiving wallet or exchange must support the same network. A matching ticker is insufficient.

Only use an alternative route after verifying the network name, token contract, recipient support and bridge or redemption path. Upgrade urgency should not override basic transfer checks.

How to turn an upgrade notice into a usable record

Begin with the issuer. A protocol foundation or coordination team is authoritative for the mainnet activation and compatible network software. A wallet is authoritative for its own release. An exchange is authoritative for its deposit and withdrawal window. One source cannot reliably speak for every layer, so a complete record may need both the network announcement and the provider notice.

Copy the exact network name. “Ethereum upgrade” can refer to Ethereum mainnet, a public testnet or an Ethereum-compatible network implementing similar proposals on a different schedule. BNB Smart Chain's Pascal incorporated features related to Ethereum's Pectra work, but the networks did not share one activation. Matching feature names do not merge the chains.

Next, capture the activation identifier in its native form. Ethereum announcements use epochs and slots alongside UTC estimates. Cardano records epochs and protocol versions. Other networks can use block heights or timestamps. The native identifier protects the record when estimated clock time shifts slightly because block production is faster or slower than expected.

Then separate audience instructions. A strong notice often contains distinct sections for holders, non-staking nodes, validators, application developers and tooling teams. Preserve those headings in your notes. Quoting the operator's mandatory update as if it applied to a wallet holder manufactures unnecessary risk; quoting the holder's “no action” line to a validator can cause downtime or penalties.

Record the expected change without turning it into a guarantee. More blob capacity can create room for lower layer-2 data costs, but a specific rollup's fee also depends on its pricing and demand. A lower fee floor does not promise that every transaction reaches the floor. Shorter blocks improve responsiveness while placing tighter requirements on networking and time-sensitive applications.

Finally, add a post-activation row. Note whether the official network reports success, whether the provider reopened transfers and whether any warning remains. Do not silently replace the scheduled entry; keeping both shows what was planned and what actually happened. If the provider does not announce reopening, its current status page is the useful evidence.

Keep the record versioned. Upgrade pages can be edited when client recommendations change, and exchange notices can add revised suspension times. Save the review date and do not present an old version table as current operator guidance. Historical dates are stable; software recommendations are not. A screenshot without its capture date cannot safely carry a future operator decision. Recheck the live release page before acting.

For a high-consequence transfer, build a three-source check: the network's activation notice identifies the protocol boundary; your wallet or exchange status page identifies whether its service is ready; and a block explorer shows whether the recognized chain is progressing. Agreement between those records is stronger than a social post or copied countdown. If they disagree, pause the transfer and treat the newest primary operational notice as controlling for that provider. Record the URL, review time and relevant network because a multi-chain asset can be available on one route while another remains suspended.

Thirteen mainnet milestones and what they actually changed

Ethereum Dencun — 13 March 2024

Dencun introduced blob transactions through EIP-4844, giving rollups a dedicated temporary data mechanism and fee market. It also included changes across the execution and consensus layers. The Ethereum Foundation told ordinary ETH holders no action was required, while node operators and stakers had to update compatible clients.

The ordinary user's observable impact was more likely to arrive through lower layer-2 data costs than through a change to the ETH balance. Developers and rollup operators had much deeper implementation work. The same fork therefore belongs in both a holder timeline and an infrastructure timeline with different action fields.

Cardano Chang — 1 September 2024

Chang activated the Conway era and the first stage of Cardano's CIP-1694 on-chain governance. Cardano's official glossary records the mainnet date and explains that later upgrades extended the governance system.

Ada balances did not need a token conversion. Stake pool operators needed compatible software, and governance participants gained new processes. A future governance choice is not the same as a wallet migration.

Avalanche Etna — 16 December 2024

Etna changed the architecture and economics of Avalanche L1 networks, introduced dynamic P-Chain fees, standardized interchain message requests and reduced the C-Chain minimum base fee. The official notice required mainnet nodes to run AvalancheGo 1.12.0 or later before activation.

A basic AVAX holder did not need a new asset. Node operators had a compatibility deadline. Teams operating Avalanche L1s faced meaningful validation and economic changes, while C-Chain users could experience a lower fee floor under low demand.

Cardano Plomin — 29 January 2025

Plomin enabled the remaining CIP-1694 governance actions and completed Cardano's transition to full on-chain governance for the Conway era. Ada holders could participate directly or through delegated representatives. Official Cardano material notes that staking rewards continued, while withdrawal of rewards interacts with delegation choices.

This is a useful exception to “holders never act.” The asset did not require conversion, but a holder who wanted to exercise governance rights or manage reward withdrawal could have a decision. The action came from governance participation, not coin survival.

Arbitrum BoLD — February 2025

The Arbitrum DAO approved upgrading Arbitrum One and Nova to the BoLD dispute protocol. BoLD enabled permissionless validation for Arbitrum One and bounded the delay an adversary could impose in the challenge process. The upgrade concerned rollup validation contracts and operators more than ordinary wallet balances.

An ARB or ETH holder did not receive a new token because the dispute system changed. Validators and infrastructure teams gained a new participation path. Application users benefited from a stronger settlement design without a manual migration.

Avalanche Fortuna — 8 April 2025

Avalanche's official fee documentation records that Fortuna activated ACP-176 and reduced the C-Chain minimum base fee from 1 nAVAX to 1 wei. The live base fee still responds to demand; lowering a protocol floor does not guarantee every transaction will cost the minimum.

Wallet users did not need to convert AVAX. Fee estimators, developers and infrastructure providers needed to represent the updated fee environment correctly.

BNB Smart Chain Lorentz — 29 April 2025

Lorentz reduced the BSC block interval to 1.5 seconds under BEP-520. The mainnet notice named the activation time and required node operators to upgrade to the compatible release. Faster blocks increased the importance of validator communication and application timing assumptions.

Ordinary BNB holders had no token swap. Developers relying on a fixed number of blocks as a rough measure of elapsed time needed to revisit the assumption. Exchanges and indexers had to ensure their confirmation and monitoring systems behaved under the new interval.

Ethereum Pectra — 7 May 2025

Pectra combined execution- and consensus-layer changes. It introduced EIP-7702 account delegation capabilities, increased blob throughput and changed validator operations, including a higher maximum effective balance and execution-layer-triggerable exits.

The official announcement said ETH holders using exchanges or wallets did not need to act unless their provider instructed them. Node operators and stakers needed compatible clients. Wallet developers gained new account possibilities, but users should not sign arbitrary EIP-7702 authorizations marketed as mandatory coin upgrades.

BNB Smart Chain Maxwell — 30 June 2025

Maxwell reduced BSC's block interval again, from 1.5 seconds to 0.75 seconds, and added validator-network and block-fetching changes. BNB Chain's notice told operators to upgrade and developers to test time-sensitive logic and performance.

Faster block production can improve responsiveness without changing the unit balance in a BNB wallet. It can also change infrastructure load, reorganization behavior and MEV timing. The correct action depends on whether the user is holding, building or operating.

Ethereum Fusaka — 3 December 2025

Fusaka activated PeerDAS, increased the path for rollup blob capacity, raised the default L1 gas limit and added protocol features including secp256r1 support. Ethereum's current documentation records it as live on mainnet and again states that ETH requires no conversion.

Node operators needed both execution and consensus clients that supported Fusaka. Developers using extremely large single transactions needed to notice the per-transaction gas cap. Wallet builders gained a more efficient path for passkey-style cryptography.

Ethereum BPO1 — 9 December 2025

Fusaka introduced Blob Parameter Only forks so blob capacity could increase through defined configuration changes after the main named fork. BPO1 raised the blob target and maximum from the Fusaka activation level. The Fusaka-ready client releases already contained the schedule.

This event shows why an operator can prepare for several activation points with one software update. It also shows why a named upgrade is not always the last row in its deployment sequence.

Ethereum BPO2 — 7 January 2026

The second planned BPO step raised blob parameters again. For ordinary ETH holders, no asset action followed. Rollups, blob users, node operators and monitoring systems cared about data-capacity and fee behavior.

A timeline that records only “Fusaka, 3 December” misses the staged capacity ramp. A holder guide can compress those steps; an infrastructure tracker should not.

Cardano van Rossem — 18 July 2026

Cardano's official hard-fork timeline records the van Rossem intra-era upgrade at epoch 644 and protocol version 11.0. It introduced ledger-rule cleanup, VRF key uniqueness, Plutus performance improvements and new cryptographic built-ins.

The event did not create a second ADA or require a token swap. Stake pool operators needed compatible software, and developers could assess new Plutus and cryptographic capabilities. Ordinary holders could continue using supported wallets and services.

Holder decision guide: when is action actually justified?

No action: the common case

Wait when the asset is already credited, the provider says it supports the coordinated upgrade, and no transfer is needed during the window. Keep the verified notice and check service status before the next deposit or withdrawal.

Self-custody does not mean manually moving a coin through every fork. A wallet may need a software update, but the balance remains on the recognized chain. Install only from the wallet's established release channel.

Timing action: funds are needed during maintenance

Complete transfers early enough to satisfy network confirmations before the provider's cutoff. Use the notice's time zone. If the cutoff is expressed as a block height, the displayed time can be an estimate.

After activation, wait for the provider's reopening status. Repeatedly resubmitting a transaction does not make an exchange crediting system reopen faster and can complicate nonce or fee management.

Software action: you operate a wallet, node or validator

A wallet user should follow the wallet's compatibility notice. A node operator must follow the network's release table. A validator may need multiple client components, signer checks and monitoring. Do not substitute an exchange article for operator documentation.

Back up configuration and slashing-protection data as the client instructs, but never expose signing keys to an upgrade website. Verify release signatures or hashes where the project provides them.

Asset action: an explicit migration or redenomination

Act only when official terms name the asset change. Verify the new contract, ratio, eligible balances, deadline and whether the exchange handles conversion automatically. A project's website, exchange notice and contract record should agree.

If an exchange handles the migration, sending the token to an unknown “swap” contract can destroy eligibility or transfer value to a scammer. If self-custody action is required, test the authentic path with a small amount.

Governance action: participation rather than survival

An upgrade can enable governance without forcing holders to vote. Plomin illustrates that holder delegation can affect participation and reward-withdrawal mechanics while the ADA asset itself remains intact. Separate optional governance choice from mandatory asset maintenance.

Operator and developer checklist

1. Identify the exact mainnet. Testnet, layer 2, sidechain and mainnet activations have separate schedules.
2. Record the protocol identifier. Keep the block, epoch, slot or timestamp in addition to the human date.
3. Use the current client table. Recheck recommended versions near activation because stability releases can replace earlier recommendations.
4. Map every dependency. Execution client, consensus client, validator client, builder software, signer, RPC, indexer and monitoring may each need validation.
5. Test with production assumptions. Reproduce load, timing, gas, transaction size and external dependencies on the supported testnet.
6. Verify state and peers after activation. Confirm the node follows the recognized finalized chain and downstream systems are caught up.
7. Communicate user impact precisely. List the services paused, cutoff time, unaffected products and evidence required for reopening.
8. Keep an incident route ready. Know the official client, network and security channels before the fork begins.

Block time is not a clock

BNB Chain's Lorentz and Maxwell changes make this lesson concrete. If an application treats 100 blocks as a fixed number of minutes, halving the block interval changes its real-time behavior. Smart contracts and off-chain jobs should use the appropriate time source and explicitly analyze reorganization and finality assumptions.

Fee floors are not fee promises

Avalanche Etna and Fortuna reduced protocol fee floors, but fees still respond to network conditions and transaction characteristics. A wallet should estimate current fees rather than hard-code the new minimum as the normal price.

New account features need signing clarity

Ethereum Pectra and BNB Pascal introduced account-related capabilities derived from EIP-7702. Delegating account code can grant powerful behavior. Wallets must explain the authorization target and scope. Users should reject messages claiming every account must delegate to remain valid.

Capacity upgrades can shift downstream bottlenecks

Dencun, Pectra, Fusaka and the BPO steps expanded the data path used by rollups. More protocol capacity does not automatically make every RPC, indexer or application ready for the new load and transaction types. Infrastructure testing remains part of the upgrade.

Forked assets, fake migrations and the price story

Support does not promise a forked-coin distribution

An exchange saying it supports a hard fork normally means it will maintain compatible infrastructure for the recognized chain. Distribution requires explicit terms: snapshot, ratio, asset code, credit conditions and listing decision.

A viable minority chain also needs developers, nodes, block producers, wallets, explorers and markets. The existence of old software does not guarantee an economically usable asset.

Never enter a seed phrase to “upgrade” a normal coin

Upgrade periods generate fake wallet releases, airdrops and migration pages. A seed phrase gives complete control over the wallet; no ordinary network fork requires submitting it to a website. Hardware-wallet users should verify actions on the trusted display.

Search ads and replies beneath official posts are common attack surfaces. Reach the network documentation through a known domain or repository. Compare contract addresses character by character.

An upgrade is not a price rule

An upgrade can change capacity, fees, governance or developer capabilities. Market participants can value those changes differently and may anticipate them long before activation. The mainnet date does not create a rule that price must rise.

Operational pauses can temporarily affect transfers between venues, but trading inside exchanges can continue. A price move around an upgrade may reflect broader market conditions, positioning or unrelated news. Technical significance and short-term price direction are separate questions.

Questions readers ask about network upgrades

Do I need to move coins before a hard fork?

Usually not for a coordinated upgrade. Confirm the official holder guidance and provider notice. Move only for a real transfer need or explicit asset migration, not because the word hard fork sounds destructive.

Why does an exchange stop withdrawals but keep trading?

Withdrawals and deposits use the blockchain. Centralized trading usually updates the exchange's internal ledger. The venue can pause network connectivity while its internal market remains open.

When will deposits reopen?

Often after the venue confirms the upgraded network is stable and its wallet systems are synchronized. The fork time is not automatically the reopening time. Check the live status page or updated notice.

Does hard fork always mean a new token?

No. Most coordinated hard forks continue as one recognized network. A separate asset requires a persistent split and an explicit distribution or market decision.

Can I keep using an old wallet?

Only the wallet provider can state compatibility. The keys and address may remain valid while the application needs an update to build or display new transactions. Use the provider's authentic release channel.

What happens if a node operator does not upgrade?

The node can follow incompatible rules, lose peers, stop syncing the recognized chain or miss validator duties. The network notice specifies the compatible client versions and activation boundary.

Is the tracker a live schedule?

No. It is a verified historical dataset with a 23 August 2026 cutoff. It excludes proposals and unscheduled future roadmap items. Always use the network's current announcement for a future activation.

Open the network upgrade tracker to filter the historical milestones, or return to the announcement explainer for the shorter decision card.