What is Mobile Wallet Adapter (MWA)?
Solana Mobile's signing protocol explained — why it exists, what problem it solves, how it differs from WalletConnect, and what role it plays on the Seeker phone.
The problem MWA solves
If you've ever used a desktop crypto wallet, you know the dance: a website asks to connect, your wallet pops up a confirmation, you approve, you sign. The browser extension model (MetaMask, Phantom in-browser) works because the wallet and the dApp live in the same browser context.
On mobile, that's broken. Mobile browsers don't run extensions. Wallets are separate apps with their own sandboxes. So how does a swap app or a marketplace app talk to your wallet to ask for a signature?
For years, the answer was QR-code-based WalletConnect: the app shows a QR, you scan it with your wallet, a connection is established through a relay server, and signatures bounce back and forth over that relay. It works, but it's slow, requires both apps to talk through a third-party server, and is awkward when both wallet and dApp are on the same phone.
The Solana Mobile team's answer was Mobile Wallet Adapter (MWA): a wallet-to-dApp signing protocol designed specifically for the case where both apps live on the same mobile OS.
How MWA works under the hood
MWA defines two roles: the dApp (e.g. seekerbridge, an NFT marketplace, a DeFi app) and the wallet (e.g. Phantom, Solflare, Backpack, or the Seeker phone's built-in Seed Vault). Communication happens through the OS, not through a relay server.
Roughly, a session looks like this:
- The dApp calls the OS with an
solana-wallet://URI scheme (Android intent / iOS deep link). - The OS opens the user's chosen wallet app.
- The wallet sets up a secure local WebSocket on the device.
- The dApp connects to that WebSocket and the two exchange an association token — a session-scoped capability that authorises future signature requests during this session.
- Inside that session, the dApp asks for transaction signatures, the wallet shows the user what's being signed, the user approves or rejects.
- Signed transactions are returned to the dApp via the same channel.
The key properties:
- No relay server. Nothing leaves the device for signing. The dApp doesn't talk to the wallet's servers, and there's no third-party relay observing the connection.
- The wallet sees the transaction. Before signing, the user is shown what they're approving — what's being transferred, where, and to whom.
- Private keys never leave the wallet. The wallet signs locally and returns the signed transaction.
- Sessions are scoped. Granting a session to a dApp doesn't give it permanent power — each significant action requires the user to confirm in the wallet UI.
Because MWA happens entirely on-device through the OS, the connection is essentially instant and you never have to leave your dApp to approve a separate notification. The wallet pops up, you confirm, you're back where you were.
MWA vs WalletConnect
Both solve "how does a mobile dApp talk to a mobile wallet". They take different roads.
| Mobile Wallet Adapter | WalletConnect | |
|---|---|---|
| Chain | Solana-first (extending to others) | Multi-chain (EVM, Solana, Cosmos, etc.) |
| Transport | OS deep links + local WebSocket | WebSocket relay server |
| Latency | Instant (on-device) | ~200ms-2s (relay round-trip) |
| QR code needed | No (same phone) | Often |
| Privacy | No external service in the loop | Relay server observes timing/metadata |
| Offline-capable | Yes (if both apps on device) | No (needs internet to reach relay) |
| Maturity | ~3 years, Solana-focused | ~5 years, ecosystem-wide |
The trade-off: MWA is faster, more private, and more elegant — but only on mobile and only on Solana. WalletConnect is universal but slower and less private.
Why Solana Seeker is built around MWA
The Solana Seeker (and its predecessor, the Saga) is the first phone designed around the assumption that a crypto wallet is a core OS-level concept rather than just another app. That manifests in two ways:
Seed Vault — wallet as a system service
On Seeker, the private keys live in a hardware-isolated secure enclave (similar to what stores fingerprints and PINs on regular phones). Apps never have direct access to the keys. When an app needs a signature, MWA is the only way to ask for it, and the Seed Vault is the implementation that handles the request.
This is structurally similar to how Apple's Touch ID / Face ID works for payments: the OS holds the credential, apps can only request use via a well-defined API, and the user always sees the prompt.
Genesis Token and dApp Store
The Seeker comes with a Genesis Token (an NFT) that proves ownership, and a dApp Store curated by Solana Mobile. Apps in that store are pre-vetted to support MWA properly. seekerbridge is one such app.
Wallets that support MWA
As of 2026, MWA is supported by all major Solana mobile wallets:
- Phantom — the most widely used Solana wallet, MWA built in since 2023
- Solflare — native Solana wallet, also supports staking and SPL tokens
- Backpack — multi-chain mobile wallet with xNFT integration
- Seeker Seed Vault — the built-in system wallet on the Seeker phone
- Glow, Coin98, others
If you're using Solana on Android, you almost certainly have a wallet that speaks MWA. If you're using Solana on iOS, the situation is messier: Apple has historically been more restrictive about how wallets and dApps communicate, and MWA's iOS story is still evolving.
How seekerbridge uses MWA
Here's something important: seekerbridge is non-custodial, which means it doesn't need to sign transactions on your behalf at all. The actual swap flow is: you send crypto from your own wallet to a Changelly deposit address, and Changelly sends the converted crypto to your payout address. seekerbridge is the user interface, not the transaction broadcaster.
So why does seekerbridge support MWA at all?
On the Seeker Store flavor of seekerbridge, MWA is used as a convenience for Solana-side flows:
- Auto-fill your payout address when receiving SOL or SPL tokens — tap "Use my Seeker wallet" instead of typing/pasting.
- Auto-fill the sending address when sending SOL or SPL tokens out (with MWA-driven signing of the deposit transaction, so the BTC/ETH/USDT is sent directly from your wallet without leaving the app).
- Verify wallet ownership for refund flows.
On the Google Play flavor, MWA is intentionally not included — Play Store policies make wallet-connection flows trickier, and not every Android user has an MWA-compatible wallet installed. The Play version uses standard copy-paste address entry, which works with any wallet.
This is why we have two build flavors. Seeker users get the smoothest possible experience because the Seed Vault is right there in the OS. Play Store users get the universal experience that doesn't assume any particular wallet app.
The future of MWA
Solana Mobile's roadmap suggests MWA evolving in three directions:
- Cross-platform support — better iOS compatibility, possibly desktop too.
- Standardised permissions — granular controls about what a session can do (sign-only-these-amounts, time-bound sessions).
- Multi-chain via MWA bridges — letting MWA negotiate signatures for non-Solana chains via wallets that support multiple ecosystems.
The bigger picture: MWA is part of a broader shift where mobile-first crypto stops being a second-class experience. Browser extensions made sense in 2017 because that's where users were. In 2026, most of the next billion users will encounter crypto on a phone first. MWA is one of the bets on what that looks like done properly.
If you have a Seeker phone, MWA is invisible to you in seekerbridge — it just makes Solana-side flows feel a tap faster. If you don't, the swap flow is identical, just with paste-the-address steps. Either way, the cryptography under the hood is the same.