After participating in several discussions here, I’d like to ask a broader question: what matters most to you when choosing a mobile wallet for Cardano?
For transparency, I work with Gem Wallet, an open-source, self-custodial multichain wallet. Gem currently supports holding, sending, receiving, and swapping ADA. It does not currently support Cardano staking, NFTs, governance, or Cardano dApp connections, so I’m particularly interested in understanding which improvements the community would value most.
Beyond basic transfers, which features are most important to you?
Clear transaction previews before signing
ADA staking and stake-pool discovery
DRep delegation and governance
Cardano native-token and NFT support
dApp connectivity
Hardware-wallet support
Better scam and suspicious-transaction warnings
Built-in swaps with transparent routes and fees
UTxO management and coin control
Privacy and minimal data collection
Recovery and backup options
I’m especially interested in practical problems: confusing transaction details, missing assets, difficulty choosing a stake pool, unreliable dApp connections, unclear fees, or anything existing wallets still handle poorly.
If you could improve only one part of the Cardano mobile-wallet experience, what would it be? Please feel free to mention the wallets you currently use and what they get right or wrong.
Thanks for reaching out this is exactly the kind of community engagement that makes projects stand out.
My top priority: Clear transaction previews, hands down.
Cardano’s eUTxO model is powerful but opaque to most users. The single biggest pain point I encounter daily is the collateral confusion users see 5 ADA “taken” and panic, not realizing it’s refundable. A wallet that clearly breaks down:
What’s being sent
What’s collateral (refundable)
What are fees (non-refundable)
What assets are involved
…in plain English would instantly build trust and reduce support headaches.
The “one thing” I’d improve: dApp connection stability on mobile. Switching apps often kills WebSocket connections, forcing users to restart transactions. Solid session management would make Gem a go-to for DeFi users.
My current setup: Eternl for power features (UTxO control is unmatched but the UI is overwhelming), Lace for its beautiful UI (but too limited). There’s a gap for a wallet that combines both clean UX with advanced controls.
Must-haves: Staking is non-negotiable for Cardano users. Without it, Gem remains a “spending wallet,” not a primary one. dApp connectivity comes second.
If you nail transaction clarity first, then staking, then dApp stability you’ll fill a real gap.
Thank you—this is very actionable feedback. The distinction between a “spending wallet” and a wallet users consider their primary Cardano wallet is especially useful.
Your transaction-preview example is also important. Collateral should be clearly separated from the amount being sent and the network fee, including the conditions under which it may be consumed or returned. Native-token movements should be equally visible rather than hidden inside technical transaction details.
Regarding mobile dApp stability, where does the connection usually fail for you: during the handoff from the dApp to the wallet for approval and back, or after either app has been left in the background? Also, are you generally using an external browser or an in-app dApp browser?
I’ve noted the priority order you suggested: transaction clarity, staking, then reliable dApp connectivity. Thanks for explaining the practical reasoning behind it.
I generally stay away from multichain wallets. However, if it is a multi chain wallet it has to have ability to completely shut down any chains users don’t want to have and even remove them visually from UI.
Ability for user to set default chain.
Always ask for permission when adding another chain or a bridge.
Never ask to add a chain or a bridge during a transaction.
One click permission removals for interacting with apps, chains and bridges.
Clearly state the source of a request for code or a pass phrase. (So user can see if a wallet or an app or a website is asking for it).
Notifications if cross chain transaction is requested by the user.
You can have a built-in list of swaps that user can then manual add. We had some built-in options before that resulted in many tokens being lost and unrecoverable.
Yes.
Hardware-wallet education and info. Yes.
Streamlined at least one HW integration. Yes.
Education.
Way too many users still think that tokens are ‘in the wallet’.
This leads to them being easily exploited by scammers when they lose access to their wallets. They don’t think they lost access to the app, they think all of their access is lost.
Have clear explanation of what passphrase is, what it accesses and how wallet is just UI on top of that.
Explain layers of protection from passphrase to HW.
Make them take a quiz on crypto safety before opening their first on-chain wallet. (I know it sounds silly, but we are nowhere near the adaption levels where you can assume this is common knowledge.)
Load screen/opening screen reminder to never share their passphrase, or that your wallet will never ask for one after set up, or to keep it safe and hidden of line, etc…
A nice option would be a notification if pool is retiring or shutting down or pool % fees are changing. I know this would be just an in app layer that you have to monitor off chain and push notifications, but it would be helpful.
Thank you, this helps a lot. A strong theme across your suggestions is user control and explicit consent: choosing a default chain, completely disabling unwanted chains, avoiding bridge or network prompts during a transaction, and having one place to review and revoke permissions.
The education point is especially valuable. Wallets should clearly distinguish between a recovery phrase, an optional passphrase, and an app password or PIN, because treating them as interchangeable can create dangerous misunderstandings. Explaining that the wallet is an interface to on-chain assets—not where the assets physically reside—could also prevent many recovery scams. Safety reminders or a short onboarding quiz could be useful if experienced users are still able to move through it efficiently.
Clear request attribution is another important point: users should be able to see whether sensitive information or approval is being requested by the wallet itself, a dApp, a website, or a bridge. Cross-chain actions should never look like ordinary same-chain transfers.
Your staking notification examples also align with earlier feedback about actionable alerts, particularly pool retirement and fee changes.
One clarification: when a user disables a chain, would you expect the wallet to stop background balance discovery, network requests, and notifications for that chain as well as removing it from the interface? That distinction could matter for both privacy and performance.
Thanks for taking the time to provide such detailed feedback.
