fix(evmigration): preserve SuperNode history during migration

[mateeullahmalik]

Short version

This PR fixes the SuperNode ownership record during EVM account and validator migration.

For example, suppose Account A owned a SuperNode from height 100 and the ownership moved to Account B at height 500. The old migration code could rebuild the record with Account B in both history entries. The result looked as though Account B had owned the SuperNode since height 100.

After this change, the existing Account A entry is left unchanged and one Account B entry is added at the migration height.

This PR fixes that ownership-history bug. It does not yet move every other piece of chain state that may refer to the old account or validator address. The known gaps are listed below so this PR is not mistaken for a complete state-continuity fix.

What this PR changes

Account migration

If the old account owns a SuperNode, the migration now:

• loads the existing SuperNode record instead of constructing a replacement;
• changes the current SupernodeAccount to the new account;
• keeps the previous account history exactly as it was;
• appends one history entry for the new account at the current block height;
• updates the SuperNode account index without changing the validator-keyed primary key.

Validator migration

If the old validator has a SuperNode, the migration now:

• moves the existing SuperNode record from the old validator key to the new validator key;
• keeps the SuperNode lifecycle history;
• moves the latest SupernodeMetricsState to the new validator key;
• updates validator addresses stored in the SuperNode's embedded evidence;
• changes the SuperNode account only when the validator was using its own account as the SuperNode account;
• leaves an independently owned SuperNode account unchanged.

A validator migration can involve two different relationships at the same time: a SuperNode owned by the validator's account, and a SuperNode registered against the validator but owned by another account. The migration now validates and preserves both instead of assuming they are the same record.

Ownership checks

Before writing migration state, the code now:

• decodes account addresses and compares the underlying address bytes instead of comparing Bech32 text;
• checks both the primary SuperNode records and the account index;
• rejects stale, duplicate, malformed, or conflicting ownership;
• rejects migration when the destination account already owns a SuperNode.

This matters because two valid Bech32 strings can decode to the same account bytes. A string-only lookup is not enough to prove that the destination is unused.

What this PR does not fix

Everlight continuity when the validator address changes

Everlight stores per-SuperNode distribution state under the validator address:

• rdist/<validator> contains the EMA, previous raw usage, eligibility start height, and active-period count;
• rhist/<validator>/... contains payout history.

rdist/ IS migrated by this PR. BuildIdentityMigrationPlan re-keys it from the old to the new validator address, preserving smoothed_bytes, prev_raw_bytes, eligibility_start_height, and periods_active verbatim (x/supernode/v1/types/identity_migration_plan.go). Smoothing baseline and ramp-up therefore do not reset. This was corrected after review; an earlier revision of this description incorrectly listed rdist/ as unmigrated.

rhist/ is NOT migrated. Payout history remains split across the old and new validator addresses. PayoutHistoryPrefixForValidator is read only by query_get_payout_history.go, so the effect is confined to the payout-history query returning a partial series for a migrated validator. It does not feed eligibility or weight, so it has no effect on distribution amounts.

This gap applies when the validator address changes. An account-only SuperNode migration that leaves the validator address unchanged does not re-key these Everlight records.

LEP-6 and audit continuity when the SuperNode account changes

The audit module stores many records using the SuperNode account string. This includes epoch reports and their indexes, evidence subject indexes and epoch counts, frozen epoch participant sets, suspicion and reporter-reliability state, postponement markers and reasons, storage-truth fact indexes, heal operations, verifier votes, and recheck records.

PR #196 does not rewrite those records when SupernodeAccount changes. The new account may be the current owner in x/supernode while the supporting audit state still refers to the old account.

The highest-risk case is migration during an active audit epoch. The epoch anchor contains a frozen participant list. Replacing the old account in live SuperNode state does not automatically replace it in that frozen list, and blindly rewriting a frozen epoch would also change the meaning of an epoch already in progress. We need an explicit rule for whether migration is blocked, deferred, or carried across an epoch boundary before implementing this part.

This audit gap applies when the SuperNode account changes. If only the validator address changes and an independently owned SuperNode keeps the same account, its account-keyed audit identity does not change.

Existing damaged history

This PR prevents new ownership-history corruption. It does not repair records already changed by an earlier migration.

Other address-keyed state

Everlight and audit/LEP-6 are confirmed gaps, not necessarily the complete list. The remaining modules and secondary indexes still need a migration audit before we call the overall account/validator migration complete.

Why the migration rejects conflicts

Choosing an arbitrary record when ownership is ambiguous would make the result depend on corrupt or duplicate state. The safer result is to reject the transaction before the first write. The operator can inspect the conflicting records and correct the cause instead of committing a migration that overwrites another SuperNode owner.

State changes in this PR

On a successful account migration:

• the validator-keyed SuperNode primary key stays the same;
• the old SuperNode account index is removed;
• the destination account index is added;
• the existing SuperNode value is updated with the new current account and one new history entry.

On a successful validator migration:

• the old validator-keyed SuperNode primary key is removed;
• the preserved SuperNode record is written under the new validator key;
• the latest SuperNode metrics value is moved to the new validator key;
• the SuperNode account index is updated only if the account itself changes.

The existing EVM migration flow still handles auth, bank, staking, Cosmos SDK x/distribution, delegations, fee grants, and action references. This PR does not add writes to Everlight's rdist/ or rhist/ keys or to the x/audit store.

Transaction and replay behavior

• CheckTx: no new state writes. Existing message, proof, ante, and mempool checks still apply.
• DeliverTx: ownership and destination checks run before migration writes. Any later error rolls back with the Cosmos SDK transaction cache.
• BeginBlock / EndBlock: unchanged.
• Replay is deterministic. The code uses decoded address bytes and deterministic store iteration; it does not use time, network calls, randomness, files, or other off-chain input.

Migration and upgrade impact

• This change does not add a store schema version or a store migration.
• The v1.20.2 migration-only upgrade handler is in follow-up PR app: register v1.20.2 migration-only upgrade handler #198.
• Operator scripts and runbooks are in follow-up PR docs(ops): add fail-closed EVM migration runbooks #197.
• Additional work is still required for Everlight and audit/LEP-6 continuity before the migration can be described as complete for every module.

Risks

• The strict ownership check scans SuperNode primary records during migration. The scan is deterministic and gas-metered, but costs more than one index lookup.
• State that was previously tolerated despite a stale or conflicting account index will now cause the migration to fail. This is intentional; committing an ambiguous ownership change would be worse.
• The remaining Everlight and audit gaps can split state between old and new identities. Operators should not treat this PR alone as proof that all module state survives migration.
• Validator downtime and multisig coordination are still operational procedures. This PR does not make those external steps atomic.

Rollback

Before any migration transaction is committed, the code can be rolled back normally.

After a successful migration transaction, rolling back the binary does not reverse the committed state. Reversal would require an explicit corrective state transition or restoration from a pre-migration snapshot. For that reason, broad rollout should wait until the remaining module-continuity rules are either implemented or explicitly accepted.

How this was verified

The focused keeper and integration tests cover:

• preserving the existing account timeline and adding one migration-height entry;
• self-owned and independently owned SuperNode relationships;
• stale and conflicting indexes;
• destination ownership collisions, including alternate valid Bech32 encodings of the same address bytes;
• rollback on validation failure.

The full script suite and lint pass on the stacked source tree.

A historical devnet rehearsal also completed from the v1.12.0 lineage through v1.20.2 with:

• 5 SuperNodes registered using v2.5.3-testnet;
• 5 standalone SuperNode account migrations;
• 4 single-signature validator migrations;
• 1 two-of-three multisig validator migration;
• 10/10 migration records and 10/10 delegations verified;
• 5/5 validators bonded and none jailed;
• the core x/supernode records and account histories preserved;
• block production continuing after the final candidate rollout.

That rehearsal proves the ownership-record behavior fixed here. It did not pre-populate and verify every Everlight or audit/LEP-6 state family across migration, so those continuity gaps remain open.

Observability

Operators can verify migration results through the migration transaction, migration record, emitted events, validator and SuperNode queries, delegation queries, and node logs. This PR adds no new off-chain telemetry dependency.

Stack order

1. This PR: preserve and validate the core SuperNode ownership record
2. app: register v1.20.2 migration-only upgrade handler #198: add the v1.20.2 migration-only upgrade handler
3. docs(ops): add fail-closed EVM migration runbooks #197: add operator tooling and runbooks

[Copilot]

Pull request overview

This PR hardens x/evmigration’s SuperNode handling so account/validator migrations preserve SuperNode ownership history and fail closed on ambiguous or corrupt ownership state, aligning migration execution and estimation with the true ownership model in x/supernode.

Changes:

• Add strict SuperNode ownership resolution that scans both primary records and the account index using decoded address bytes, detecting duplicates/stale/malformed state.
• Rework account and validator migration flows to prevalidate SuperNode ownership against pristine state, preserve existing ownership history verbatim, and append a single migration-height entry when the effective owner changes.
• Update DI wiring and mocks/tests (unit + integration + devnet checks) to use the strict ownership path and cover failure/rollback scenarios.

Reviewed changes

Copilot reviewed 17 out of 18 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
x/supernode/v1/module/depinject.go	Exposes the concrete Supernode keeper via depinject for modules needing strict ownership behavior.
x/supernode/v1/keeper/supernode_raw.go	Implements strict ownership resolution by scanning primary + index and comparing decoded address bytes.
x/supernode/v1/keeper/supernode_raw_internal_test.go	Adds internal tests for strict scanning behavior, terminal iterator errors, and state immutability.
x/evmigration/types/expected_keepers.go	Extends the expected Supernode keeper interface to include strict ownership lookup.
x/evmigration/module/depinject.go	Switches Supernode dependency to the concrete keeper to access strict ownership APIs.
x/evmigration/mocks/expected_keepers_mock.go	Updates mocks to include StrictGetSuperNodeByAccount.
x/evmigration/keeper/query.go	Makes MigrationEstimate use strict ownership logic (and validator dual-dimension validation) for correct HasSupernode reporting.
x/evmigration/keeper/query_test.go	Updates/extends estimate tests to match strict ownership behavior and error propagation.
x/evmigration/keeper/msg_server_migrate_validator.go	Adds strict preflight validation for validator SuperNode dimensions before the first mutation, and uses validated plans during V5.
x/evmigration/keeper/msg_server_migrate_validator_test.go	Updates validator migration msg-server tests for strict preflight + validated SuperNode migration.
x/evmigration/keeper/msg_server_claim_legacy.go	Adds strict preflight ownership resolution + destination collision checks and passes validated SN data into migration.
x/evmigration/keeper/msg_server_claim_legacy_test.go	Updates claim tests to reflect strict preflight behavior and early rejection before mutation.
x/evmigration/keeper/migrate_validator.go	Implements validator SuperNode ownership validation plan + preserves history while re-keying validator-associated records and metrics.
x/evmigration/keeper/migrate_test.go	Updates migration unit tests to assert history preservation and alternate-encoding behavior.
x/evmigration/keeper/migrate_supernode.go	Refactors supernode migration into a “validated record” path and preserves prior history verbatim.
tests/scripts/devnet-makefile.bats	Ensures dry-run targets don’t recurse into real make during tests by overriding MAKE.
tests/integration/evmigration/supernode_ownership_execution_test.go	Adds integration coverage for fail-closed ownership validation and no-mutation guarantees on failure.
devnet/tests/evmigration/migrate_validators.go	Updates devnet verification to assert SuperNode history immutability (except for one appended migration entry).

Files not reviewed (1)

• x/evmigration/mocks/expected_keepers_mock.go: Generated file

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 57 out of 57 changed files in this pull request and generated no new comments.

Suppressed comments (4)

app/upgrades/v1_20_2_bringup_external_test.go:42

• newV1202Params claims to build “real keeper wiring”, but it sets ModuleManager to module.NewManager() and Configurator to a stub. That means the upgrade handlers’ RunMigrations path isn’t exercised here and these tests can pass even if the real upgrade would fail with the app’s ModuleManager/Configurator. Use the app’s real module wiring so the test meaningfully models a chain upgrade.

// newV1202Params builds the real keeper wiring a coordinated upgrade would have.
func newV1202Params(app *lumeraapp.App, chainID string) appParams.AppUpgradeParams {
	return appParams.AppUpgradeParams{
		ChainID:           chainID,
		Logger:            log.NewNopLogger(),
		ModuleManager:     module.NewManager(),
		Configurator:      module.NewConfigurator(nil, nil, nil),
		BankKeeper:        app.BankKeeper,

app/upgrades/v1_20_2_bringup_external_test.go:88

• This test passes an empty fromVM into the upgrade handler, but a real v1.12.0 chain’s fromVM contains versions for all existing (non‑EVM) modules. Using an empty map can mask bugs (e.g., InitGenesis re-runs) and doesn’t model the actual mainnet one-hop shape. Build fromVM from app.ModuleManager.GetVersionMap() and delete only the EVM + evmigration modules.

	// fromVM is EMPTY: mainnet carries no EVM module versions at 1.12.0.
	newVM, err := config.Handler(sdk.WrapSDKContext(ctx), upgradetypes.Plan{}, module.VersionMap{})
	require.NoError(t, err, "the mainnet 1.12.0 -> 1.20.2 one-hop must succeed")

tests/integration/evmtest/feeconfig.go:91

• MinCosmosGasPriceWithHeadroom is documented as safe to pass directly to --gas-prices, but it currently returns only the decimal (e.g. "0.0125") without the denom suffix. Cosmos CLI expects a full coin string like "0.0125ulume"; this helper should append the denom (or the comment/name should be adjusted).
  x/supernode/v1/types/identity_migration_plan.go:72
• PR description says Everlight continuity is not fixed and that neither rdist/<validator> nor rhist/<validator>/... are moved on validator address changes. This plan explicitly migrates rdist/ state via SNDistStateKey(...), so the PR description (and any related operator expectations) should be updated to reflect that only payout history (rhist/) remains unmigrated.