Description

When a user links a Card to a Money Account, the approve transaction is submitted by Sentinel on the user's behalf via a delegation. For Sentinel to redeem that delegation without the Money Account itself signing (and therefore without needing native MON on the account), the Money Account must be EIP-7702-upgraded on the card token chain (Monad, 0x8f). Previously the linkage pre-flight would hard-fail with Money account is not 7702-upgraded on Monad whenever the account had not already been upgraded — most commonly for users who discover the Money Account directly through the Card dashboard CTAs and have never deposited mUSD before. The first revision of this PR attempted to fix that by triggering the Money Account upgrade via CHOMP from the Card controller and polling isAtomicBatchSupported until ready, but confirmed with CHOMP that the /v1/account-upgrade endpoint only stores the signed 7702 authorization and only redeems it lazily on the first mUSD deposit — so the poll could never succeed and the flow timed out at 60s.

This PR removes the explicit pre-flight entirely and relies on the existing Delegation7702PublishHook (app/util/transactions/hooks/delegation-7702-publish.ts:215) to bundle the 7702 authorization atomically with the same Sentinel relay submission that publishes the Card approve. When delegationAddress is undefined for the account on the target chain, the hook signs an EIP-7702 authorization via KeyringController:signEip7702Authorization, attaches it to the relay request as authorizationList, and Sentinel submits both legs as one transaction. The race the original pre-flight was designed to prevent does not actually exist — CHOMP checks on-chain code before redeeming its stored auth and skips it if the account was already deployed by a competing path.

Verified end-to-end on dev-api: linking with a Money Account whose eth_getCode returned 0x on Monad produced one Sentinel submission that confirmed in the usual sponsored-relay window. Post-link, eth_getCode on the account returned 0xef010063c0c19a282a1b52b07dd5a65b58948a07dae32b — the canonical EIP7702StatelessDeleGatorImpl for delegation framework 1.3.0 on chain 143. No 60s hang, no 409 retry, no separate upgrade step.

Key changes:

• CardController linkage pre-flight simplified — drops the TransactionController:isAtomicBatchSupported check and the Money account is not 7702-upgraded on Monad rejection. Only the Monad gas-sponsorship feature-flag gate remains. The publish hook now owns the 7702 upgrade as part of the same relay submission. Related messenger and type wiring (TransactionControllerIsAtomicBatchSupportedAction and the corresponding messenger delegation) are removed.
• useMoneyAccountCardLinkage cleanup — removes the is7702Ready gating from canSubmitDelegation so the CTA is enabled regardless of the account's current upgrade state. The useIsMoneyAccount7702Ready hook and its tests are deleted.
• The Money Account upgrade domain (app/actions/money/index.ts, MoneyAccountUpgradeController) is intentionally left untouched — Card linkage no longer depends on it.

Changelog

CHANGELOG entry: Enabled Card linkage on Money Accounts that have not yet been EIP-7702-upgraded — the upgrade now happens atomically with the linkage approve transaction, so users no longer need a separate upgrade step before linking.

Related issues

Fixes:

Manual testing steps

Feature: Card <> Money Account linkage with automatic EIP-7702 upgrade

  Background:
    Given the app is configured with MM_DEV_API_ENV=dev
    And Monad gas sponsorship is enabled for chain 0x8f

  Scenario: Linking a Card with a Money Account that is not yet 7702-upgraded
    Given I have a Money Account whose eth_getCode on Monad returns "0x"
    When I trigger Card linkage from the Card dashboard CTA
    Then exactly one Sentinel relay submission is created
    And the submission carries both a 7702 authorization for the Money Account and the Card approve
    And the relay confirms within the usual sponsored window (well under 60s)
    And eth_getCode on the Money Account on Monad now returns "0xef0100" followed by the EIP7702StatelessDeleGatorImpl address
    And the Money Account allowance to the Card delegation contract matches the requested amount

  Scenario: Linking a Card with a Money Account that is already 7702-upgraded
    Given I have a Money Account that is already EIP-7702-upgraded on Monad
    When I trigger Card linkage from the Card dashboard CTA
    Then the publish hook detects the existing delegation and does not sign a new authorization
    And the relay confirms the approve as before
    And the Card is linked successfully

  Scenario: Money deposit on an un-upgraded account is unaffected
    Given I have a Money Account whose eth_getCode on Monad returns "0x"
    When I initiate a deposit from the Money home screen
    Then the deposit succeeds via the existing MM Pay path
    And the account is upgraded as part of the deposit transaction

Screenshots/Recordings

Before

N/A

After

N/A

Pre-merge author checklist

• I've followed MetaMask Contributor Docs and MetaMask Mobile Coding Standards.
• I've completed the PR template to the best of my ability
• I've included tests if applicable
• I've documented my code using JSDoc format if applicable
• I've applied the right labels on the PR (see labeling guidelines). Not required for external contributors.

Performance checks (if applicable)

• I've tested on Android
  • Ideally on a mid-range device; emulator is acceptable
• I've tested with a power user scenario
  • Use these power-user SRPs to import wallets with many accounts and tokens
• I've instrumented key operations with Sentry traces for production performance metrics
  • See trace() for usage and addToken for an example

For performance guidelines and tooling, see the Performance Guide.

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.