The wallet’s blind spot
Wallets have gotten better at surfacing DeFi positions. Open Phantom or Solflare today and you’ll see your Kamino position, your Jupiter LP, your staked SOL. The data is there.
But it’s their interface, not yours. The wallet decides how to display your position, what to call it, what actions to surface. You get a generic card in a list of other positions. You don’t get to show users what matters most in your domain, guide them through your specific workflows, or speak in your own vocabulary.
And that interface is designed for people who already understand crypto. Seed phrases at signup. Transaction approval screens. Token addresses. Fine for your current users — a barrier for everyone else.
If you want to control how users experience your product, you need to own the interface.
The “dApp browser” was supposed to solve this. It didn’t. Using a dApp browser means loading a website inside your wallet app, usually with a cramped viewport and a worse keyboard. You’re not getting a mobile experience — you’re getting a desktop experience squeezed onto a phone screen. For crypto-native users who already understand the mental model, this is tolerable. For everyone else, it’s a barrier.
What mainstream adoption actually looks like
The teams building for users outside crypto have recognized this limitation and responded by building native apps that hide the blockchain entirely.
AAVE launched a native iOS app in November 2025. The interface doesn’t mention stablecoins or protocols — it looks like a savings account. Users deposit via bank transfer or debit card. They see an interest rate and a balance. Stani Kulechov, Aave’s CEO, described the target audience directly: “Typically, DeFi has been accessible to very savvy, professional users. The next step for DeFi is to bring more direct access for consumers.” The app strips away terminology that would alienate someone unfamiliar with crypto.
Lulo, on Solana, took the same approach. Their iOS app has no seed phrases in the onboarding flow, no gas fees visible to users, no trading charts or leverage controls. The design goal, according to their launch materials, was to feel “more like a high-yield savings app than a crypto platform.” The result is something a user could recommend to friends and family without needing to explain what a wallet is.
Both apps recognize the same thing: if you want to reach users who don’t already understand crypto, you cannot hand them a general-purpose wallet and expect them to figure it out. You need to own the interface.
Why this matters now
Crypto is no longer early-adopter territory. Stablecoin usage is growing outside the crypto-native crowd — people using USDC for remittances, storing savings in dollar-denominated assets, earning yield without understanding what a liquidity pool is.
These users aren’t going to learn what Phantom is. They’re not going to write down twelve words and store them in a safe. They’ll use an app that does what they need, or they won’t use crypto at all.
The applications that capture this wave won’t be the ones with the most features in their smart contracts. They’ll be the ones that meet users with interfaces that feel familiar — apps that look like banking apps, savings apps, game apps. The blockchain is infrastructure. The wallet is a signing mechanism. Neither needs to be visible.
The companion app pattern
For most Solana applications, building a full AAVE-style app with fiat onramps and custodial key management is overkill. But there’s a middle path: a companion app that handles the read experience natively while delegating signing to existing wallets — or to an email-based keypair for less crypto-savvy users.
The pattern works as follows:
Read operations happen directly in your app. Your app knows your program’s account structure. It can deserialize your PDAs, interpret the state, and present it in terms that make sense for your domain. A lending app shows health factors and liquidation thresholds. A game shows inventory and achievements. An order book shows open orders and fill history. None of this requires wallet integration — it’s just reading public on-chain data.
Write operations use deep links to mobile wallets. When a user needs to sign a transaction, your app constructs the transaction, serializes it, and opens a deep link to Phantom, Solflare, or Backpack. The wallet app opens, shows the user what they’re signing, and handles the signature. After signing, control returns to your app.
This separation gives you several things. Users get a native interface designed for your specific use case. You control the vocabulary — “withdraw” instead of “transfer”, “position” instead of “associated token account”. The wallet still manages keys, so you don’t take on custody risk. And users who already have a wallet don’t need to set up a new one.
Deep linking in practice
Mobile wallets on Solana support deep linking via URL schemes. The basic flow:
Your app constructs a transaction. You serialize it to base58 or base64. You build a deep link URL with the transaction payload. You open the URL, which launches the wallet app. The user reviews and signs. The wallet redirects back to your app with the signature.
Phantom’s deep link scheme, for example, uses phantom:// URLs with the transaction encoded as a query parameter. Solflare and Backpack have similar schemes. The wallet SDKs provide helpers for constructing these URLs correctly.
The transaction construction happens entirely in your app. You have full control over the instructions, the accounts, and the compute budget. The wallet only sees the final transaction and handles signing.
For apps that want tighter integration, Phantom and others also support wallet adapter connections within mobile apps, where the wallet acts as a background signer. But for many use cases, deep links are simpler and work across all major wallets without wallet-specific SDK integration.
This isn’t just for “normies”
A common objection: “My users are crypto-native, they’re fine with wallets.” But good UX serves everyone. A crypto-native user checking their Kamino position would also prefer to see it in a dedicated interface rather than navigating to a mobile browser. The companion app pattern isn’t about dumbing things down — it’s about showing users what they actually care about.
The teams that built AAVE’s and Lulo’s apps understood this. The same app that works for someone’s non-crypto parents also works for DeFi power users. Clear information display and intuitive controls aren’t compromises for mainstream adoption; they’re just good product design.
The path forward
If you’re building on Solana and your program has custom state — which is most programs — your users cannot see that state in their wallet. They have to come to you.
You have two options: send them to a website, or build an app that meets them where they already are (their phone). The website works, but it’s a desktop experience on a mobile device. The companion app takes more effort upfront, but it lets you control the entire experience from state display to transaction construction.
AAVE and Lulo point toward where this is heading. As more teams recognize that general-purpose wallets can’t serve application-specific needs, we’ll see more native apps that treat the blockchain as infrastructure rather than interface. The wallet becomes what it should be: a key manager and transaction signer, not the primary way users interact with your product.
For developers ready to build this way, Blueshift is launching a learning path on mobile Solana development — from reading on-chain state in native apps to integrating wallet deep links for signing. The companion app pattern is straightforward once you understand the pieces.
