Docs
Privacy
btcintel is built to know as little as possible about you: reads are anonymous, a Nostr key writes without any account, and an e-mail account (optional, and open only when features.accounts says so) holds the minimum a sign-in needs. This page says what is kept, by whom and for how long.
in forceEffective 2026-09-24. Adopted by the operator on 2026-09-24 (decision P54 in the btcintel codex); the account terms were added on 2026-09-29 (S5.5), approved by the operator on 2026-09-30 (P61) and apply once accounts open (features.accounts); a lawyer's review is on the launch checklist. Changes are published here with their date.
Responsible party
Satsboard LLC, 1021 E Lincolnway 10076, Cheyenne, WY 82001, United States. Requests about personal data and legal notices: [email protected]. If the law where you live gives you rights over personal data, write to that address; we answer within the timelines of the takedown process.
Commitments
- No third-party scripts other than the analytics named below; fonts self-hosted; no fingerprinting.
- No account is needed to read, nor to write with a Nostr key. An e-mail account is optional: it stores the address, a password hash and the second factor, nothing more, and is closed and anonymised on request.
- Transactional e-mail only (verification, sign-in links, resets, new-device notices, invitations, the closure notice), never marketing; the message body is never logged.
- Usage is counted per day and route for quotas, never per request or address beyond in-memory counters that do not persist.
- No access logs at the API, the relay or the site's origin; nothing is logged with query strings.
- Feedback is explicit and treated as user content; there is no telemetry in our code.
- The browser talks only to our domains.
What is kept today
| Item | State |
|---|---|
| Analytics | Cloudflare Web Analytics, injected by Cloudflare at the edge on every HTML page: cookieless, no cross-site tracking; aggregate page views, referrers, country and browser under Cloudflare's privacy policy. Google Analytics is planned and arrives with a consent decision and an update of this page. |
| Cookies | One session cookie after a sign-in (a key's NIP-98 login, or an account's password, link or passkey): HttpOnly, Secure, SameSite=Lax, a random id, revocable at once. No other cookie exists. |
| Accounts (t4) | Approved by the operator on 2026-09-30 (P61); open since 2026-10-01 (P64). An account keeps: the e-mail (verified by link; a change is verified before it replaces the old one), the password as an Argon2id hash, the public keys of its passkeys, an authenticator secret encrypted at rest, recovery codes hashed, its sessions with their assurance level and sign-in methods and a hash of each browser's user agent, its organisations and roles, invitations (the invited address, seven days), and its API keys hashed. Everything it holds is exportable as JSON at any time. Closing it refuses sign-in at once, keeps 30 days of grace during which a sign-in reopens it, then anonymises it: e-mail and names removed, audit rows keep the account id only. |
| Custodied signing keys | Built and switched off (features.signing: false) until checkpoint CP4 closes; this row applies from then and is put to the operator with CP4. When open, every account is given a Nostr key when it signs in, generated by btcintel's signer service, kept encrypted (a per-key data key under a key-encryption key that lives only in the signer's environment) in a database of its own that the API cannot read, and unwrapped in memory for one signature at a time. On the API's side: the public key and its link to the account (custodied, extension, remote or Android signer; for a replaced key, the date until which it is kept), never on a public page or record, visible to the account and to human operators in the audit. On the signer's side: the wrapped key, the apps connected through NIP-46 (each app's public key, the name the account gave it, its permissions, when it connected and last asked), and an audit of every request (the account as a keyed hash, the app, the event kind, the outcome), never the event or the signature. Export hands the private key to the account once per request after a second-factor confirmation and is recorded and alerted. The person can replace it with a key they hold elsewhere at any time: the replaced key is unlinked and its apps disconnected, stays encrypted and exportable for 30 days (notes signed with it can only be deleted with it), then is destroyed. Unlinking after an export, or closing the account and its 30-day grace, destroys the encrypted key; the public key stays as a tombstone. A key the person holds elsewhere is only linked, by a signed proof: btcintel never receives it. |
| E-mail sending | Resend (resend.com) delivers the transactional e-mails from mail.btcintel.io as our processor: it sees the address and the message. Our logs carry the template name and a hashed account id, never an address. |
| Cloudflare edge | Every public hostname is proxied: Cloudflare sees traffic and keeps edge logs under its own policy, accepted for DDoS absorption. |
| Community | Public, signed Nostr events and their pubkeys, stored verbatim from our relay and from public relays; pubkeys are public data by design. The relay and the API keep no access logs; rate limiting uses in-memory counters per pubkey and per network address. A deletion by the author hides the event (the row is kept, shown to nobody); moderation and legal takedowns hide it and purge it after 90 days. Our pages do not resolve NIP-05 names. |
| Feedback contact | An entry may carry a Nostr pubkey or an API key as its contact, kept until the entry is closed or deleted; an entry with a contact is deleted on the requester's word; entries without a contact hold no personal data and are kept. |
| API keys and tokens | Stored hashed; usage per day and route. A key owned by an account or an organisation is listed to its owner with the prefix, created and last used; a minted token or an ops-issued key carries no contact. |
| Curated sources | Some sources name natural persons (sanctions lists, court documents, open-source research); each passes a licensing and personal-data checklist before import, and only parsed rows and fetch hashes are stored, never the source files. See sources. |
Before each feature ships
| Feature | Rule |
|---|---|
| Key backups | NIP-49 ciphertext only, produced in your browser; btcintel never sees the key or the password; downloads gated by a password-derived key and rate-limited; the blob is opaque to us and never logged. |
| Sessions | A session cookie is set only after a NIP-98 login or an account sign-in: HttpOnly, Secure, SameSite=Lax, bound to the npub or the account, revocable at once; it holds a random id, never a key or a password; no other cookie exists. |
| Sign-in providers | Google, GitHub and Apple sign-in are built and off. A provider is switched on one at a time by configuration, only after this page names what it receives (the verified e-mail and the provider's subject id), with no provider script on the page (decision P57). |
| Ops agents | Act through the API with scoped tokens; their model key lives with ops, never on our servers. |
| Victims of an incident | A campaign may list the addresses or transactions funds were taken from. They are published with the role victim: no abuse word, never an indicator in a STIX export or a tag in a TagPack, disputable like every claim, and delisted with a date when the source corrects itself. An address can belong to a person: its holder can dispute the claim or write through the takedown process. None is published until a source that lists victims passes the source checklist (decision P73). |
Any change that adds logging, a third-party service or client-side telemetry requires a decision record first; the record is public in the btcintel codex repository.