Can a MetaMask account delegate (EIP-7702) to our own smart account contract?

Smart Accounts
1

  • Integration details: Web dapp. We’d like users to keep their existing MetaMask EOA and delegate it via EIP-7702 to our own audited smart account contract (one shared implementation, not a per-user account).

  • Describe problem/question:

    • We understand MetaMask currently delegates only to its own hardcoded delegator (0x63c0c19a282a1B52b07dD5a65b58948A07DAE32B).
      • 1. Is it possible for a MetaMask account to delegate to a different, custom smart account contract that we choose?
      • 2. If not today, is it planned — or is there a process to allow-list an audited third-party implementation?
      • 3. If it won’t be supported, what’s the recommended way to integrate a custom smart account contract with MetaMask?

  • Code snippets: N/A — this is a capability question, not a bug.

  • Exact error and logs: No runtime error. The blocker is a missing capability: no dapp-facing way to sign an EIP-7702 authorization to a custom contract..

  • Package details: Mention SDK version and related dependencies.

2

Short answer — confirmed: MetaMask does NOT let a user delegate (EIP‑7702) to an arbitrary third‑party smart account contract today. The built‑in delegation flow is tied to MetaMask’s own delegator and is not configurable by dapps.

  1. Can MetaMask delegate to a custom contract? — No. There’s no dapp-facing way to ask MetaMask to sign an EIP‑7702 authorization that targets a contract you choose.

  2. Allow‑listing / roadmap? — There is no public allowlist or documented plan to support third‑party delegator targets at this time. If you want, I can escalate and file a feature request with Product to evaluate adding support (would you like me to do that?).

  3. Recommended approach — Don’t rely on wallet‑internal delegation. Use MetaMask’s supported smart‑account tooling instead (Smart Accounts Kit / Account Abstraction patterns like ERC‑4337) or implement a per‑user on‑chain authorization flow where users sign approvals (EIP‑712/EIP‑191) that your shared smart account verifies. These approaches give the shared implementation + per‑user authorization you want and are supported by the Smart Accounts docs: https://docs.metamask.io/smart-accounts/ (and use the MetaMask SDK for connection).

Reasoning (brief): Wallets control signing UX and security boundaries, so delegation targets are restricted to protect users; that’s why a configurable EIP‑7702 target isn’t exposed.

If you want, I’ll escalate this to Product/Engineering for consideration or help you map your flow to Smart Accounts (tell me which you prefer). A human from Support/Product will follow up once you pick.

Note: This response was generated by an AI bot and may require further verification. The MetaMask Community Team has tracked this issue and will be responding as soon as possible.

Additionally, we would recommend you to join our monthly Office Hours to discuss this with our engineering team. MetaMask Developer Office Hours