Release 697.0.0

[salimtb]

Explanation

extension PR: MetaMask/metamask-extension#38359
Mobile PR: MetaMask/metamask-mobile#23367

References

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

Releases 697.0.0, publishing @metamask/assets-controllers 92.0.0 and updating dependent packages (bridge/transaction-pay), plus a chain ID fix in bridge-controller.

• Release
  • Bump monorepo version to 697.0.0.
• Packages
  • @metamask/[email protected]
    • Changelog: optional JWT auth for multi‑chain accounts API; optional market data in searchTokens.
  • @metamask/bridge-controller
    • Dependency: bump @metamask/assets-controllers to ^92.0.0.
    • Fix: add missing MON and SEI to integer chain IDs.
  • @metamask/transaction-pay-controller
    • Dependencies: bump @metamask/assets-controllers to ^92.0.0, @metamask/bridge-controller to ^63.2.0, @metamask/bridge-status-controller to ^63.1.0, @metamask/transaction-controller to ^62.3.0.
• Dependencies
  • Update yarn.lock accordingly.

^{Written by Cursor Bugbot for commit d89e71d. This will update automatically on new commits. Configure here.}

[salimtb]

@metamaskbot publish-preview

[cryptodev-2s]

@salimtb do we need to release this package too ? I see CI working fine in your client updates maybe this is not needed ? Nothing would break if we don't upgrade TransactionPayController too ?

[salimtb]

@cryptodev-2s not sure we have to release it , since assets is not a peer dependency anymore

[Gudahtt]

@salimtb but won't this assets controllers update break older versions of the TransactionPayController, since they won't use the correct version of AuthenticationController:getBearerToken?

[matthewwalsh0]

The TransactionPayController doesn't do any remote requests through the asset controller, only reliant on state. So ideally no breaking changes needed.

[matthewwalsh0]

Can we consider this not breaking as the TransactionPayController is not reliant on any API requests and it should only validate that messenger action is included if called?

With this new dependency model, can we consider it on a per controller basis, rather than assuming every major is a breaking, is that not the key benefit?

[cryptodev-2s]

LGTM!

[matthewwalsh0]

Can we consider this not breaking as the TransactionPayController is not reliant on any API requests and it should only validate that messenger action is included if called?

With this new dependency model, can we consider it on a per controller basis, rather than assuming every major is a breaking, is that not the key benefit?

[matthewwalsh0]

Ideally no breaking change in TransactionPayController, but unblocking as going AFK.

[Gudahtt]

LGTM!