[mikesposito]

Explanation

When RpcDataSource emits metadata for a chain's native asset, it builds a stub from network controller state only: symbol and name both default to the network ticker, decimals is hardcoded to 18, and there is no image. Native asset metadata from the config registry (assets.native: symbol, name, decimals, imageUrl) is never consumed, so registry-only chains (or chains whose native asset data was updated in the registry) show wrong or blank native asset details and logos downstream.

#collectMetadataForBalances now calls ConfigRegistryController:getNetworkConfigByCaip2ChainId (an action the data source already calls for the multicall3 address, already in the messenger allowlist) and prefers the registry's assets.native symbol, name, decimals and image when emitting the native stub. It also re-emits when the registry provides an image for an existing native entry that has none, upgrading previously emitted stubs without clobbering richer entries (e.g. image/description added by AccountsAPI). The messenger action was already allowed and registered; consumers pick this up via a package version bump.

References

N/A

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
• I've introduced breaking changes in this PR and have prepared draft pull requests for clients and consumer packages to resolve them

[maxime-oe]

Nice one thanks.
Still makes me superstitious to change an existing - even suboptimal - behavior.
I will run that one locally on a couple of test networks before approving - especially Tempo for which there is no real native token but for which we need USD in some places and OUSD (prev. pathUSD) in others.