·Trust & privacy

How Satsignal earns trust.

Independence from the operator is the whole point. Whether you’re anchoring an agent commitment, a policy snapshot, an evidence manifest, or an ordinary file, the proof is verifiable without us — against the on-chain commitment itself, through any public block explorer.

A proof establishes the anchorer knew this exact fingerprint by time T (and, if they later produce matching bytes, held data matching it) — tamper-evidence and timing. It does not prove authorship, authority, truth, that the content existed before T, or that any event it describes happened.

·The receipts

Don’t take our word — read the artifacts.

Every claim on this page resolves to something you can open, run, or re-check yourself. Here is the whole evidence surface in one place — specs, vectors, the verifier, and the public ledger.

Canonical proof model Exactly what every proof commits to — the canonical JSON, byte for byte. satsignal.cloud Protocol specification The full .mbnt bundle format and on-chain anchor protocol. proof.satsignal.cloud Conformance vectors The pass/fail test vectors every compliant verifier must satisfy. proof.satsignal.cloud OpenAPI reference The machine-readable API contract, rendered live from the spec. proof.satsignal.cloud In-browser verifier Re-check any proof yourself — no account, runs entirely in your browser. proof.satsignal.cloud Security posture How keys, broadcast, and data handling are secured — and what one operator key can and can’t do. satsignal.cloud Privacy policy What we keep (short fingerprints + one log line) and what we never see. satsignal.cloud Anchors on the public ledger Every anchor is a real Bitcoin SV transaction — inspect it on an independent explorer. whatsonchain.com ↗

The trust model, in one look

Who has to trust whom?

A Satsignal proof is designed so the people checking it don’t have to trust you, the platform that ran the agent, or us. Here’s exactly where trust does — and doesn’t — sit.

Layer	Who you rely on	Satsignal’s role
Original payload	You keep it — it never has to leave your side	Doesn’t need to store it
Fingerprint	Publicly verifiable maths — anyone can recompute it	Anchors it on a public chain
Chain transaction	Independent miners mine the block that carries the commitment	Broadcasts — doesn’t mine
Verification	Anyone can re-run the checks themselves	No account, no API needed^*

^* With the .mbnt proof in hand. Hash-discovery and sealed-row reveal use a Satsignal lookup — the cryptographic checks themselves never do.

You hold the data·The chain holds the proof·Anyone holds the verifier

01Why people use it

Built to outlast us.

Only short fingerprints reach our server

Commitments, snapshots, manifest leaves, and files are hashed locally; only short fingerprints reach our server. The one exception is incoming-webhook anchoring — the provider sends the raw body and we hash it server-side.

Independently verifiable

Each anchor is an ordinary Bitcoin SV transaction, mined into a public block anyone can look up — the on-chain commitment is what verification rests on. The .mbnt manifest may also carry a broadcast acceptance record (when the broadcast service returned one) noting which mining endpoint accepted the transaction and its reported status: useful corroboration, but informational only, not independently verifiable, and never load-bearing. The verifier is a single static HTML file you can save, share, and audit. It runs in any browser and checks your bundle against the public chain by reading the anchor from a public block explorer — WhatsOnChain, with a Bitails fallback — never through us.

Works after we don’t

The verifier is a single static HTML file you can save and run offline. Your bundle is a small .mbnt you can email, attach, or archive. As long as one Bitcoin SV node or block explorer is reachable, the proof keeps verifying — with or without us.

Selective disclosure

An evidence manifest can hold up to 10,000 items behind one on-chain anchor. The holder can later prove any single item was in the batch — without revealing the others. Same primitive works at the file level for proving one page, one row, or one archived entry was the version anchored.

02Questions worth asking

Things people want to know before they trust this.

Is Satsignal free?: Verification at proof.satsignal.cloud/verify is always free and never asks for an account — recipients of a .mbnt bundle can confirm it without signing up. Anchoring a new proof — on proof.satsignal.cloud (sealed mode at proof.satsignal.cloud/sealed), or via the app.satsignal.cloud API — uses a magic-link account. Sign-in is instant: enter your email, click the link we send, and you’re anchoring within a minute. New accounts start on the free plan; current limits and planned paid plans are on the pricing page. Verification stays free and account-free regardless.
Does my payload actually leave my environment?: For file and contract proofs, commitments, policy snapshots, and manifests: no. The browser form hashes files locally before they leave your device; the API accepts fingerprints your runtime computes before the call — commitments, policy snapshots, and the per-item hashes of a manifest; the server assembles the manifest’s Merkle leaves and root from those fingerprints. Only short fingerprints reach our server — never the underlying bytes. Filename labels and memos travel with the form and are kept in our private server-side record — not in the .mbnt bundle you download and share — but never reach the chain. The raw payload itself is yours. One deliberate exception: incoming-webhook anchoring — when you point a Stripe, GitHub, Langfuse, or custom webhook at Satsignal, the provider delivers the raw event body to us and we hash it server-side. That is the feature; if an event must never reach our server, hash it in your own runtime and use the standard API instead.
What can the chain reveal about me?: 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 instead; without the bundle salt, observers cannot test candidate payloads against the proof. If existence of a proof is itself sensitive (an unrevealed bid, an internal policy snapshot, a pre-disclosure exhibit), choose Sealed.
Why does this matter for AI agents?: Internal logs answer to the operator that runs them. That’s fine for the easy cases. The hard cases — an incident review, a regulator request, a losing bidder asking to see the proofs — are exactly the cases where the platform’s log can no longer be the sole source of truth. A public on-chain anchor lets a third party verify what was committed, when, and under what policy — without trusting your dashboard, your platform vendor, or us.
How long does a proof last?: As long as the Bitcoin SV chain has the transaction, which is effectively permanent. If “effectively permanent” on a minority-hashrate chain raises an eyebrow, we answer that directly. Your bundle is small enough to email or archive; that copy plus any block explorer is enough to verify years later.
What happens if Satsignal disappears?: Your anchor and bundle keep working without us — as long as you still hold the .mbnt. The verifier is a single static HTML file you can save now and run offline; while one Bitcoin SV node or block explorer is reachable, the chain side checks out and your bundle ties the payload fingerprint to it. If you never downloaded the bundle, re-binding the on-chain transaction to your payload’s hash relies on our public /lookup_hash — no account, but it is the one Satsignal-hosted step, so download your bundle while the proof is live.
Is the verifier open source?: Yes — the verifier is a single static HTML file you can save, audit, and share. It runs in any browser and reads the anchor from a public block explorer — WhatsOnChain, with a Bitails fallback — so verification never goes through us.
Can I verify completely offline?: Almost. The bundle’s internal integrity (canonical doc to its 20-byte commitment to the on-chain marker structure) checks fully offline. The “is it really on the chain?” step needs internet — the verifier reads it from WhatsOnChain (with a Bitails fallback), and you can confirm the same txid on any explorer or your own node — and so does re-deriving a PDF’s text-content fingerprint, which loads the PDF text-extraction library on demand.
What does a Satsignal proof establish — and what does it not?: A valid proof establishes that whoever submitted the anchor knew this exact payload — an agent commitment, a policy snapshot, a manifest leaf, or an ordinary file — by the timestamp of its on-chain transaction. It does not, by itself, prove who produced the payload, that the content predates the anchor, what its claims mean, or that any underlying event actually happened. For those questions you still need surrounding documentation, witnesses, or counsel. Satsignal is tamper-evidence and timing, not authentication of intent or fact. Full terms →