Data-processing addendum.
What Satsignal processes on your behalf when you anchor proofs, exactly how long each artifact stays, who else touches it, and what can — and deliberately cannot — be deleted. The unusual part of this DPA is how little there is to govern: on the anchoring API, your file contents never reach us at all.
DRAFT v0.1 — prepared 2026-06-11, pending counsel review. This is a complete working draft of the data-processing addendum, published so privacy and procurement reviewers can assess the actual data flows before counsel finalizes the text. It has not been reviewed by counsel, is not yet offered for signature, and may change. Square-bracketed items are open points for counsel. To request a signed DPA or the current subprocessor list: hello@satsignal.cloud.
You are the controller; Satsignal is your processor — with one account-administration carve-out.
This addendum applies when you (the customer) use the hosted Satsignal service to anchor proofs and, in doing so, any personal data is processed. For that personal data, the customer acts as controller (or as a processor on behalf of its own controllers) and Satsignal LLC acts as processor, processing only on the customer’s documented instructions — the instructions being: operate the service as documented, anchor what the customer submits, and honor the retention and deletion rules below.
Two roles, by activity. For customer proof data submitted for anchoring — fingerprints, commitments, and the optional label/filename/memo — Satsignal acts as processor on the customer’s documented instructions, as above. For account administration — creating and operating the account, billing, fraud prevention, security, and meeting Satsignal’s own legal obligations — Satsignal determines its own purposes and acts as an independent controller for that limited data (account email, workspace and quota records, API-key metadata, short-lived access logs). [Counsel to confirm this controller/processor split and its labels.]
One deliberate boundary case. The on-chain anchor itself — a short content-free commitment written to the public Bitcoin SV chain (section 03) — contains no personal data: no name, no email, no filename, no IP address, and no fingerprint that is itself personal data unless the customer chooses to anchor one in Standard mode. Once broadcast it is outside anyone’s operational control, including ours; section 08 states the consequences precisely. [Counsel to confirm the characterization of the broadcast transaction under applicable data-protection law.]
Tamper-evidence and timing — from fingerprints, not files.
Satsignal anchors SHA-256 fingerprints and salted commitments
to the public Bitcoin SV chain and returns verifiable
.mbnt bundles. Processing consists of: accepting
fingerprints and the small metadata fields listed in
section 03; building and broadcasting the content-free
anchor transaction; assembling the bundle; storing what
section 04 says is stored, for as long as it says; and
operating the customer’s account (sign-in, quotas, API
keys, dashboards) — for which the controller/processor roles
are set out in section 01. Duration: the term of the agreement
plus the
deletion handling in section 08.
Exactly what reaches us — and the one thing that never does.
Never transmitted on the anchoring API: your file contents. For file, contract-commitment, policy-snapshot, and sealed proofs, hashing happens client-side (in the browser or your own integration) and only fingerprints cross the wire. For manifest-backed proofs you hash each item yourself and submit only label-plus-fingerprint pairs; the server assembles the Merkle leaves and root from those fingerprints — item bytes still never cross the wire. There is no upload endpoint on those paths; we could not retain your file bytes if we wanted to, because we never receive them.
What is processed:
- Account data — the email address used for magic-link sign-in and account notices; workspace records (plan, quota usage, folder names, API-key metadata).
- Per-proof data — hex fingerprints and salted
commitments; the file size; the optional, freeform label,
filename, and memo strings you choose to type (kept in our
private server-side records — not in the
.mbntbundle a customer downloads — and never written to chain; if you type personal data into them, we receive it); the transaction id and timestamps. - Sealed-mode material — in Mirror storage (the default), the bundle we mirror contains the salted-hash structures and the master salt, held until you delete the proof or, where an explicit retention window was set, until that window expires (section 04). In Blind submission, the salt never leaves your device and no bundle is stored with us at all.
- HTTP request metadata — timestamp, source IP, path, status, one line per request.
Two documented exceptions, by design:
- Incoming webhook proofs. If you point a SaaS source’s webhook at a Satsignal webhook URL, the raw event body necessarily transits our server: it is read to verify the source’s signature and compute its SHA-256, and only the fingerprint enters the proof record — the body itself is not stored. Don’t route webhook payloads you don’t want transiting our infrastructure.
- Plaintext provenance manifests. The provenance endpoint accepts a structured JSON manifest whose canonical form is hashed server-side and shipped inside the bundle, so a plaintext provenance manifest (including any personal data you put in its fields) is stored with the bundle. A sealed provenance path exists where the manifest is canonicalized and committed client-side and never reaches us — use it for sensitive manifests.
By artifact and mode.
- Standard-mode bundle (server copy)
- Stored until you delete it from the dashboard or by request
— no automatic expiry is applied to the server copy today.
Your downloaded
.mbntis yours and verifies independently forever. - Sealed-mode bundle — Mirror (default)
- Stored until you delete the proof — the same retained-until-deletion rule as a standard-mode bundle, on every plan. Each anchor may instead set an explicit retention window (minimum 1 day); a server sweep then removes the mirrored bundle, including the master salt, when that window expires. After a server copy is gone, only the holder of the local bundle can verify. Proofs anchored before 2026-06-11 carry the retention window recorded at anchor time and are removed when it expires, as originally stated on those proofs.
- Sealed-mode — Blind submission
- No bundle and no salt are ever stored with us; the bundle is assembled in your browser at submit time. Transient operational records from the submission are removed by a housekeeping sweep within minutes (the sweep runs every 10 minutes). What remains is a bookkeeping row — proof id, transaction id, timestamps, and any label you typed — and the content-free on-chain anchor.
- Account records
- Email address and workspace records are kept for the life of the account so you can sign in and manage proofs; deleted on account closure (section 08).
- HTTP access logs
- Rotated by the operating system on a short cycle; not indexed, not retained beyond ordinary rotation.
- The on-chain anchor
- Permanent, by design, and content-free: roughly 20 bytes of truncated commitment plus a small structural marker. It is the property that keeps a proof verifiable years later and is not personal data on its own.
What actually protects the little we hold.
- Structural minimization first. The strongest control is architectural: file bytes never arrive (section 03), and Blind submission extends that to the salt and bundle — in Blind mode we hold no plaintext material whatsoever for the proof.
- Scoped API authentication. Every anchoring call requires an API key; keys carry explicit permission scopes and can be restricted to individual folders. Keys are revocable; minting and revoking keys is restricted to the workspace owner.
- Account access via magic-link email sign-in — no passwords stored.
- Transport security — HTTPS throughout; the public pages carry a strict content-security policy and integrity-pinned scripts (see the security page).
- Backups — server state is backed up hourly (worst-case loss about one hour), with client-side encryption before it leaves the server; the offsite copy is held under credentials that cannot delete or rewrite existing snapshots. Backup retention follows the live data: a deleted artifact ages out of the encrypted backups as those snapshots expire under the backup-retention schedule — up to about 3 years for the longest-retained snapshots.
- Operational posture — a deliberately small, single-operator service: production access is held by the operator alone, with no additional staff accounts to manage or compromise. Security posture and the disclosure contact are published on the security page.
Who they are, and what each one can see.
Satsignal uses a deliberately short list of subprocessors, named below. This list is also an annex to the signed DPA, and we keep it current under the change-notice clause below.
- Hostinger — infrastructure hosting
- Hosts the virtual server the service runs on (and the operator mailbox); the databases, proof bundles, and server-side metadata records live here. Can see what any infrastructure host can see: the running server’s disk and network metadata. An EU-based hosting provider, headquartered in Lithuania.
- Backblaze, Inc. — offsite backup storage
- Stores backup snapshots that are encrypted client-side before upload; the provider holds ciphertext only and cannot read bundles, account records, or salts. Credentials are append-only (no delete/rewrite of existing snapshots). Headquartered in San Mateo, California, USA.
- Cloudflare, Inc. — sign-in bot protection (Turnstile)
- When the bot-protection challenge is enabled, account sign-in
loads Cloudflare’s Turnstile widget in the visitor’s
browser (directly from
challenges.cloudflare.com), and on submit the server also forwards the visitor’s source IP to Cloudflare to validate the challenge token. Because the widget runs in the browser, Cloudflare’s edge receives the source IP and the usual browser request signals (user-agent, request headers, and its own challenge telemetry) and may set a short-lived anti-abuse cookie. It does not receive any email, file fingerprint, or proof content. The challenge appears only at the sign-in step — the sign-in page atapp.satsignal.cloudand the sign-in prompt embedded in the anchor forms — never on the offline verifier or proof pages. Cloudflare is a US company headquartered in San Francisco, California, USA, operating a global edge network, so the IP may be processed at an edge node near the visitor. (When the challenge is not configured on a deployment, the widget is not loaded and no data is sent to Cloudflare.)
Broadcast to the public Bitcoin SV network uses public endpoints. Because the anchor transaction carries only a content-free ~20-byte commitment plus a small structural marker — no personal data, no filename — these are public infrastructure rather than a subprocessor of personal data; the same data is, by design, visible to the entire network.
Change notice. We will give customers with a signed DPA at least 30 days’ notice before adding or replacing a subprocessor (notice by email to the account address), and the customer may object on reasonable data-protection grounds; if the objection cannot be resolved, the customer may terminate the affected service with a pro-rata refund of prepaid fees. Transactional sign-in email is currently sent from our own server, not via a third-party email provider; if that changes it will be handled as a subprocessor addition under this clause.
What we can demonstrate, and how requests flow.
Data-subject requests. Requests from individuals (access, deletion, correction) that reach us but concern data the customer controls are forwarded to the customer; we assist with fulfilling them within the bounds of section 04 and section 08. Because we never hold file contents, most requests reduce to: the account email, label/filename/memo strings, and server-side bundles — all deletable.
Audit support. On reasonable request, we will provide the information needed to demonstrate the obligations in this addendum — the published specifications, this data inventory, and the subprocessor annex. The verification path itself is independently auditable by construction: the bundle format and verifier are open, so a reviewer can confirm without our cooperation that proofs verify without sending us data. [Counsel: scope of on-site/remote audit rights appropriate for a single-operator service.]
What we delete on termination — and the one thing nobody can.
Deletable, and deleted. On account closure or termination (or earlier on instruction), we delete: the account email and workspace records; API keys; label, filename, and memo strings; remaining server-side bundles — Standard copies and any unexpired Sealed mirrors, including mirrored master salts. Live-storage deletion is completed promptly, and in any case within 30 days. Deleted data then ages out of our encrypted, append-only backups (ciphertext only) as those snapshots expire under the backup-retention schedule — up to about 3 years for the longest-retained snapshots (section 05).
Not deletable, by anyone. The on-chain anchor — the ~20-byte content-free commitment inside a Bitcoin SV transaction — is replicated across a public network that Satsignal does not operate or control. It cannot be edited or removed by us, by the customer, or by a third party; permanence is the service’s core property, stated before every anchor. The anchor carries no personal data itself. The residual consideration is mode-dependent and disclosed up front: a Standard anchor lets anyone who already holds the same payload (or its SHA-256) confirm a matching proof exists; a Sealed anchor is a salted commitment that exposes no matchable fingerprint without the salt. Customers anchoring fingerprints of personal data should prefer Sealed mode for exactly this reason. On an erasure request we delete the requester’s live server-side data within 30 days; the encrypted, append-only backups hold ciphertext only and are never restored into live use, so the residual backup copy is functionally unreadable and ages out as its snapshots expire (section 05). The on-chain anchor is content-free (a ~20-byte commitment, no personal data) and is replicated across a public network we do not control, so it falls outside any practicable erasure obligation; sealed mode is offered precisely so that even the existence of a matchable fingerprint can be withheld. We treat key/live-data deletion (crypto-shredding) as the operative erasure act for material we hold. [Counsel: confirm this erasure-vs-backup-tail and immutable-anchor treatment.]
What the customer keeps. Deletion on our side never touches the customer’s downloaded bundles or the chain; every proof already delivered remains verifiable (terms, section 13).
If something goes wrong, you hear it from us, fast.
We will notify affected customers of a personal-data breach without undue delay after becoming aware of it — targeting within 72 hours — by email to the account address, with what we then know: the nature of the incident, the categories and approximate volume of data involved, likely consequences, and the measures taken. Because of the inventory in section 03, the blast radius of a worst-case server breach is structurally bounded: account emails, metadata strings, server-side bundles and unexpired mirrored salts — never customer file contents.
Open point for counsel.
[Counsel to complete. Intended approach: identify the hosting and backup storage locations in the subprocessor annex; for customers transferring personal data from the EEA/UK/CH, incorporate the appropriate EU Standard Contractual Clauses module(s) — expected Module 2 (controller → processor) for customer proof data, and counsel to confirm whether Module 1 (controller → controller) is also needed for the account-administration data for which Satsignal acts as independent controller (section 01) — and UK addendum, with the annexes populated from sections 03–06 of this addendum. The on-chain anchor is globally replicated by design and carries no personal data; counsel to confirm it sits outside transfer-restriction analysis.]
How this becomes binding.
This addendum takes effect when incorporated into a signed agreement (design-partner agreement or order form) or when both parties execute it directly, and lasts as long as we process personal data for you. It prevails over the terms of use for data-protection subject areas. [Counsel: signature mechanics — whether the published DPA is offered for countersignature as-is, via order-form incorporation, or both.] Until counsel review completes, this page is a draft and is not offered for signature; procurement teams that need a signed DPA now should email hello@satsignal.cloud and we will handle it directly.