~30 minutes, Yuriy + Claude, live in MetaMask. We validate the four wallet capabilities the onboarding & game-feel design depends on — and close the one open Solana inference from the chain research. Every session key we test must be scoped, time-boxed, and revocable (zero-trust).
Tracks: issue #7 · test T5Chain: Polygon Amoy (test rig live) · Base Sepolia added if two-chain ratifiedOutcome: PASS / PARTIAL / FAIL per capability, recorded on #7
The honest headline (verified, mid-2026): three of the four are solid and testable today — social-login self-custody, EIP-7702 batching, and the Solana account. The one soft spot is Test 3, session keys: ERC-7715 is still a draft standard, experimental in MetaMask, Early-Access ~June 2026 — expect PARTIAL, not a clean pass. The two design decisions to make now (not just record) are session keys behind an abstraction and Test 1's password-as-second-factor onboarding footgun.
Before we start
~5 min prep
Latest MetaMask browser extension installed and updated (Settings → About to confirm version; note it for the record).
A Google account you're willing to use for a throwaway test wallet — not a personal high-value one. Social login will derive a real wallet from it.
A password recorded in a password manager BEFORE you start. For social-login wallets the password is a required second recovery factor (Test 1) — losing it mid-session would strand the test wallet.
Polygon Amoy network params handy (already on the brief's inventory card): chainId 80002, RPC https://rpc-amoy.polygon.technology, currency POL.
Base Sepolia added as a second network (optional) — our second trial chain for #12, and on MetaMask's smart-account list, so a useful cross-check for Test 2.
The funded test wallet exists (0xF0C51CFC317eBa73Be4085C79F40f87706c15b5d, key in GCP) — we may send a little test POL to the new social-login wallet so it can pay gas.
A second empty browser profile or a note of your current MetaMask state, so the test wallet stays separate from anything real.
~10 min of test POL / test USDC on hand for the batching test (faucet links on the brief).
The four tests
what · why · steps · pass / fail
1
Social login → self-custodial wallet FUNNEL
Testing: does MetaMask's Google login produce a wallet the user actually controls (own keys), not a custodial account?
Why it matters: the whole onboarding funnel is "MetaMask + social login" for non-technical players. Zero-trust requires the player — not us, not a vendor — to hold the keys. If social login is custodial, the funnel violates the mandate and needs a different primary.
In a clean MetaMask, choose the social / Google login onboarding path (rather than "create with seed phrase").
Complete the Google sign-in. Note how many screens and how long — this is the real player experience.
Reveal the SRP: account selector → the three dots → Account details → Secret Recovery Phrase → answer the two self-custody prompts → enter password → Hold to reveal. Confirm a standard 12-word SRP appears (don't save it anywhere shared — it's a test wallet, but treat the reveal seriously).
State the recovery model for the record: recovery needs the Google account AND the password together; the full SRP only ever exists on-device after auth (MetaMask uses TOPRF + Shamir, so no complete key sits on their servers). The SRP is an independent, exportable backup.
The real finding, whatever the result: the password is a hard second recovery factor. Lose it — and the user hasn't backed up the SRP — and the wallet is unrecoverable even with the Google account. Onboarding must prompt social-login users to reveal + back up their SRP, and set expectations that the password is not throwaway. Record this as a required onboarding-copy item.
Pass
Google login yields a self-custodial wallet with a revealable SRP; recovery = Google + password, SRP as independent backup. Funnel is sound; player holds keys. (Docs support this outcome.)
Fail / partial
No SRP revealable / keys provably held by MetaMask → funnel is custodial, can't be the zero-trust primary; revisit onboarding (seed-phrase-primary + optional social convenience). Not expected — docs contradict it.
2
EIP-7702 atomic batching UX
Testing: can we bundle approve + purchase into ONE confirmation via EIP-7702 EOA-delegation, instead of two signatures per pack?
Why it matters: one signature per pack vs two is the gap between a smooth game and a clunky one. 7702 lets a plain EOA act like a smart account for a transaction, so approve + buy settle atomically. We need to know it's real in MetaMask today and on our candidate chains.
Confirm the account can operate as a smart account (Settings / account menu). MetaMask points the EOA at a MetaMask Delegator contract via a 7702 tx — the SRP stays the controlling key, and it's reversible (you can revert to a plain EOA). New accounts may be auto-enabled; otherwise the upgrade is offered when a dapp requests batching.
Switch to Polygon Amoy (80002). Both Amoy and Base Sepolia are on MetaMask's smart-account supported-network list (verified) — cross-check Base Sepolia too if time allows.
Use MetaMask's own 7702-Readiness test dapp (github.com/MetaMask/7702-Readiness) or our spike dapp. Trigger a batched action (under the hood: EIP-5792 wallet_sendCalls + 7702 delegation).
Observe the confirmation: the two calls should appear as one bundled confirmation / one signature, not two popups. Approve, and confirm the batch settled atomically (both calls in one tx, or both revert together).
Optionally have the dapp call wallet_getCapabilities and confirm atomic is supported for chain 80002.
Flag: the account-upgrade confirmation ("delegate your account to a contract") can look scary to a non-technical user — note the UX friction. Edge case: if a user already upgraded to a third-party smart account, MetaMask won't batch for it.
Pass
approve + purchase collapse to one user confirmation on at least one candidate chain → design the pack-buy as a single-signature batch.
Fail / partial
Batching unavailable on our chains → either accept two signatures, pre-approve a spending allowance once, or route through a 4337 smart account instead.
3
Session keys — sign once, play many ZERO-TRUST
Testing: can a player grant a short-lived, scope-limited permission so they sign ONCE per session then play with no popup — and revoke it at will?
Why it matters: a wallet popup on every play kills game feel; a broad standing approval violates zero-trust. The answer is a scoped, time-boxed, revocable session permission (ERC-7715 wallet_grantPermissions). We need to know what's production vs experimental.
Read this first — least mature of the four. ERC-7715 is still a DRAFT ERC (draft since May 2024, still draft April 2026). MetaMask exposes it only through experimental Delegation Toolkit actions, with an Early Access Program opening ~June 2026 — not general-availability, and it needs a dapp integration (possibly a Flask/experimental build), not a click any user can make in stock MetaMask. Do not expect a clean PASS. The honest goal is to characterize what's actually available today.
Ground truth first: Claude states aloud that ERC-7715 is draft + experimental, so we're recording maturity, not just yes/no.
Check the installed build: does stock MetaMask expose any connected-sites / permissions / sessions surface and advertise wallet_grantPermissions? If it needs Flask or an experimental flag, that's itself a material finding.
If we have a spike dapp wired to the Delegation Toolkit's experimental ERC-7715 actions: request a scoped, time-bounded permission (e.g. "spend up to X test-USDC" for N minutes) and observe what MetaMask presents.
Approve, then run one in-scope action with no fresh popup (the core "play without confirming each move" behavior).
Attempt an out-of-scope action (over cap, or a different contract) and confirm it's rejected — scope enforcement is the zero-trust half.
Revoke / expire: revoke (or wait out the box) and confirm later actions are blocked. Record which mechanism delivered any working behavior (ERC-7715 / 7702-delegated key / 4337 session key) and its maturity label.
Pass (realistically: PARTIAL)
A scoped, expiring, revocable session permission works — even via an experimental build. Given draft status, a "good" outcome is PARTIAL: works in the toolkit, not GA. Architect the game loop behind an abstraction so the moving standard can't break it.
Fail
Nothing scoped/revocable we can ship → do NOT fall back to a broad standing approval (forbidden). Session-key layer becomes a tracked build dependency; consider 4337 session keys / a relayer; escalate to the architecture session.
4
Solana account from the social-login wallet RESEARCH-CLOSER
Testing: does the same social-login wallet expose a usable Solana account (receive / hold)?
Why it matters: this closes the one open inference in the chain research (issue #12). A yes keeps Solana a real fallback / expansion target with the same wallet; a no raises Solana's migration cost. MetaMask has had native Solana support (SRP-derived) since mid-2025.
In the same social-login wallet, open the address dropdown under the account name → select Solana. Since v13.5 every MetaMask account carries one EVM + one Solana + one Bitcoin address, SRP-derived — this should apply to the social-login account because it produces a standard SRP.
Confirm a Solana address is present and displayed. This is the exact inference we're closing: that the social-login-derived SRP yields a working Solana account like a phrase-created wallet.
Receive test value: send a small amount of devnet/testnet SOL from a faucet and confirm the balance appears. Live uncertainty: docs confirm SOL/SPL + mainnet but did not confirm devnet/testnet — if only mainnet is surfaced, test receive with a trivial amount of real SOL instead, or mark the step "mainnet-only, untested on devnet."
Note the constraints for the record: Solana RPC is Infura-only (no custom RPC — itself a centralization point to weigh), no Ledger-Solana, and no raw Solana private-key import yet.
Pass
Social-login wallet exposes a working Solana account → Solana stays a same-wallet fallback / first expansion target. Inference closed positive.
Fail / partial
No usable Solana account from social login → Solana requires a separate wallet, raising migration + onboarding cost. Weight against Solana in #12.
Session outcome
fill in live, then paste into issue #7
Capability
Result
One-line finding
1 · Social login self-custody
TBD
—
2 · EIP-7702 batching
TBD
—
3 · Session keys
TBD
—
4 · Solana account
TBD
—
After the session: record MetaMask version + date, mark each row PASS / PARTIAL / FAIL with the one-line finding, and comment the table on issue #7. Any FAIL/PARTIAL becomes a design input, not a blocker — the onboarding & game-feel design adapts to what's real.