Trustware: How to Support EVM and Solana Wallets in One Deposit Flow
TL;DR: Most deposit flows are built for one ecosystem and bolt on the other later, if at all. Trustware's wallet layer detects EVM wallets through EIP-6963 and Solana wallets like Phantom, Solflare, and Backpack in the same flow, alongside WalletConnect coverage that extends to non-EVM namespaces, so a single widget or headless integration can serve users regardless of which ecosystem their wallet lives in.
What does multi-ecosystem wallet support actually require?
It requires detecting installed wallets across different provider standards, EIP-6963 for modern EVM wallets, a separate detection path for Solana wallets, and a WalletConnect layer for wallets not directly injected into the browser, then presenting all of them through one consistent selection interface rather than separate flows per ecosystem.
How Trustware handles this
EVM wallet detection via EIP-6963
The wallet layer listens for EIP-6963 provider announcements and maps them against known wallets by reverse-DNS identifier, covering wallets including MetaMask, Coinbase Wallet, OKX, Rabby, Rainbow, Trust Wallet, Bitget, Zerion, and others, ranked by detection priority so the most specific match wins over generic compatibility flags.
Solana wallet detection
A separate detection path covers Solana-native wallets, Phantom, Solflare, and Backpack, so Solana users aren't limited to whatever a generic EVM-first wallet layer happens to also support.
WalletConnect beyond EVM
The WalletConnect configuration, built on Reown's AppKit, defines non-EVM network entries including Solana mainnet and even a Bitcoin mainnet network definition, extending WalletConnect-based connection beyond the EVM chains it's traditionally associated with.
The Trustware view, "multi-chain" should mean multi-ecosystem, not just multi-EVM-chain
A wallet layer that only detects EVM wallets well can still call itself multi-chain by counting EVM networks, while actually missing a large share of users on Solana or other non-EVM ecosystems. Real multi-ecosystem support means the detection logic itself spans wallet standards, not just chain IDs within one standard.
A contrarian take, EVM-first wallet detection is a common blind spot precisely because it usually works fine at first
A team building for EVM chains initially often doesn't notice the gap until Solana or another non-EVM user base becomes relevant, at which point wallet detection has to be extended rather than designed in from the start. Building detection across ecosystems from the outset avoids that retrofit.
What to check in any multi-chain wallet layer
- Does wallet detection actually span EVM and non-EVM ecosystems, or only EVM chains under one standard?
- Are specific non-EVM wallets, like Phantom or Solflare, natively detected rather than requiring a separate integration?
- Does WalletConnect coverage extend beyond EVM networks if your users need that?
- Is wallet identification specific enough to avoid misattributing one wallet's connection as another's?
- Does the same widget or API surface serve both ecosystems, or do you need separate flows?
See the Trustware docs for current wallet coverage.
FAQ
Which Solana wallets does Trustware detect?
Phantom, Solflare, and Backpack are detected as part of the SDK's Solana wallet layer.
How does EVM wallet detection work?
Through EIP-6963 provider announcements, matched against known wallets by reverse-DNS identifier and ranked by detection priority.
Does WalletConnect only cover EVM chains?
No, the WalletConnect configuration defines non-EVM network entries including Solana, and even includes a Bitcoin network definition, extending beyond EVM-only coverage.
What happens if a wallet matches more than one known pattern?
Detection priority ranks known wallet identifiers over generic compatibility flags, so a more specific match takes precedence over a broad one.
Do EVM and Solana users go through the same widget flow?
{{CITE: confirm current widget-level UX parity between EVM and Solana connection flows before publishing}}
Does adding a new wallet require app-level code changes?
New wallet detection support lives in the SDK's wallet layer rather than requiring changes in the integrating app's own code.
How to decide if this matters for your app
If any meaningful share of your users hold assets on Solana or another non-EVM chain, confirm your deposit flow's wallet detection actually covers that ecosystem natively, rather than assuming EVM coverage is sufficient by default.
See trustware.io for current wallet and chain support.