Solana signInWithWeb3 fails on Ledger hardware wallets

[borcherd]

Bug report

• I confirm this is a bug with Supabase, not with my own application.
• I confirm I have searched the Docs, GitHub Discussions, and Discord.

Describe the bug

There is still a blocking issue with Solana Web3 auth (signInWithWeb3) when using Ledger hardware wallets.
Even though issue #2092 was addressed and the related PR was merged, the fix did not fully resolve the problem.

The core issue is that the SIWS flow relies on off-chain message signing, and Ledger’s Solana app does not reliably handle this path when accessed through Phantom/Solflare. The message never reaches the hardware wallet, so authentication always fails for Ledger-backed accounts.

This means that any Solana user using a Ledger wallet cannot authenticate through Supabase, even after the merged fix.

I reached out to the author of the original PR on Twitter — he confirmed that additional issues likely remain, but hasn’t followed up.

This is a significant problem because most high-value users, teams, and institutional Solana accounts use hardware wallets. Right now they are completely unable to log in.

To Reproduce

1. Set up a Solana wallet using Phantom or Jupiter wallet with a Ledger device.
2. Implement supabase.auth.signInWithWeb3({ chain: "solana" }) in a Next.js / JS project.
3. Attempt to sign in with the Ledger-backed wallet.
4. The SIWS message never appears on the Ledger device; the wallet rejects the request; authentication fails.

This reproduces consistently across browsers and environments.

Expected behavior

I expected authentication to work for Ledger users after the fix for #2092.
Instead, SIWS still fails because message signing never reaches the hardware wallet.

Ideally, you should either:

• Continue refining SIWS to work with hardware wallets, or
• Provide a fallback mechanism for wallets that do not support off-chain message signing (e.g., a minimal transaction-based signature flow or another supported signing method).

System information

• OS: all
• Browsers: all
• supabase-js: latest
• Node.js: all

Additional context

• This is not an issue with my application — it reproduces with clean setups.
• The fix for solana web3 SIWS is incorrectly implemented #2092 improved part of the flow but did not solve the Ledger case.
• Ledger has stated that off-chain message signing issues are not likely to be resolved quickly on their end, so this currently blocks a large segment of Solana users. This makes this feature, signInWithWeb3, a no-go for production environments

[borcherd]

Pinging the people that seem to be maintaining Solana according to latest git blame:
@Bewinxed @hf @staaldraad

[etodanik]

The issue is with the wallets not having properly implemented the RFC defined flow. Phantom and Jupiter have a faulty implementation without proper preambles.

The reason this is in such a state of disrepair for them is that Ledger only patched the ability to sign arbitrary messages a few months ago, so those wallets never actually allowed proper flows on Ledger, and instead did a transaction sign.

Supabase actually has the correct RFC/SIP defined behavior.

We should reach out to them and ask them to come up with a fix.

[etodanik]

To follow up further, you can see here a discussion:
https://github.com/orgs/phantom/discussions/139

Here is the PR with which Ledger could start doing off-chain message signing:
LedgerHQ/app-solana@47441ae

My original PR:
#2092

The actually accepted proposal for message signing on Solana, which differs slightly from Phantom's own take & web3auth's take by including a preamble:
https://docs.anza.xyz/proposals/off-chain-message-signing

The next logical step seems to be to try to communicate to all wallets and get them to catch up to the fix in Ledger & implement the proper preamble from the Solana Proposal.

[Bewinxed]

Unfortunately waiting for all wallet apps to support this will be a very hard ordeal, and the proper fallback for now would be to support empty-tx based verification (you send an empty transaction with a certain code then you verify it), which has few issues:

• You would need to have your own node/get rate limited by public nodes.
• The backend would need to have the logic to parse/verify this transaction (IO/Network Load).
• Sending and approving an empty tx would make a lot of users Paranoid unless they 100% trust the UI they're on.

Does it work when used through the Ledger direct connection? or only fails on Phantom/Other wallet apps?

Edit: In Theory, we could add client-side support for Ledger Live which works on desktop/ios/android but that will not fix the issue for Phantom/Other wallets, not to mention it will only work for Ledger wallets, other hardware wallets might need more work.

@hf wyt

[etodanik]

How would one decide which flow to use? If one wallet supports the proper flow we have right now and one doesn't, how do we decide which flow to use?

I'm fairly certain I could get Solflare to implement the proper flow quickly. They're one of the top wallets, them having it would create incentive for Jupiter and Phantom to follow suit.

I don't see it such a huge deal to make some pressure on the wallets to implement the proper flows.

Implementing a terrible workaround seems worse all around.

[Bewinxed]

The general practice in the Solana webdev space unfortunately is that we try normal message signing first, then if it fails with a specific error code, we attempt the 2nd fallback.

Some UIs provide a "Use Hardware Wallet" toggle, which uses the fallback immediately, this has been the case for the longest time.

Unfortunately it means your users pay (a very miniscule) amount for signing into your app :/

On my own UIs, i use this kind of UX:

then

then

[etodanik]

The general practice in the Solana webdev space unfortunately is that we try normal message signing first, then if it fails with a specific error code, we attempt the 2nd fallback.

Yeah, I'm very much a part of Solana dev space as well, and am close enough to most of the wallet teams to the point where I think it's worth at least trying to avoid this ugly historic hack (which only existed because nobody bothered to patch Ledger's Solana app, which is now patched)

I'll reach out today & see how receptive are some of the wallet teams, and it will be clearer what's a good implementation is.

If we can pay a small price (of research and communication) to do something better, rather than doing it worse, I think it's worth it.

[Bewinxed]

I agree.

Let me know if I can help with any details. If wallets implement this properly, recommending any of them that do, is a helpful interim solution for users, adoption of this feature will be key for any wallet looking to retain their user base long-term.

[borcherd]

Hey @etodanik @Bewinxed - any movement on this?

I've checked Jupiter, Phantom, and Solflare again recently. Same issue across all major wallets. The signMessage request simply doesn't reach the Ledger device when using these wallet adapters. (or for jupiter it says 'Signing off-chain messages is not supported by Ledger yet. Please try again with a different wallet.')

I understand the "correct" fix is for wallets to properly implement the Solana off-chain message signing spec. But realistically, this coordination across multiple wallet teams isn't happening anytime soon - these issues have been open for years with no resolution.

I feel like an immediate fix would still be to implement a transaction-based fallback system. This can be a manual toggle, which is extremely common in the space too (and works reliably).

[borcherd]

Maybe another way of solving this, if a transaction fallback would be too involved or unpreferred, would be adding the ability to create a Web3 identity via the Admin SDK - similar to how createUser already supports email/phone identities. That way apps can handle the signature verification etc. themselves and implement their own preferred fallback.

Wdyt? @Bewinxed @etodanik

[etodanik]

Hey @etodanik @Bewinxed - any movement on this?

I've checked Jupiter, Phantom, and Solflare again recently. Same issue across all major wallets. The signMessage request simply doesn't reach the Ledger device when using these wallet adapters. (or for jupiter it says 'Signing off-chain messages is not supported by Ledger yet. Please try again with a different wallet.')

I understand the "correct" fix is for wallets to properly implement the Solana off-chain message signing spec. But realistically, this coordination across multiple wallet teams isn't happening anytime soon - these issues have been open for years with no resolution.

I feel like an immediate fix would still be to implement a transaction-based fallback system. This can be a manual toggle, which is extremely common in the space too (and works reliably).

Yes actually, I think Solflare will be fixed soon.

Jupiter too.

How would the toggle work if some wallets work correctly and some don't?

How would the user know what to toggle?

[borcherd]

Oh, thats great to hear! From my tests today, none of the wallets i mentioned above work so thats why i proposed the workaround.

The approach thats pretty much industry standard these days is whenever its a hardware wallet, always do tx based signing. Theres not really a large downside.

Would love to be kept in the loop if there's any update from the wallets that you've reached out to, thanks for the help there!

[etodanik]

Oh, thats great to hear! From my tests today, none of the wallets i mentioned above work so thats why i proposed the workaround.

The approach thats pretty much industry standard these days is whenever its a hardware wallet, always do tx based signing. Theres not really a large downside.

Would love to be kept in the loop if there's any update from the wallets that you've reached out to, thanks for the help there!

I'm actually super optimistic about Solflare & Jupiter as I have a great access to people working there. Give me a little bit of time (days) to work my way through the communication process.