feat: MetaMask Connect

[wenfix]

Summary

• Adds a new MetaMask Connect button backed by the published @metamask/connect-evm package.
• Registers the Connect EVM provider as an EIP-1193 provider with explicit supported networks and shared dapp metadata.
• Updates provider initialization and teardown so extension, EIP-6963, SDK Connect, WalletConnect, and MetaMask Connect flows can switch/disconnect without stale provider state.
• Aligns local Node requirements with the published package and updates webpack's process shim so the production bundle resolves Connect EVM's ESM dependencies.

Notable behavior

• The new button text is MetaMask Connect; the connected state is MetaMask Connect - Disconnect.
• net_version is optional. Providers that do not support it fall back to the decimal value derived from eth_chainId.
• Disconnecting an inactive provider no longer clears the currently active provider's accounts or connection state.
• WalletConnect provider subscriptions are registered once and guarded against duplicate state transitions.

Node version bump

@metamask/connect-evm@1.4.0 (and several of its transitive deps) declare engines.node: ">=20.19.0" and rely on Node 20.19+ runtime behavior. This PR mirrors that floor in package.json engines and .nvmrc, and drops Node 18.x from the build-lint-test CI matrix so CI only runs against a supported runtime.

Verification

• fnm exec --using=20.19.1 yarn lint
• fnm exec --using=20.19.1 yarn build

Build completed with warnings only:

• Existing MetaMask SDK optional dependency warning for @react-native-async-storage/async-storage
• Existing webpack asset/entrypoint size warnings

Manual testing still recommended

• Connect/disconnect with MetaMask Connect in a browser.
• Switch active providers between extension/window.ethereum, EIP-6963, SDK Connect, WalletConnect, and MetaMask Connect.
• Disconnect MetaMask Connect after switching away from it.
• WalletConnect modal reconnect/disconnect flow.

Notes for reviewers

• Socket Security flags @metamask/connect-evm and its transitive tree (network-access and obfuscated-code alerts, plus a protobufjs CVE). These require supply-chain triage via @SocketSecurity ignore ... comments rather than a code change.

---

Note

Medium Risk
Touches core provider switching/teardown used by all wallet flows; new third-party Connect EVM dependency tree adds supply-chain surface, though changes are localized to the test dapp.

Overview
Adds a MetaMask Connect flow using @metamask/connect-evm, with a new UI button, shared dapp-metadata, and registration of the Connect EVM EIP-1193 provider (supported networks + chain IDs).

Provider lifecycle is refactored so switching and disconnecting across extension, EIP-6963, SDK, WalletConnect, and Connect EVM does not leave stale state: teardown uses removeListener/off, clears contract/ethers context on close, only resets the UI when the active provider is removed, and treats any provider with request (not only isMetaMask) as usable. net_version is optional with fallback from eth_chainId; WalletConnect subscriptions are registered once with duplicate-transition guards.

Tooling: Node floor raised to ≥20.19.0 (.nvmrc, package.json engines, CI matrix drops 18.x); webpack process shim points at process/browser.js; Lavamoat allow-scripts entries for Connect EVM transitive deps; ESLint ecmaVersion: 2020 for src/**/*.js.

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

[socket-security]

Review the following changes in direct dependencies. Learn more about Socket for GitHub.

Diff	Package	Supply Chain Security	Vulnerability	Quality	Maintenance	License
	@​metamask/​connect-evm@​1.4.0

View full report

[socket-security]

All alerts resolved. Learn more about Socket for GitHub.

This PR previously contained dependency changes with security issues that have been resolved, removed, or ignored.

Ignoring alerts on:

• @metamask/analytics@0.6.0
• @metamask/connect-evm@1.4.0
• @metamask/connect-multichain@0.15.0
• @metamask/mobile-wallet-protocol-core@0.4.0
• @metamask/mobile-wallet-protocol-dapp-client@0.3.0
• @metamask/multichain-api-client@0.10.1
• @metamask/multichain-ui@0.4.1
• @protobufjs/aspromise@1.1.2
• @protobufjs/base64@1.1.2
• @protobufjs/codegen@2.0.5
• @protobufjs/eventemitter@1.1.1
• @protobufjs/fetch@1.1.1
• @protobufjs/float@1.0.2
• @protobufjs/inquire@1.1.2
• @protobufjs/path@1.1.2
• @protobufjs/pool@1.1.0
• @protobufjs/utf8@1.1.1
• @types/lodash@4.17.24
• centrifuge@5.6.0
• lodash@4.18.1
• long@5.3.2
• pako@2.1.0
• protobufjs@7.6.1
• qr-code-styling@1.9.2
• qrcode-generator@1.5.2
• ws@8.21.0
• @metamask/utils@11.11.0
• uuid@11.1.1
• @metamask/rpc-errors@7.0.3
• @types/node@25.9.1
• async-mutex@0.5.0
• eciesjs@0.4.17
• undici-types@7.24.6

View full report

[wenfix]

mm-connect requires node version >=20.19.0

[wenfix]

@SocketSecurity ignore-all

these are all introduced by @metamask/connect-evm, a package we own.

[adonesky1]

Seeing a strange first click between the SDKs gets to own the modal behavior:

Screen.Recording.2026-06-30.at.2.59.15.PM.mov

Claude's take:

both connect buttons end up showing the same modal because @metamask/sdk (via sdk-install-modal-web) and @metamask/connect-evm (via multichain-ui, which bundles its own copy of sdk-install-modal-web) are both Stencil bundles that register the same custom element tags — mm-install-modal, mm-pending-modal/mm-otp-modal, etc.

customElements is a single global registry and define() is first-wins. so whichever button you click first claims ; the second lib's Stencil bootstrap sees the tag's already defined, skips its own registration, and the browser just instantiates the first lib's component → you get the first modal again.

not a dapp wiring issue (the click handlers do point at the right clients) — it's a packaging collision between the two libs.

fix is upstream: the two modal bundles need namespaced/distinct tag names, or connect-evm + sdk should share one sdk-install-modal-web instead of each shipping their own. can't really fix it cleanly in the test-dapp while both are loaded on the same page.

That being said this isn't a real case. We wouldn't ever expect both SDKs to be installed in the same place. This is just for this test app.

[adonesky1]

Tiny nit in webpack.config.js: the ProvidePlugin was changed to process/browser.js (line 47), but resolve.fallback.process (line 12) still uses process/browser. If the .js suffix was needed for ESM resolution, the fallback should match for consistency.