Trustware: How Wallet Auto-Detection Actually Works in a Deposit Widget

Q: Why would a wallet be misidentified without this?

Older detection relied on generic global flags multiple wallets could set for compatibility, making the specific wallet hard to determine.

Q: How are Solana wallets detected if they don't use EIP-6963?

Through a separate detection path for Solana-native wallets like Phantom, Solflare, and Backpack.

Q: What happens if two wallets both set a generic compatibility flag?

Detection priority ranks specific known identifiers above generic flags.

Q: Can a user still manually select a wallet not automatically detected?

Confirm current fallback behavior for manual wallet selection directly before publishing.

TL;DR: "Auto-detect wallets" usually means listening for browser-injected providers and guessing which wallet is which. Trustware's detection layer uses the EIP-6963 standard to get a reliable identifier from each announced provider, cross-references it against known wallet patterns, and ranks matches by specificity, so a MetaMask install doesn't get misidentified just because it also sets a generic compatibility flag.

What is wallet auto-detection actually doing under the hood?

Auto-detection listens for wallet providers a browser extension injects into the page, identifies which specific wallet each one is, and presents that list to the user, rather than requiring the user to already know which wallet to manually select from a static list.

How this works in practice

EIP-6963 provider announcements

Modern wallet extensions announce themselves through the EIP-6963 standard, providing an info object with a reverse-DNS identifier rather than relying solely on older, less reliable global-object detection. Trustware's detection layer listens for these announcements directly.

Matching identifiers to known wallets

Announced identifiers are matched against a reverse-DNS pattern map, for example patterns identifying MetaMask, Coinbase Wallet, OKX, Rabby, Rainbow, Trust Wallet, Bitget, Zerion, Safe, and others, so the detection layer knows specifically which wallet is present rather than treating every EVM-compatible provider the same.

Resolving ambiguous or generic signals

Some wallets set generic compatibility flags, like an "isMetaMask" flag other wallets sometimes also set for compatibility reasons, that shouldn't be trusted as a specific identifier on their own. Detection priority ranks wallets so a more specific match always wins over one of these generic compatibility signals.

Solana wallets through a separate path

Because Solana wallets don't use the EIP-6963 standard, a parallel detection path covers Solana-native wallets like Phantom, Solflare, and Backpack, feeding into the same overall wallet list the user sees.

The Trustware view, wallet detection quality is invisible until it's wrong

A detection layer that correctly identifies wallets is unremarkable to a user, it just works. One that misidentifies a wallet, or shows a duplicate or generic entry, creates confusion at exactly the moment a user is about to connect funds. Getting this right is largely invisible engineering that only becomes visible when it fails.

A contrarian take, more detected wallets isn't automatically better if the ranking is wrong

A detection layer that lists every possible provider without resolving conflicts between generic and specific signals can present a confusing list, several similar-looking entries where only one accurately reflects the user's actual wallet. Correct ranking matters more than raw detection breadth.

What to check in any wallet detection layer

Does it use EIP-6963, or rely only on older, less specific detection methods?
Does it correctly rank specific wallet matches above generic compatibility flags?
Does it cover non-EVM wallets through a dedicated path, not just EVM providers?
Does the detected list avoid showing confusing duplicate or ambiguous entries?
Is new wallet support added at the detection-layer level, without requiring app-side changes?

See the Trustware docs for current wallet detection details.

FAQ

What is EIP-6963?

A standard for wallet extensions to announce themselves with a structured info object, including a reverse-DNS identifier, improving on older, less reliable detection methods.

Why would a wallet be misidentified without this?

Older detection methods often relied on generic global flags that multiple wallets could set for compatibility, making it hard to distinguish which wallet was actually present.

How are Solana wallets detected if they don't use EIP-6963?

Through a separate detection path specifically for Solana-native wallets like Phantom, Solflare, and Backpack.

What happens if two wallets both set a generic compatibility flag?

Detection priority ranks more specific known identifiers above generic flags, so the correct wallet is identified rather than a generic match.

Does adding support for a new wallet require changes to an integrating app's code?

No, wallet detection support lives in the SDK's wallet layer rather than the integrating app's own code.

Can a user still manually select a wallet not automatically detected?

{{CITE: confirm current fallback behavior for manual wallet selection before publishing}}

How to decide if your integration needs to worry about this

If you're using Trustware's widget or auto-detection mode, this detection logic is handled for you. If you're building a custom wallet connection flow yourself, this is exactly the kind of edge-case handling worth confirming before assuming your own detection is reliable across all major wallets.

See trustware.io for current wallet support.