Description

When building the EIP-7702 authorization list for a Pay delegation transaction, the nonce was previously read from NonceLock.nextNonce — the value computed by the nonce tracker, which accounts for locally-pending transactions the Relay has no visibility into. This could produce a nonce ahead of the true on-chain state, causing the Relay to reject the authorization as invalid.

The fix reads NonceLock.nonceDetails.params.nextNetworkNonce instead — the raw eth_getTransactionCount result that the nonce tracker already fetches internally. This gives the committed on-chain nonce the Relay needs to verify the authorization signature, without introducing a separate provider call or adding a new Engine dependency.

Changelog

CHANGELOG entry: null

Related issues

Related to: #30798

Manual testing steps

Feature: EIP-7702 Pay delegation transaction

  Scenario: user submits a Pay transaction requiring EIP-7702 upgrade
    Given the account has not yet been delegated (not upgraded to EIP-7702)
    And the account has locally-pending transactions in the queue

    When user initiates a Pay transaction and confirms
    Then the authorization list is signed with the correct on-chain nonce
    And the transaction submits successfully via Relay

Screenshots/Recordings

Before

After

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

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.