#multiversxplanshardforkrecovery
⚠️ MultiversX plans to restore the hard fork ⚠️
The network was operating normally. Then one rhythm exploitation was changed, forcing validators to stop and pushing developers to focus on a single question: how can the chain be restored without compromising its historical record?
MultiversX says that on September 19, an attacker exploited an issue in VM-level (virtual machine) atomicity, which led to invalid state changes and halted the network’s progress. The team confirms that the vulnerability was isolated and that a fix was prepared the same day.
The restoration plan now is to carry out a coordinated hard fork from a known “good” checkpoint. MultiversX says the procedure was reviewed in advance on Testnet and Devnet, with validator participation before the main restart.
My opinion: The interesting part isn’t just that a hard fork is coming. It’s how the network responds under pressure. The recovery process must balance speed with state safety, coordinate validators, and protect users.
Even before the “all is well” signal was issued, MultiversX advised users not to send transactions or rebroadcast them, and not to use EGLD or ESDT deposit/withdrawal routes via exchanges or bridges.
❓ Do you think that a transparent, coordinated hard-fork recovery can strengthen trust in MultiversX?
Please follow up
#MultiversX #EGLD #GrowWithSAC $EGLD $SAGA $FTT
#MultiversXPlansHardForkRecovery
⚠️ MultiversX plans to restore the hard fork ⚠️
The network was operating normally. Then one rhythm exploitation was changed, forcing validators to stop and pushing developers to focus on a single question: how can the chain be restored without compromising its historical record?
MultiversX says that on September 19, an attacker exploited an issue in VM-level (virtual machine) atomicity, which led to invalid state changes and halted the network’s progress. The team confirms that the vulnerability was isolated and that a fix was prepared the same day.
The restoration plan now is to carry out a coordinated hard fork from a known “good” checkpoint. MultiversX says the procedure was reviewed in advance on Testnet and Devnet, with validator participation before the main restart.
My opinion: The interesting part isn’t just that a hard fork is coming. It’s how the network responds under pressure. The recovery process must balance speed with state safety, coordinate validators, and protect users.
Even before the “all is well” signal was issued, MultiversX advised users not to send transactions or rebroadcast them, and not to use EGLD or ESDT deposit/withdrawal routes via exchanges or bridges.
❓ Do you think that a transparent, coordinated hard-fork recovery can strengthen trust in MultiversX?
Please follow up
#MultiversX #EGLD #GrowWithSAC $EGLD $SAGA $FTT
#MultiversXPlansHardForkRecovery
