Privacy Policy

BAGHOLDER Version 1.0 — Last updated: October 6, 2026

1. Introduction

BAGHOLDER LLC, an Ohio limited liability company ("BAGHOLDER," "we," "us," or "our"), offers BAGHOLDER, a non-custodial cryptocurrency software tool. This Privacy Policy explains how we collect, use, disclose and protect information when you use our mobile application ("App"), the BAGHOLDER server the App talks to, and the private-key export page the App opens (Section 6.2). It does not cover the services of third parties, such as payment and payout providers, which have their own privacy policies (Section 6).

The App helps you buy, swap, send and sell tokens using your own non-custodial embedded wallet on supported blockchain networks (currently: Base, Optimism, Arbitrum, Avalanche, BNB Smart Chain, Polygon, and Solana). Buys, sells and swaps are carried out as decentralized exchange (DEX) swaps, which your wallet signs. We do not hold or take custody of your funds, and our server cannot sign transactions from your wallet.

Transactions on a public blockchain, including your wallet address and the amounts you move, are public and permanent. They are recorded by the network, not by us, and neither we nor anyone else can delete or change them.

2. Information Stored on Your Device

The following data is stored on your device. Secrets (sign-in tokens, and the account protection data below) are kept in your phone's secure storage (iOS Keychain / Android Keystore). Everything else is kept in the App's local database. That database is not separately encrypted by the App: it is protected by your phone's own storage encryption (when your phone has a lock screen), and your phone's operating system keeps it private to the App.

• Wallet addresses (your EVM and Solana addresses)
• State of residence (the U.S. state you declared)
• Age verification status — the App records only the time you passed the age check. Your date of birth is not stored.
• Bags and token lists (your portfolio preferences)
• Order history (records of the on-chain transactions the App made for you: buys, sells, swaps and sends), including purchases and orders that are still pending
• Send records (including the addresses you send to, which are stored with your send records and carried in your encrypted backup — see Section 6.4)
• Portfolio snapshots (value summaries; those older than 365 days are pruned)
• Issue reports (a local log of errors the App ran into, recorded automatically). These are not sent to us automatically; they leave your phone only if you attach them to a support email (Section 9.1).
• App settings and preferences (display preferences, disclosure, terms and privacy acceptance records, etc.)
• Account protection data — a random identifier the App generates for this installation (it is not a device identifier), and a setting recording that this phone confirms sends, sales and cash-outs with your BAGHOLDER PIN rather than Device Authentication. Both are kept in your phone's secure storage. Both are sent to our server, over an encrypted connection, with each account-protection check; the server keeps a one-way hash of the identifier, that setting, and the other phone details listed in Section 3. Your PIN itself is not stored on your device.

Apart from the encrypted cloud backup described below, the account protection data above, issue reports you choose to email us, and the information each feature sends to our server as described in Section 3 (for example, your wallet address and state code when you buy, sell, swap or send), this data remains on your device.

The App keeps an encrypted cloud backup of most of the above — Section 6.4 lists exactly what. Issue reports are not included. The backup is automatic rather than something you switch on: your local data is encrypted on your device with a key derived from your wallet signature, and the resulting opaque ciphertext is uploaded shortly after your records change. Our server does not hold the decryption key and cannot read the contents.

3. Information Stored on Our Server

Our server stores the following data in an access-controlled database:

• Payment charge records (payment provider and its session or order identifiers, the provider's checkout link, charge amount, fee amounts including the provider's fee, wallet address, chain, the stablecoin used, state code for compliance check, status, transaction hashes, timestamp)
• Gas funding records (wallet address, transaction hash, native token amount, chain, timestamp)
• Treasury ledger / fee records (platform fee and gas accounting for tax and audit purposes: chain, amount, fee type, transaction hash, wallet address, timestamp)
• Swap event logs (per-token outcomes of swaps: wallet address, chain, token symbol, amounts, DEX used, success or failure reason, transaction hash)
• Swap fee and swap check records — when you swap one token for another: your wallet address, any separate spending address, the state code, the chain, the tokens involved, the dollar value, the fee and its transaction hash, and whether the swap was allowed.
• Server error records (errors our server ran into while handling your requests: the error message, the request path, and your wallet address when known)
• Usage events (e.g., app opens, feature usage, purchase outcomes, and the reasons a buy was blocked by a pre-buy check — including the chain, amount requested and token symbols) for service improvement and compliance. Each event is stored with your wallet address; after 90 days the address is replaced with a keyed one-way hash, and events are automatically deleted after 1 year. An event's details may include identifiers such as a transaction hash, and these are not removed when the address is hashed.
• Wallet address bindings (a record pairing your EVM address with your Solana address, used to authorize Solana-side features without re-authentication). Your EVM address is established when you sign in. The paired Solana address is the one the App reports for your account; we do not verify a signature from the Solana address. Each Solana address can be bound to only one account.
• Wallet-to-account bindings (a record linking each wallet address you sign in with to the account identifier issued by our wallet provider, Privy). This binding is established by verifying an authentication token issued by Privy and is used to enforce the one-gas-seed-per-person rule and suspension provisions described in our Terms of Service (Section 6) — it is not used to impose a per- account limit on how much you may purchase. No additional personal information is collected through this binding.
• Onboarding attestation records (Section 3.1) — events recorded during signup before you have a wallet, used to maintain an audit trail of the eligibility checks we applied. Keyed by a per-device fingerprint, not your wallet address. The state-of-residence events (your attestation at signup, pass or fail, and any later change of state in Settings), and only those events, also include the request IP address.
• Suspended-wallet list (wallet addresses we have refused service to, for example after a sanctions match, with a short text reason and timestamp). Used to enforce the suspension provisions in our Terms of Service. Deleting your account does not remove a wallet from this list, so that account deletion cannot undo a suspension. A suspended wallet retains the ability to export its private key through the private-key export page (Section 6.2; see Terms, Section 4.1); the suspension blocks only starting a new payment for a purchase through the App, receiving network gas from BAGHOLDER, and creating new shared bags.
• Shared bag configurations (the bag name, its token list with market data shown on the card, and your wallet address for attribution) if you choose to share a bag via the sharing feature. The amounts you hold are not included.
• Encrypted backups (opaque ciphertext only; server cannot decrypt — see Section 6.4).
• Balance and token-account caches — our server reads the token balances of your addresses on your behalf, covering all the coins you hold and not only the tokens in your bags, so the App can show them. It keeps short-lived caches keyed by wallet address, used to reduce RPC costs and improve responsiveness. It also keeps a record of which token accounts your Solana wallet has (Solana ATA membership), so we charge the correct account-creation rent, and short-lived records of the swap quotes issued for your buys.
• Added tokens — If you add a token, the App asks our server for its price using only the network and contract address. We keep an anonymous list of which tokens are added, with no wallet or account attached.
• Send check records — when you send, the recipient address and the token are sent to our server once, to be checked against U.S. sanctions lists. The recipient address is not stored. We keep a record of the attempt: your wallet address, any separate spending address, the network, the token, the state code, and whether the send was allowed, plus its dollar value when known.
• Account protection records — kept for the PIN and phone checks described in our Terms of Service (Section 7.4). Per account, keyed by your wallet address: a salted, one-way scrambled form of your BAGHOLDER PIN (not the PIN itself), a count of wrong PIN entries made from phones on which your PIN has never been entered and any lock that results, the times your PIN was set or reset, which phone asked for a reset, and when a reset was last cancelled. For the 24 hours after a reset we also keep the scrambled form of the previous PIN, so that the reset can be cancelled. Per phone your account is signed in on: a one-way hash of a random identifier the App generates (not a device identifier), computed together with your account, so the same phone signed in to two accounts has a different stored value on each; whether it is an Android phone or an iPhone; when it was first and last seen; whether it is trusted or frozen; whether the App found that phone with no screen lock; and a count of wrong PIN entries made on that phone and any lock that results. When an account has more than six of these phone records, those for phones on which your PIN was never entered, which are not frozen and have not been seen for 30 days, are deleted. Your PIN is sent to our server over an encrypted connection to be checked; we do not store it in a form that can be read back, and we cannot recover it for you.
• Sell (cash-out) session records — created when you start a sell: the payout provider and the sub-provider identifier used, your wallet address, the chain, the asset, the crypto amount, your chosen payout method, the state code used for the eligibility check, an idempotency key, the provider's transaction identifier, the redirect link to the provider's page, the status, and any error text returned to us. As the sell progresses we also record what the provider reports back: its own status, the fiat payout amount and currency, the provider's fee, the settled crypto amount, the deposit transaction hash, and timestamps. These rows contain no personal information beyond your wallet address and state code — the same categories as a payment charge record.
• Sell fee records — created only when a BAGHOLDER sell fee applies to a sell: your wallet address, the chain, the asset, the gross and fee amounts in that asset, the fee rate, the price reference used, the fee transaction hash and nonce, the amount verified on-chain, the status (armed, verified, or skipped and why), the sell disclosure version and fee label you accepted, the payout session reference, and any refund transaction hash. These rows contain no personal information beyond your wallet address.
• Payout provider webhook records — the raw notification body a payout provider sends us about your order, stored so that we process each notification exactly once and ignore duplicates. This body can contain your wallet address, the amounts involved and other order details the provider includes. We do not ask the provider to include your name, email address or identity details, but we do not control what a notification contains and we store the body as received. See Section 7 for how quickly the body is blanked.
• Payment provider notification records — for buys, we keep only the provider's event identifier, its transaction identifier and the status it reported (for example, a completion notice), so each notification is processed once. These records are deleted after 180 days.
• Per-state activity aggregates and snapshots — aggregated rolling-12-month totals of purchase volume, completed cash-out (sell) volume, swap and send activity, platform fees, purchase count, and active-user count, broken out by the state code recorded on each transaction. Used to monitor compliance with state licensing requirements. A completed sell counts toward these totals on the same basis as a purchase. A snapshot of these aggregates is persisted to a separate table approximately once per calendar quarter, to provide a historical record of what we knew when. The aggregates and snapshots do not contain wallet addresses or any individual purchase, sell, swap or send records — only state-level totals.
• Server operational logs — separate from the database above, our server writes operational logs about the requests it handles (for example the request path, the time and the outcome). These logs do not contain IP addresses: our server does not write the IP address of any request to its logs, including sign-in, payment and requests refused for exceeding a rate limit, and it stores an IP address only on the state-of-residence onboarding records (Section 3.1). Our hosting provider keeps these logs for up to 30 days. We use them to operate and protect the service. Our hosting provider (Railway), whose network passes each request to our server, records each request in its own request log, including your IP address, the time, the page requested and your device's browser or app identifier; it keeps that log for up to 30 days. We can view it for up to 30 days to operate, secure and support the service, and do not copy the IP address into our own records.

We use these records for payment processing, service improvement, security, legal and regulatory compliance, and feature functionality. Apart from the IP address on the state-of-residence onboarding records (Section 3.1), and anything a payout provider puts in a notification it sends us (see "Payout provider webhook records" above), these records do not include your name, email, phone number, mailing address, date of birth, government ID, biometric data, IP address, or user-agent string. We treat wallet addresses as pseudonymous identifiers that are personal information for the purposes of this policy and of U.S. state privacy laws such as the California CCPA/CPRA. Wallet addresses are public on the blockchain, but they can be linked to other information about you.

For some record types, after a fixed period, wallet addresses are automatically replaced with a keyed one-way hash (see Section 7 for the per-table schedule). Other record types keep the address until you delete your account. Hashing keeps the underlying financial records intact for accounting and audit while removing the direct link to your wallet identifier.

Your email address on a buy. The App sends our server the email address of your sign-in account, over an encrypted connection, only when the payment provider chosen for that buy requires it in its payment API, and our server then forwards it to that provider. Neither our current payment provider, Coindisco, nor the Coinbase Onramp fallback described in Section 6.1 requires it, so on a buy today your email address is not sent to our server at all. Only an older Coinbase checkout, which our server uses only if none of those providers is set up, requires it. No table in our database stores your email address.

3.1 Onboarding attestation records

During signup, before you have a wallet, the App sends events to our server to record outcomes at each gate (age verification, state selection, and legal-document review). These records exist so that we can show, to a regulator or as otherwise required by law, how we screened our users. The events we record:

• Age verification outcome — pass or fail. On a fail we record an age band (under 13, 13–15, or 16–17) and the attempt number; on a pass, the number of earlier failed attempts. We do not record your date of birth — only the band the attempted age fell into.
• State attestation outcome — pass or fail, with the state code you attested (so a NY resident who attempts to attest NY before correcting to a supported state shows in the audit trail as having attested NY first), plus the attempt number or the number of earlier blocked attempts.
• Legal-document review events — that you opened the Disclosure, Terms, or Privacy screen; and, if you left it without accepting, how long you spent on it and whether you scrolled to the bottom.

Each event is keyed by a per-device fingerprint — a random UUID issued by our server on first launch, stored in your device's secure storage. We do not link the fingerprint to your wallet, name, email, or any identity on our side; it exists only so we can recognize repeat attempts from the same install. The fingerprint resets if you reinstall the App on Android (iOS Keychain persists across reinstalls).

We also store the request IP address, but only with the state-of-residence events — your attestation at signup (pass or fail) and any later change of state in Settings — not with the other onboarding events. It is the address our hosting provider's network reports for the request, not one the App supplies. We use it only as a passive cross-reference for the audit trail (and could disclose it as described in Section 5.1). It is kept for one year, we do not link it to your wallet or payment records, and we do not display it back to you anywhere in the App.

Sanctioned-region check. To comply with U.S. sanctions law, when you sign up, sign in, buy, sell, cash out, swap or send, and on certain other account requests, our server looks up the network location of the request in a location database and refuses it if it comes from Cuba, Iran, North Korea, Syria, or the Crimea, Kherson, Zaporizhzhia, Sevastopol, Donetsk or Luhansk regions of Ukraine. The lookup happens in memory; the IP address is not stored by this check (the separate state-of-residence record above is the only place an IP address is kept). When a request is refused we record, in our operational logs (Section 3), only the region, the kind of request, the time, and a keyed one-way scrambled code derived from your wallet address (or, before sign-in, the IP address) — not the address itself. The location database is an approximate signal (a VPN, for example, can hide a location) and is one check among several, not a guarantee. IP geolocation by DB-IP (https://db-ip.com), licensed under CC BY 4.0 (https://creativecommons.org/licenses/by/4.0/).

We treat the captured IP address as a signal, not a proof. Many factors — VPNs, mobile carrier NAT (millions of mobile users share egress IPs through the same carrier), corporate networks, school networks, IPv6 transition, Tor — make the IP address of a request an unreliable indicator of the user's actual physical location. We do not treat the IP address as proof of where you live or where you were when you attested. Your self-attested state of residence is the primary record; the IP address is one secondary cross-reference for the audit trail. If you later update your state of residence (see Settings → State of Residence), we record a separate state_changed event with the prior and new state codes — this preserves the full history of every state you have attested, which is the durable record we rely on.

Soft-block. If the same device records three rejected attempts at the age or state gate within 24 hours, the App will display a "we can't verify your eligibility right now, please try again later" message and disable further attempts until 24 hours after the first of those attempts. This check runs in the App, on your device. It is a friction control to prevent rapid retry-with-different-input attacks.

These records are retained for one year (see Section 7). We do not link them to your wallet, payment, or order records, even after you have a wallet, and deleting your account does not reach them because they are not keyed to your wallet.

4. Information We Do NOT Store on Our Servers

We do not store on any BAGHOLDER server:

• Private keys or wallet seed phrases
• Your name, email address, or phone number (your email address passes through our server only on a buy whose payment provider requires it — Section 3 — and is not stored there; messages you email us are kept in our email system, as described in Section 9.1; any identity/KYC data, which may include a phone number, is collected directly by the licensed payment provider on its own checkout page; see Section 4.1)
• Date of birth (only the age band on a rejected attempt — Section 3.1)
• Biometric data (Device Authentication returns a yes/no result only)
• Bank account credentials or login information
• Social Security numbers or government IDs
• Location data from your device (we do keep the U.S. state of residence you declare, on each purchase, sale, swap and send record, to apply state rules)
• IP addresses, with one exception: the state-of-residence onboarding records in Section 3.1. Our server does not log or store the IP address of routine requests (Section 3). The sanctioned-region check in Section 3.1 reads the address in memory and does not store it.

4.1 Identity Data at Checkout (Payment Processing)

When you fund a purchase, our payment provider, Coindisco (an aggregator that routes each purchase to an underlying licensed provider), runs the fiat-to-stablecoin step on its own hosted checkout page, opened in an in-app browser tab.

• To create the order we send the provider your wallet address, the amount, the destination chain and the stablecoin, and we forward your IP address so the provider can run its own fraud and geography checks. Where a provider's API requires it, we also forward your email address (Section 3).
• Any identity or KYC information the provider requires — which may include a phone number — is collected directly by the provider on its own page, under the provider's privacy policy. BAGHOLDER does not ask for it, forward it or store it; for a buy, we keep only the provider's event identifier, transaction identifier and status from its notifications (Section 3).
• BAGHOLDER's database does not store your phone number or email address — payment_charges and related tables have no column for either.
• We do not use your email address or any identity information for marketing or support outreach.

4.2 Identity Data at Cash-Out (Selling)

Where selling is available, your cash-out is handled by a third-party payout provider reached through the Coindisco aggregator. Today that provider is Transak, reached through Coindisco. The provider performs identity verification on its own hosted page, under its own privacy policy.

• The provider collects your identity documents and payout details directly from you: typically a government photo ID, your Social Security number, a selfie, and your card details. BAGHOLDER does not ask for, forward or keep any of it, and no BAGHOLDER database has a column for any of it. (If a provider puts such a detail in an order notification it sends us, it is handled as described for payout provider webhook records in Section 3.)
• We do not send the provider your name or your email address on a sell. We send only what is needed to price and create the order: the chain, the asset, the amount, the payout method, the currency, and your state (as the provider's region).
• Your IP address is forwarded to the provider in the request header so that it can run its own geography and fraud checks. It is passed through only — we do not log or store it, and there is no IP column on any sell record (Section 3).
• The provider's own privacy policy governs everything it collects and is presented on its page before you confirm.

5. How We Use Information

• Age verification: To confirm you are 18 or older.
• Buy execution: To orchestrate on-chain swap transactions through your non-custodial wallet.
• Onramp payment: To create payment sessions with our licensed payment provider that fund your wallet with a USD stablecoin (such as USDC) ahead of swaps.
• Solana account setup: On Solana, each new token requires a one-time on-chain Associated Token Account (ATA) which is created through your wallet using a small refundable SOL deposit.
• Sell execution and cash-out: To price a sell, create the order with the payout provider, hand you off to the provider's page, and record the outcome for our financial, audit, and state-threshold records.
• Swaps and sends: To build the transactions your wallet signs, and to run the sanctions and eligibility checks before a send or swap.
• Account protection: To check your PIN and the phones your account is signed in on, as described in our Terms of Service.
• Record backup: To upload an encrypted copy of your local activity records when they change, and to restore it on a new install of the App with the same wallet. The backup is encrypted on your device; we cannot read its contents.
• Portfolio tracking: To display your holdings, read from the blockchain for your address, and the history of what the App did for you. The App does not display cost basis or gains.
• Price display: To show current cryptocurrency prices in the app.
• Service improvement: To understand feature usage and improve the App experience.
• Bag sharing: To publish the bags you choose to share, and to filter bag names for profanity before publishing.
• Compliance, security and fraud prevention: To check wallet addresses against U.S. sanctions lists (when you buy, sell, swap or send, when we fund network gas, and for a send also the recipient address and token), using copies of those lists held on our server, so the address is not sent to an outside screening service; to run the sanctioned-region check (Section 3.1); to enforce our Terms of Service; to detect and prevent abuse; and to keep the financial and audit records the law requires.
• Support: To answer the messages you send us.

5.1 When We Disclose Information

We do not sell your personal information, and we do not share it for cross-context behavioral (targeted) advertising. The App contains no advertising or marketing-analytics software; the only third-party analytics-type services it uses are Firebase Crashlytics and Firebase Remote Config (Sections 6.3 and 6.3.1). We disclose information only:

• To service providers and the providers you use, as described in Section 6, to carry out the purposes in Section 5;
• To comply with law, including a subpoena, court order, or other legal process or a request from a government authority that we believe in good faith we must answer, and sanctions, tax and other legal reporting obligations;
• To protect the security of the service, investigate or prevent fraud, sanctions violations or other illegal activity, enforce our Terms of Service, and protect the rights, property and safety of BAGHOLDER, our users and others;
• In a business transfer — if BAGHOLDER is involved in a merger, acquisition, financing, reorganization or sale of all or part of its business, the information we hold may be transferred as part of it, subject to this policy or one at least as protective; and
• With your direction or consent, for example when you share a bag or email us.

6. Third-Party Services

BAGHOLDER integrates with third-party services that process your data under their own privacy policies:

6.1 Onramp Payment Provider (Payment Processing)

Our payment provider, Coindisco (an aggregator that routes each purchase to an underlying licensed provider), processes the USD-to-stablecoin conversion via a hosted onramp and delivers the stablecoin directly to your wallet. The provider (and the underlying business) may collect payment information and identity data under their own privacy policies. What we send it is listed in Section 4.1. We receive back the provider's session or order identifiers, its checkout link, its fee, the order status and confirmation of delivery; we do not receive any of the KYC information the provider may collect.

Tax reporting: BAGHOLDER does not prepare or file tax forms on your behalf and does not issue tax forms. We provide information to a tax authority only where the law requires it (Section 5.1). Any tax form relating to your crypto activity would come from a third party, such as the payout provider you cash out through. Activity in the App shows your history, read from the blockchain for your address. Our Terms of Service describe the tax consequences you are responsible for; we do not give tax advice.

The provider's own privacy policy is presented on its checkout page before you pay. If Coindisco cannot route a purchase, it may instead be handled by Coinbase Onramp, under Coinbase's own terms and privacy policy. We do not send your email address to Coinbase on such a purchase; Coinbase collects whatever it needs on its own page. Section 3 describes the one older Coinbase checkout that would need it.

6.2 Privy (Wallet Creation)

Privy creates and manages your non-custodial embedded wallet using advanced cryptographic techniques. Privy may collect your email address or social login credentials for authentication. We do not receive or store your login credentials. The App reads the email address of your sign-in account from Privy and includes it with a buy only when that buy's payment provider requires it (Section 3), and our server stores the account identifier Privy issues to you (Section 3, wallet-to-account bindings). See: privy.io/privacy

Private-key export page. The export page the App opens is a BAGHOLDER web page that runs Privy's sign-in and Privy's own key-reveal window. The page itself sends nothing to our server; the key is shown to you by Privy, and we do not receive it.

6.3 Firebase Crashlytics (Crash Reporting)

Operator: Google LLC. Purpose: collecting crash and stability diagnostics so we can identify and fix bugs.

When the App crashes or encounters an uncaught framework error, Crashlytics uploads:

• A random Crashlytics Installation UUID (a per-install identifier generated by Google; we do not link it to your wallet, account, or any identity on our side).
• The error message and the stack trace of the failing code path.
• Device model (e.g. "iPhone 12") and operating system version.
• App version and build number.

Before a crash report leaves your device, our error sanitizer removes the following from the error message:

• Wallet addresses (both EVM and Solana formats)
• Transaction hashes and signatures
• Authentication tokens (Privy JWTs)
• Onramp session identifiers and idempotency keys (and any other identifier in the same format)

We do not attach your name, email address, wallet address or transaction history to crash reports, and we do not set a user identifier in Crashlytics. Crashlytics also receives your IP address at upload time, which Google states it uses for geographic distribution analysis and discards afterward.

Retention: Google states that Crashlytics retains crash reports for up to 90 days. We use crash data only to find and fix problems, not for advertising, and we do not disclose it to anyone other than Google except as described in Section 5.1.

See: firebase.google.com/support/privacy

6.3.1 Firebase Remote Config (Feature Flags)

We also use Firebase Remote Config, operated by Google, to control feature flags and the minimum supported app version. The App sends no wallet address or account data to Remote Config. As with other Firebase services, a request carries the App's identifier and version, a Firebase installation identifier, and reaches Google from your IP address.

6.4 Encrypted Cloud Backup

The App keeps an encrypted cloud backup of your local data. It is automatic: an upload follows shortly after your records change, so a lost or replaced device does not mean lost records. It covers your bags, your buys, your sells and cash-outs, your token swaps, your sends (including the addresses you sent to), stablecoin conversions, our platform fees, gas purchases, your settings (which include your wallet address, your state of residence and when you passed the age check) and your portfolio snapshots — everything the App records locally except issue reports, caches and in-flight queues, which are rebuilt rather than carried.

Two of those are carried but do not each trigger an upload of their own: a change to your settings alone, or to your portfolio snapshots alone, is included in the next upload any other record triggers, or in the backup the App makes when it starts (at most once a day). Everything financial triggers an upload shortly after it is recorded.

Your data is encrypted on your device with a key derived from your wallet signature before being uploaded. The server stores the opaque ciphertext, your wallet address (as the lookup key), how many records and bags it contains, a version counter, and a timestamp. It also keeps a short history of your previous encrypted backups — the most recent few, one per day for the last week, and the largest from the last 30 days — so that a bad or truncated upload can be recovered from rather than being the end of your records. Every one of those is the same opaque ciphertext: the server does not hold the decryption key and cannot read the contents of any of them. On a reinstall or a new device, signing in with the same wallet lets the App decrypt and restore your data.

There is no setting to disable the backup, and the reason is not convenience: it is the only way your records survive a lost phone. The App has no feature that rebuilds them by reading the blockchain — your coins stay on-chain, but what you paid for them is not written there — so an off switch would quietly cost you that.

Your control is to delete the backup at any time through Settings > Delete Account.

We cannot read the contents of your backup. We can see that one was uploaded and roughly how many records it holds, and because uploads follow your activity closely, those timestamps and counts do say something about when you used the App and how often. We do not use them for anything beyond storing and restoring your backup.

6.5 CoinGecko (Market Data)

We fetch public cryptocurrency price, chart, and market data via CoinGecko. We do not send CoinGecko your wallet address. The App loads token images directly from CoinGecko's image servers and, if our server cannot be reached, may request prices from CoinGecko directly; those requests come from your device, so CoinGecko receives your IP address and the tokens requested.

6.5.1 DefiLlama (Near-Live Prices)

Our server fetches public near-live token prices from DefiLlama, keyed only by the token identifier. No user data is shared with DefiLlama.

6.6 Off-Ramp Payout Provider (Selling)

Where selling is available, your cash-out is handled by a third-party payout provider reached through the Coindisco aggregator — today, Transak, reached through Coindisco (Section 4.2). We send the provider the chain, the asset, the amount, the payout method, the currency, your state, and your forwarded IP address, so that it can quote and create the order. The provider performs identity verification, compliance checks, and the payout itself, under its own terms and privacy policy — see Section 4.2. We receive back the order status, the fiat payout amount and its currency, the provider's fee, the settled crypto amount, the deposit transaction hash, and the notifications described in Section 3.

BAGHOLDER is not the buyer or the seller, does not receive the crypto you sell or the cash you are paid (apart from any BAGHOLDER sell fee, which your wallet sends by a separate transfer), and cannot reverse a transfer. See Terms of Service §7.1.

6.7 Blockchain Infrastructure Providers (RPC), Including Helius

Third-party providers relay blockchain data between your wallet and the network: they answer balance and history lookups and broadcast the transactions your wallet signs. The App normally reaches them through our server, so they see your wallet address and your signed transactions, but not your IP address. On Solana, our server uses Helius for this, including balance reads, transaction broadcasts and your transaction history. If our server cannot be reached, the App may contact a public RPC provider directly, which then sees your IP address together with your wallet address. No personal data is shared beyond your wallet address, on-chain data and, on that direct fallback, your IP address.

6.8 Jupiter (Solana DEX Aggregator)

For buys, sells and swaps on Solana, the App sends your swap parameters (input token, output token, amount, your wallet address) through our server to Jupiter's aggregator API so it can return a routed swap transaction your wallet then signs. Jupiter sees the wallet address and swap parameters, not your IP address. See: jup.ag/legal/terms-of-use

7. Data Retention

7.1 Retention schedule

Each server-side record type has a defined retention window, after which either the entire record is deleted OR the wallet address is replaced with a keyed one-way hash (HMAC), or the record is kept as stated below. Replacing the address removes it from the record, but it is not full anonymization: the amounts, dates, chain and state code that remain could in principle be matched against the public blockchain.

Record type	Retention	Wallet address handling
Payment charge records	Retained indefinitely as the financial and audit record	Retained raw — required for tax and payment-provider dispute windows; replaced with a keyed hash on account deletion
Treasury ledger / fee records	Retained indefinitely as the financial and audit record	Wallet address replaced with a keyed hash after 90 days
Gas funding records	Retained indefinitely as the financial and audit record	Wallet address replaced with a keyed hash after 1 year
Swap fee and swap check records	Retained indefinitely as the financial and audit record	Retained raw; replaced with a keyed hash on account deletion, when the fee transaction hash and any spending address are also cleared
Send check records	Retained indefinitely as the financial and audit record	Retained raw; replaced with a keyed hash on account deletion, when any spending address is also cleared. The recipient address is not stored
Swap event logs	Up to 1 year, then deleted	Deleted on account deletion
Server error records	Deleted 90 days after the error last occurred	Deleted on account deletion
Usage events	1 year, then deleted	Wallet address replaced with a keyed hash after 90 days, or on account deletion if sooner
Onboarding attestation records (Section 3.1)	1 year, then deleted	Keyed by device fingerprint (the state-of-residence events also carry the request IP), not linked by us to a wallet or payment record; not reached by account deletion
Shared bag configurations	A shared bag created more than 1 year ago that has been opened at most once and never copied is deleted; other shared bags are kept until account deletion	Deleted with the bag
Encrypted backups and their history	While account is active (history thinned as described in Section 6.4)	Deleted on account deletion
Wallet address bindings and wallet-to-account bindings	While account is active	Deleted on account deletion
Gas seed record (a keyed one-way hash of your Privy account identifier, and each network on which you received a gas seed — no wallet address, transaction or amount)	Indefinitely	Kept after account deletion, so the one-time gas seed is not claimed again by deleting and recreating an account
Account protection records (scrambled PIN, and the records of the phones your account is signed in on)	While account is active; some phone records are deleted earlier (Section 3)	Deleted on account deletion
Balance caches	Served for up to 60 seconds; deleted after 7 days	Deleted on account deletion
Swap quote records	Deleted when the quote expires	Deleted with the record
Other balance-lookup caches	Up to 30 days	Deleted with the record
Added-token list (which tokens users add, as a count per token)	Dropped 30 days after a token was last asked for	No wallet or account attached, so nothing to delete per account
Solana token-account (ATA) records	While account is active	Deleted on account deletion
Suspended-wallet list	Kept while the suspension stands	Not removed on account deletion, so that deleting an account cannot undo a suspension
Sell (cash-out) session records — order created	Retained indefinitely as the financial and audit record, on the same basis as payment charge records	Retained raw; replaced with a keyed hash on account deletion
Sell session records — creation failed before the order reached the provider	Deleted after 90 days	Deleted with the record
Sell fee records	Retained indefinitely as the financial and audit record, on the same basis as sell session records	Retained raw; replaced with a keyed hash on account deletion, when the fee and refund transaction hashes are also cleared
Payout provider webhook records	Raw body blanked 30 days after the notification is processed; the record itself deleted after 180 days	No wallet column; the body, which may name your wallet, is blanked
Payment provider notification records	Deleted after 180 days	No wallet column
Server operational logs (Section 3)	Up to 30 days, kept by our hosting provider	Contain no IP addresses
Hosting provider request logs (Section 3)	Up to 30 days, kept by our hosting provider (Railway)	Include your IP address; not copied into our records

Local on-device data is stored until you delete your account or uninstall the App. Local portfolio snapshots older than 365 days are pruned.

Two caveats about sell records. First, a sell whose outcome we could not confirm — for example, where we could not tell whether the order reached the provider — is kept, not deleted at 90 days, because deleting a record of a transfer that may have happened would destroy the audit trail. Second, unlike some other record types, a sell record's wallet address is not replaced with a hash automatically after a fixed period; it is hashed when you delete your account (Section 7.2).

The periods above are what our systems do in the ordinary course. We may keep a specific record longer, and suspend a scheduled deletion or hashing, where the law requires it, to comply with a subpoena, court order or other legal process or a legal hold, to resolve a dispute, or to investigate fraud, a sanctions matter or a security incident. Records held by third parties (Section 6) are kept under their own policies.

7.2 Account deletion

When you delete your account from Settings → Delete Account, the App first asks our server to:

1. Delete the following records: encrypted backups and their history, shared bag configurations, wallet address bindings, the link between your wallet and your Privy login, balance caches, swap event logs, server error records, the record of which token accounts your Solana wallet has, and your account protection records (the scrambled form of your PIN and the records of the phones your account is signed in on).

To stop the one-time gas seed being claimed again by deleting and recreating an account, we keep a keyed one-way hash of your Privy account identifier together with each network on which you received a seed. It holds no wallet address, transaction or amount. We use it only to check whether a seed was already sent, and we keep it indefinitely.

2. Remove your wallet address from the following records, replacing it with a keyed one-way hash: payment charges, gas fundings, treasury ledger, usage events, sell (cash-out) session records, sell fee records, swap fee and swap check records, and send check records. We retain the underlying financial records (amounts, fees, timestamps, chain and the state code used for the eligibility check) for tax, accounting and compliance obligations, as permitted by Apple App Store and Google Play deletion policies for legal and financial obligations. The details of a usage event are not changed.

We additionally clear the transaction hashes and provider transaction identifiers on payment charge, gas funding and treasury ledger records, and any spending address on swap and send check records, because these can identify your wallet on-chain.

For sell fee records we additionally clear the fee transaction hash and any refund transaction hash, because either one identifies your wallet on-chain.

For sell records we additionally clear the provider redirect link, the provider's transaction identifier, any error text, and the deposit transaction hash. We also blank the stored payout-provider webhook bodies that referenced you or your orders, leaving an empty stub so that a repeat notification from the provider stays a no-op.

Records that account deletion does not reach are listed in the table in Section 7.1: onboarding attestation records, which are not keyed to your wallet; the suspended-wallet list, which we keep so that deleting an account cannot undo a suspension; and short-lived caches, which expire on their own schedule. Account deletion also does not reach logs kept by our hosting provider (up to 30 days), crash reports held by Google (Section 6.3), records kept longer for a reason listed at the end of Section 7.1, information held by third parties such as Privy and the payment and payout providers (contact them directly), or anything recorded on a public blockchain, which no one can delete.

If our server cannot be reached or any server step fails, the App does not erase anything on your phone and asks you to try again. Server steps that had already completed stay completed; trying again finishes the rest.

Once the server steps succeed, the App:

3. Disconnects your Privy wallet session. This does not affect your wallet itself — it remains yours, and you can export its keys to use them in a wallet app of your choice. Your Privy login is not deleted: signing in again with the same login reopens the same wallet. To delete the Privy login itself, contact Privy (privy.io/privacy).
4. Erases all data the App stored on your phone.

8. Data Security

We use reasonable administrative, technical and physical measures designed to protect the information we hold, appropriate to its nature. They include:

• Platform secure storage for secrets on your device (iOS Keychain / Android Keystore)
• On-device records kept in the App's local database, which relies on your phone's own storage encryption (when your phone has a lock screen) rather than encryption added by the App
• Encrypted connections (HTTPS) between the App and our server
• Wallet keys managed by our wallet provider, Privy, rather than by us
• Wallet-based sign-in to our server
• Third-party API keys kept on our server rather than in the App

No method of storing or transmitting information is completely secure, and we cannot guarantee the security of your information. You are responsible for securing access to your device, your sign-in account and your wallet. If we learn of a security incident affecting your personal information, we will notify you and others as required by applicable law.

9. Your Rights

• Access: You can view your on-device records — your bags, your transaction history and your current holdings — within the App.
• Wallet export: You can start an export of your wallet's private key from Settings; the key is shown on a web page the App opens (handle with extreme care; anyone with the key can drain your funds).
• Deletion: You can delete your account via Settings > Delete Account, as described in Section 7.2.
• Server data deletion: You can also ask us to delete server-stored data by contacting us at [email protected]. We handle that request the same way as an in-App deletion (Section 7.2), including the records described there that we keep or cannot reach.
• Portability: Your wallet remains yours; disconnecting from BAGHOLDER does not affect it. You can continue to use the wallet via any compatible interface.
• Copy and correction of server data: You can ask us, at [email protected], for a copy of the personal information our server holds for your wallet address, or to correct it. Financial and audit records describe transactions that happened and are corrected only where they are inaccurate.

How we handle requests. Because our server records are keyed by wallet address rather than by name or email, we will ask you to show that you control the wallet the request concerns (for example, by signing a message with it) before we act on it, and we may decline a request we cannot verify. You may use an authorized agent where the law allows; we may ask the agent for proof of your authorization and ask you to verify your identity directly. We may decline or limit a request where an exception in applicable law applies, for example records we must keep under Section 7.1. We respond within the time required by applicable law, and if we decline a request we will tell you why and how to ask us to reconsider. We do not charge for requests and do not treat you differently for making them.

9.1 Contacting Support

When you tap Settings > Contact Support, BAGHOLDER opens your device's email app with a message addressed to [email protected] (or, if no email app is set up, your device's share sheet with that address at the top of the message). The email body is pre-filled with a short summary: a random support code for your copy of the App (it is not derived from your wallet), your EVM and Solana wallet addresses, the app version, your device's operating system and its version, a count of anything unfinished, and up to three recent payment session IDs. For faster triage we also pre-attach a CSV file (bagholder_diagnostics.csv) containing:

• The same summary, plus: whether your account PIN is set, whether this phone is trusted, and whether your account is frozen, PIN-locked or in a reset pause and until when (never the PIN itself); which buying, selling, swapping and sending switches are on; the App settings that affect routing; the version of the token list on your phone; the time and type of the App's last error (not its message); when the App last reached our server and the time and kind of its last network failure; and the time and size of your last backup and last restore
• A count of unfinished items of each kind, however old, with up to five of each listed with their dates: card charges that delivered nothing or only part, unfinished network-coin purchases, purchases and orders waiting to retry, swaps in flight, unfinished sales, swaps or conversions, sends not yet confirmed, fees waiting to be collected on your next buy, and incomplete orders from the last 90 days
• For the last 30 days (at most 50 rows per section, newest first): purchases and orders, stablecoin conversions, card charges that delivered nothing, network-coin purchases, sales and cash-outs, token swaps, sends, BAGHOLDER fees paid, and your local issue reports (Section 2, each description shortened to 300 characters). Rows show dates, status and reason codes, networks, tokens and amounts, fees, the provider and payout method, transaction hashes, and the references our server and the payment or payout provider use to find the same transaction (such as onramp session IDs, charge IDs, idempotency keys, sale IDs and the provider's transaction reference)
• A short legend explaining the codes used in the file

The file never contains your private key, your sign-in tokens, your PIN, the address a send went to, or a payout provider's deposit address (the transaction hash identifies them on the blockchain).

You can preview and remove the attachment before sending, edit the email body, or close the composer entirely without sending anything. Nothing leaves your device unless you tap Send. The email goes to BAGHOLDER support through your email provider and ours; we use it only to answer you and do not otherwise disclose it except as described in Section 5.1.

Messages you send us. Any email or letter you send us — to support, or to our notices address ([email protected], or our mailing address in Section 14), for example a Notice of Dispute, an arbitration opt-out or a copyright complaint under our Terms of Service, or a privacy request under Section 9 — reaches us with your email address, your name if you include it, and its contents. We keep these messages in our email system for as long as we need them to answer you and as a record of the request, including any period the law requires; they are not added to the records in Section 3.

10. U.S. State Privacy Rights (including California)

Several U.S. states, including California, give their residents rights over personal information. Some of these laws apply only to businesses above certain size or activity thresholds, and describing them here is not a statement that any particular law applies to BAGHOLDER. Whatever your state, we offer every user the rights in Section 9: to know and get a copy of the personal information we hold, to have it deleted (subject to the exceptions in Section 7), to correct it, and not to be treated differently for asking.

• Sale, sharing and targeted advertising. We do NOT sell or share your personal information (as "sell" and "share" are defined in the CCPA), we do not use it for targeted advertising or for profiling that produces legal or similarly significant effects, and we have not done so in the past 12 months. Nevada residents: we do not sell covered information.
• Sensitive personal information. The information we handle that some state laws may treat as sensitive is your BAGHOLDER PIN, kept only in a salted, one-way form (Section 3). We use it only to provide the service you request and keep your account secure, and not to infer characteristics about you; we understand that California's rules give no right to limit a use of that kind. If you believe otherwise, contact us.
• Categories we collect (past 12 months): identifiers (wallet addresses, the random installation and device identifiers described in Sections 2 and 3.1, the Privy account identifier, and the IP address on state-of-residence records); commercial information (records of your buys, sells, swaps, sends and fees); internet or app activity (usage events and server error records); coarse location (your declared state, and the region derived in memory from your IP address for the sanctioned-region check); your age-check result (Section 3.1); the sensitive information above; and, if you email us, your email

address, name and message (Section 9.1). We collect them from you, from your device, from public blockchains, and from the providers you use (Section 6). Purposes are in Section 5, recipients in Sections 5.1 and 6, and retention in Section 7.

To make a request, contact us at [email protected] (Section 9, "How we handle requests").

Opt-out preference signals. Because we do not sell or share personal information or use it for targeted advertising, there is nothing for a Global Privacy Control or similar signal to opt you out of; we treat every user as opted out.

Do Not Track. The App does not track you across other companies' apps or websites and does not serve advertising, so it has no behaviour that changes in response to a browser "Do Not Track" signal.

11. Geographic Availability

BAGHOLDER is available in 41 U.S. states — see Terms of Service §5 for the full enumerated list.

BAGHOLDER is not available in New York, Connecticut, Louisiana, Vermont, New Mexico, the District of Columbia, Pennsylvania, Oregon, Arkansas, or West Virginia.

The App is offered only to residents of the United States and is not directed to anyone outside it. Information you provide is processed in the United States and, by our service providers (Section 6), wherever they operate. If you use the App from outside the United States, you do so on your own initiative and understand that U.S. law applies to the information we hold.

12. Children's Privacy

BAGHOLDER is not intended for, and may not be used by, anyone under the age of 18. The App asks for your age before signup and does not let anyone who enters an age under 18 continue. We do not knowingly collect personal information from anyone under 18, apart from the age-check record described in Section 3.1: if someone enters an age under 18, we record only the age band and attempt number, with the random install identifier, as an audit record of the check, and no date of birth. If we learn that someone under 18 has given us other personal information, we will take steps to delete it. To tell us, contact [email protected].

13. Changes to This Policy

We may update this Privacy Policy from time to time. The current version is available in the App under Settings, with its effective date. If we make material changes, we will tell you in the App before they apply to you, normally by asking you to review and accept the updated policy. Where the law requires your consent to a change, we will ask for it and will not apply the change to you without it.

14. Contact

If you have questions about this Privacy Policy, or want to make a request under Section 9 or 10, contact BAGHOLDER LLC at:

[email protected]

BAGHOLDER LLC, 162 1/2 E Central Ave, Delaware, Ohio 43015-1873

https://getbagholder.com