Conversation
| capabilities: Awaited<ReturnType<GetCapabilitiesAPI['getCapabilities']>> | ||
| ) => { | ||
| // TODO: investigate why using SolanaSignTransactions constant breaks treeshaking | ||
| const supportsSignTransaction = capabilities.features.includes('solana:signTransactions');//SolanaSignTransactions); |
There was a problem hiding this comment.
this change will break MWA 2.0 compliant wallets. the specified identifier is solana:signTransactions. that value must be checked. If we need a translation for misbehaving wallets that are hard coding an incorrect identifier we can do that, but there is a better layer for that.
There was a problem hiding this comment.
Ahh good catch, I had assumed the strings were matched between MWA and Wallet Standard features because that's what Seed Vault Wallet was returning:
This is what SVW is returning in capabilities:

Seems like the fix is that SVW actually needs to return the correct string solana:signTransactions (plural)
There is no typo here. Always check the spec for the source of truth. the MWA specification defines this constant: solana:signTransactions Let me explain this fully. wallet capabilities here is an MWA API, NOT a wallet-standard API. We need to be careful in the wallet-standard wallet to be sure when we are working with which. |
562d440 to
0fd20fe
Compare
I discovered a typo in the
handleWalletCapabilitiesResultwhen checking for the Wallet StandardsignTransactionfeature.The typo caused a bug where
handleWalletCapabilitiesResultwould always think the wallet did not supportsignTransaction, thus removing it from it's advertised#featuresobject.Fix:
solana:signTransactions->solana:signTransactionImpact:
This change will fix a long-running bug with Privy x MWA web apps (see here) where trying to sign a transaction throws an error
This is because the Privy wallet library checks for the presence of the
signTransactionfeature