[gator-permissions-controller] ERC-7715 grant fails on Robinhood Chain (4663): pinned @metamask/delegation-deployments 1.4.0 has no entry for the chain #10667

Summary

wallet_requestExecutionPermissions on Robinhood Chain (chain id 4663) shows the permission screen correctly, but fails when the user clicks Grant:

code -32603 | An internal error was received. | External signature requests cannot sign delegations for internal accounts.

The same request on Base (8453), from the same account and the same dapp, succeeds.

wallet_getSupportedExecutionPermissions lists 4663 for every permission type, so the wallet advertises a chain on which it cannot sign.

Environment

• MetaMask extension v13.48.0 (Chrome), software (imported) account, already upgraded to EIP7702StatelessDeleGator (0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B)
• Resolved in the extension's yarn.lock at tag v13.48.0: @metamask/gator-permissions-controller 4.2.2, @metamask/signature-controller 39.2.10, @metamask/gator-permissions-snap 2.4.0, @metamask/delegation-deployments 1.4.0
• The latest release, v13.50.0, resolves the same @metamask/gator-permissions-controller 4.2.2 and @metamask/delegation-deployments 1.4.0 in its yarn.lock.
• Dapp: @metamask/smart-accounts-kit 2.0.0, viem 2.57.2
• Origin: http://localhost:3000

Steps to reproduce

1. Switch MetaMask to Robinhood Chain (4663).
2. Call wallet_getSupportedExecutionPermissions. erc20-token-allowance lists chain 4663 with rule types expiry, redeemer, payee.
3. Call wallet_requestExecutionPermissions with:

await walletClient.requestExecutionPermissions([
  {
    chainId: 4663,
    from: account,
    to: "0xd9eeA7fA73e4Ed58FDe08cF543e370ECceB491Ed",
    expiry: now + 86400,
    redeemer: ["0xd9eeA7fA73e4Ed58FDe08cF543e370ECceB491Ed"],
    payee: ["0xd9eeA7fA73e4Ed58FDe08cF543e370ECceB491Ed"],
    permission: {
      type: "erc20-token-allowance",
      isAdjustmentAllowed: false,
      data: {
        tokenAddress: "0x5fc5360D0400a0Fd4f2af552ADD042D716F1d168", // USDG
        allowanceAmount: 1000000n,
        justification: "test",
      },
    },
  },
]);

4. The permission screen renders correctly (network "Robinhood Chain", token USDG, redeemers, payees).
5. Click Grant.

Expected

The permission is granted, as it is on Base with the same parameters (chain id 8453, USDC).

Actual

The request rejects with External signature requests cannot sign delegations for internal accounts.

Analysis

This is from reading the source, the published packages and the lock files. I did not capture the extension's internal logs, so the root cause is inferred, not observed. File paths are on core main; the published 4.2.2 and 39.2.10 builds contain the same logic.

1. The snap asks the extension to sign the Delegation typed data. SignatureController.#tryGetDecodedPermissionIfDelegation calls GatorPermissionsController:decodePermissionFromPermissionContextForOrigin. Any error there is caught and only logged (Failed to decode permission), and decodedPermission stays undefined (packages/signature-controller/src/SignatureController.ts).
2. With no decoded permission, validateDelegation treats the request as a raw delegation from an external origin for an internal account, and throws (packages/signature-controller/src/utils/validation.ts).
3. The decode fails because decodePermissionFromPermissionContextForOrigin looks up DELEGATOR_CONTRACTS['1.3.0'][chainId] from @metamask/delegation-deployments and throws Contracts not found for chainId: 4663 when the chain is missing (packages/gator-permissions-controller/src/GatorPermissionsController.ts, src/decodePermission/enforcerAddresses.ts).
4. @metamask/delegation-deployments 1.4.0 has no entry for 4663. Versions 2.0.0 and 2.1.0 do:

require("@metamask/delegation-deployments@1.4.0").DELEGATOR_CONTRACTS["1.3.0"][4663] // undefined
require("@metamask/delegation-deployments@2.0.0").DELEGATOR_CONTRACTS["1.3.0"][4663] // defined

5. @metamask/gator-permissions-controller depends on @metamask/delegation-deployments ^1.4.0 in every published version from 4.2.1 to 6.0.1, and on core main. The range ^1.4.0 cannot resolve to 2.x.

Why the merged extension change does not fix it

metamask-extension PR #46194 ("chore: Bump @metamask/delegation-deployments from ^1.3.0 to ^2.0.0", merged 2026-09-22, not yet in a release; its description says it brings the Robinhood chain deployments) bumps the extension's own direct dependency. The controller keeps its own copy. As of 2026-10-02, yarn.lock on release/13.51.0, release/13.52.0 and main has both:

"@metamask/delegation-deployments@npm:^1.4.0":
  version: 1.4.0
"@metamask/delegation-deployments@npm:^2.0.0":
  version: 2.0.0

"@metamask/gator-permissions-controller@npm:^4.2.1":
  version: 4.2.2
  dependencies:
    "@metamask/delegation-deployments": "npm:^1.4.0"

So the signature path in 13.51.0 and 13.52.0 still reads the 1.4.0 chain list. I have not run a 13.51.0 build to confirm the behaviour.

metamask-extension PR #46777 (open, "chore: Bump @metamask/delegation-deployments from ^2.0.0 to ^2.1.0") changes the same direct dependency only, so it has the same limit.

Other chains with the same gap

On v13.48.0, wallet_getSupportedExecutionPermissions returns 43 chain ids. I compared that list with DELEGATOR_CONTRACTS['1.3.0'] in each published version:

I tested only 4663. By the same code path, I expect the other chains in the 1.4.0 row to fail in the same way.

Suggested fix

• Bump @metamask/delegation-deployments to ^2.1.0 in @metamask/gator-permissions-controller, release it, and bump the controller in the extension. The Dependency Dashboard (Dependency Dashboard #10300) lists this update under "Pending Approval" ("update dependency @metamask/delegation-deployments to v2"); no PR exists for it yet.
• metamask-mobile main depends on the controller at ^5.0.1. Its yarn.lock resolves that to 5.0.2 with @metamask/delegation-deployments 1.4.0, so mobile needs the controller bump too.
• Optional: surface the decode error. The user-facing message says "External signature requests cannot sign delegations for internal accounts", which hides the real cause ("Contracts not found for chainId: 4663").
• Optional: derive the advertised chain list and the controller's decodable chain list from the same source, so wallet_getSupportedExecutionPermissions cannot list a chain that the extension cannot sign for. The table above shows that a version bump alone does not close the gap for 25, 338 and 6342.

Related

• [Bug]: Money account deposit quotes fail on Robinhood Chain (4663) — "No contracts found for version 1.3.0 chain 4663" metamask-mobile#35681 (closed): the same missing chain 4663 in @metamask/delegation-deployments 1.4.0, on a different code path (getDeleGatorEnvironment). The fix there bumped mobile's direct dependency (chore: Upgrade @metamask/delegation-deployments from ^1.0.0 to ^2.0.0 cp-8.10.0 metamask-mobile#35678). That does not change the controller's copy.
• Why are 712 delegation signatures disallowed in MM Core? #6125 and fix: validateDelegation should allow redelegation signing (non-root authority) #7917 report the same error message with a different cause.