Release 1102.0.0 - #9421
Merged
Merged
Conversation
cloudonshore
temporarily deployed
to
default-branch
July 7, 2026 21:54 — with 
GitHub Actions
Inactive
GitHub Actions
Inactive
cloudonshore
temporarily deployed
to
default-branch
July 7, 2026 21:55 — with
GitHub Actions
Inactive
GitHub Actions
Inactive
|
✅ Changelogs updated and pushed. |
cryptodev-2s
approved these changes
Jul 7, 2026
pull Bot
pushed a commit
to dmrazzy/core
that referenced
this pull request
Jul 9, 2026
## Explanation <!-- Thanks for your contribution! Take a moment to answer these questions so that reviewers have the information they need to properly understand your changes: * What is the current state of things and why does it need to change? * What is the solution your changes offer and how does it work? * Are there any changes whose purpose might not obvious to those unfamiliar with the domain? * 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? * If you had to upgrade a dependency, why did you do so? --> ## [Asset Controller 10.2.0] ### Added - Add Robinhood Chain (`4663`/`0x1237`) in `MulticallClient` ([MetaMask#9443](MetaMask#9443)) ### Changed - `MulticallClient` memoizes `balanceOf` and `getEthBalance` call encodings per account address when building multicall batches, reducing redundant ABI encoding for wallets with many tokens ([MetaMask#9425](MetaMask#9425)) - Bump `@metamask/transaction-controller` from `^68.2.2` to `^68.3.0` ([MetaMask#9421](MetaMask#9421)) - Bump `@metamask/keyring-api` from `^23.3.0` to `^23.5.0` ([MetaMask#9390](MetaMask#9390)) - Bump `@metamask/keyring-snap-client` from `^9.0.2` to `^9.2.0` ([MetaMask#9390](MetaMask#9390)) - Bump `@metamask/account-tree-controller` from `^7.5.3` to `^7.5.4` ([MetaMask#9429](MetaMask#9429)) - Bump `@metamask/assets-controllers` from `^109.3.0` to `^109.3.1` ([MetaMask#9429](MetaMask#9429)) - Bump `@metamask/assets-controllers` from `^109.3.0` to `^109.4.0` ([MetaMask#9429](MetaMask#9429), [MetaMask#9450](MetaMask#9450)) ## [Assets-Controllers 109.4.0] ### Added - Add Robinhood Chain (`4663`/`0x1237`) entries in `multicall.ts` and `codefi-v2.ts` ([MetaMask#9443](MetaMask#9443)) ## References <!-- Are there any issues that this pull request is tied to? Are there other links that reviewers should consult to understand these changes better? Are there client or consumer pull requests to adopt any breaking changes? For example: * Fixes #12345 * Related to #67890 --> ## 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](https://github.com/MetaMask/core/tree/main/docs/processes/updating-changelogs.md) - [ ] I've introduced [breaking changes](https://github.com/MetaMask/core/tree/main/docs/processes/breaking-changes.md) in this PR and have prepared draft pull requests for clients and consumer packages to resolve them <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Low Risk** > Version and changelog/lockfile coordination only; functional changes are additive chain support and multicall encoding optimizations described in prior PRs. > > **Overview** > Cuts **monorepo release `1109.0.0`** by bumping published package versions and aligning dependent packages and `yarn.lock`. > > **`@metamask/assets-controller` `10.2.0`** documents Robinhood Chain (`4663`/`0x1237`) support in `MulticallClient`, memoized `balanceOf` / `getEthBalance` encodings in multicall batches, and several dependency bumps (including `@metamask/assets-controllers` to `^109.4.0`). > > **`@metamask/assets-controllers` `109.4.0`** documents Robinhood Chain entries in `multicall.ts` and `codefi-v2.ts`. > > **`bridge-controller`** and **`transaction-pay-controller`** update their `package.json` dependencies to `@metamask/assets-controller` `^10.2.0` and `@metamask/assets-controllers` `^109.4.0`, with matching changelog notes. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit c721375. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> --------- Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This was referenced Jul 13, 2026
Merged
pull Bot
pushed a commit
to Reality2byte/metamask-mobile
that referenced
this pull request
Jul 21, 2026
…ask#33175) ## **Description** Integrates the published core fix for stuck bridge smart transactions into mobile. Changes: - Bump `@metamask/smart-transactions-controller` `^24.2.2` → `25.0.0` - Bump `@metamask/transaction-controller` to `68.4.0` (dependency `^68.3.0` + resolution `68.4.0`) - Update the smart transactions controller messenger to delegate `TransactionController:failTransaction` instead of `TransactionController:updateTransaction` **Why:** When the relay cancelled a smart transaction, the STX controller previously called `updateTransaction`, which only patches state and does not emit transaction lifecycle events. Consumers that react to `transactionFailed`/`transactionStatusUpdated` (the bridge status controller and metrics) were never notified, so cancelled bridge smart transactions stayed **stuck pending indefinitely**. The core fix ([MetaMask/core#9400](MetaMask/core#9400)) adds a `failTransaction` action that fails the tx through the standard path and emits those events; this PR wires mobile's STX messenger to use it. **Note on versions:** `smart-transactions-controller` is pinned to `25.0.0` (and the `transaction-controller` resolution to `68.4.0`) to keep `transaction-controller` within `68.x`. `stx@25.0.1` requires `transaction-controller@^69.0.0`, a larger major bump out of scope for this fix. ## **Changelog** CHANGELOG entry: Fixed bridge smart transactions that could remain stuck as pending after being cancelled by the relay ## **Related issues** Refs: - [MetaMask/core#9400](MetaMask/core#9400) — fail cancelled smart transactions through the standard path - [MetaMask/core#9401](MetaMask/core#9401) — ignore saved gas fees for internal transactions - Released in [MetaMask/core#9421](MetaMask/core#9421) ## **Manual testing steps** 1. Build the branch and set up a wallet with a bridge route on a supported chain. 2. Initiate a bridge that is submitted as a smart transaction. 3. Observe a relay-side cancellation of the smart transaction. 4. Confirm the transaction transitions to **failed** in the activity list (instead of remaining pending) and the bridge status updates accordingly. ## **Screenshots/Recordings** N/A — dependency bump + messenger wiring (no UI changes). ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Mobile Coding Standards](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I've included tests if applicable - [x] I've documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I've applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-mobile/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Touches transaction lifecycle integration for smart transactions; incorrect wiring could affect how cancelled STX are surfaced, but scope is limited to messenger delegation and a controlled dependency bump. > > **Overview** > **Integrates the core fix for bridge smart transactions that stayed pending after relay cancellation.** > > Bumps `@metamask/smart-transactions-controller` from `^24.2.2` to `25.0.0` and updates the Smart Transactions controller messenger (and related test harnesses) to delegate **`TransactionController:failTransaction`** instead of **`TransactionController:updateTransaction`**. The upgraded STX controller uses the fail path when a relay cancels a smart transaction so **`transactionFailed` / `transactionStatusUpdated`** fire and bridge status and activity UI can leave the pending state. > > No app-layer transaction logic changes beyond messenger wiring and dependency lock updates. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 02840f1. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
pull Bot
pushed a commit
to Reality2byte/metamask-extension
that referenced
this pull request
Jul 21, 2026
…ask#44372) ## **Description** Integrates the published core fix for stuck bridge smart transactions into the extension. Changes: - Bump `@metamask/smart-transactions-controller` `^24.2.2` → `25.0.0` - Bump `@metamask/transaction-controller` `^68.2.2` → `^68.3.0` (resolves to `68.4.0`) - Update the smart transactions controller messenger to delegate `TransactionController:failTransaction` instead of `TransactionController:updateTransaction` **Why:** When the relay cancelled a smart transaction, the STX controller previously called `updateTransaction`, which only patches state and does not emit transaction lifecycle events. Consumers that react to `transactionFailed`/`transactionStatusUpdated` (the bridge status controller and metrics) were never notified, so cancelled bridge smart transactions stayed **stuck pending indefinitely**. The core fix ([MetaMask/core#9400](MetaMask/core#9400)) adds a `failTransaction` action that fails the tx through the standard path and emits those events; this PR wires the extension's STX messenger to use it. **Note on versions:** `smart-transactions-controller` is pinned to `25.0.0` (not a caret range) to keep `transaction-controller` within `68.x`. `stx@25.0.1` requires `transaction-controller@^69.0.0`, a larger major bump out of scope for this fix. ## **Changelog** CHANGELOG entry: Fixed bridge smart transactions that could remain stuck as pending after being cancelled by the relay ## **Related issues** Integrates the published core fix: - [MetaMask/core#9400](MetaMask/core#9400) — fail cancelled smart transactions through the standard path - [MetaMask/core#9401](MetaMask/core#9401) — ignore saved gas fees for internal transactions - Released in [MetaMask/core#9421](MetaMask/core#9421) ## **Manual testing steps** 1. Build the branch and set up a wallet with a bridge route on a supported chain. 2. Initiate a bridge that is submitted as a smart transaction. 3. Observe a relay-side cancellation of the smart transaction. 4. Confirm the transaction transitions to **failed** in the activity list (instead of remaining pending) and the bridge status updates accordingly. ## **Screenshots/Recordings** N/A — dependency bump + messenger wiring (no UI changes). ### **Before** Cancelled bridge smart transactions stayed pending indefinitely. ### **After** Cancelled bridge smart transactions transition to failed and notify the bridge status controller / metrics. ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Extension Coding Standards](https://github.com/MetaMask/metamask-extension/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I’ve included tests if applicable - [x] I’ve documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I’ve applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-extension/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Touches smart-transaction and transaction lifecycle integration; behavior change when relays cancel STXs, but scoped to messenger delegation and a targeted dependency bump. > > **Overview** > Integrates the core fix for **bridge smart transactions stuck pending** after relay cancellation by bumping `@metamask/smart-transactions-controller` to **25.0.0** (pinned) and aligning the lockfile. > > The extension wires the smart transactions controller messenger to delegate **`TransactionController:failTransaction`** instead of **`TransactionController:updateTransaction`**, in both production init and unit test setup, so cancelled STXs go through the standard failure path and emit **`transactionFailed`** / **`transactionStatusUpdated`** for bridge status and metrics. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 3985dc9. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
seaona
pushed a commit
to MetaMask/metamask-extension
that referenced
this pull request
Jul 22, 2026
## **Description** Integrates the published core fix for stuck bridge smart transactions into the extension. Changes: - Bump `@metamask/smart-transactions-controller` `^24.2.2` → `25.0.0` - Bump `@metamask/transaction-controller` `^68.2.2` → `^68.3.0` (resolves to `68.4.0`) - Update the smart transactions controller messenger to delegate `TransactionController:failTransaction` instead of `TransactionController:updateTransaction` **Why:** When the relay cancelled a smart transaction, the STX controller previously called `updateTransaction`, which only patches state and does not emit transaction lifecycle events. Consumers that react to `transactionFailed`/`transactionStatusUpdated` (the bridge status controller and metrics) were never notified, so cancelled bridge smart transactions stayed **stuck pending indefinitely**. The core fix ([MetaMask/core#9400](MetaMask/core#9400)) adds a `failTransaction` action that fails the tx through the standard path and emits those events; this PR wires the extension's STX messenger to use it. **Note on versions:** `smart-transactions-controller` is pinned to `25.0.0` (not a caret range) to keep `transaction-controller` within `68.x`. `stx@25.0.1` requires `transaction-controller@^69.0.0`, a larger major bump out of scope for this fix. ## **Changelog** CHANGELOG entry: Fixed bridge smart transactions that could remain stuck as pending after being cancelled by the relay ## **Related issues** Integrates the published core fix: - [MetaMask/core#9400](MetaMask/core#9400) — fail cancelled smart transactions through the standard path - [MetaMask/core#9401](MetaMask/core#9401) — ignore saved gas fees for internal transactions - Released in [MetaMask/core#9421](MetaMask/core#9421) ## **Manual testing steps** 1. Build the branch and set up a wallet with a bridge route on a supported chain. 2. Initiate a bridge that is submitted as a smart transaction. 3. Observe a relay-side cancellation of the smart transaction. 4. Confirm the transaction transitions to **failed** in the activity list (instead of remaining pending) and the bridge status updates accordingly. ## **Screenshots/Recordings** N/A — dependency bump + messenger wiring (no UI changes). ### **Before** Cancelled bridge smart transactions stayed pending indefinitely. ### **After** Cancelled bridge smart transactions transition to failed and notify the bridge status controller / metrics. ## **Pre-merge author checklist** - [x] I've followed [MetaMask Contributor Docs](https://github.com/MetaMask/contributor-docs) and [MetaMask Extension Coding Standards](https://github.com/MetaMask/metamask-extension/blob/main/.github/guidelines/CODING_GUIDELINES.md). - [x] I've completed the PR template to the best of my ability - [x] I’ve included tests if applicable - [x] I’ve documented my code using [JSDoc](https://jsdoc.app/) format if applicable - [x] I’ve applied the right labels on the PR (see [labeling guidelines](https://github.com/MetaMask/metamask-extension/blob/main/.github/guidelines/LABELING_GUIDELINES.md)). Not required for external contributors. ## **Pre-merge reviewer checklist** - [ ] I've manually tested the PR (e.g. pull and build branch, run the app, test code being changed). - [ ] I confirm that this PR addresses all acceptance criteria described in the ticket it closes and includes the necessary testing evidence such as recordings and or screenshots. <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Medium Risk** > Touches smart-transaction and transaction lifecycle integration; behavior change when relays cancel STXs, but scoped to messenger delegation and a targeted dependency bump. > > **Overview** > Integrates the core fix for **bridge smart transactions stuck pending** after relay cancellation by bumping `@metamask/smart-transactions-controller` to **25.0.0** (pinned) and aligning the lockfile. > > The extension wires the smart transactions controller messenger to delegate **`TransactionController:failTransaction`** instead of **`TransactionController:updateTransaction`**, in both production init and unit test setup, so cancelled STXs go through the standard failure path and emit **`transactionFailed`** / **`transactionStatusUpdated`** for bridge status and metrics. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 3985dc9. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Explanation
Releases two packages needed to fix stuck/underpriced bridge smart transactions in the clients (extension + mobile).
@metamask/transaction-controller—68.2.2→68.3.0(minor)failTransactionmethod +TransactionController:failTransactionmessenger action (#9400) — fails a tx through the standard path, emittingtransactionFailed/transactionStatusUpdated/transactionFinished.isInternal) txs such as swaps and bridges (#9401).@metamask/messenger^1.2.0→^2.0.0(#9392).@metamask/smart-transactions-controller—24.2.4→25.0.0(major)TransactionController:failTransactioninstead ofupdateTransactionwhen a smart transaction is cancelled (#9400). Consumers must now grant the STX messenger access toTransactionController:failTransaction.@metamask/messenger^1.2.0→^2.0.0(#9392).All other changed packages are
intentionally-skip(owned by other teams); dependent version ranges were updated automatically.References
Checklist
Uncategorized; breaking change marked)Note
Medium Risk
Touches transaction failure signaling and gas on internal bridge flows; STX 25.0.0 is a breaking messenger permission change for extension/mobile integrators.
Overview
Monorepo release
1102.0.0that publishes@metamask/transaction-controller68.3.0and@metamask/smart-transactions-controller25.0.0, and rolls@metamask/transaction-controller^68.2.2→^68.3.0through dependent packages andyarn.lock.transaction-controller68.3.0(documented in its changelog for this release): addsfailTransaction/TransactionController:failTransactionso out-of-band failures emit normal lifecycle events; fixes advanced gas fees so they apply only to dApp txs, notisInternalbridge/swap txs.smart-transactions-controller25.0.0(breaking): on smart-tx cancel, callsfailTransactioninstead ofupdateTransaction; hosts must delegateTransactionController:failTransactionon the STX messenger.Other touched packages in the diff are mainly version/changelog dependency bumps tied to this release, not new feature code in those files.
Reviewed by Cursor Bugbot for commit c423a08. Bugbot is set up for automated code reviews on this repo. Configure here.