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 tracking, no analytics, no account needed to verify a proof — but creating a proof does put a small artifact on the public ledger forever, and we want that part to be clear too.
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 and the file size
are sent with the form and recorded in the proof bundle; any
optional filename label or memo you typed is kept only in our
private server-side record — not in the .mbnt
bundle you download and share — and none of it is written
to chain. Avoid sensitive filenames or use a neutral label.
No tracking, no analytics, verification needs no account
Satsignal runs no third-party analytics or marketing tags and
sets no tracking cookies. Signing in sets a first-party session
cookie so you stay signed in (and, if the sign-in bot-check is
enabled, Cloudflare’s Turnstile widget may set its own
short-lived anti-abuse cookie — not used for tracking);
browsing this site or verifying a proof sets none. The verifier on /verify and
public hash lookup need no account — checking a proof
never ties you to an identity. Anchoring a proof uses a
magic-link sign-in at app.satsignal.cloud to manage
your free-tier quota, folders, and API keys; 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 public ledger. The ledger 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.)
Two short lists.
What we receive
- The file’s short cryptographic fingerprints (computed in your browser)
- The file size in bytes
- For anchoring: the email address tied to your free account (for magic-link sign-in and account notices), plus the account’s workspace records — quota usage, any folders you create, and API keys you issue. Verification uses none of this
- Any filename label or memo you typed (kept only in our private server-side record — not included in the bundle you download and share, and never written to chain)
- For sealed mode with the default mirror option: the
master salt (kept in your bundle and mirrored on our server
— by default until you delete the proof; if you chose
an explicit retention window instead, it is auto-deleted
when that window ends, as printed on the proof). With
blind submission (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
- At account sign-in only: if the bot-protection challenge is
enabled, your browser loads a Cloudflare Turnstile widget (from
challenges.cloudflare.com) and on submit we forward your source IP to Cloudflare to validate it — abuse prevention on the sign-in step. Because the widget runs in your browser, Cloudflare receives your IP and the usual browser signals (user-agent, request headers, challenge telemetry) and may set a short-lived anti-abuse cookie; it does not receive your email, files, or proofs. The offline verifier and proof pages never load it. Cloudflare is named in the subprocessor list.
What we do not receive
- Your file’s bytes
- Your name — we don’t ask for it. Anchoring a proof requires a free account, which asks only for an email address (used for magic-link sign-in and account-related notices); verification asks for nothing. 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
Two documented exceptions, by design. If you point a SaaS source’s webhook at a Satsignal webhook URL, the raw event body necessarily passes through our server: we read it to verify the source’s signature and compute its SHA-256, and only that fingerprint enters the proof record — the body itself is not stored. And the plaintext provenance endpoint accepts a structured JSON manifest that we hash server-side and store inside the bundle — including any personal data you typed into its fields. A sealed provenance path commits the manifest client-side instead — in your browser or your own integration — so it never reaches us; use it for sensitive manifests.
Retention, by artifact.
The short version, on every plan and mode: we keep the server-side copy of your bundle until you delete the proof — there is no fixed expiry. A sealed-mirror anchor may instead set an explicit retention window, after which a server sweep deletes that one bundle when the window ends. Deleting a proof (or closing your account) removes the live server-side copy promptly — in any case within 30 days. Our backups are hourly and encrypted client-side before they leave the server, held in an append-only offsite copy (ciphertext only); deleted data then ages out of those backups as the snapshots expire, up to about 3 years for the longest-retained snapshots. We never restore deleted data from backup into live use. See the DPA for the full retention and deletion statement. The on-chain anchor is content-free and permanent regardless.
- Bundle (manifest + canonical doc, no file bytes) — standard mode
- Stored at
/bundle/<id>.mbnton our server. We keep it until you delete it — there is no fixed expiry. You can delete it at any time from your dashboard, or on request to hello@satsignal.cloud; deletion removes the bundle and its server-side record. Your local copy and the on-chain anchor are unaffected by server-side deletion — any.mbntyou’ve downloaded stays independently verifiable for as long as that chain operates. - Bundle — sealed mode (mirror, the default)
- Same shape, plus the master salt. Kept until you delete the proof — the same retained-until-you-delete rule as standard mode — unless you chose an explicit retention window at anchor time, in which case a server sweep auto-deletes it when that window ends (the date is printed on the proof). After a server copy is gone, 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>.mbntdoes not resolve. The chain anchor is the same 20-byte commitment as the mirror path. - Account records (anchoring)
- Your account email and workspace records (quota usage, folders, API keys) are kept for as long as the account exists, so you can sign in and manage your proofs. Ask us to close the account and we delete them; email hello@satsignal.cloud. Verification creates no account and no such record.
- HTTP access logs
- A JSON record per request — timestamp, source IP, method, host, path, status, response size and duration, and request headers such as User-Agent and Referer. Rotated by the web server’s built-in log roller (size/age-capped); not indexed and not retained beyond rotation.
- The on-chain anchor
- Permanent, by design. The chain is the property that makes a Satsignal proof 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.
Third parties, named.
Creating or verifying a proof necessarily contacts the public ledger. Here is who sees what:
- The public ledger
- 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 ledger entry is replicated across the network and stays public forever. It contains no personal data, no filename, no IP address.
- Block explorers (when you verify)
- The proof page links to
whatsonchain.comfor the chain-side lookup; the verifier itself reads the anchor transaction from WhatsOnChain, with a Bitails fallback. Either way your browser makes the request directly to the explorer — Satsignal does not mediate it. For a manual check you can use any other block explorer or run your own node. - Ledger broadcasters and chain queries (server-side)
- To anchor a proof on the public ledger, our server contacts broadcast and chain-query infrastructure. These contacts carry the operator-side transaction, not your file or any personal data of yours.
- Transport security
- The site is served over HTTPS with certificates from a standard certificate authority. Certificate issuance is an automated process that does not involve your file or your identity.
- Nobody else
- No analytics, no advertising networks, and no third-party
JavaScript at runtime — with one exception: the account
sign-in step loads Cloudflare’s Turnstile bot-protection
widget (named in the
subprocessor list). Every
other script the pages load is vendored at
/static/and SRI-pinned — full list on the security page.
Decisions you control.
- Pick the right mode for your sensitivity. Standard proofs record the payload’s SHA-256 in the proof; the chain stores a short commitment to that proof. Anyone with the same payload — or its SHA-256 — can confirm a matching Standard proof exists. Sealed proofs record a salted commitment to the payload; the chain stores a short commitment to that sealed proof. Without the bundle salt, observers cannot test candidate payloads against the proof. If existence of a proof is itself sensitive, choose Sealed.
- Request server-side bundle deletion. Email hello@satsignal.cloud with the proof’s ID. We’ll delete the live server copy promptly — in any case within 30 days; it then ages out of our encrypted, append-only backups (ciphertext only) up to about 3 years later as those snapshots expire (see the DPA). The chain anchor is permanent — that’s the property that makes the proof tamper-evident in the first place — but our server-side copy can come down.
- Access, correct, or delete your data. Email hello@satsignal.cloud to get a copy of the account and proof data we hold for you, correct it, or delete it (server-side; the public chain anchor is permanent, as noted above). On an erasure request we delete the live server-side data promptly (within 30 days); any residual copy in our encrypted, append-only backups holds ciphertext only and ages out as those snapshots expire, up to about 3 years — we do not restore deleted data from backup into live use. If you’re covered by a data-protection law such as the EU or UK GDPR, your statutory rights may also include access, rectification, erasure, restriction, objection, and portability, and the right to lodge a complaint with your supervisory authority.
- 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.
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 — for a standard proof, the same artifact anyone can fetch by its opaque ID; for a sealed proof on the default Mirror option, the server copy includes the master salt, and a requester holding that salt can test candidate payloads against the proof (a Blind submission leaves us no salt and no bundle to produce) — the proof’s server-side record (the fingerprints, file size, and any filename label or memo you typed), the access-log line for a given request, and — for an anchoring account — the account email and its workspace records. We can’t produce file bytes, names, 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.
- Business and data-processing terms
- Organizations that need a data-processing addendum — controller and processor roles, the full data inventory, per-mode retention, subprocessors, and international-transfer terms — can use our data-processing addendum (currently a draft pending counsel review).
- Jurisdiction
- The service is operated by Satsignal LLC, an Iowa limited liability company. Privacy-related questions are governed by the laws of the State of Iowa, without regard to its conflict-of-laws rules. Detailed dispute-resolution mechanics are pending counsel. See the full terms.
- Contact
- Email hello@satsignal.cloud for any privacy-related question, deletion request, or correction.