Skip to content

fix(statics): dispatch EVM token creation by token kind - #9959

Closed
ralph-bitgo[bot] wants to merge 1 commit into
masterfrom
CECHO-2453-fix-hbarevm-token-dispatch
Closed

ralph-bitgo[bot] wants to merge 1 commit into
masterfrom
CECHO-2453-fix-hbarevm-token-dispatch

Conversation

@ralph-bitgo

@ralph-bitgo ralph-bitgo Bot commented Oct 13, 2026

Copy link
Copy Markdown

Description

@bitgo/statics createToken dispatched EVM token creation on the token's family, but the hbarevm family supports both ERC20 and ERC721 (SUPPORTS_ERC20 + SUPPORTS_ERC721 on its base coin), so its family name keyed both erc20ChainToNameMap and erc721ChainToNameMap. The switch matched the ERC20 case first while the ERC721 registration loop had already replaced the family's initializer with erc721Token, so ERC721 tokens were constructed with the ERC20 argument layout: features landed in the wrong parameter and the coin failed its required account-model feature check (MissingRequiredCoinFeatureError). The BitGo Admin CLI (bga) then logged Skipping malformed token and dropped erc721:hbarevmtoken and hbarevm:mclmongp — reported in CECHO-2453.

This change dispatches families covered by the ERC20/ERC721 chain maps on the token's kind (asset === UnderlyingAsset.ERC721) instead of the family, so each initializer receives its own argument layout, and removes the initializerMap overrides that made the overlapping family maps ambiguous. AMS tokens on hbarevm now create correctly for both kinds (EthLikeERC721Token / EthLikeERC20Token, with account-model) with no malformed-token warnings and no skips.

No dependency changes. Follow-up: bga (BitGo/bitgo-admin) picks this up via a @bitgo-beta/statics bump after this lands on master.

Issue Number

CECHO-2453 (Linear)

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to not work as expected)
  • This change requires a documentation update

How Has This Been Tested?

  • New regression test should create hbarevm ERC721 and ERC20 AMS tokens instead of skipping them as malformed in modules/statics/test/unit/coins.ts feeds fresh hbarevm-family AMS configs of both kinds through createTokenMapUsingTrimmedConfigDetails (the code path bga uses at startup) and asserts the tokens are created with the correct classes, contract addresses, and account-model feature, and that no Skipping malformed token warning is emitted. On the previous code the test fails with coin 'hbarevm:freshnft' is not defined (the token is skipped exactly as reported); with the fix it passes.
  • Full @bitgo/statics unit suite: 39,701 tests passing.
  • Smoke run against the built package mirroring the reported scenario (erc721:hbarevmtoken, hbarevm:mclmongp plus fresh AMS-only tokens of both kinds): all four tokens processed with account-model and zero malformed-token warnings; before the fix the same run emitted 3 Skipping malformed token warnings and dropped every token.
  • tsc --build for modules/statics passes and prettier --check is clean.

Checklist:

  • My code follows the style guidelines of this project
  • I have performed a self-review of my own code
  • My code compiles correctly for both Node and Browser environments (tsc --build for modules/statics passes; the change is pure TypeScript with no runtime-specific APIs)
  • I have commented my code, particularly in hard-to-understand areas
  • My commits follow Conventional Commits and I have properly described any BREAKING CHANGES
  • The ticket or github issue was included in the commit message as a reference
  • I have made corresponding changes to the documentation and on any new/updated functions and/or methods - jsdoc
  • I have added tests that prove my fix is effective or that my feature works
  • New and existing unit tests pass locally with my changes

Ticket: CECHO-2453

The hbarevm family supports both ERC20 and ERC721, so its family name
keyed both erc20ChainToNameMap and erc721ChainToNameMap inside
createToken. The switch matched the ERC20 case first while the ERC721
loop had already replaced the family's initializer with erc721Token,
so ERC721 tokens were constructed with the ERC20 argument layout:
`features` landed in the wrong parameter and the coin failed its
required account-model feature check. bga then logged "Skipping
malformed token" and dropped erc721:hbarevmtoken and hbarevm:mclmongp.

Dispatch map-covered families on the token's kind (asset === erc721)
instead of on the family so each initializer receives its own argument
layout, and drop the initializerMap overrides that made the family
maps ambiguous. AMS tokens on hbarevm now create correctly for both
kinds with no warnings.

Ticket: CECHO-2453
Session-Id: 5215fb23-4ab1-4f77-835c-d7bdddff05cf
Task-Id: 30c88a03-cff5-449c-9da3-5ad8a9e65771
@linear-code

linear-code Bot commented Oct 13, 2026

Copy link
Copy Markdown
Contributor

CECHO-2453

@github-actions

Copy link
Copy Markdown
Contributor

⚠️ Unit tests are failing on Node 26.x (Current release line, non-blocking). This is not an LTS version yet, so it does not block merge, but it signals an incompatibility to fix before Node 26.x becomes LTS.

View run

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.

2 participants