Permissions a wallet app asks for on your phone

There are two things called permissions in a wallet, and conflating them is a genuine source of confusion. There are the phone's permissions — camera, notifications, biometrics — which the operating system asks for. And there are on-chain approvals, which the wallet asks you to sign. The first set governs what the app can do on your device; the second governs what a contract can do with your funds.

A wallet permission is a capability the operating system grants an app on your device — the camera, notifications, the keychain — and it is worth understanding on its own terms, because a wallet is one of the few apps where "what does it need this for?" has a specific right answer, and anything beyond that answer is worth a pause.

What a wallet legitimately needs

A wallet permission list should be short. Five entries, each with an obvious purpose.

• Camera. Scanning QR codes for addresses and for connecting to sites. This is the most-used permission in a wallet and the most clearly justified.
• Notifications. Alerting you to incoming transfers, confirmations, or a signature request from a connected session. Useful, and genuinely optional.
• Biometrics or passcode. Unlocking the app and authorising a signature. This does not give the app your fingerprint — the system returns a yes or no.
• Secure storage. The keychain or equivalent, where key material is kept protected by the device's hardware.
• Network access. Reading balances, broadcasting transactions.

A wallet needs to see QR codes, notify you, unlock with biometrics, store keys in hardware, and reach the network. That list is short on purpose.

What should make you stop

Four requests do not follow from a wallet's job, and any wallet permission on this list deserves a pause.

Full photo library access. Scanning a QR code needs the camera, not your album. A wallet asking for the whole library — rather than a single-photo picker when you choose to import an image — is asking for far more than the task requires.

Accessibility services. On Android, this permits reading the screen and acting on it. There is no legitimate wallet feature that needs it, and there is an obvious illegitimate one.

SMS access. A wallet has no reason to read your messages. Where an app claims it needs this for verification, that is a design choice made against you.

Contacts. Some wallets offer an address book of your own making; that is a feature. Access to your phone's contacts is different and unnecessary.

The accessibility row is the one to treat as disqualifying. It is the mechanism by which a malicious app watches everything you type, and a wallet requesting it should be removed rather than reasoned about.

Where the real risk actually is

The wallet permission list on your phone is the smaller half of the risk. The larger half is what you sign, and the two get conflated because both are called permissions.

A device permission is granted to an app and revocable in settings at any time, with effect immediately.

An on-chain approval is granted to a contract, recorded on the chain, and revoked only by sending a transaction that costs gas. Nothing in your phone's settings touches it.

That asymmetry matters: you can uninstall a wallet entirely and the approvals you granted through it remain live, because they were never a property of the app. They belong to the address.

This is why reviewing outstanding approvals against an address is a separate exercise from reviewing app permissions — a scanner such as Riskira reads the second list without connecting a wallet at all, and it is the list that persists across app changes, phone changes and everything else.

What the operating system does for you regardless

Some protection is structural, and knowing what you already have prevents both complacency and unnecessary worry.

App sandboxing. Each app has its own storage that other apps cannot read. A wallet's key material is not visible to a game you installed, and this holds without you configuring anything.

Hardware-backed key storage. The secure element or equivalent keeps key material in hardware that does not release it to the app itself — the app asks for a signature rather than for the key. This is why a device passcode matters more than people assume.

Runtime prompts for sensitive access. The camera, the microphone and the photo library all prompt when first used, and the indicator light stays visible while they are in use.

Store review and revocation. An app found to be malicious can be pulled and, in some cases, disabled on devices — which is the main argument for installing a wallet from the official store rather than from a link.

Two things this does not protect against, and both matter more than the permission list: a phrase you typed into a website, and a signature you approved. Neither involves the operating system at all, because in both cases you performed the action yourself with legitimate software.

That is the honest summary of the boundary. The platform protects the key on the device very well; it does not protect a decision you made about what to sign, and no permission setting changes that.

Judging a wallet before installing

Five checks in about five minutes, starting with the wallet permission list itself.

1. Read the permission list on the store page, before installing. Both stores show what an app can request, and this is the cheapest possible filter.
2. Check whether the code is open. For a wallet holding meaningful value, a published, audited codebase is a materially different proposition from a closed one.
3. Look at how long it has existed and how many people use it. Not proof, but a wallet with years of history and a large user base has had more adversarial attention than one released last month.
4. Find the recovery model. Does it produce a standard seed phrase you control, or is recovery tied to the company? Both exist legitimately; you should know which you are choosing.
5. See whether it works with a hardware wallet. Even if you do not use one now, the option matters as holdings grow.

Point four is the one people discover too late. A wallet where recovery depends on an account with the provider is a custodial arrangement in practice, whatever the marketing says, and it fails differently from a self-custody wallet.

Reviewing what you already granted

Both lists are worth an occasional pass, and they are checked in different places.

On the device: Settings → Privacy (iOS) or Settings → Apps → Permissions (Android). Look at what your wallet has, and turn off anything that is not on the short list above. Removing notifications or photo access costs you a convenience and nothing else.

On the chain: an approvals dashboard or scanner, checking both token allowances and NFT approvals — they appear on separate tabs in most tools, and checking only the first is the most common mistake in this whole area.

Two habits that make both easier: keep a wallet that only holds what is in play for anything that connects to sites, and treat approvals as expiring by revoking after a sale or a swap concludes rather than leaving standing grants.

More on what signing grants in web3 security, reading a preview before you sign in transaction safety, and key handling in wallet security. The permission model on the device side is documented in Apple's privacy guidance.

The short version

A wallet permission on your phone should cover five things: camera for QR codes, notifications, biometric unlock, secure storage, and network access. Photo library access, accessibility services, SMS and contacts do not follow from a wallet's job, and accessibility in particular should end the evaluation.

But the device list is the smaller risk. On-chain approvals survive uninstalling the app, changing your phone and switching wallets entirely, because they belong to the address rather than the software — so review that list separately, including the NFT tab, and revoke what you no longer need.