MWA stops working on PWA after closing and re-opening

[Michaelsulistio]

Describe the bug
This team (flash.trade) has a PWA-wrapped Android App (via Bubblewrap) and is running into an MWA issue.

After sometime and re-opening the app, an error is surfaced when attempting to execute a trade/transaction using MWA.

Dependency Versions

A list of relevant dependencies in your app and their versions.

// Web
"@solana-mobile/wallet-standard-mobile": "^0.4.4
"@privy-io/react-auth: ^2.24.0"

Wallets tested
Please check all the wallets you have tested against to reproduce this bug.

• Mock MWA Wallet
• Seed Vault Wallet
• Phantom
• Solflare
• Backpack

Before submitting an issue, you must test with at least Mock MWA Wallet + 1 other wallet.

Recording/Screenshots
If applicable, add at least 1 screenshot or a screen recording to help explain your problem.

screen-20260102-210855.mp4

To Reproduce

This issue isn't 100% reproducible, but general steps are:

1. Install the Flash.trade PWA app via dApp Store
2. Connect a wallet via Mobile Wallet Adapter
3. Attempt some trade/transaction (should work)
4. Close and exit the app completely
5. Re-open the app and attempt some trade/transaction (should fail)

Expected Behavior

The transactions should be correctly signed and sent just like the first attempt.

Smartphone (please complete the following information):

• Device: Seeker
• Browser: Test with Chrome as your default browser
• Version: if this issue is endemic to specific Android versions [e.g. 22]
• Additional Details: any additional information about the device? [e.g. low power mode on, privacy mode on, etc.]

Additional context
Add any other context about the problem here.

[rohit0110]

Hi @Michaelsulistio
In the video you provided, is the initial trade that is showing on the dashboard made by MWA or privy wallet?
What i want to confirm is whether or not MWA tx is successful at any point, since during my attempt to reproduce the bug even the initial tx didnt go through.
I only tried using the Mock MWA since i wanted to try and separate the issue from privy, since the entire flow of logging in to creating a trade should not have privy utilised anywhere

[Michaelsulistio]

@rohit0110 I didn't create that initial video, but I just attempted to reproduce on my own Seeker and am seeing the same issue.

I used chrome://inspect to read the logs and am seeing this error:

Error closing position: Error: WalletSignTransactionError: Connected wallet does not support signing transactions

I have seen similar reports of this in the past and have seen this issue with Privy and MWA before. There's some issue where Privy doesn't recognize MWA as having the SignTransaction capability even though it's defined here so it never even invokes the wallet app.

What I think is happening:

1. User loads website
2. MWA is registered as a standard wallet and appears as an option
3. User connects via MWA
4. User attempts to signTransaction
5. Privy makes a check to see if MWA supports it
6. For some reason, it doesn't find the signTransaction feature and blocks the attempt.

We need to understand step 5 and how Privy's logic determines whether a wallet supports signTransaction.

Something else I noticed: After disconnecting and reconnecting MWA, the transaction signing works fine and I don't see that error anymore. Leads me to wonder if there's some caching logic that goes wrong somewhere.

[rohit0110]

Hi @Michaelsulistio
Was there any headway made with privy team on #1263 (comment)
From the testing I did, its pointing to the above linked issue as well. On a page refresh, the application attempts to initialize Privy before the Mobile Wallet Adapter (MWA) has finished making itself available to the browser. This results in Privy believing that no MWA wallet is present, which causes the connection to fail or an existing session to be invalidated.
It would also explain why a disconnect and reconnect fixes it, which is essentially the UX mentioned in #1263 as well

[Michaelsulistio]

@rohit0110

On a page refresh, the application attempts to initialize Privy before the Mobile Wallet Adapter (MWA) has finished making itself available to the browser. This results in Privy believing that no MWA wallet is present, which causes the connection to fail or an existing session to be invalidated.

Can you explain how you know this is true? MWA registers itself normally just like any other standard wallet so Privy would run into this issue with any other standard wallet.

Also, we know that Privy does recognize MWA because we can see it in the list of wallets.

[rohit0110]

Hi @Michaelsulistio

MWA registers itself normally just like any other standard wallet so Privy would run into this issue with any other standard wallet.

From my understanding, to utilize MWA, registerMwa function has to be used, without it, it does not show up in the list of wallets. However wallets like Phantom do not require that extra bit of code to be available, while also being able to open the wallet on the Mobile

Can you explain how you know this is true?

I apologize for the confusion, i should have worded it better, i meant to say its my hypothesis that, there is a race condition where Privy may query the Wallet Standard before MWA has completed its registration, especially on page refresh when both systems are initializing simultaneously. However after more detailed logging that doesnt seem to be the case, here is what i have so far

First Connection (works for both):
User clicks "Connect Wallet" → Privy queries wallets → Connection successful

After Page Refresh:

Phantom (Injected):
Privy restores session → Checks window.phantom → Reconnects wallet ✅
authenticated: true, walletsCount: 1

MWA (Wallet Standard):
Privy restores session → Does NOT check getWallets() → No reconnection ❌
authenticated: true, walletsCount: 0

Example Logs

[INIT] MWA wallet registered in Wallet Standard ✅
[AUTH] Privy session restored: authenticated: true ✅
[AUTH] Privy wallets state: walletsCount: 0 ❌

I am checking with Privy team if shouldAutoConnect is expected to work with Wallet Standard wallets, or if there's a different approach needed

[Michaelsulistio]

autoConnect should work with standard wallets, but I'm not sure if that's the issue here.

We need to ask the Privy team how their library checks for the signTransaction feature and see why it's failing to detect MWA's signTransaction feature.

I've posted a help message in the Privy slack and am awaiting a response.

[Michaelsulistio]

Update on investigation

I checked with the Privy team to understand how their SDK checks whether a wallet supports signTransactions.

Their reply:

...to answer your question, yes, it directly checks the wallet object's features array. Specifically, it verifies:
Whether the key solana:signTransaction exists in the features object
Whether that feature object includes a signTransaction method
The features object follows the Solana Wallet Standard format, where each wallet advertises its capabilities accordingly.
Regarding caching, there is no caching of the features object. Features are accessed directly from the external wallet instance each time.

• This is odd because the MWA Standard Wallet does support signTransactions in it's #features array. (reference)

• I also confirmed the Seed Vault Wallet app does correctly return both solana:signTransactions and supports_sign_and_send_transactions in its capabilities object, so it's not getting overwritten later.

Next

My next hunch is that the Privy SDK is using and registering an older version of @solana-mobile/wallet-standard-mobile. Versions < 0.4.1 might run into this signTransactions issue as it was fixed here.

Even if the client app (e.g flash.trade) is using a newer version > 0.4.1, the older version from Privy "overrides" the wallet object.

So next facts to verify:

• Does the Privy SDK use and register @solana-mobile/wallet-standard-mobile?
• If yes, what version?
• If yes, is it correctly using the client registered version?
• If not, why?