Impact of downgrading from Scale to Growth on no-modal v10 (custom wallet UI, no Wallet Services UI widgets needed)

Embedded Wallets (Web3Auth)
2

Hi 鍾敏 劉 — thanks for the detailed write-up. I checked our internal docs/knowledge base and here’s a concise, trust-but-verify summary for each question. I’ve flagged the items where I couldn’t find an explicit statement in docs and will loop in the product/billing folks to confirm.

  1. Initialization safety
  • What I found: The no-modal v10 SDK does not require walletServicesConfig to be present for basic init/use if you never call Wallet Services APIs. Omitting walletServicesConfig is the recommended pattern for headless/custom UI integrations.
  • Confidence: likely. Caveat: I couldn’t find an explicit statement about plan-enforced init failures on Growth — I’ll confirm with the team.
  1. Provider & signing
  • What I found: The EIP-1193 provider (web3auth.provider) is part of core SDK behavior. Methods like personal_sign, eth_sendTransaction, eth_signTypedData_v4, eth_chainId, eth_getBalance, eth_accounts, and wallet_switchEthereumChain are core wallet functions and are not routed through Wallet Services if you’re not using the wallet-services plugin.
  • Confidence: high for behavior; moderate for absolute guarantee across plan tiers.
  1. Transaction confirmation UX
  • What I found: The confirmation UI is provided by Wallet Services / embed UI. If you remove walletServicesConfig and don’t initialize/use wallet-services/wsEmbed, the SDK does not surface a built-in confirmation modal. In practice that means requests will behave like auto-approve from the SDK side and you must present your own confirmation UI in your custom wallet before calling provider methods.
  • Action: Implement your own confirmation flow for eth_sendTransaction / personal_sign.
  • Confidence: moderate-high; I’ll confirm there’s no hidden fallback confirmation modal on Growth.
  1. Custom JWT login (AUTH_CONNECTION.CUSTOM)
  • What I found: Custom JWT connections are a core product feature (server-side verification, custom connections) and are not typically plan-gated. Your existing connectTo(AUTH, { authConnection: CUSTOM, … }) flow should continue to work.
  • Confidence: moderate-high.
  1. WalletConnect v2 login
  • What I found: WalletConnect interoperability is supported in the Web SDK. Using WALLET_CONNECT_V2 to let external wallets log in is not typically gated by Wallet Services.
  • Confidence: moderate-high.
  1. Identity Token (web3auth.getIdentityToken())
  • What I found: getIdentityToken() / JWT issuance for backend verification is a core capability described in our docs. This should continue to work after downgrade.
  • Confidence: moderate-high.
  1. MAW (Monthly Active Wallet) counting
  • What I found: I could not find an unequivocal doc statement in the knowledge base about whether existing logged-in sessions are back-counted or only forward-counted when the plan changes. This is a billing/analytics detail — I will escalate to billing to confirm exact behaviour and whether any retroactive MAW reconciliation happens after plan change.
  • Action: I’ll ask billing to confirm and get back with definitive wording.
  1. Recommended cleanup pattern (no Wallet Services dependency)
  • Recommended minimal steps:
    • Remove walletServicesConfig from Web3AuthNoModal constructor.
    • Remove any calls to web3auth.getPlugin(‘wallet-services’) and any wsEmbed.* fallbacks.
    • Ensure you don’t import/initialize the wallet-services plugin/embedding code anywhere.
    • Implement all confirmation UI and UX in your custom wallet before calling provider.sign/send methods.
    • Run end-to-end tests (login, getIdentityToken, connectTo WALLET_CONNECT_V2, all provider RPCs, sign flows) on a staging project after changing dashboard plan.
  • Confidence: high — this is the supported pattern for headless/no-modal custom UI.

Next steps from my side

  • I’ll escalate two items for confirmation:
    1. Explicit plan gating or init failure risk if walletServicesConfig is omitted on Growth (Q1).
    2. Exact MAW counting semantics after downgrade (Q7).

If you want, I can open a ticket with Engineering/Billing with your exact config and link to this thread so we get formal confirmation. Otherwise, you can proceed with the planned code removals above and run staging tests — that’s the safest path.

If you want I can also prepare a short code diff showing the minimal edits to strip wallet-services references.

Summary: Based on our docs, you can remove walletServicesConfig and wallet-services usage and keep core provider, signing, custom JWT login, WalletConnect v2, and getIdentityToken. Implement your own confirmations. I’ll confirm the two outstanding plan/billing specifics and report back.

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