Argentum Wallet Privacy Policy

Last updated: August 29, 2026 · Applies to the Argentum Wallet mobile apps for iOS and Android, published by Argentum. On your phone the app appears as Ag Wallet.
The August 28, 2026 revision corrected three statements — in sections 3, 4 and 8 — that described the apps as more private than they are. The corrections are marked where they apply.

Scope

This policy covers the Argentum Wallet apps. It does not cover argentumhq.com, which has its own policy, and it does not cover Argentum AI, a separate product with its own policy at argentumai.app/privacy. Argentum Wallet is non-custodial: Argentum never holds, moves or has access to your funds. See the Terms of Use.

The short version

• Your recovery phrase and private keys never leave your device. Argentum has no copy, cannot read them, cannot reset them and cannot recover them for you.
• There is no account. No sign-up, no login, no email, no profile. Nothing in the app links a blockchain address to a person.
• We do not collect personal data for analytics, advertising or profiling. There is no advertising identifier and no product analytics in the app.
• Most blockchain requests go through an Argentum service, which sees the address it is asked about while it forwards the request — and stores none of it. Some do not. On Tron and the XRP Ledger, and on any network whenever that service is unreachable, your phone asks a public node directly — and that node's operator sees the address together with your IP. Both paths are described in full below, including what this policy does not promise.

1. Your keys and your recovery phrase

The recovery phrase is a standard BIP-39 phrase generated on your device. The keys for every supported network are derived from it on your device.

• Sealed by your phone's hardware. On Android the phrase is encrypted with a key held in the Android Keystore, in StrongBox where the device provides it. On iOS it is held in the Keychain, bound to that one device, and protected by the Secure Enclave where the device provides one.
• Released only when you unlock. The key requires a device passcode to exist at all, and using it requires your biometrics or your device passcode.
• Never transmitted, never written unencrypted, never logged — and never included in an error report.
• Shown only where it must be, and protected while shown. The screen that displays your phrase and the encrypted-backup screen are excluded from screenshots, screen recordings and the app-switcher preview: a capture of those screens comes out black.
• Encrypted backup is yours alone. If you export a backup, it is a file encrypted with a password you choose and keep. Argentum never receives the file or the password and cannot open it. If you lose the password, the file is unusable and there is nobody to ask.

The consequence is stated plainly because it is the point of a non-custodial wallet: if you lose your recovery phrase and your device, no one — including Argentum — can restore your funds.

2. No account, no identity

Argentum Wallet has no user accounts. There is no registration, no sign-in, no password held by us, no email address, no phone number and no profile. We do not assign you an identifier, we do not use an advertising identifier, and we run no product analytics or usage tracking inside the app. We therefore hold no way to associate an address with a person.

3. What the app sends, and to whom

The wallet makes four kinds of request on its own. Three are on by default because it needs them to be useful; the fourth — error reports — is off unless you turn it on. The Android app has two more that only happen when you go looking for them (3.5), and both apps can hand a link to your phone's browser (3.6).

3.1 Blockchain requests

To show balances and history the wallet must ask a blockchain node. There are three ways it can get there, and they are not equally private. The app always tells you which one is in use for each network, in Settings.

1. Your own node, if you set one. Nothing about that network reaches Argentum. See section 5.
2. Argentum's node service — the default, and what happens for Solana, Ethereum, Base, Arbitrum, Optimism and Polygon. The request goes to an Argentum service that forwards it to a commercial node provider, so the provider receives our address rather than yours.
3. A public node, asked directly by your phone. This is the case the earlier version of this policy did not mention, and it is the one where you are least protected.

When your phone asks a public node directly, that node's operator sees the address you are asking about together with your IP address. Argentum is not in the middle and cannot be: there is nothing for us to see, and nothing for us to shield. It happens in two situations, and one of them is permanent:

• Tron and the XRP Ledger, always. Argentum's service does not serve those two networks at all. Every balance and history request for them goes from your phone straight to api.trongrid.io and xrplcluster.com. There is no setting that changes this — the only way to avoid it is to point those networks at your own node.
• Any other network, when the service is unreachable. If Argentum's service times out or fails, the wallet retries against the network's public node (api.mainnet.solana.com, ethereum-rpc.publicnode.com, mainnet.base.org, arb1.arbitrum.io, mainnet.optimism.io, polygon-bor-rpc.publicnode.com) rather than leaving you without a balance. It is not silent: the app records it and Settings says so for the next ten minutes.

What those operators do with what they see is governed by their own policies, not by this one. Everything that follows in this section describes the Argentum service, which is the path we can make promises about.

What that service sees, while the request is in flight: the address being queried and any transaction signatures in the request, the node's answer, the JSON-RPC method, the network, the latency, and — as with any internet connection — your IP address.

What survives the request: one aggregated line per network and method, with a count, an error count and average and maximum latency. It contains no address, no IP, no client identifier and no per-request timestamp. Specifically:

• Addresses are never written to a database or a file. The service's request path does not talk to any database at all.
• Responses are not cached; every response is returned with Cache-Control: no-store.
• Rate limiting uses a hash of your IP or device identifier salted with a value generated fresh each time the service starts, so the identifiers cannot be recovered and do not survive a restart.
• Error messages returned by node providers are replaced with our own text before being handled, because providers echo the offending parameter — that is, the address — back in them. Reports sent to our error monitoring have addresses and node URLs redacted and the request body dropped entirely.
• Metrics are aggregated by network and method only. There is no per-address, per-IP or per-client counter.

The service cannot sign anything. It holds no keys. This is true of every path above, not only ours: when you send a transaction, your device signs it, and whatever carries it to the network — our service, a public node or your own — receives bytes that are already signed. Altering them would break the signature and the network would reject it.

See also “What this policy does not promise” below — that section is part of this one.

3.2 US-dollar valuation

To show what your holdings are worth, the app asks an Argentum price service for prices. What leaves your device is the list of asset identifiers you hold — network, family and, for tokens, the contract address. What does not leave your device: any quantity, any value, any of your wallet addresses and any key. The multiplication of quantity by price happens on your phone. The service is prohibited from recording, persisting or logging which assets a client asked about, and that prohibition is enforced by tests, not only by policy. If the service is unavailable the wallet still works and shows on-chain quantities without a dollar value.

3.3 News headlines

The wallet can show press headlines about the assets you hold. The request it makes carries only a language and the word “crypto” — it is identical for every user of the app in the same language, carries no address, no asset list, no device identifier and no session. The matching against what you actually hold happens on your phone, after the headlines arrive.

3.4 Error reports — off unless you turn them on

Crash reporting ships disabled and only runs if you enable it in Settings. When enabled, it sends crash and error reports to our error-monitoring provider. It carries no screenshots, no view hierarchy, no session recording, no touch trail, no performance traces and no usage metrics; addresses and node URLs are redacted from any text, and request bodies are dropped. One thing we cannot filter and will not pretend otherwise: your IP address travels with the connection to that provider, outside the report itself, so no client-side scrubbing can remove it. That is a reason the setting is off by default.

3.5 Connecting to a dApp — Android only

The Android app can connect your wallet to a decentralised app, through the Connections screen. The iPhone app has no such screen and none of this applies to it. Two mechanisms sit behind it, and neither does anything until you open that screen — they are not started when the app launches.

• WalletConnect. Opening Connections brings up a WebSocket to the WalletConnect relay, operated by Reown. Pairing and every message afterwards travel through it. When you approve a session, the dApp receives the public address you approved it for — that is the point of connecting, and nothing happens until you tap approve. The relay identifies our app by a project id that is the same in every copy of the wallet and says nothing about you. The SDK's own analytics are switched off in our build, explicitly and against its default. As with any connection, the relay sees your IP.
• Mobile Wallet Adapter. Lets a Solana app on the same phone ask this wallet to sign. The association is local to the device; the remote variant of that protocol, which would route through a server, is not enabled in this app.

Argentum runs neither the relay nor the dApp. What a dApp does with an address you gave it is governed by its policy, not by this one. You can see and revoke your sessions from the same screen.

3.6 Links that open in your browser

Some screens offer a link — “view on the explorer” next to a transaction, a news headline, a link to Argentum AI. Tapping one hands the address to your phone's browser; the wallet does not fetch it. The site that opens then sees your IP and whatever is in the link, which for a block explorer is the transaction or address you were looking at. That is ordinary web browsing, outside this app and outside this policy, but it is worth knowing that the tap leaves the wallet.

4. What Argentum never receives

• Your recovery phrase, your private keys or anything derived from them that could reconstruct them.
• Your app PIN.
• Your balances, your holdings' quantities or their value.
• Your encrypted backup file or its password.
• Your contacts, photos, files or location. The app requests no such permissions.

Device permissions. On Android, three permissions are ours, in the sense that we asked for them and a feature you can see depends on each one:

• Internet access — every request in section 3.
• Camera — used only while you are scanning a QR code, with no image stored or transmitted. Android also asks you for it the first time, and the wallet works without it if you paste the address instead.
• Show notifications — for the balance alerts in section 6.

Seven more appear on the app's Play listing, and an earlier version of this policy wrongly said there were only three. They are added automatically by the Android libraries the app is built with, not requested by our code, and none of them asks you for anything or gives the app access to your data — Android grants them at install time because they change nothing a user would need to decide. They are:

• USE_BIOMETRIC and USE_FINGERPRINT — from the biometric library, so the system can show you the fingerprint or face prompt that unlocks the wallet. They let the app ask the system to authenticate you; they do not give it your fingerprint or your face, which never leave the phone's secure hardware.
• ACCESS_NETWORK_STATE, WAKE_LOCK, RECEIVE_BOOT_COMPLETED, FOREGROUND_SERVICE and a private DYNAMIC_RECEIVER… permission that only this app can use — from WorkManager, the Android component that runs the scheduled balance check in section 6: to know whether there is a connection before trying, to finish a check that started, and to still be scheduled after you restart the phone.

What matters is what is not there, and that has not changed: no location, no storage or file access, no contacts, no microphone, no phone or SMS, and no advertising identifier. On iOS the app asks for two things only — the camera, to scan a QR code, and Face ID or Touch ID, to unlock the wallet and authorise a signature.

5. Using your own node

You can point any network at a node you control. When you do, that network's requests go directly to your node and Argentum sees nothing for it — not the addresses, not the balances, not when you looked. Your node's URL is treated as a credential: it is stored on the device and displayed only masked, because for several providers the access key is part of the URL. If your own node fails, the wallet tells you and does not silently reroute the request anywhere else.

6. Balance alerts — Android only, for now

If you turn on alerts for movements in your accounts, your device performs the check on a schedule. There is no push service and no address is registered on any Argentum server. That design is also why an alert arrives on the next check rather than instantly — it is the cost of not telling a server which addresses to watch.

The iPhone app does not have this feature yet and sends no notifications at all. If it gains them, they will work the same way and this section will say so.

7. The Argentum AI link

The wallet can note that you also use Argentum AI. That note is stored on your phone and nothing else happens automatically: for an address to reach your Argentum AI portfolio, you copy it and add it there yourself. Argentum AI never receives from this app how much you hold or of what; if you add an address there, it reads balances from the public chain, as anyone could.

8. What this policy does not promise

An honest policy states its own limits. These are ours.

• The node operator sees the address anyway, and sometimes your IP with it. On the networks Argentum's service handles, it forwards your request to a commercial node provider, which sees the address being queried but receives our IP instead of yours. On Tron and the XRP Ledger there is nothing in the middle today: your phone asks those nodes directly and their operators see the address and your IP together. The same is true, temporarily, on any network when our service is unreachable and the wallet falls back to a public node. An earlier version of this policy said your IP never reached the provider; that was wrong, and section 3.1 now says exactly when it does. What those operators do with what they see is governed by their own policies, not by this one.
• The blockchain is public. Your addresses and every transaction they make are public records that anyone can read in a block explorer. No wallet and no intermediary changes that, and this one does not claim to.
• “Not stored” is not “not seen”. While a request is being forwarded, the address exists in the memory of the service handling it. What we guarantee is that nothing is written down when the request ends; we do not claim that an operator with access to a running process could not observe traffic in flight.
• If you enable error reports, our error-monitoring provider receives your IP address with the connection, as described in 3.4.
• If you connect to a dApp on Android, that dApp has the address you approved and the WalletConnect relay carried the messages. Neither is ours, and revoking the session in the app stops future messages — it does not un-tell the dApp what it already learned. See 3.5.

9. Children

Argentum Wallet is not directed to children and we do not knowingly collect information from them. Since the app has no accounts and collects no personal data, there is no profile to delete.

10. Your rights

Because we hold no account and no personal data tied to you, there is generally nothing for us to access, correct or erase on request. The exception is correspondence: if you write to us, we keep that email for as long as we need it to answer you. Depending on your jurisdiction (for example the GDPR in the EU, the CCPA in California, or Law 25.326 in Argentina) you may have rights over that correspondence — write to support@argentumhq.com. We do not sell personal data and we do not share it for advertising, cross-context behavioural advertising or profiling — there is nothing here to sell. The transfers this policy does describe, and which the store listings declare as data sharing, are the operational ones in section 3: a node operator receiving the address it is being asked about, and a dApp receiving an address you approved.

11. Changes

If this policy changes, this page changes and the date above changes with it. Material changes will also be reflected in the app's store listings.

12. Contact

Argentum · support@argentumhq.com