MultiversX Supernova on September 10: The Hard Fork Checklist for EGLD Holders

On September 10, 2026, the MultiversX network switches over to the Supernova hard fork. For you as an EGLD holder, the most important answer is a reassuring one: if your coins sit in your own wallet, you have nothing to do. There is no token swap, no migration and no claim you would have to register. Addresses, private keys and balances remain backwards compatible according to the project. Anyone who prompts you to take action over the coming days is trying to defraud you.

There is still something to be done, and it concerns three places: balances on an exchange, staking, and running a node of your own. The hard fork halts the network for roughly 24 minutes, during which no new transactions are accepted. Anyone needing a withdrawal in that window is better off arranging it beforehand. If you intend to move your coins from the exchange into self-custody anyway, a network upgrade is a good occasion for it; which devices come into question is set out in our hardware wallet comparison.

This text answers the questions that have not been put in writing anywhere so far: when the fork really takes effect according to the round arithmetic, how far node migration has actually come today, why the staking unbonding period still takes ten days despite a tenfold increase in speed, and how to recognize the fraud pattern that accompanies dates like this one.

What exactly happens at MultiversX on September 10, 2026

Supernova is a hard fork. That is a protocol change all nodes in a network have to adopt at the same time, because the new rules are no longer compatible with the old ones. Anyone leaving the old software running computes differently from the majority from the switchover point on and drops out of the shared chain.

What Supernova changes is the core of block production. Until now MultiversX produces a block every six seconds. After the switch it is 600 milliseconds, a tenth of that. This becomes possible because the protocol takes transaction execution out of the critical path of consensus: validators vote on a block while execution continues in parallel, instead of waiting for it.

For you as a user this means in everyday terms: a transfer within the same shard is final in fractions of a second rather than in several seconds. The figures for the targeted finality within a shard range between 100 and 300 milliseconds depending on the source; for a transaction across shard boundaries the sources give roughly 1.8 to 2.4 seconds against around 18 seconds so far. That range appears this way in the documents and is not smoothed to a single value here.

Supernova explained: why block time drops from six seconds to 600 milliseconds

A shard is a self-contained section of the blockchain that processes its own transactions; MultiversX currently operates three of them plus a coordinating metachain. This very division has been the bottleneck so far: a payment from shard A to shard B needed three rounds, because the metachain first had to certify the sending shard's block before the receiving shard was allowed to accept it.

Supernova speeds up both sides of that calculation. The rounds get shorter, and the order changes: validators start executing a block as soon as the local check is through, and only vote afterwards. Final clearance across shard boundaries remains tied to the metachain, so that a cross-shard payment counts as arrived only once the block in the sending shard is demonstrably final.

The path to this point was no short-term decision. According to the project documentation, the change was adopted in an on-chain vote between January 8 and 18, 2026 and received 99.64 percent approval at a quorum of 33.63 percent of the voting stake. A public stress test ran between March 11 and 31, 2026, in which the network carried 120,000 transactions per second on the final day according to the project. An external security audit was completed in June 2026.

When does the hard fork actually switch? The activation round recalculated

The switchover hangs on a round rather than on a clock time. A round is the fixed cadence in which the network is allowed to produce a block. The mainnet configuration of August 31, 2026 gives round 32,157,661 in epoch 2233 as the activation point. An epoch is the cycle after which MultiversX redistributes validators across the shards; it lasts 24 hours.

That number can be translated into a clock time, and we did so ourselves instead of copying it. Querying the official mainnet gateway on September 6, 2026 at 00:36:48 UTC returns: current round 32,089,568, epoch 2228, round duration 6,000 milliseconds, 14,400 rounds per epoch, start of the current epoch at round 32,085,434.

From this it follows: 68,093 rounds are missing until the activation round. Multiplied by six seconds, that is 408,558 seconds or 113.5 hours. The switchover therefore falls on September 10, 2026 at around 18:06 UTC, so around 8:06 p.m. German time. By the same calculation, epoch 2233 begins at round 32,157,434 and thus at around 17:43 UTC; the activation round lies 227 rounds behind it. The statement "epoch 2233" from the reports therefore agrees with the chain data.

One qualification belongs with this: that is round arithmetic, not a commitment. If a round is missed because a block producer does not use its slot, the point in time moves back. In practice it is a matter of minutes to a few hours. What holds up is "around 6 p.m. UTC on September 10", not the second.

Roughly 24 minutes without new transactions: what the network halt means

The changeover does not run through during ongoing operation. Ahead of activation, the network stops accepting new transactions into the pool for roughly 240 rounds, in order to work through those already in flight. At the old cadence of six seconds per round, that is 24 minutes.

What happens to your transfer during that time matters more than the duration itself: nothing is lost in the process. Newly submitted transactions stay in the queue until Supernova processes them. What you do not get in that window is a fast confirmation. Anyone wanting to trigger a payment with a deadline at that moment, a margin call on a collateralized position for instance, should bring it forward.

EGLD in your own wallet: why self-custodians have nothing to do

This is the core point for most readers. MultiversX explicitly maintains backwards compatibility for addresses, keys and balances. Your seed phrase stays valid, your address stays the same, your balance stays where it is. There is no new token and no need to move anything.

What changes for you is something you will notice after the fork at most in that confirmations arrive faster. A wallet app that connects to the network picks up the new cadence by itself. A hardware wallet keeps signing the same transaction formats; it knows nothing of block time.

One duty of care remains: keep your wallet application up to date. Applications that derive time windows or fees from the old block time may show incorrect estimates after the switch. That is a display error and no risk of loss, but it is irritating.

No token swap, no claim: how to recognize the hard fork scam

Ahead of network changes of this kind, websites and direct messages regularly appear demanding a "token migration", a "snapshot" or a "wallet upgrade". With Supernova there is none of that. There is no swap, no claim and no registration.

Three features let you recognize such offers without needing technical background knowledge. First, no genuine protocol change ever asks for your seed phrase; whoever asks for it wants your money. Second, there is no deadline for holders, and so no reason for time pressure. Third, a project communicates through its official channels and not through a direct message that writes to you first.

This warning refers to no known incident around Supernova. The note stands here because the pattern recurs with every announced fork. How it looked at other chains is shown by our account of the Zilliqa hard fork and the ZIL migration, where, unlike here, a migration genuinely did take place, and by the look at the Mina hard fork with its network halt.

EGLD on an exchange: why you should check the withdrawal window beforehand

If your coins sit with a trading platform, you hold no key of your own and therefore have no decision of your own. During network changes, exchanges usually suspend deposits and withdrawals for a window while trading continues. That is routine and no warning sign.

The state of play we checked ourselves: on September 6, 2026 at around 00:40 UTC, the Binance announcement directories for listings, delistings and general news carried no notice on EGLD or Supernova. That does not mean none is coming. Experience says such notices appear one to three days before the date. It means you cannot rely today on knowing a withdrawal window.

A simple rule follows from this in practice: if you want to pull EGLD out over the coming days anyway, do it before September 10 and not on September 10. Anyone wanting to seize the occasion and change provider will find the terms in our crypto exchange comparison. How often such deadlines actually get tight is something we worked out in our count of the crypto deadlines and cut-off dates currently running.

Staking and delegation: the unbonding period stays at ten days

Delegation means assigning your EGLD to a staking provider, which uses them to secure the network and passes you a share of the rewards for it. If you want them back, you start an unbonding, and a fixed waiting time then runs before you can move the money.

This is where the biggest misunderstanding around this upgrade sits. A network that ticks ten times faster does not release balances ten times faster. The unbonding period stays at exactly ten days.

We looked this up in the network configuration itself as well, instead of assuming it. The configuration currently carries two values side by side: erd_unbond_period at 144,000 rounds and erd_unbond_period_supernova at 1,440,000 rounds. Convert both into time and both give the same value: 144,000 rounds at six seconds are 864,000 seconds, and 1,440,000 rounds at 0.6 seconds are likewise 864,000 seconds. In both cases that is ten full days. The numeric value multiplies by ten because the rounds get shorter; the waiting time behind it stays the same.

For you this means: an unbonding you start today ends at the same moment whether or not the fork falls in between. And an unbonding you start after September 10 takes just as long as before. If you are currently reviewing where your stake sits and what it brings in, our staking platform comparison helps with the sorting. The question was of a similar kind at the Solana upgrade, which we worked through in our text on Alpenglow and the consequences for staking.

84 percent instead of 4.6: how far node migration has really come today

Whether a hard fork runs smoothly is decided by how many nodes move to the new software in time. As of September 1, 2026, the finding was sobering: according to an evaluation of the public network data, 95.35 percent of 5,171 nodes were still running the old version v1.11.11.0 at that point. A good four percent had migrated.

We repeated this measurement on September 6, 2026 at 00:37 UTC, through the public endpoint api.multiversx.com/nodes/versions. The picture has turned around in five days:

• 83.02 percent of the nodes run on v2.0.6.0, another 1.24 percent on a version reported as v2.0.6. Together that is 84.26 percent.
• A further 13.6 percent still stand on the old v1.11.11.0.
• The remaining 2.14 percent are spread across older versions of the 1.11 series, down to v1.11.0.0.
• The total number of nodes stands at 5,176. In absolute figures that is roughly 4,361 updated nodes and roughly 704 nodes on the old main version.

This figure is the real leading indicator for September 10, and anyone can follow it up themselves: the endpoint is public and supplies share values per software version. Whoever wants to know whether the switchover is running in an orderly way takes another look there on the day before.

What happens if too few nodes migrate in time?

Before activation, old and new program versions can run alongside one another without anything happening. Only from the activation round onwards do the new processing rules take hold. A node with old software can then arrive at a deviating result for the same transaction and loses its connection to the majority chain.

For an individual operator that means downtime and forgone rewards. For the network it only becomes delicate once a large share is left behind, because block production is then spread across fewer shoulders. Going by today's level of roughly 84 percent updated nodes, nothing points to this scenario.

As an EGLD holder you need to derive nothing from it. There is no button you could press and no choice between two chains. The question is relevant for operators and for judging whether longer waiting times are to be expected in the switchover window.

Node operators: which software version is mandatory from round 32,157,661

If you run a validator or an observer node yourself, the fork means work. A version from v2.0.5.0 onwards is required; the chain currently reports v2.0.6.0 as the current marker. This value sits in the network configuration in the field erd_latest_tag_software_version and was set at the time of the query on September 6 at 00:36 UTC.

The migration itself is uncritical before the activation round, because both versions can exist side by side. After it, the migration is no longer optional. Whoever misses the date catches up afterwards and has to let the node resynchronize. A validator with a minimum stake of 2,500 EGLD should not let this situation come to it.

Smart contracts and dApps: why timestamps are no longer unique after Supernova

This point concerns you indirectly, but it is the most underestimated part of the whole upgrade. A smart contract is a program that sits on the blockchain and executes rules automatically, the interest on a deposit or the deadline of an offer for instance.

Many such programs compute with timestamps in seconds. As long as a block is created every six seconds, a second-level timestamp identifies exactly one block. After the switch, ten blocks fit into the same second, and the timestamp is no longer unique. The project documentation names the consequences openly and gives examples: checks along the lines of "the new point in time must be greater than the last one" can fail, limits of one action per block can be circumvented if they are measured in seconds, expiry deadlines become longer than intended, and reward calculations that use a time difference as a divisor can run into a division by zero.

For you as a user of a DeFi application on MultiversX this means: expect isolated display errors in the days after September 10, or applications that pause as a precaution. Affected are programs whose operators have not prepared for the change. A balance in your own wallet is untouched by it. If you have larger amounts sitting in an application from a small provider, a look at its announcements ahead of the date is the cheapest precaution there is.

What the hard fork is not: no deadline, no price statement

Three clarifications, so that no false expectation arises from this date.

It is no deadline for holders. Unlike a migration with an exchange window, nothing expires here. Whoever does nothing until September 10 has exactly the same coins afterwards as before.

It is no price statement. EGLD was quoted at $4.61 on September 6, 2026 at 00:34 UTC according to CoinGecko, or 3.97 euros, around three percent below the previous day and around 27 percent above the level of seven days earlier, at a market capitalization of about $141.5 million. These figures stand here as a snapshot and not as the basis for a forecast. Whether a technical upgrade shows up in a price cannot be stated seriously in advance.

It is no foregone conclusion. The switchover hangs on the migration of the nodes, and while that is going well, it is not yet complete as of September 6. The date can shift by minutes to hours, because it hangs on rounds and not on the clock.

The schedule up to September 10 at a glance

What sensibly happens in the remaining days, in the order in which it comes up:

1. Up to September 9: settle withdrawals from an exchange if you need them in these days. Keep an eye on your provider's announcements, because experience says they come at short notice.
2. On the morning of September 10: take another look at the version status of the nodes if you are interested in whether the switchover is running in an orderly way.
3. On September 10 at around 17:40 to 18:10 UTC: do not submit time-critical transactions. What you submit is not lost, but it will initially only be queued.
4. Afterwards: update your wallet application if it visibly misjudges deadlines or fees.

MultiversX Supernova: what you take away from this

1. Self-custody demands no action, but it does demand vigilance. There is no token swap and no claim. Every prompt to that effect is an attempted fraud, and the answer to it is always the same: no seed phrase, nowhere. If you take this occasion to move your coins from a provider into your own custody, you will find the devices in the hardware wallet comparison.
2. Check before September 10 whether you can reach your balance. Exchanges announce withdrawal pauses at short notice, and on September 6 no notice was in place yet. Whoever wants to switch or withdraw does it beforehand; the terms are in the exchange comparison.
3. Keep reckoning with ten days for staking. The faster chain does not shorten the unbonding period, even though the numeric value in the configuration now looks ten times larger. Where your stake sits and what it brings in is sorted out by the staking comparison.

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

Sources and evidence: the chain data come from the official network configuration of the MultiversX mainnet gateway; the activation round, the 24-minute window and the version status of September 1 come from the report by CryptoSlate of September 2, 2026.