Thanks — I’m on the MetaMask & Web3Auth team. This is a common async/timing effect; the right pattern is to treat wallet interactions as event-driven and model an explicit transaction lifecycle in your UI. Quick checklist and next steps:
-
Subscribe to provider events (accountsChanged, chainChanged, connect, disconnect) and drive UI from those events rather than optimistic assumptions. Example:
provider.on(‘accountsChanged’, accounts => updateUI(accounts));
provider.on(‘chainChanged’, chainId => resetAppState(chainId)); -
Don’t treat eth_sendTransaction as final — wait for confirmation. Use ethers.js provider.waitForTransaction(txHash) or poll eth_getTransactionReceipt, show an intermediate “pending_tx” state, then update on confirmed.
-
Model explicit UI states: idle / connecting / awaiting_signature / pending_tx / confirmed / failed. Show “awaiting_signature” immediately after triggering a request so modal delays don’t look like bugs.
-
After confirmation, re-fetch contract state (or consume events/logs/indexer) rather than relying on wallet to push contract updates.
-
For development: log provider requests/responses and timestamps for request start → tx hash → confirmation to locate gaps.
What I need from you to help further: SDK version number and platform (Web: injected window.ethereum vs MetaMask SDK mobile / desktop). If you can, paste a minimal code snippet that handles connection/tx flow or a console screenshot. If you prefer, I’ll route this to an engineer to investigate once you provide the SDK version + platform.
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