Base Hard Fork on September 30: Binance Freezes Base Transfers an Hour Before Cobalt

The Base network receives a hard fork on Tuesday, September 30, 2026, at 18:00 UTC. It is called Cobalt, and for you as a holder it means one thing above all: deposits and withdrawals over Base will stand still for some time that evening. Binance has announced the freeze from 17:00 UTC, an hour before the switch. Trading continues; only transfers between the exchange and your own wallet pause. Your tokens do not disappear in the process, they are not swapped, and no second coin appears. If you want to move something over Base that evening, do it beforehand or wait until the next morning.

The real stumbling block lies elsewhere: the exchange resumes transfers without further announcement as soon as the network is running stably. There is no starting gun you could wait for — you have to look yourself. This article sets out what actually happens in a hard fork, why exchanges regularly cut the bridge at such moments, and what the date means for your balance, your holding period and your own node.

Base hard fork Cobalt: the timetable for Sepolia and mainnet

Cobalt is the Base hard fork that follows Beryl. Beryl was the June 2026 upgrade that brought the B20 token standard and the Reth V2 node software to the chain. Cobalt builds on it and was re-scoped in two rounds in September before its contents were settled.

Activation is not a loose plan but a fixed timestamp compiled into the node software. For the Sepolia testnet (chain ID 84532) the value there is 1790186400, which is September 23, 2026 at 18:00 UTC. For mainnet (chain ID 8453) it is 1790791200, that is September 30, 2026 at 18:00 UTC. Exactly seven days apart.

That sequence is why the mainnet date is more reliable than an announced date usually is: the testnet already went through the fork on September 23, and the maintenance window closed cleanly at 20:00 UTC. An upgrade that has cleared the testnet is rarely pulled at short notice. That is a difference from networks where an activation date is computed from an ongoing validator vote and can shift as soon as approval falls below a threshold.

What a hard fork is, and why it is not a new coin

A hard fork is a change to a blockchain's rules under which the new rules are no longer compatible with the old ones. Every node that wants to validate the network's blocks needs the new software for that. A node on an old version regards the new blocks as invalid and drops out of the network.

The opposite term is the soft fork: there the rules are merely tightened, old nodes still accept the new blocks, and the network stays on one line even without a complete update. A soft fork is backwards compatible, a hard fork is not.

From this incompatibility grew the misconception that a hard fork automatically produces a second coin. That happens only when a meaningful share of participants deliberately continues under the old rules — that is how Bitcoin Cash (BCH) emerged from Bitcoin in 2017. Such a chain split presupposes two camps that both want to carry on, each with miner or validator support and with exchanges that list the split-off chain.

None of that is visible at Cobalt. There is no competing version of the Base network, no group wanting to stay on the old software, and nothing you could "claim". It is a pure maintenance upgrade, of the kind Ethereum has carried out regularly for years. Anyone offering you a "fork airdrop" for a planned network upgrade, or asking you to connect your wallet to unlock tokens, is attempting fraud.

The Binance transfer freeze begins an hour before the fork

Binance has announced that it will support the Base upgrade and has set the freeze for September 30, 17:00 UTC — one hour ahead of the fork at 18:00 UTC.

Affected are deposits and withdrawals of tokens over the Base network. That is a network statement, not a token statement: the same coin you cannot withdraw over Base may under some circumstances still be moved over Ethereum or another supported chain — at different fees and with a different duration. If your exchange offers several networks for the same token, that is the way out on this particular evening.

How long the pause lasts, nobody commits to in advance. Experience from comparable upgrades ranges from about an hour to several hours, depending on how quickly the exchange's nodes follow the new chain and how many confirmations it waits for before release.

Trading continues, only deposits and withdrawals stand still

The point often gets swallowed in reports on network upgrades although it is the most important in practice: trading on the exchange is not affected by a network hard fork. Buying, selling and swapping run in the exchange's internal book without any transaction arising on the blockchain. So as long as your balance sits on the exchange, you can keep trading.

What stands still is only the way out and the way in: the withdrawal to your own wallet and the deposit from it. Precisely those two operations are real transactions on Base, and precisely those the exchange pauses until it is certain its nodes see the right chain.

From this follows simple scheduling. If all you want to do on Tuesday evening is watch, the fork does not concern you at all. If instead you want to bring a balance from the exchange into self-custody — onto a hardware wallet, say — then the afternoon is the right moment, not the evening. A transaction that starts at 16:55 UTC but would only be confirmed at 17:05 UTC can get stuck in the exchange's queue.

Network upgrade and deposits: why the bridge between exchange and chain is cut

An exchange is liable for every credit it books into a customer's account. A deposit is credited only once its own nodes see the transaction in a block and that block counts as sufficiently secured. In the minutes around a hard fork, precisely that foundation is uncertain.

Two things can happen. First, a reorganisation can occur: the network discards a short sequence of blocks and replaces it with another. A transaction that looked confirmed a moment ago is then no longer included. Had the exchange already credited it, the balance in the account would no longer be matched by a transaction on the chain. Second, an exchange node can simply be stuck on the old software: it then sees a chain the rest of the network no longer follows.

The pause is therefore not a sign of a problem but the opposite — it is the precaution. You find the same pattern at every larger network upgrade, whatever the chain. We have traced it among others at the BNB Chain and at MultiversX, and in the sharper variant at an emergency hard fork at Core DAO that came without the usual lead time. The sequence is the same every time: freeze shortly before the date, switch, observation, quiet resumption.

What Cobalt brings technically: B20 extensions and conditional transactions

Cobalt's scope covers four areas according to the network's technical documentation. For holders they are all unremarkable; for developers and node operators they are not.

• A series of additions to the B20 token standard, introduced with the preceding Beryl upgrade.
• Conditional transactions: transactions that only become valid once the state of the chain matches a previously defined condition. For you as a user that is invisible at first; it is a tool for applications meant to execute only under certain market conditions.
• A first step towards decoupling fork timestamps from the node software. Until now an activation date such as September 30 is hard-compiled — every future upgrade therefore forces a software update. If that value becomes dynamic, dates can be adjusted without every operator having to install a new version.
• A new registry for TEE prover signatures, in which attestation is verified directly on chain.

What deliberately does not appear on this list: any change to balances, to addresses or to the validity of existing tokens. A hard fork of this kind does not touch your holdings. Your address stays the same, your seed stays the same, and you need to change nothing in your wallet.

Balances in your own wallet: what happens to your tokens during the fork

If your tokens sit in a self-custodied wallet on Base, the least changes for you. The chain runs on, your balance stays at the same address, and transactions remain possible — apart from possibly brief interruptions around the moment of the switch, when individual nodes and RPC providers are still catching up.

There is one qualification nonetheless. Your wallet usually does not speak to a node of its own but through a provider's RPC endpoint. If that provider is stuck on the old software after the fork, you may see an outdated balance or a transaction that does not go through. That is a display error on the way to the chain, not a loss: your tokens sit on the chain, not in the app. If it happens, a look at a block explorer as a second source helps before you repeat anything.

What you should expressly not do in that situation: send the same transaction several times because it does not appear. In the period of increased throughput after an upgrade, a transaction can sit in the pool longer and then execute after all. Anyone who pushes another one through ends up with two transfers and two lots of fees paid.

Node operators need the minimum version, everyone else waits

Anyone running a Base node themselves is the only party with a real task before the date: the software must run on a version that knows Cobalt. A node on an older version regards the blocks after 18:00 UTC as invalid and is thereafter cut off from the valid chain.

Important here: the minimum versions for testnet and mainnet are not identical according to the technical documentation. Anyone running both networks should check the figures separately and not rely on a version that sufficed on Sepolia also being enough on mainnet.

For everybody else — and that is the great majority — there is no task. You need to update nothing, confirm nothing and sign nothing. Experience shows this is exactly where fraud attempts start: fake "upgrade portals" that demand a wallet connection for an announced fork, supposedly to make your tokens fit for migration. A genuine network switch never requires a signature from end users. How to check a provider before the first euro is set out in the comparison of crypto exchanges; Base itself is the Ethereum layer 2 developed by Coinbase, which explains its link to Ethereum — an overview of the ecosystem is in the piece on the tokens on Base.

Tax and holding period: a hard fork is not a sale

The question comes up at every network upgrade, and in the Cobalt case the answer is pleasingly short: a protocol upgrade without a chain split is not a disposal. You swap nothing, you receive nothing, your token stays the same. Your holding period under Section 23 of the German Income Tax Act therefore also runs on unbroken — the one-year period, after which a gain from the sale of privately held crypto assets remains tax-free in Germany, does not start again.

The case would be different only at a genuine split, where you receive a new token in addition to your existing one. The German Federal Ministry of Finance has addressed this in its circular on crypto assets; classifying such allocations is demanding in the individual case and belongs in the hands of a tax adviser. At Cobalt the question does not arise, because no new chain comes into being.

One practical note remains nonetheless. If on September 30 you withdraw your position from the exchange before the freeze, that transfer is not a sale either — a transfer between two of your own wallets triggers no tax. The operation should, however, be recorded in your documentation as a transfer and not as a disposal, otherwise software will later compute a gain for you that never existed.

The hard fork cluster: what Core DAO, MultiversX and the BNB Chain have shown

This Base date is the latest instance of a pattern that has repeated several times in 2026, and the cases differ in exactly one point: the lead time.

At the BNB Chain and at MultiversX the date was fixed weeks in advance, the exchanges announced the freeze, and the process was unspectacular. At Core DAO the hard fork came as an emergency measure — there holders had barely any time, and the transfer freeze caught many without warning. The Base case lies at the calm end of this series: announced, tested on the testnet, with a moment fixed to the minute.

The transferable lesson is less technical than organisational. Anyone leaving a balance permanently on an exchange depends on its schedule at every such date — and learns of the end of the freeze only when they look themselves. Anyone self-custodying is not affected by the freeze but carries the responsibility for their own access credentials. That is not a recommendation in either direction, but the trade-off that sits behind every one of these dates.

Base hard fork: how to proceed now

1. Check by Tuesday afternoon whether you need to move anything over Base that evening. If so, do it before 17:00 UTC, or switch to another network, provided your exchange offers the token there as well. Which venues support which networks is shown in the comparison of crypto exchanges.
2. Decide where your balance should sit after the date. Anyone repeatedly caught out by such freezes is holding more on the exchange than they actually want to. The alternative and its costs are in the comparison of hardware wallets.
3. Record your transfers cleanly in your documentation. A withdrawal to your own wallet is not a sale and must not appear as one. Tools that keep transfers and disposals apart are among the crypto tax tools.

And if you have nothing planned for Tuesday evening: then the right action is to do nothing. The fork runs without you, your balance stays where it is, and by Wednesday morning deposits and withdrawals are highly likely to have been open again for a while.

(As of September 28, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)

Sources: Binance announcement on the Base network upgrade and the technical overview of the Cobalt upgrade.