·Privacy

What we collect, what we don’t.

A short, specific account of what enters our servers when you use Satsignal, what doesn’t, where things go, how long they stay, and what choices you have. No cookies, no analytics, no account needed for public proof or verification — but creating a proof does put a small artifact on the public chain forever, and we want that part to be clear too.

Effective 2026-05-06. First version of this page.

01At a glance

The three things most readers want to know.

Your file stays on your device

The page reads your file with the browser’s File API and computes its fingerprints locally. The file’s bytes never leave your browser. Short hex fingerprints, the file size, and any optional filename label or memo you typed are sent with the form, included in the receipt bundle on our server, and never written to chain. Avoid sensitive filenames or use a neutral label.

Note: filename label, memo, and matter label fields reject literal LLM-tool-control substrings (e.g. <system-reminder>) at submit time. This affects only that narrow set of strings used as control channels by AI agent harnesses; it does not affect the file you’re notarizing. The check is defense-in-depth for downstream agents that read receipts.

No cookies, no analytics, file proof needs no account

Satsignal sets no cookies and runs no third-party analytics or marketing tags. The file-proof flow on proof.* / sealed.* and the verifier on /verify need no account — nothing ties multiple proofs to the same person because we don’t ask who you are. Developer / API workspaces at app.satsignal.cloud use a magic-link sign-in to manage API keys, matters, and quotas; what that account stores is described in section 02.

The on-chain anchor is permanent and public

Creating a proof writes a short commitment (about 20 bytes plus a small structural marker) to the Bitcoin SV chain. The chain entry has no personal data and no filename, but it is permanent and public. In Standard mode, anyone with the same payload — or its SHA-256 — can confirm a matching proof exists. (See section 05 and the sealed mode note for when this matters.)

02What we collect, what we don’t

Two short lists.

What we receive

The file’s short cryptographic fingerprints (computed in your browser)
The file size in bytes
Any filename label or memo you typed (included in the receipt bundle on our server, never written to chain)
For sealed mode with the default mirror option: the master salt (kept in your bundle and mirrored on our server until the retention TTL printed on the receipt — default 7 days, max 30 — then auto-deleted). With blind submission (opt-in on sealed.satsignal.cloud, or via the API by omitting salt_b64), the salt never leaves your browser; no bundle is stored on our server.
HTTP request metadata: timestamp, source IP, path, status

What we do not receive

Your file’s bytes
Your name — we don’t ask for it. The file-proof flow asks for nothing; the developer-API account asks only for an email address (used for magic-link sign-in and account-related notices). Note: the optional filename label and memo fields above are freeform — if you type your name there, we’ll receive it
Any tracking-cookie or browser-fingerprint payload
Any third-party analytics, advertising, or marketing pixels (we don’t embed them)
The contents of the .mbnt bundle after you download it locally and start working with it

The verifier at /verify works the same way: file hashing happens in your browser. The only network call is a chain-side lookup to a public BSV explorer (you can substitute any explorer; we don’t mediate).

03How long things stay

Retention, by artifact.

Bundle (manifest + canonical doc, no file bytes) — standard mode: Stored at /bundle/<id>.mbnt on our server. Kept indefinitely; deleted on request to hello@satsignal.cloud. Your local copy and the on-chain anchor are unaffected by server-side deletion.
Bundle — sealed mode (mirror, the default): Same shape, plus the master salt. Auto-deleted from our server after the retention TTL on the receipt (default 7 days from anchor, max 30). After that, only the holder of the local bundle (and the file) can verify. The chain anchor remains permanent regardless.
Bundle — sealed mode (blind submission): Never on our server. The salt stays in your browser; the bundle is assembled and downloaded client-side at submit time. There is no server copy to retain or delete, and /bundle/<id>.mbnt does not resolve. The chain anchor is the same 20-byte commitment as the mirror path.
HTTP access logs: One line per request — timestamp, source IP, path, status. Rotated automatically by the operating system; not indexed and not retained beyond ordinary log rotation.
The on-chain anchor: Permanent, by design. The chain is the property that makes a Satsignal receipt independently verifiable years later. It contains no personal data — only a 20-byte commitment plus a small structural marker.
Anything we’ve told you we don’t collect: Zero retention — we don’t have it.

04Where things go

Third parties, named.

Creating or verifying a proof necessarily contacts the public Bitcoin SV network. Here is who sees what:

The Bitcoin SV chain: Your proof’s 20-byte commitment plus a small structural marker is written into a transaction by us and broadcast to independent miners, who include it in a block. The chain entry is replicated across the BSV network and stays public forever. It contains no personal data, no filename, no IP address.
BSV explorers (when you verify): The verifier and the receipt page both link to whatsonchain.com for the chain-side lookup. When you click that link or run the verifier, your browser makes a request directly to the explorer. Satsignal does not mediate that request. You can substitute any other BSV explorer or run your own node.
BSV broadcasters and chain queries (server-side): To anchor a proof on chain, our server contacts BSV broadcasters (ARC) and a public ElectrumX node for UTXO lookups. These contacts carry the operator-side transaction, not your file or any personal data of yours.
Caddy and Let’s Encrypt: Caddy fronts the site with TLS certificates issued by Let’s Encrypt. Certificate issuance is an automated process that does not involve your file or your identity.
Nobody else: No analytics, no advertising networks, no third-party JavaScript at runtime. Every script the page loads is vendored at /static/ and SRI-pinned — full list on the security page.

05Your choices

Decisions you control.

Pick the right mode for your sensitivity. Standard receipts record the payload’s SHA-256 in the receipt; the chain stores a short commitment to that receipt. Anyone with the same payload — or its SHA-256 — can confirm a matching Standard proof exists. Sealed receipts record a salted commitment to the payload; the chain stores a short commitment to that sealed receipt. Without the bundle salt, observers cannot test candidate payloads against the receipt. If existence of a proof is itself sensitive, choose Sealed.
Request server-side bundle deletion. Email hello@satsignal.cloud with the bundle ID. We’ll delete the server copy. The chain anchor is permanent — that’s the property that makes the proof tamper-evident in the first place — but our server-side mirror can come down.
Mind the hash-lookup endpoint. /lookup_hash?sha=<hex> exists so the upload form can dedupe submissions. As a side effect, anyone with a file’s SHA-256 can confirm whether a standard-mode proof for that file exists. Treat the SHA-256 of a sensitive file like a password — or use sealed mode, which doesn’t expose a hash-checkable surface.
Inspect what we send. Open the browser’s developer tools before submitting; the network tab shows everything that leaves your machine.

06Fine print

Lawful process, children, changes.

Lawful process: If we’re served with valid legal process compelling disclosure, we can produce only what we have: the bundle (which is public anyway) and the access-log line for a given request. We can’t produce file bytes, identities, or anything else from this list of things we don’t collect — we don’t have them.
Children: Satsignal is not directed at children, does not knowingly collect data from anyone known to be under 13, and has no use case that would benefit a child. If you believe a minor has submitted information, email hello@satsignal.cloud and we’ll delete the relevant server-side bundle.
Changes to this policy: We’ll update this page if the practices change. The effective date at the top reflects the current version. Material changes will get a brief note here describing what changed.
Jurisdiction: The operator entity and governing law for any disputes will appear here when those are formalized. Until then, treat this service as operated personally and informally; act accordingly with sensitive material.
Contact: Email hello@satsignal.cloud for any privacy-related question, deletion request, or correction.