feat: send the MetaMask auth token to built-in Infura endpoints

[basgys]

Explanation

Infura accepts the MetaMask auth token as Authorization: Bearer alongside the v3 project ID in the URL. This adds an optional getInfuraAuthToken option to NetworkController and wires it in @metamask/wallet to AuthenticationController:getBearerToken, gated on analytics opt-in.

new NetworkController({
  infuraProjectId,
  getInfuraAuthToken: async () =>
    messenger.call('AnalyticsController:getState').optedIn
      ? await messenger.call('AuthenticationController:getBearerToken')
      : undefined,
});

Built-in Infura endpoints only. The token goes on the primary endpoint of infura-type network clients, the ones built from infuraProjectId. Custom endpoints never carry it, even on an infura.io host: that is someone else's key. Failover endpoints never carry it: other providers. The gate is client type plus position in the chain, not URL matching, so rpcFailoverMode: 'forced' sends the token nowhere.

Read per request. A refreshed token is used on the next request. If the function returns undefined or throws, the request is made without the header. In the wallet that covers the locked state (getBearerToken throws until unlock) and clients that do not register AuthenticationController, such as wallet-cli.

Analytics opt-in only. The token identifies the user, which is only allowed for analytics opt-ins. The wallet returns it only while AnalyticsController state has optedIn: true, otherwise undefined. NetworkController stays policy-free: the option is the seam, and clients that construct the controller directly own the gate in their own getInfuraAuthToken.

Wallet wiring. AuthenticationController:getBearerToken is delegated to the network controller messenger, as it already is for ShieldApiService, ClaimsService, and SubscriptionService, and passed through getInfuraAuthToken. AnalyticsController:getState was already delegated. No new instance option. @metamask/profile-sync-controller is added as a dependency for the action type.

Not supported: Infura-issued JWTs. Same header, mutually exclusive. MetaMask clients use v3 keys and the UI has no JWT input.

Open question: the extension's FEATURED_RPCS networks (Linea, Base, ...) are RpcEndpointType.Custom with our project ID, so the type gate excludes them. Include them by also matching /v3/<infuraProjectId>, or keep the type gate?

References

None.

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

---

Note

Medium Risk
Changes outbound RPC auth on default Infura traffic and ties it to analytics opt-in and bearer retrieval; mis-gating could leak identifiers or break RPC when tokens fail.

Overview
Adds optional getInfuraAuthToken on NetworkController, threaded through auto-managed network clients into RPC fetch. A withInfuraAuthToken wrapper sets Authorization: Bearer … once per request; missing or failed token lookup still sends the RPC without the header.

The credential applies only to the primary endpoint of infura-type clients (built from infuraProjectId), not custom RPC URLs or failover endpoints—even on Infura hosts—so user keys are never paired with the MetaMask token.

@metamask/wallet wires the hook to AuthenticationController:getBearerToken when AnalyticsController reports optedIn, delegates that action on the network messenger, and adds @metamask/profile-sync-controller for the action type. Tests cover bearer behavior, per-request refresh, endpoint scoping, and wallet opt-in gating.

^{Reviewed by Cursor Bugbot for commit ef7260c. Bugbot is set up for automated code reviews on this repo. Configure here.}

[Gudahtt]

Thoughts on moving this inside of the NetworkController, rather than passing it in as a constructor parameter?

For context, our intention with the messenger is to use it for all communication between wallet components, reserving constructor parameters just for platform dependencies that haven't been migrated to a service yet. Eventually we hope to eliminate all (or nearly all) constructor parameters in favor of messenger actions/events.

Also, the messenger is meant to represent the full set of wallet capabilities that a particular component has. This strategy of extending the capabilities of the messenger just for initialization creates a misleading perception of the capabilities of the NetworkController (it will appear to not have the AuthenticationController:getBearerToken capability, but in reality it will), which is definitely not something we want.