The rwa/phase2-sdk-upgrade branch now boots and the four sim gates pass, but every gate starts from fresh genesis and validates zero migration behavior. The live mantle-1 chain (running the deployed v1.x binary, SDK v0.47-era) must upgrade in place, and that path has never been exercised.
What is unverified (grounded)
- The upgrade handler runs
RunMigrations for the v0.4x -> v0.50 module migrations; none of these run in the sim (fresh genesis skips migration). The legacy x/params key tables were registered so migrations do not panic on a missing table, but whether each module's actual stored params migrate cleanly from mainnet bytes is untested.
StoreUpgrades.Added was corrected to {crisis, consensus} by comparing against the deployed binary's store list from memory; this must be re-derived against an actual mainnet store export, not assumed.- Applied-plan name
v2.0.0 replaces the burnt v1-Yellow Spaceship (verified applied at height 7,135,001 via rest.assetmantle.one). Correct, but the height/skip wiring is only meaningful once tested against real state.
Proposed fix (no code decision needed to start)
Export current mantle-1 state, run an in-place-testnet upgrade rehearsal (halt at the upgrade height, swap binary, resume), and make that rehearsal a release gate. Derive StoreUpgrades.Added and any param migration from the rehearsal, not from inspection.
Fix-priority scorecard
| SEC |
UX |
AUTO |
YAGNI |
DELTA |
FIN |
| 75 |
30 |
25 |
60 |
20 |
43 |
SEC high (a botched live upgrade halts/corrupts a chain holding real value); AUTO low (needs mainnet export + human-judged rehearsal), so this is a human-decision item, not autonomous-fix.
The
rwa/phase2-sdk-upgradebranch now boots and the four sim gates pass, but every gate starts from fresh genesis and validates zero migration behavior. The livemantle-1chain (running the deployed v1.x binary, SDK v0.47-era) must upgrade in place, and that path has never been exercised.What is unverified (grounded)
RunMigrationsfor the v0.4x -> v0.50 module migrations; none of these run in the sim (fresh genesis skips migration). The legacyx/paramskey tables were registered so migrations do not panic on a missing table, but whether each module's actual stored params migrate cleanly from mainnet bytes is untested.StoreUpgrades.Addedwas corrected to{crisis, consensus}by comparing against the deployed binary's store list from memory; this must be re-derived against an actual mainnet store export, not assumed.v2.0.0replaces the burntv1-Yellow Spaceship(verified applied at height 7,135,001 viarest.assetmantle.one). Correct, but the height/skip wiring is only meaningful once tested against real state.Proposed fix (no code decision needed to start)
Export current
mantle-1state, run an in-place-testnet upgrade rehearsal (halt at the upgrade height, swap binary, resume), and make that rehearsal a release gate. DeriveStoreUpgrades.Addedand any param migration from the rehearsal, not from inspection.Fix-priority scorecard
SEC high (a botched live upgrade halts/corrupts a chain holding real value); AUTO low (needs mainnet export + human-judged rehearsal), so this is a human-decision item, not autonomous-fix.