Security

Signing on device

Keys exist only for the moment of signing

1. 01
   Stored on devicePhrase sealed in the Keychain or Keystore
2. 02
   You unlockBiometrics or PIN, plus optional step-up
3. 03
   Derive, sign, dropThe key is never cached between transactions

This guide is the practical companion to our Privacy Policy.

The self-custodial model

There are two kinds of crypto wallets. Custodial wallets (like a centralized exchange) hold your keys for you, which means they can recover your account but they can also freeze it, lose it to a breach, or be compelled to surrender it. Self-custodial wallets — like mallow — give you the keys directly. You hold all the power, and all the responsibility.

In practice, that means:

• The first time you create or import a wallet, the app generates or accepts a 12- or 24-word recovery phrase locally on your device. New wallets get 12 words by default; 24 is available, and import accepts either.
• That phrase derives every key you will ever need for that wallet, across every supported chain (Solana, Ethereum, Tezos).
• mallow never sees, stores, or transmits the phrase. There is no server-side account that can recover or control your wallet.
• If you uninstall the app without backing up your recovery phrase, your funds are gone permanently.

Social sign-in is a different custody model

Signing in with Google or Apple is the other way to create a wallet, and it does not work like the above. Those keys are derived through Web3Auth (MetaMask Embedded Wallets) and are deterministic for your login identity — they are reconstructed from Web3Auth's key network inside the SDK rather than grown from a phrase you hold.

What follows from that:

• A social wallet has no recovery phrase, and it is recoverable: signing in again on a new device reproduces the same keys.
• Its security is the security of your Google or Apple account, plus the Web3Auth network. That one login reconstructs the keys for all three chains — Solana, Ethereum, and Tezos — so anyone who can complete it reproduces your whole wallet, not one chain of it.
• Ethereum and Tezos additionally share a single key. One secp256k1 key is stored for Ethereum and re-used as the Tezos seed, so a leak of either one alone exposes both chains.
• After login it behaves like an imported key: it is written to the same secure storage, and every later signature happens locally on your device.

Both models are self-custodial in the sense that mallow cannot move your funds. They differ in who else could, and in what happens when you lose the device. Choose deliberately.

What stays on your device

Your secrets live in the platform's own hardware-backed key store — the iOS Keychain, or the Android Keystore — and are encrypted at rest:

• The 12- or 24-word recovery phrase
• Private keys you imported directly, and the keys reconstructed by social sign-in
• A salted hash of your PIN — never the PIN itself
• Your biometric-unlock and app-lock settings, and the failed-attempt cooldown
• Session and authentication tokens
• The encryption key for the local database

On iOS these are marked available only when the device is unlocked, on this device only, which keeps them out of iCloud Keychain and means they can never be restored onto another device. On Android, your recovery phrase and private keys are each sealed under their own non-exportable AES-256-GCM key held in the Keystore; everything else is encrypted under a Keystore-protected key. Cloud backup and device transfer are disabled for the app outright.

Your keys cannot be restored from a backup onto another device — which is why restoring a phone does not restore your wallet. Only your recovery phrase does that.

For a wallet backed by a recovery phrase, per-chain keys are not stored at all: they are derived from the phrase on demand, used, and dropped. Imported keys and social sign-in keys are the exception — there is no phrase to derive them from, so the key itself is the stored artifact.

Derivation paths

Paths are per account index, where i is the account you picked in the import screen:

On import the app can also read two legacy Solana schemes — m/44'/501'/i' and the index-less m/44'/501' — so a phrase from an older wallet still finds its address. Wallets created by social sign-in use no derivation path.

How keys are used

When the app needs a key — for example, to sign a transaction you have approved — it reads the recovery phrase from secure storage, derives the key, signs, and lets both fall out of scope as soon as the operation completes. Keys are never cached in a field, a provider, or a service singleton, so no decrypted key material sits in long-running memory between transactions.

What does not stay on your device

The following data leaves your device when you use specific features. The Privacy Policy lists every recipient.

• Public wallet addresses (visible to all RPC providers and indexers by the nature of public blockchains)
• Transactions you sign and broadcast (public on the chain)
• Requests to the chains' RPC nodes — mallow's Solana proxy for most calls, Solana's own public mainnet node for staking and .sol name resolution, and public Ethereum and Tezos nodes
• Unsigned Ethereum transactions, sent to the simulation service that checks them before you sign (see Transaction safety)
• Your OAuth identity, sent to Web3Auth, if you use social sign-in
• Diagnostic data — crash logs, a 10% sample of performance traces, and breadcrumbs — sent to mallow's self-hosted error-tracking service with recovery phrases, keys, PINs, and tokens scrubbed before transmission. Screenshots and view-hierarchy capture are disabled
• Product analytics — which actions you complete or fail, and roughly what they were worth. Not which artworks or profiles you look at. It is sent to mallow's own backend, which forwards it to our analytics provider; your device never talks to that provider. Both this and the diagnostics above stop the moment you turn off "Share usage analytics" in Settings → Security & Privacy
• Push notification token (registered with Firebase and with mallow's backend, if you opt into push)
• Token swap quotes, plus token metadata and search queries, sent to Jupiter
• Token prices and charts, requested from CoinGecko
• NFT metadata you choose to mint (sent to our IPFS pinning service)
• An avatar request to DiceBear carrying your public username or wallet address as the seed, for accounts with no profile picture
• Anything you put on a profile, if you create one — username, bio, images, social links, and a verified email address if you add one. Your profile is public

Locks and gates

The app layers its own protections on top of the OS key store:

• PIN or biometrics — at least one is always active once setup completes. You may skip the PIN during onboarding only if you enabled biometric unlock, so there is no way to end up with no lock at all.
• Unlock — the lock screen prompts for biometrics first and falls back to your PIN. After 5 wrong PIN attempts a cooldown ladder starts at 30 seconds and climbs to 30 minutes, and it survives a force-quit.
• Privacy screen — the instant the app leaves the foreground its contents are blurred, and on Android the app-switcher thumbnail is blanked outright. A glance at your task switcher cannot reveal balances or history.
• App lock — after 60 seconds in the background, the app re-locks and asks for biometrics or your PIN. Shorter trips out of the app do not force re-authentication.
• Viewing your recovery phrase always demands re-authentication: biometrics only, with your PIN as the in-screen fallback. This is the most sensitive screen in the app, so an unlocked phone left unattended cannot leak your phrase.

Step-up authentication for transactions

You can require a second authentication for transactions above a value you choose, under Settings → Security & Privacy.

Once enabled, the default threshold is $100, and the check is strict — a transaction exactly at the threshold passes. It fails closed: any transaction whose value cannot be priced prompts anyway, which in practice means every transfer the app cannot price — Ethereum, Tezos, and NFTs. Tokens the app affirmatively prices at $0 are the one exception, and still pass without a prompt. Ledger wallets get the same gate, ahead of the hardware device's own confirmation.

Transaction safety

Ethereum transfers are simulated before you can sign them. The app checks the transaction's bytes and then runs it through an eth_simulateV1 simulation, and signing is blocked unless the only asset movement is the one you asked for — no approvals, no other outflow. It fails closed: if the simulation service is unreachable, the transfer errors rather than proceeding unchecked.

The wallet only signs transactions built by mallow's own flows. There is no WalletConnect, no Mobile Wallet Adapter, no deep-link signing intent, and no embedded web view. No third-party site or app can put a transaction in front of you.

A server can block signing, but never cause it

Every signing path first checks a mallow-operated switch that can disable a given chain and flow — for example, to stop a broken mint the moment we detect it. It is worth stating the bounds of that plainly:

• It can only refuse a signature. Nothing a server sends can lower a threshold, skip a prompt, weaken a gate, or produce a signature.
• The check runs before any key material is touched, so a blocked flow never loads your phrase or keys.
• It is off by default and fails open — a backend outage cannot brick your wallet — and nothing is written to disk, so a block cannot outlive the incident.

Your keys remain yours regardless. A hostile or compromised backend could refuse to serve you, or lie to you about balances, but it cannot sign anything.

Hardware wallet support

mallow integrates with Ledger hardware wallets over Bluetooth. When you connect a Ledger, the private key never leaves the hardware device. You confirm transactions on the Ledger's screen, and the app only ever sees the signed result. This is the strongest protection available for mobile self-custody.

Backing up your recovery phrase

Your recovery phrase is the only way to recover a wallet you created or imported. Treat it with the care you would give a passport or large amount of cash.

Recommended practices

• Write it on paper or stamp it on metal. Store it somewhere physically secure that is not your phone.
• For larger holdings, store backups in two separate physical locations so a single fire, flood, or theft does not destroy your only copy.
• Verify your backup by reading it back word-for-word before you fund the wallet.

Avoid these mistakes

• Do not type your recovery phrase into a website, chat, email, or any password manager that syncs to the cloud.
• Do not photograph or screenshot it.
• Do not store it in a notes app, even one you trust.
• If you copy your phrase to the clipboard from the settings screen, paste it where you intend and then overwrite the clipboard. It is not cleared for you, and on iOS the clipboard can propagate to your other Apple devices.
• Do not share it with anyone, including someone claiming to be mallow support. We will never ask for your recovery phrase.

Recognizing scams

Common scam patterns to watch for:

• Fake support. Anyone DMing you asking for your recovery phrase, asking you to "validate" your wallet, or asking you to import a "mallow recovery tool" is a scammer. mallow does not provide DM support and does not have a recovery tool that needs your phrase.
• Fake airdrops. Tokens that appear in your wallet asking you to visit a site to "claim" are usually traps designed to drain your wallet when you sign their transaction.
• Phishing apps and clones. mallow wallet is not on the App Store or Google Play yet. Until it is, the only official builds are TestFlight on iOS and Google Play closed testing on Android, both by invitation from mallow. If you did not get the link from us, it is not ours. The app is open source, so anyone can fork it, point it at a backend they control, and publish the result under a name that looks like ours.
• Address spoofing. Always verify the full recipient address before sending. Some attackers send dust to your wallet from an address that looks like one of your past contacts so it appears in your history.

What to do if something goes wrong

• Compromised device or recovery phrase exposure — assume the wallet is fully compromised. Generate a fresh phrase in a new wallet on a clean device, and immediately move funds out of the compromised wallet.
• Lost or stolen device — if you have your recovery phrase backed up, you can restore the wallet on any new device. The app is locked by your PIN and biometrics, but a determined attacker with physical access and time is a real risk; move funds from a known-stolen device promptly. Note that anyone holding your unlocked phone can delete the wallet from the app without passing a lock — harmless if your phrase is backed up, unrecoverable if it is not.
• Lost recovery phrase, device still works — generate a fresh phrase in a new wallet immediately and migrate your funds. Do not keep using a wallet whose phrase you cannot reproduce.

Reporting a vulnerability

If you have found a security vulnerability in the app, the site, or our backend, please email [email protected]. You can also use GitHub's private vulnerability reporting on mallow-labs/mallow-wallet, which reaches the same people. Please do not open a public issue for a security problem — public issues are indexed within minutes, and for a wallet that turns a report into a race.

Please include:

• A clear description of the issue
• Steps to reproduce
• The impact you observed
• The version or commit you tested

A proof of concept is welcome but never required. Report what you find even if you are not sure it is exploitable — deciding that is our job.

Please do not test against other users' wallets or against production data you do not own. Use your own wallets and your own test funds.

We do not run a paid bug-bounty program, and we would rather say so than let you spend time on the assumption that we do. What we do offer is a response within 3 business days, a triage decision within 10, a disclosure timeline coordinated with you, and credit by name in the release notes and advisory unless you would rather stay anonymous.