Skip to content

feat(v30): re-derive collection addresses with tokenization module name#76

Merged
trevormil merged 1 commit intomasterfrom
feat/v30-collection-addr-migration
Apr 20, 2026
Merged

feat(v30): re-derive collection addresses with tokenization module name#76
trevormil merged 1 commit intomasterfrom
feat/v30-collection-addr-migration

Conversation

@trevormil
Copy link
Copy Markdown
Collaborator

Summary

Re-opens #69 on a clean base — that PR's files-changed view got stuck at 208 files / 63k+ additions because 8 of its 9 commits had already landed on master directly, leaving GitHub's diff computation confused. Only the address-migration commit remained unmerged.

This PR is that one commit, cherry-picked onto current master. Three-dot diff: 1 file, +172 lines (x/tokenization/keeper/migrations.go).

What it does

Wires a catch-up migration into the v30 upgrade handler that was missed when x/badges was renamed to x/tokenization in v23. Every existing mainnet collection still stores a mintEscrowAddress / cosmosCoinBackedPath.address / cosmosCoinWrapperPath.address derived from module="badges", while today's msg handlers and downstream consumers derive with module="tokenization". The indexer consistency check surfaced this as 16-field drift across all 11 active mainnet collections.

For each collection the migration:

  1. Computes the legacy (badges) and new (tokenization) forms of mintEscrowAddress, cosmosCoinBackedPath.address, and every cosmosCoinWrapperPath.address.
  2. Moves any bank balances from old → new via bankKeeper.SendCoins (no-op if zero).
  3. Flips the reserved-protocol-address flag from old to new.
  4. Overwrites the stored address on the collection.

Idempotent: old == new is a no-op, so re-running or running on a post-rename chain does nothing. Derivation helpers are direct ports of msg_server_universal_update_collection.go with a pluggable module name.

Pairs with bitbadges-indexer#100, which mirrors the chain-augmented fields in the handler and has a one-shot v29-patch migration to re-sync DB state from chain after v30 lands.

Test plan

  • Unit test on migration with mixed old/new collections
  • Dry run against mainnet state export
  • Verify indexer consistency check passes after v30

🤖 Generated with Claude Code

…me (#74)

The x/badges module was renamed to x/tokenization in v23, but the migration
that re-derives collection addresses with the new module name — and moves
the corresponding bank balances — was never wired into any upgrade handler.
Every existing mainnet collection still stores a mintEscrowAddress /
cosmosCoinBackedPath.address / cosmosCoinWrapperPath.address derived from
module="badges", while today's msg handlers and every downstream consumer
derives with module="tokenization". The daily indexer consistency check
surfaced this as a 16-field-per-collection drift across all 11 active
collections on mainnet.

This adds migrateCollectionAddressesFromBadgesToTokenization and hooks it
into the existing MigrateCollections loop so v30 will:

  1. For each collection, compute the legacy (badges) and new (tokenization)
     forms of mintEscrowAddress + cosmosCoinBackedPath.address + every
     cosmosCoinWrapperPath.address.
  2. Move any bank balances from the old address to the new one via
     bankKeeper.SendCoins. No-op when balances are zero (common for fresh
     wrapper/backed paths that never held funds).
  3. Flip the reserved-protocol-address flag from the old address to the
     new one so downstream lookups don't treat stale module addresses as
     reserved.
  4. Overwrite the stored address on the collection so future queries return
     the tokenization-derived value.

All steps are skipped when old == new, so re-running the migration (or
running it on a chain that was created post-rename) is a no-op. Derivation
helpers are direct ports of the ones in msg_server_universal_update_collection.go
with a pluggable module name.

Pairs with bitbadges-indexer#100 which mirrors chain-augmented fields in
the handler + has a one-shot v29-patch migration to re-sync DB state from
chain; after v30 runs, that migration will pick up the new addresses.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@trevormil trevormil merged commit 227342c into master Apr 20, 2026
6 checks passed
@trevormil trevormil deleted the feat/v30-collection-addr-migration branch April 20, 2026 17:41
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant