I’m locked out of a seedless wallet created via Sign in with Apple, and I believe I’ve hit a rate-limiter bug rather than a forgotten password. Support ticket #127213997 (opened Aug-23) has had no technical reply in 12 days.
The sequence. I signed into this wallet without any problem for months. I then deleted the app. From the reinstall onward, every single attempt has returned the lockout. I never changed the password between the last working sign-in and the first failure.
What happens: every unlock attempt returns “Too many attempts. Try again in 23:59:xx”. The password is never evaluated — unlockPageIncorrectPassword has never once been returned, only the too-many-attempts path. The nodes reject before the password is checked.
Why I think guessCount never decays: I ran a controlled test. I waited 2 days with zero attempts, then 3 days, then ~4 days. The first attempt after each wait immediately returned a fresh 24:00:00 lock. The window can never expire, so the lockout is permanent by construction.
Client state (extension 13.44.0.0, Chrome, macOS), read out of the extension’s LevelDB:
All 5 nodeAuthTokens + metadataAccessToken issued 2026-08-01, expired 2026-08-02
So the “Welcome back” screen here is not a local unlock — it’s step 2 of a social import, i.e. the rate-limited network recovery call. There is no local vault on this machine to decrypt, which is consistent with never seeing an incorrect-password error.
Is a non-decaying guessCount with a re-arming lockTimeSeconds intended behaviour, or a bug?
Is there any path to have the counter reset on the key-share nodes? The rate limiter is MetaMask-operated infrastructure, not part of my self-custody — so “non-custodial, we can’t help” doesn’t apply to clearing a server-side counter.
Can someone confirm ticket #127213997 is still open? I never received a confirmation email, and replying to support@metamask.io is auto-rejected as a new query.
I have the userId / JWT sub and the socialLoginEmail and will share them privately with anyone from the team who needs them — not posting them publicly.
This question concerns the MetaMask Extension’s seedless/social-import recovery flow and a support-ticket status — not an Embedded Wallets (Web3Auth) SDK integration issue, so it’s out of scope for this hub.
Specifically, the Embedded Wallets developer documentation does not cover: (1) the extension’s guessCount / lockTimeSeconds rate-limiter semantics or whether the re-arming behavior you observed is intended, (2) any procedure for resetting a server-side attempt counter on the key-share nodes, or (3) support-ticket status lookup. I can’t confirm anything about ticket #127213997 from this channel, and I won’t speculate about node-side behavior that isn’t documented here.
Best path: raise this through official MetaMask user support (support.metamask.io) and/or the MetaMask Extension support channel, referencing your existing ticket number and the same redacted diagnostics you posted here.
Security note: as before — don’t post your JWT, sub/userId, nodeAuthTokens, metadataAccessToken, or any password/recovery material publicly; share them only through the official support ticket. No one from MetaMask will ask for them in a public thread or by DM.
Thanks — but this is a circular referral, and I’d rather explain why than just re-file somewhere else.
I came here from official support. Ticket has been open since Aug-23 with no human technical reply in 12 days. Replying to support@metamask.io is auto-rejected in under 60 seconds as a “new query” — I tried twice, from both addresses on the account, with correct In-Reply-To and References headers, and each attempt opened a brand-new conversation instead of threading. So the path being recommended to me is not actually reachable from my side. That’s why I’m here.
On scope: I don’t think this is an extension question. The counter I’m hitting isn’t in the extension — it’s on the key-share nodes. My own client’s tokens carry aud: sapphire_mainnet/w3a-metadata, iss: auth-service.api.cx.metamask.io, authConnection: apple, nodeIndexes 1–5. The extension is a consumer of that infrastructure; the rate limiter is the infrastructure.
@yashovardhan@shana — I’d settle for one answer to one question, and I’m not asking anyone to touch my account in public:
Is a guessCount that never decays, combined with a lockTimeSeconds that re-arms to a full 24h on every attempt, intended behaviour on the sapphire_mainnet key-share nodes?
If it’s intended, I’ll stop chasing it. If it isn’t, then this is a bug report and it’s in the right category.
Agreed on the security note — I have not posted my JWT, sub/userId, node tokens or any password material, and I won’t. I can’t send private messages yet (trust level 0), so if someone needs the account identifiers to look this up, DM me and I’ll reply there.
Sorry for the slow reply, and thanks for your patience.
I have to be straight with you: this one isn’t answerable from the Embedded Wallets documentation available to me. The public docs cover Apple sign-in setup (Apple sign-in with Embedded Wallets), but they don’t document guessCount, lockTimeSeconds, the decay/reset semantics for those counters, or any self-service way to clear a lock on sapphire_mainnet. Anything I said about why the timer re-arms would be speculation, and guessing here could make things worse for an account you may be locked out of.
This needs someone with visibility into the network side, so please raise it through MetaMask Embedded Wallets developer support rather than as a docs question. To make that fast, include:
Network: sapphire_mainnet
Your Client ID and the verifier / connection ID for the Apple login
The user identifier (redact or hash if you prefer — support can work from a hash)
UTC timestamps of the failed attempts and of when the lock re-armed
The full error payloads showing guessCount and lockTimeSeconds
Whether the same identity works on sapphire_devnet
One safety note: don’t post seed phrases, private keys, recovery factors, or full JWTs in a public thread, and don’t send them to anyone who asks — support will never need them to investigate a rate limit.
If you can share the redacted error payload here, I’m happy to help sanity-check your SDK-side login/config while the account-level lock is investigated separately.
Happy to help — good luck with it. For anyone finding this thread later: the public Embedded Wallets docs cover configuring Apple sign-in (Apple sign-in with Embedded Wallets), but they don’t document lockTimeSeconds, guessCount decay, or reset behavior for Sapphire Mainnet rate limits — so that part needs to go through the network/account-recovery support channel. When you file it, include the affected verifier and user identifier (redacted as needed), timestamps, and the exact SDK/API error responses. Never share private keys, seed phrases, or OAuth tokens.
Thanks @shanerr. Just so it is easy to find, the full account-level details are already with you privately. I sent them on September 5 as a reply in the system welcome message thread, since a new account here cannot start a private message. That message has the network, the Apple connection IDs, the JWT sub, and ticket #127213997.
I have now added the timestamps and the error detail to that same private thread rather than posting them here.
Two clarifications in case they save your team a step. There is no third-party Client ID: this is MetaMask’s own extension and iOS app, so the login is your first-party Apple connection, and sapphire_devnet does not apply.
The one question I am asking is a data question, not an opinion. For that account, what are the per-node guessCount and lockTimeSeconds values right now? I have made no unlock attempts on any device since August 23, so whatever the counters read today, nothing I have done has touched them in over two weeks.
Tagging you correctly this time, @shana. My previous post used your display name, so the mention did not resolve and you may not have been notified.
Restating the single ask in one line: could someone read the per-node guessCount and lockTimeSeconds for the account identifier I sent privately on September 5, in the system welcome message thread?
No unlock attempts have been made on any device since August 23, so those counters have not been touched by me in over two weeks.
As mentioned many times by our support bot, unfortunately we won’t be able to help you in this forum. This forum is meant for metamask developers, particularly metamask embedded wallets. This apple login issue you are facing is for the metamask extension for which support.metamask.io is the correct channel.
Understood, and thank you for the clear answer, Yashovardhan.
I will take it back to support.metamask.io today and reference ticket #127213997, which has been open since August 23 with no technical reply.
One request only, since only your team operates the sapphire_mainnet key-share nodes: the account identifiers are already in my September 5 private message in the system welcome thread. If someone could forward them internally to whoever can read the per-node guessCount and lockTimeSeconds, that would let the support ticket be actioned instead of bounced again. No reply needed here.
I went back to support.metamask.io today as advised. I found that this case already has two technical support tickets, #121135651 (August 3 to 16) and #127213997 (August 23, closed August 24 with no reply). The August 4 answer from support on the first ticket says, in writing:
“We cannot directly read or modify per-account rate-limit counters (like guessCount or lockTime) on the TOPRF key-share nodes from the support side. Those internals are not exposed to support workflows and are intentionally isolated to protect against abuse. We cannot issue a reset_ratelimit action on your behalf. There is no supported support tool or admin override to clear TOPRF rate limits for a specific account.”
So support has confirmed they cannot act, and this forum has said it is out of scope here. That leaves no channel through which a user can reach whoever operates the sapphire_mainnet key-share nodes.
I have also filed the client-side finding with the Consensys security program: in @metamask/toprf-secure-backup 1.1.0, validateSeed throws on any single node’s rate-limit error before the 3-of-5 threshold is checked, so one locked node blocks a recovery that three healthy nodes could serve.
Single question, and then I will stop posting: which team owns the sapphire_mainnet rate limiter, and how does an affected user reach them? If the answer is “forward it internally”, the identifiers are in my September 5 private message. Thank you.