Mobile Wallet Adapter Protocol
The Mobile Wallet Adapter protocol is what defines the communication exchange between a dApp and a mobile wallet app. In the protocol, the dApp sends requests (e.g.authorize, sign_transactions), while the wallet is responsible for displaying
these requests to the user and responding back to the dApp if approved.
For an extensive, deep dive into the specifics of the protocol and MWA methods, refer to the MWA spec.
High Level
The following diagram shows a bird’s eye view of a mobile dApp’s interactions with mobile wallets and the Solana network.Session Establishment
To begin the protocol, a dApp initiates first contact with a mobile wallet and establishes an MWA session. With the current SDKs, the MWA session is initiated through Android intents, with the dApp broadcasting an intent with thesolana-wallet:// scheme.
Example: Authorize and Sign Transaction
Once a session is established, the dApp can now begin sending MWA Requests to receive signed transactions from the wallet. This example case outlines an MWA session where the dApp:- Establishes a session with a wallet.
- Requests authorization, elevating the session to an “authorized state” and receiving a list of authorized accounts and an authToken.
- Requests transaction signing, receiving a transaction signed by the authorized accounts.
Submitting to the Solana network
Just like web dApps, the process for a mobile dApp submitting transactions to the blockchain network is the same. The dApp specifies a cluster and an RPC endpoint then sends the transaction payload, following the JSON RPC API. For certain usecases, the dApp may choose to communicate with the RPC through the Websocket APISign and Send Transaction
For submitting transactions, it is encouraged for the dApp to send asign_and_send_transaction MWA request to the wallet. This request
type sends a unsigned transaction to the wallet. If authorized, the wallet will then sign the transaction and send it to the network with its
own implementation. Depending on the wallet app, this can include applying its own priority fee.
Relying on the wallet reduces the risk of replay attacks with durable nonce based transactions, which can be abused with sign_transactions.
