Skip to content

Conversation

@salimtb
Copy link
Contributor

@salimtb salimtb commented Nov 2, 2025

Explanation

What is the current state of things and why does it need to change?

The TokenRatesController was using the single-chain /v1/spot-prices endpoint from the Codefi Price API, which required making separate API calls for each chain when fetching token prices across multiple networks. This approach was inefficient and created unnecessary network overhead, especially as MetaMask supports an increasing number of chains.

What is the solution your changes offer and how does it work?

This PR migrates the TokenRatesController to use the multichain /v3/spot-prices endpoint, which allows fetching token prices for multiple chains in a single API request. The key improvements include:

  1. Single API call efficiency: Instead of making individual requests per chain, we now batch all token requests across chains into one API call
  2. SLIP44 support for native tokens: Native tokens now use the proper CAIP asset ID format eip155:{chainId}/slip44:{coinType} (e.g., eip155:1/slip44:60 for ETH) instead of using zero addresses
  3. No fallback logic: The system now exclusively uses the v3 endpoint and fails fast if unavailable, ensuring consistent behavior

Are there any changes whose purpose might not obvious to those unfamiliar with the domain?

  • SLIP44 integration: Added @metamask/slip44 dependency to properly generate CAIP asset IDs for native tokens. SLIP44 defines standardized coin type numbers (e.g., 60 for ETH, 966 for MATIC) that the v3 API requires for native token identification.

  • CAIP asset ID parsing: Added helper functions to handle both ERC20 token format (eip155:1:0xA0b86a33E6441B6F3A82F1a2b1F1D7a8F2C8A3E8) and native token SLIP44 format (eip155:1/slip44:60) when processing API responses.

  • Interface extension: Made fetchMultichainTokenPrices a required method in AbstractTokenPricesService to ensure consistent multichain support across implementations.

If your primary goal was to update one package but you found you had to update another one along the way, why did you do so?

The primary changes were in assets-controllers, but I had to update multiple test files (TokenRatesController.test.ts, CurrencyRateController.test.ts, TokenSearchDiscoveryDataController.test.ts, assetsUtil.test.ts) to add mock implementations of the new fetchMultichainTokenPrices method, ensuring all tests continue to pass with the updated interface.

If you had to upgrade a dependency, why did you do so?

Added @metamask/slip44: ^4.3.0 as a local dependency to assets-controllers to access standardized SLIP44 coin type constants needed for generating proper CAIP asset IDs for native tokens as required by the v3 Price API.

References

  • Improves performance by reducing API calls from N (per chain) to 1 (multichain)
  • Aligns with CAIP standards for asset identification
  • Part of ongoing multichain architecture improvements

Checklist

  • I've updated the test suite for new or updated code as appropriate
  • I've updated documentation (JSDoc, Markdown, etc.) for new or updated code as appropriate
  • I've communicated my changes to consumers by updating changelogs for packages I've changed, highlighting breaking changes as necessary
  • I've prepared draft pull requests for clients and consumer packages to resolve any breaking changes

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