Bug: Base Sepolia transactions refused for newly-created 7702 accounts, while wallet_getCapabilities reports the chain as supported

[tamez]

Describe the bug

Newly-created Base Accounts cannot send any transaction on Base Sepolia (84532). The keys.coinbase.com popup shows "This chain is not supported. Base Sepolia is not supported. Please try a different chain." and rejects the request with { code: 4001 }. Accounts created before the ERC-4337 to EIP-7702 provisioning change still transact on Base Sepolia normally, through the same popup, from the same app.

Steps

Reproduction

1. Create a new Base Account (any surface: base.app, or the popup's own email signup).
2. Connect from a dapp whose wagmi config lists baseSepolia.
3. Sign in with personal_sign. This succeeds.
4. Send any transaction on 84532 (eth_sendTransaction or wallet_sendCalls).
5. The popup renders the unsupported-chain screen and rejects.

A 20-line standalone harness reproduces it with no bundler. Happy to attach.

What works and what does not, for a new account on 84532

method	result
eth_requestAccounts, wallet_connect, wallet_switchEthereumChain	ok
personal_sign	ok
eth_sendTransaction	refused
wallet_sendCalls	refused
eth_signTypedData_v4	refused

Where the refusal comes from

In the popup bundle (keys.coinbase.com/static/main.<hash>.js), the unsupported-chain copy
(message ids Zhuq4r and 2leMnv) lives only inside the wallet-upgrade component, alongside
"We need to set up your wallet to transact on {chainName}. Scan the QR code with the Base app."
and a https://base.app/sync?targetChainId=… link. Its predicate is:

var j = dt.fromChainId(BigInt(c)),            // c = target chainId
    w = !(null != j && j.isTestnet || !f[c]); // f = supportedChainsToNetworkMap
if (!w) return /* "…is not supported. Please try a different chain." */

Base Sepolia is present in f (its displayName is what fills the error copy), so isTestnet
is the operative term. The screen is reached only via a hook that short-circuits when the account
has factoryAddress/factoryCalldata (ERC-4337) and otherwise checks
isDelegatedEOA(address, chainId) against the designator above.

So the refusal is not a chain-support decision. It is delegation provisioning refusing to run on
a testnet, surfaced with chain-support copy.

Two things that look inconsistent

1. For the very account it refuses, wallet_getCapabilities returns Base Sepolia as capable:

   "0x14a34": { "paymasterService": {"supported": true}, "atomicBatch": {"supported": true},
                "atomic": {"status": "supported"}, "auxiliaryFunds": {"supported": true},
                "dataSuffix": {"supported": true} }

   EIP-5792 says a wallet that does not support a requested chain "MUST NOT respond with an
   error, and MUST instead not include a key for the unsupported chain(s)." The wallet includes
   the key, and the one EIP-5792-defined capability present, atomic: { status: "supported" },
   is spec-defined to mean the wallet will execute the calls atomically. It then refuses them.
   A dapp doing capability-based feature detection has no way to know the chain is unusable.

2. CDP's EIP-7702 documentation states that testnet delegation on Base Sepolia is supported and
   simply unsponsored: "On testnets (Base Sepolia, Ethereum Sepolia), the delegation transaction
   requires ETH in the user's EOA. Use the CDP Faucet to fund accounts for testing." I understand
   that page describes CDP Wallets rather than Base Account, so this is not a direct
   contradiction. But it does suggest the obstacle is sponsorship, not chain support, and the
   popup never checks the account's balance before refusing.

Also worth noting

• preference: 'smartWalletOnly' no longer produces a 4337 account. Reading
  @coinbase/wallet-sdk@4.3.6, preference.options is only consulted at util/provider.js:37
  to choose the injected extension, and createSmartAccount.js getFactoryArgs() carries
  // TODO: support creating factory data and only echoes what the popup supplies. So there is
  no client-side way to opt into an account type that works on testnets.
• SDK version is not a factor: keys.coinbase.com/connect serves byte-identical HTML for
  sdkVersion=2.4.0 and 2.5.7, and the predicate reads neither sdkName nor sdkVersion.
• The bundle contains a feature flag named scw_native_delegation that selects between two
  upgrade-screen variants, which may be related.

Questions

1. Is refusing all testnets in the delegation-provisioning flow intended, or a gap?
2. Is there a timeline for enabling 7702 delegation provisioning on Base Sepolia?
3. In the meantime, is there any supported path for a dapp to develop and test against Base
   Sepolia with newly-created Base Accounts? If not, could wallet_getCapabilities omit chains
   the wallet will refuse, so dapps can detect this and degrade gracefully instead of walking
   users into a dead-end popup?

Expected behavior

7702 delegation provisioning on Base Sepolia

Version

• @base-org/account 2.4.0 and 2.5.7 (identical behavior) - @wagmi/connectors 6.2.0 (baseAccount connector), wagmi 2.19.5, viem 2.45.2 - Chains: [baseSepolia, base]; also reproduced with @coinbase/wallet-sdk 4.3.6 and preference: 'smartWalletOnly'

Additional info

No response

Desktop

iOS Chrome and Safari

Smartphone

No response

[osr21]

We hit a variant of this building the Smart Wallet Gas Sponsorship feature in BasePay on Base Mainnet (8453), which surfaces a related but distinct pattern.

Our setup: coinbaseWallet connector with preference: { options: "smartWalletOnly" as const } in wagmi v3, OnchainKit <Transaction> component, CDP Paymaster for gas sponsorship.

What we observed on Base Mainnet with newly-created EIP-7702 accounts:

Operation	Result
Connect + eth_requestAccounts	✅ works
personal_sign	✅ works
wallet_getCapabilities	✅ returns { "8453": { paymasterService: { supported: true }, ... } }
ERC-20 transfer via OnchainKit <Transaction> (with paymaster)	✅ works
ERC-20 transfer via OnchainKit <Transaction> (without paymaster)	⚠️ intermittent — spinner stalls then silent cancel

The silent cancel without paymaster matched the pattern described in coinbase-wallet-sdk #1423. The fix that unblocked us was always passing the paymasterService capability — even for users who have ETH — because the EIP-7702-provisioned smart wallet on Base Mainnet appears to expect UserOp submission path (through the Paymaster/Bundler) rather than a direct eth_sendTransaction.

This is related but not identical to the Base Sepolia issue reported here — on Mainnet the chain isn't rejected (code 4001 doesn't appear), but the transaction silently times out if submitted without paymaster context.

Hypothesis: Newly-created EIP-7702 accounts may have a deployment step triggered by the first Paymaster-sponsored UserOp. Without that first sponsored UserOp the account may not be fully initialized on-chain, causing the raw send path to stall (the transaction references a counterfactual address with no bytecode yet, so it's never mined).

If the team has a way to distinguish "needs first sponsored UserOp" from "fully initialized" accounts in wallet_getCapabilities output or a new method, that would let dApps handle this gracefully by always gating the first send behind paymaster even when the user has ETH.

Implementation for reference: docs/SMART_WALLET.md