Privacy Policy

1. Who is responsible and what this covers

This policy covers the Sovran app and sovran.money website. The operator identified above is responsible for personal information it processes for its own services. Independent mints, relays, indexers, media hosts, AI providers, carriers, remote signers, and app stores may act as separate controllers under their own policies. Contact the operator above for privacy questions or requests.

A public key, wallet identifier, IP address, or payment record can be personal information even if it does not contain your real name. Sovran is not anonymous by default. Information leaves your device when the app communicates with services, including default services used to load content. Acknowledging this notice is not consent to every use of personal information.

2. Information stored on your device

The app stores wallet settings, local profiles, keys or signer connection information, ecash proofs, transaction records, cached social content and messages, AI conversations, moderation preferences, and document acceptance records. Private key material held by the app uses operating-system secure storage; other app data uses local databases, files, or settings storage. Not all local app data is encrypted by Sovran.

Locally held recovery phrases and private keys are not intended to be uploaded as part of ordinary app operation. A remote signer, if used, holds its own key material. Copying, exporting, sharing, device backups, malware, or another person with access to your device can expose data. Do not paste secrets into posts, AI prompts, support requests, or untrusted apps. We cannot promise to recover locally lost keys.

3. Wallet and payments

Mints and payment providers receive the requests needed to issue, validate, swap, redeem, or pay with ecash. Depending on the operation these include proofs being spent, blinded outputs, invoices, payment destinations, amounts, timestamps, public locking keys, and network information such as your IP address. Ecash blinding limits certain links; it does not make every payment or network request untraceable.

Recipients receive what you send them, including payment requests, tokens, invoices, and any included message. Public zaps can associate your Nostr identity with a recipient and amount. On-chain services and the blockchain can reveal transaction information publicly and permanently. Exchange-rate, mint-discovery, auditing, swap-routing, and merchant-map services receive requests needed for those features. Do not publish bearer tokens unless you intend others to redeem them.

4. Social profiles, feeds, and media

Publishing to Nostr sends signed events to relays. Public events may contain your public key, profile name, biography, picture, website, payment address, posts, images or media links, follows, reactions, and timestamps. Other users, indexers, search services, and anyone accessing those relays may read and copy them. Public content can be associated with your activity across apps.

Loading feeds, profiles, searches, notifications, and threads sends queries and identifiers to configured aggregators, caches, and relays. Defaults include Sovran’s Nagg service, Primal, and public Nostr relays. Operators can observe requested public keys or events, search terms, connection times, and IP addresses. Network settings and relay selection affect which services receive requests.

Nagg also records a viewer public key and last-seen time on certain requests to recognize active users and retain content relevant to them. This can associate use of Sovran with that public key.

Selected uploads go to a media server, by default Primal’s Blossom server, or the configured alternative. Uploaded files may be publicly retrievable by URL and may contain identifying details or embedded metadata; do not assume these are stripped. Viewing remote images, video, avatars, previews, or web pages contacts their host and may disclose your IP address and requested resource. Removing a post does not necessarily delete its uploaded file.

5. Messages, reports, and blocks

Supported private Nostr messages are encrypted on the device for their recipients. Relays store or forward encrypted events and may see routing information and connection metadata. Encryption does not prevent recipients from copying messages, compromised devices from exposing them, or linked and uploaded media from being fetched separately. Public chats are not private messages. Experimental messaging transports may have different metadata protections.

Reporting publishes a signed Nostr report that identifies the reporter and reported user or event and includes a reason. Do not include private messages or sensitive details in public reports. Contacting the operator directly sends the information you include and your contact details to the operator and its communications provider.

Blocking takes effect locally first. The app attempts to sync your Nostr mute list; newly added private entries are encrypted for your identity, while existing public entries from other clients may remain public. Relays still see event metadata. The optional private-message word filter works locally; it does not send a dictionary or the matched plaintext to a moderation service.

6. Optional location, nearby communication, and device access

Device permissions are requested for features such as camera scanning, choosing or recording media, location, and nearby Bluetooth communication. Granting an operating-system permission does not make everything captured by the sensor public; what is transmitted depends on the feature you use. You can change permissions in device settings.

Location-based BitChat channels use a geographic cell derived from your location. Joining or posting to a cell can disclose your area to relays and participants, including precise, block-level location. Resolving place names also uses the operating system’s reverse-geocoding service, which may send coordinates to its geocoding provider. A public post with a geographic tag remains public after you leave. Nearby Bluetooth communication exposes presence and relevant identifiers or messages to nearby devices and relaying peers. It does not guarantee anonymity.

The payment-location setting is separate from public location chat. Locally stored payment location is used to show your own payment history; it is not permission to publish that history. Merchant maps may fetch map tiles or nearby merchant information from external providers. Disable features you do not want and review the specific disclosure before sharing location.

7. AI and eSIM services

Using AI sends your prompt, selected conversation history, model choice, and selected attachments to the configured Routstr endpoint and the model services it uses. The default endpoint is api.routstr.com. These providers process the plaintext needed to answer and can receive request metadata and credit or payment credentials. Provider retention and training policies are their own; do not assume that paying with ecash makes the prompt private or prevents retention.

eSIM browsing, quoting, ordering, and installation involve Sovran’s eSIM service and its provisioning or payment partners. Requests and records can include package choices, invoice or order identifiers, payment status, activation information, and network metadata. A carrier processes additional connectivity and device information when you use its network. Do not share an order link or activation code; possession may allow access to the order or service.

8. Website, diagnostics, and support

Our production hosting provider, Railway, and other website and API hosts receive network requests, including IP addresses, URLs, timestamps, and technical browser or device information. Website local storage remembers preferences such as language. Opening checkout pages sends the order or invoice identifiers in their URLs to the services handling them.

Builds that expose diagnostic tools include local logging and export; persistent developer logging is not a standard production feature. An export you choose to share can contain sensitive wallet or activity information; review it and use a private channel. App stores and operating systems may separately collect crash, installation, or diagnostic information according to their settings and policies. This policy does not promise that independent infrastructure keeps no access logs.

Support and privacy requests include the contact information and details you supply. We use those details to respond, investigate a problem, and handle the request. Never send a recovery phrase, private key, bearer token, or complete unredacted wallet database to support.

9. Purposes, legal bases, and recipients

For processing under our control, we use information to provide requested features and purchases, respond to support, maintain service security and reliability, address abuse, and comply with legal obligations. Where UK or EU data-protection law applies, the relevant bases are performance of a contract for requested services, legitimate interests in service reliability, recognizing active users and retaining content relevant to them, security, and support where those interests do not override your rights, legal obligations where applicable, and consent where a specific optional activity requires it. A terms checkbox is not a substitute for such consent.

Information reaches the recipients described in the feature sections, infrastructure providers supporting our services, and authorities where disclosure is legally required. Public publication deliberately makes information available to others. An independent service you choose is governed by its own terms; this does not remove our obligations for processing that we control.

Public networks and independent service providers can operate in other countries with different privacy laws. You cannot limit a public Nostr event to one country. Our website and api.sovran.money services are configured in Railway’s Amsterdam region, but this does not mean all hosting-provider processing stays in the Netherlands. Railway’s published Data Processing Addendum describes processing in the United States and safeguards for applicable transfers, including standard contractual clauses and the UK Addendum. You can read those terms at https://railway.com/legal/dpa or contact us for information about safeguards for a particular service. Independent services you use have their own transfer arrangements.

10. Retention and deletion

Local records remain until removed by the app’s cache management, by you, or by deleting app data. Operating-system backups and secure storage may survive some reinstalls. Settings → Delete account attempts to remove local profiles, settings, secure keys, and wallet databases; filesystem caches, diagnostic exports, backups, or data whose cleanup failed may remain. Move funds and back up necessary keys first. It does not close every account with an external service.

Public events and third-party copies may be retained indefinitely. Nostr deletion requests cannot compel every relay, indexer, or recipient to delete a copy. Settings → My media can request deletion of supported uploads from their original server; other copies may remain. Blocking is not deletion. Blockchain records cannot be erased by Sovran.

We do not automatically export production server logs to another logging service or storage destination outside Railway. Railway currently makes seven days of log history available under our hosting plan. Its documentation says upgrading can make older logs accessible, so this window is not a guarantee that all copies are permanently erased after seven days. Other records, including database entries, support correspondence, and copies held by independent services, have separate retention arrangements.

For records under our control, retention depends on the purpose: service records for the period needed to deliver and reconcile the service, support correspondence while resolving the request and related disputes, security records while investigating or preventing abuse, and records required by law for the applicable legal period. These are purpose-based retention criteria, not a single deletion deadline for all data. Contact us for the retention period applicable to your request or order. Independent providers set their own retention periods.

To request access or deletion of information held by Sovran, email the address above with your public identifier or order reference where relevant. Do not send secret credentials. We may request proportionate proof that you control the relevant account. We will explain if a legal obligation or another valid exception prevents deletion. You can use this contact route without reinstalling or signing into the app.

11. Your choices and rights

You can limit optional features, adjust network settings, revoke device permissions, remove local data, and stop using a service. These choices do not recall information already published or delivered. Where processing relies on consent, you may withdraw it without affecting earlier lawful processing.

Your right to object: where we rely on legitimate interests, you may object to processing based on your particular situation. We must stop unless we demonstrate compelling legitimate grounds that override your interests, rights and freedoms, or need the processing for legal claims. You can always object to processing for direct marketing. Contact the operator above to make an objection.

Depending on the law that applies, you may have rights to access, correct, erase, or receive a portable copy of your information, restrict processing, and complain to your data-protection authority. Contact the operator above to exercise rights. You do not need to waive these rights to use Sovran.

You may complain to the UK Information Commissioner’s Office (ICO) at https://ico.org.uk/make-a-complaint/ or to another competent data-protection authority. You do not have to contact us first.

Sovran is intended for adults aged 18 or over. If you believe a child has provided personal information to a Sovran-operated service, contact us. Public content, payment risks, and external services make this app unsuitable for children.

12. Updates to this policy

The date and content revision identify this policy. The app asks you to acknowledge a changed policy when you install an update containing it, separately from agreeing to the terms. A website update does not silently record acknowledgment on your device. Acknowledgment records the version and time locally; it does not authorize new optional processing. Where a change requires fresh consent or a prominent feature-specific disclosure, that must be obtained separately before the affected processing.