We are using @web3auth/no-modal v10.10.0 in production on the Scale plan and are planning to downgrade to the Growth plan due to internal cost optimization. Before we change the plan in the dashboard,
we would like to confirm exactly what will break and what will continue to work, so we can prepare the code changes in advance.
We do not use the built-in Web3Auth wallet UI. We have our own fully custom wallet UI (token list, send, receive, activity, network selector, settings).
We do not use @web3auth/wallet-services-plugin (we rely on the v10 built-in integration).
Authentication: custom JWT (AUTH_CONNECTION.CUSTOM) for X / Discord / LINE social logins, plus WALLET_CONNECTORS.WALLET_CONNECT_V2 for external wallets.
We use the EIP-1193 provider for: personal_sign, eth_sendTransaction, EIP-712 typed-data signing (EIP-2612 Permit, EIP-3009 TransferWithAuthorization), eth_chainId, eth_getBalance, eth_accounts, chain
switching, and SIWE.
What we currently use from Wallet Services
Only these three things:
walletServicesConfig passed into the Web3AuthNoModal constructor — we set confirmationStrategy: CONFIRMATION_STRATEGY.DEFAULT and whiteLabel.showWidgetButton: false.
web3auth.getPlugin(‘wallet-services’).showWalletConnectScanner({ show: true }) (with a fallback to (authConnector as any).wsEmbed.showWalletConnectScanner()).
web3auth.getPlugin(‘wallet-services’).showReceive({ show: true }) (with a fallback to wsEmbed.showReceive({ show: true })).
Reading/writing wsEmbed.confirmationStrategy to switch between ‘modal’, ‘auto-approve’, and ‘default’.
We are fully prepared to remove (1)–(4) from our codebase as part of the downgrade.
Questions
Initialization safety: After removing the walletServicesConfig block from the Web3AuthNoModal constructor, will web3auth.init() still complete successfully on the Growth plan? Or does v10 require
walletServicesConfig to be present even if Wallet Services UI methods are never called?
Provider & signing: On Growth, will the EIP-1193 provider returned by web3auth.provider continue to handle personal_sign, eth_sendTransaction, eth_signTypedData_v4, eth_chainId, eth_getBalance,
eth_accounts, and wallet_switchEthereumChain exactly as it does today on Scale? Are any of these silently routed through Wallet Services in v10?
Transaction confirmation UX: Today, with confirmationStrategy: ‘default’, an internal confirmation dialog is shown before signing. After downgrading to Growth (and with walletServicesConfig removed),
what is the expected confirmation UX for eth_sendTransaction and personal_sign?
Will signatures execute silently (no confirmation UI at all)?
Or is there still a built-in confirmation modal?
Is auto-approve mode effectively the only behavior available on Growth?
Custom JWT login: Our login flow uses connectTo(WALLET_CONNECTORS.AUTH, { authConnection: AUTH_CONNECTION.CUSTOM, authConnectionId, idToken, … }). Will this continue to work unchanged on Growth, or
is AUTH_CONNECTION.CUSTOM plan-gated?
WalletConnect v2 login: We also call connectTo(WALLET_CONNECTORS.WALLET_CONNECT_V2) to allow external wallets to log in. Is this connector gated by plan tier on Growth?
Identity Token: We call web3auth.getIdentityToken() after login to obtain a JWT for our backend. Does this continue to work on Growth?
MAW (Monthly Active Wallet) counting: After we downgrade, will existing logged-in users (whose sessions were created under the Scale plan) be re-counted, or is the count strictly forward-looking from
the date of the plan change?
Recommended cleanup: Is there an officially recommended pattern in v10 no-modal for projects that intentionally do not want any Wallet Services dependency (custom UI only)? For example, is there a
way to instruct the SDK at init time to disable all wallet-service code paths, so we don’t need to rely on getPlugin(‘wallet-services’) returning null?
Thank you very much — we want to make sure our migration is smooth and we don’t surprise our users.
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.
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.
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.
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.
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.
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.
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.
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.
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:
Explicit plan gating or init failure risk if walletServicesConfig is omitted on Growth (Q1).
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
thank you very much for the detailed answers, they were extremely helpful. Two of our original questions were left as “to be confirmed by Engineering / Billing.” We would appreciate definitive
answers on these two points before we execute the downgrade in production, since they affect both our deploy plan and our cost forecast.
Q1 follow-up — Init / runtime failure risk on Growth
Background: We will remove the walletServicesConfig block from the Web3AuthNoModal constructor and remove all getPlugin(‘wallet-services’) and wsEmbed.* calls from our codebase before the downgrade.
Please confirm:
Once walletServicesConfig is omitted entirely from the constructor, will web3auth.init() succeed on the Growth plan with no warnings, no errors, and no rejected promises related to plan gating?
Is there any other code path in @web3auth/no-modal v10.10.0 (e.g. event handlers like connected / rehydration_error, the AUTH connector’s internal initialization, connectTo(), or session restoration)
that lazily instantiates Wallet Services even when walletServicesConfig is not provided? If yes, will those code paths throw the “feature not available on growth plan” error on Growth?
Is there a flag (e.g. disableWalletServices: true, or similar) we should pass to be 100% explicit that Wallet Services should never be initialized? Or is “simply not passing walletServicesConfig” the
only and complete way to opt out?
Concretely, we need a yes/no answer to: “After removing walletServicesConfig and all wallet-services calls, will our init() and connectTo() flows be free of any plan-gated error on Growth?”
Q7 follow-up — MAW counting on downgrade
Background: We are currently on the Scale plan and have an existing user base of logged-in wallets. We will downgrade to the Growth plan, whose included MAW threshold is 3,000 (vs. 10,000 on Scale).
Please confirm:
Reset vs. continuation: When the plan is downgraded mid-billing-cycle, does the MAW counter for the new (Growth) period start from zero at the moment of plan change, or does it inherit/continue the
Scale-period count?
Re-counting of existing sessions: Users who logged in under Scale and whose sessions are still valid (we use sessionTime: 86400 * 30, i.e. 30 days) — when they make their first Web3Auth-touching
request after the plan change, are they:
(a) counted as a new MAW for the Growth plan, or
(b) treated as already-counted for the current period and not double-billed?
Overage billing: Once we exceed 3,000 MAW on Growth, the documented price is $0.03 per additional MAW. Is overage billed continuously per MAW as it crosses the threshold within the cycle, or only at
the end of the billing cycle? Is there any spending cap / hard limit we can configure?
Definition of MAW on downgrade: Is “MAW” measured as a unique wallet that performed at least one action (login, signature, or session restoration) in the calendar month, regardless of which plan was
active when that action occurred?
A concrete numeric example would help a lot. For instance: “If on day 15 of the month you have already had 5,000 unique active wallets on Scale, and you downgrade to Growth on day 16, then for days
16–end of month you are billed Growth’s overage rate from MAW #1 / from MAW #5,001 / not at all.” — which of these matches reality?
Thanks again. With these two confirmed, we can lock the rollout date and prepare engineering and finance accordingly.
For Q1 follow-up, in short, for V10 all configurations are set in your Web3Auth dashboard so you should change the configs there instead of changing in your code.
For Q7 follow-up about billing, we passed to our team and we will update you as soon as we can.
Thanks very much for the Q1 follow-up — that’s very helpful.
To make sure we’ve understood correctly before we execute the downgrade in production, here is our reading of your answer:
We do not need to pass walletServicesConfig in the SDK constructor — Wallet Services availability is governed by the Dashboard / plan tier, and the V10 SDK respects whatever the
Dashboard says at runtime.
We have already removed walletServicesConfig and all getPlugin(‘wallet-services’) / wsEmbed.* calls from our app code (we run a fully custom wallet UI on top of the EIP-1193
provider).
After downgrading the Dashboard plan from Scale to Growth, our Web3AuthNoModal.init() and connectTo(WALLET_CONNECTORS.AUTH, …) flows will not throw a plan-gated error, and
web3auth.provider plus getIdentityToken() will continue to work for our X / Discord / LINE custom-JWT logins and our WalletConnect v2 login.
Could you please confirm this reading is correct? A simple “yes, that matches” is enough — we just want to be sure before we flip the plan in production.
For Q7 (MAW counting on downgrade), no rush — we’ll wait for your billing team’s update. We’re prepared to delay the production plan change until that detail is confirmed, since
it affects our cost forecast for the first billing cycle.