Waves rolls back mainnet to block 5,481,020

Waves said on November 9 that it had rolled its mainnet back to block 5,481,020 and made node version 1.6.5 mandatory. The release notice, posted at 09:02 UTC, directs operators to roll back their local mainnet nodes after upgrading. It also names the expected identifier for the block at height 5,481,021.

The two heights answer different questions. Block 5,481,020 is where the project says the network rolled back. Block 5,481,021 is one height later and gives operators a way to tell which history their node is following after that boundary. A node can report the new software version and advance beyond the rollback height while still needing a check against the block identifier. For a wallet, exchange or indexer, the next question is whether the transaction it recorded appears in the history it now reads.

Three checks for the Waves rollback

Software. Version 1.6.5 identifies the node software the project wants operators to run. The release is labeled for mainnet, testnet and stagenet. The rollback height in the notice specifically refers to mainnet. A service that operates more than one environment needs to keep the version check and the network check separate. The linked release commit identifies the version change. That commit page alone provides no basis for attributing the incident to a specific flaw or estimating its impact.

Chain. The release gives the expected identifier at height 5,481,021 as 79hmk7xT74PoZpa7G2DG68uhfNegEpu4eBT4mSfm4B9. Two blocks can occupy the same numbered position on competing histories. The block identifier is what makes the published check discriminating. If a node has yet to reach that height, its alignment is still undetermined by this check. If it has reached the height and returns another identifier there, it disagrees with the history described by the notice. A match establishes agreement at that checkpoint. It leaves the node's current sync position and later blocks to be checked separately.

Transaction. A payment service needs to find the relevant transaction in the history it trusts and apply its own confirmation and reconciliation rules. Matching the release checkpoint answers the first question about the chain. It cannot say whether a particular later transfer was included, how many confirmations a service now assigns it, or whether an exchange already credited it internally. Those are separate records with separate evidence.

What changes for a transfer recorded after the boundary

Consider a hypothetical Waves deposit that a service recorded at height 5,481,023 before it learned of the rollback. That height is three blocks above the rollback point and two above the published comparison block. Suppose the service later sees its node at 5,481,023 again. The matching height could make its old record look current, but the service still needs to establish whether the transaction is present on the history that followed the rollback.

There are several possible results. The transaction could appear on the aligned chain at the same height, it could appear at a different height, or it could be absent from the service's latest view. The first two outcomes allow the service to reconcile the saved record with a current observation. The third leaves the service with an unresolved deposit. A missing transaction on a lagging indexer is different from a transaction that is absent from a current chain view, and neither observation alone establishes how an exchange handled its internal balance.

The release's rollback settings specify that the local operation should leave the option to return rolled-back transactions to the node's unconfirmed pool disabled. That is a local recovery instruction. A transaction may be seen again if it is included in a block on the history the node follows. A customer-facing receipt that still shows the old block therefore needs to be checked against current transaction evidence before anyone relies on it or sends a replacement. The example describes how to reconcile an observation. CoinAbout did not trace a live deposit or submit a transaction for this report.

Why this differs from the previous release

The project's August 27 version 1.6.4 notes describe a feature vote for an adjustment to the block reward distribution. They say operators upgrading from 1.6.3 do not need to rebuild state. The November notice instead requires an explicit local rollback after the version change and publishes a block identifier for comparison. A service applying the same completion test it used for a routine upgrade could close its maintenance window as soon as the new binary comes online. That would leave the chain identity check unfinished.

Waves used a similar two-height check in its April 14 version 1.6.2 release. That notice described a testnet rollback to 4,047,001 and supplied the identifier of block 4,047,002 so operators could check their history after applying a testnet snapshot. In both notices the identity check is exactly one height beyond the rollback boundary. The April instructions concern a test environment and cite incompatibilities with version 1.6.1. The November instructions concern mainnet and specify a manual local rollback. The common structure helps explain the role of the next-block identifier while leaving the two events and their causes separate.

The distinction matters even where operators and customer-facing services work from the same infrastructure. A node can agree at the named height while a separate indexer still serves entries from an earlier view. A wallet can display a transaction saved in its local history while its provider is still syncing. An exchange can pause transfers while its ledger team checks customer credits after the node has aligned. In each case the software version, the chain view and the service's own accounting can become current at different times.

For a service reviewing its own records, the useful comparison is between the old transaction identifier and block association, and the same transaction's position in a current view of the aligned chain. If the service stores only the block height, its review has less evidence because that number can recur on a different history. For a customer, the equivalent distinction is between what a wallet or explorer shows on the network and what the receiving service says it credited. A service notice can clarify deposit or withdrawal availability for that platform. It cannot establish network-wide recovery.

What the published checkpoint can establish

The November 9 release note establishes the rollback boundary stated by Waves, the requested version, the sequence of the local recovery work, and the expected next block identifier. The difference between 5,481,020 and 5,481,021 is one. That describes the distance from the rollback point to the comparison block. It does not measure the depth of the rollback because the release does not say how high the prior history had reached. The notice also does not count affected transactions, quantify losses or report how many nodes had followed the instructions when it was posted.

A service that uses a reference endpoint might argue it can resume once that endpoint agrees with the published identifier. The match is evidence that the reference has the expected block at one height. For services with an independent indexer or balance ledger, the stronger test also checks that those systems are using the intended chain and that affected records have been reconciled against it. Dated operator reports, current observations from distinct nodes and transaction-specific evidence would help answer those questions. The release note on its own supports a narrower conclusion. Waves gave operators a specific block to compare after a mandatory update and mainnet rollback.