Everything you need to evaluate Satsignal — already public.
This page assembles, in one place, what a prospective design partner — or their security, privacy, or compliance reviewer — needs: live on-chain samples you can verify yourself, the scope statements, the security and data-handling pages, the published legal drafts, and live operational status. Nothing here requires an account or an NDA.
Verify something yourself.
The strongest evidence we can offer is real on-chain proofs you can re-check without us. Verification is free, account-free, works offline, and resolves against any public chain explorer — it does not depend on Satsignal staying in business. Each sample below ships its artifacts and a reproduction path.
.mbnt bundle — no account, runs entirely in your browser.
proof.satsignal.cloud
Interop samples on mainnet
Five live mainnet samples — a full reproduction recipe with pure-stdlib verification snippets, each anchor confirmable on a public explorer.
satsignal.cloud
Sealed deep-content samples
Anchor everything, disclose selectively: downloadable disclosure bundles plus redacted copies — run the tamper test yourself.
satsignal.cloud
Agent Evaluation demo
A grader’s policy snapshot provably anchored before its verdicts — two mainnet transactions in miner-attested order.
satsignal.cloud
Sealed Bid demo
Five sealed bids, one anchor, one row revealed — verify the reveal offline and resolve the commitment account-free.
satsignal.cloud
File-proof gallery
Six live share pages — one anchored sample each for PDF, CSV, PNG, JSON, ZIP, and plain text.
satsignal.cloud
Prefer to verify from code or CI? The docs cover programmatic verification, a confirmation-depth gate, and the durability table.
What it proves — and what it doesn’t.
The scope statement is held word-for-word identical across the site, the verifier, and the legal drafts: a proof establishes tamper-evidence and timing, not authorship, truth, or pre-existence.
- What a proof proves, and what it doesn’t
- The canonical scope statement, written for lawyers, auditors, and regulators: integrity, timing, inclusion, and commitment are established — truth, authorship, pre-existence, legal compliance, and completeness are explicitly not, unless precommitted in the manifest.
- The canonical proof model
- Defines
satsignal.provenance.v1— the single canonical evidence object every adapter normalizes into, with C2PA/Sigstore/SLSA bridging in by digest. - Why this chain
- Chain-choice rationale for a skeptical reviewer: the chain is a timestamp substrate carrying one commitment per anchor (never content), what reorgs and confirmation depth mean for an anchor, and why issued proofs don’t depend on Satsignal existing.
- Wire-format specs & conformance vectors
- The full
.mbntand on-chain anchor specifications, plus the pass/fail vectors any independent verifier implementation must satisfy. The OpenAPI reference is the machine-readable API contract.
What we receive, what we never hold.
Each page below owns its own claims and numbers; this index deliberately restates none of them.
- Trust & privacy
- The trust model layer by layer — who must trust whom — with an artifact grid linking every claim to a spec, conformance vectors, the open verifier, or the public ledger, including Standard vs Sealed chain exposure and the documented incoming-webhook carve-out.
- Security posture
- Plain-language posture: browser-local hashing on the file-proof path, bundles that structurally cannot contain file bytes, vendored SRI-pinned JavaScript with no runtime CDN, HTTPS/HSTS/CSP, rate limits on write endpoints (verifying a bundle is not rate-limited), and vulnerability reporting via hello@satsignal.cloud.
- Privacy (effective, non-draft)
- A concrete what-we-receive vs what-we-never-receive inventory, per-artifact retention by mode, named third parties (and “nobody else” — no analytics), and a lawful-process clause enumerating exactly what is compellable.
- Data-processing addendum (draft)
- The densest document for a privacy or procurement reviewer: controller/processor roles, the exact data inventory — including the honestly documented server-side carve-outs — security measures, subprocessor categories with change notice, and breach-notice terms. Published as a marked draft; see Legal below.
Published drafts, open for redlining.
The three documents below are published drafts under counsel review, each carrying an amber DRAFT banner, with square-bracketed open points marked where counsel input is needed, and not yet offered for signature. They are published early on purpose — so a reviewer can redline before anything is signed. The privacy page (above) is effective, not draft.
- Terms of use
- Plain-language sections 01–06 (effective since 2026-05-16) defining what a proof does and does not establish, plus complete draft formal sections 07–16 (fees, acceptable use, availability, warranties, liability, termination, governing law) marked DRAFT v0.1 pending counsel review. Downloaded bundles and on-chain anchors survive any termination or shutdown.
- Data-processing addendum
- Complete draft DPA (DRAFT v0.1, pending counsel review): roles, data inventory, per-mode retention, security measures, subprocessors, breach notice, and the deletion-vs-permanent-anchor clause. International transfers are an explicit open point for counsel.
- Embedding & resale rider
- Draft one-page rider (DRAFT v0.1, pending counsel review) for platform partners who may embed Satsignal anchoring: sealed-mode by default, the attribution-vs-white-label split, no sublicensing or key pooling, and the terms that must flow down to end customers.
Status you can probe, posture stated plainly.
- Live status
- Per-component health sourced from independent third-party
monitoring (healthchecks.io) — the page never shows a green
light it didn’t receive — with public
/healthzendpoints you can probe directly without trusting the badge. - Availability & SLA
- States plainly that there is no formal SLA during early access, names the published engineering target (contractual only when paid plans launch), and gives an outage-impact breakdown showing that already-anchored proofs verify offline regardless of our uptime. Availability riders are part of the design-partner conversation.
Early-stage realities, stated plainly.
Where honest disclosure beats an engineering promise we can’t yet make, here is the operating posture a reviewer should know going in. Every item below is mitigated by the same thing: the proof is a file you hold and can verify offline against the public chain, with no dependency on Satsignal.
- One operator, one region today
- Satsignal is operated by one person from a single production
server today. The durable guarantee is the proof artifact, not
the hosted service: every downloaded
.mbntverifies offline, against the public chain, with no Satsignal dependency. - Business continuity
- Bundles are retained until you delete them, and a wind-down of
the hosted service takes 90 days’ notice
(terms §13). Because
every
.mbntverifies offline against the chain with no dependency on us, download your bundles at anchor time and your proofs survive any wind-down regardless. Design-partner terms add a bulk export of your retained server-side bundles. - No third-party security attestation yet
- No SOC 2, penetration test, or bug bounty at this size. In their place: this packet’s security overview, the open-source in-browser verifier you can audit yourself, and a published vulnerability contact with a stated acknowledgment target (security.html §04).
- Single-operator anchor authority
- Anchors are signed by a single operator key today; multi-party signing is on the roadmap. What that key cannot do: alter or backdate an existing anchor — the chain holds those.
- Single-user workspaces, no roles
- Workspaces are single-user today; per-agent scoped API keys are the supported attribution mechanism, and viewer/auditor roles are on the roadmap — the audit packet plus a read-only key is the interim auditor seat.
- Bundle links are bearer capabilities
- Server-stored bundles are addressed by an unguessable 64-bit ID that is itself the access capability — whoever holds a bundle or share link can fetch it, so treat those links as bearer secrets. Sealed-blind anchors keep no server copy at all.
- Hourly backup RPO
- Backups are hourly, 3-2-1 with an append-only offsite copy (encrypted client-side, ciphertext only); worst-case data loss for server-side metadata is one hour. When you delete a proof the live copy is removed promptly (within 30 days) and then ages out of the encrypted backups up to about 3 years later as those snapshots expire (see the DPA). Your proofs on chain and your downloaded bundles are unaffected.
Become a design partner.
Pricing is opening with design partners first, and self-serve billing is not yet enabled — partners onboard directly with us. What that means in practice: direct contact with the operator, invoice billing, and custom retention and data-handling terms as part of the design-partner offer. Current posture and the free tier are on the pricing page; this page intentionally repeats no numbers.