Litigation evidence preservation.
A litigator preparing to introduce a chain-anchored proof — or to rebut one offered by opposing counsel — needs to know what the proof does and doesn’t prove, what the operator can attest to, and how to preserve the artifact so the proof survives to trial. This page describes that workflow honestly: it is not a claim of admissibility.
Authentication, integrity, and preservation.
An offering party of a digital record typically needs to show three things: that the record is what it purports to be, that it hasn’t been altered since creation, and that custody of it can be accounted for. A Satsignal proof contributes to the middle two by design and to the first via a sworn declaration from a qualified witness. None of the three are answered by the proof alone.
Authentication of the record
The proof binds a SHA-256 of a specific document to a public-chain transaction at a specific time. What the operator can sworn-attest to is narrow and concrete: it received that SHA-256 digest, embedded it in the bundle the system produced, and broadcast the chain transaction — and, for digests submitted through the programmatic API under a workspace key, that the submission was tied to that account. (The operator-attended browser form keeps no account-linked record, so for those submissions the operator can attest to the bundle and broadcast but not to an account.) The document’s bytes never reach Satsignal — they are hashed on the customer’s machine — so the operator cannot attest to the bytes themselves, only to the digest it received and committed. The declaration template below sets out those facts in the form a witness could adopt under oath; admission of the underlying record still rests on FRE 901 / 902 analysis with the court.
Integrity since the anchor moment
This is the property the proof is designed to give. Re-hashing the document and walking the bundle’s cryptographic path to a transaction that’s been confirmed by independent miners shows the bytes haven’t changed since that block. A reviewer verifies this in any browser against any public block explorer — no Satsignal account, no platform trust.
Preservation of the artifact
The chain transaction is durable independent of
Satsignal. The .mbnt bundle and (for standard
mode) the canonical document on the operator’s
server are not guaranteed to be. A sealed-mirror server copy
is kept until the proof is deleted by default, but an anchor
can carry an explicit retention window that auto-deletes it
— and deletion (by the customer or by such a window)
is always possible; the customer must self-preserve.
The preservation recipe below sets
out the four artifacts a litigator should hold.
Three scenarios where the proof’s shape changes the case.
Plenty of digital-evidence questions are answered adequately by routine business-records testimony or vendor logs. The Satsignal proof has structural properties that matter most in a narrower set of scenarios — not because alternative timestamping mechanisms fail there, but because the public-chain anchor changes who has to be trusted.
policy_snapshot or commitment
proof anchors the bytes to a chain timestamp predating the
dispute, settled in a block whose mining was outside the
offering party’s control. The point isn’t that
alternative timestamps are unreliable; it’s that this
one doesn’t require the court to weigh the offering
party’s vendor relationships at all.
Four artifacts to hold for the record.
The chain transaction is durable; everything else is the litigator’s problem. The recipe is short. Once preserved, the four artifacts together let any qualified witness reproduce the verification end-to-end at trial.
# 1. Save the .mbnt bundle. This is the primary preservation
# artifact: a standard ZIP holding manifest.json (mode, mbnt
# version, the chain txid), canonical.json (the document whose
# hash is committed on-chain), and, for batched/manifest proofs,
# proofs.json (the Merkle leaves). Treat it as any other digital
# exhibit: hash it, log it, store it on write-once or
# version-controlled media.
#
# The bundle is private to your workspace. Download it from your
# dashboard at app.satsignal.cloud ("Download bundle (.mbnt)" on
# the proof page), OR over the API with a programmatic key minted
# in the dashboard under API keys (/w/<workspace>/keys; scope
# proofs:read).
# A bare curl with no Authorization header returns 401.
curl -O -H "Authorization: Bearer sk_<your-api-key>" \
"https://app.satsignal.cloud/bundle/<proof_id>.mbnt"
sha256sum <proof_id>.mbnt > bundle.sha256.txt
# 2. Save the canonical document the bundle commits to. For
# standard-mode anchors this is the file the customer submitted.
# For sealed-mode anchors it's the customer-held document plus
# the salt printed on the proof; the operator does not have it.
# Either way the offering party must produce these bytes at trial
# or there is nothing for the proof to bind to.
sha256sum <canonical_document> > document.sha256.txt
# 3. Note the chain transaction. The txid lives at the top level of
# manifest.json inside the bundle; unzip the .mbnt, read it, and
# record it independently against any public BSV block explorer.
# Print the explorer view as exhibited evidence; the operator's
# site is a convenience, not a system of record.
unzip -o <proof_id>.mbnt manifest.json
TXID=$(jq -r .txid manifest.json)
echo "https://whatsonchain.com/tx/$TXID" > chain_reference.txt
# 4. Verify end-to-end yourself, before depositions, and again
# before trial. The verifier is a single static web page that runs
# its checks in your browser — there is no result to curl down.
# Open https://proof.satsignal.cloud/verify , drag in the .mbnt
# bundle from step 1 and the canonical document from step 2, let
# it walk the cryptographic path to the confirmed chain
# transaction, and screenshot the green result for the record.
# The verifier walks the same path a court-appointed witness will.
# 5. Adapt the declaration template below with your qualified
# witness (the operator, the customer's IT custodian, or both
# depending on your authentication theory). Filed as a
# declaration in support; the court does the FRE 901/902
# analysis on motion.
A starting point for a qualified-witness declaration.
The text below is a template, not a form. Counsel must adapt it to the case, the jurisdiction, the rules of evidence in force, and the witness actually offered. The Satsignal operator can sworn-attest to the system facts in paragraphs 4–6; the customer’s custodian typically attests to paragraphs 1–3 (the document and how it was held). Both attestations are usually needed.
DECLARATION OF [WITNESS NAME] IN SUPPORT OF AUTHENTICATION OF
EXHIBIT [N]
I, [witness name], declare under penalty of perjury under the
laws of [jurisdiction]:
1. I am [title] at [organization]. I make this declaration based
on personal knowledge and on the records of [organization]
maintained in the regular course of business. If called as a
witness, I could and would competently testify to the matters
set forth below.
2. Exhibit [N] is a true and correct copy of [describe document]
("the Document"). The Document was [created / received / held]
by [organization] on or about [date], in the regular course of
business, by a person with knowledge of the events recorded.
3. On [anchor date], [organization] computed the SHA-256 digest of
the Document on its own systems and caused that digest to be
submitted to the Satsignal LLC anchoring service (hereinafter
"Satsignal") operated at satsignal.cloud, which produced a proof,
recorded in the bundle identified below ("the Bundle"). The bytes
of the Document submitted to [organization]'s hashing step at that
time were preserved by [organization] and are byte-for-byte
identical to the bytes of Exhibit [N]; the SHA-256 digest recorded
in the Bundle is the digest of those bytes.
4. [Operator-witness paragraph.] Satsignal is an anchoring
service that, for each submission, receives a SHA-256 digest
computed by the submitter — the document's bytes are hashed on
the submitter's own machine and are never transmitted to or
received by Satsignal — embeds that digest in a structured
bundle ("the .mbnt bundle"), and broadcasts a transaction
containing a derived 20-byte commitment to the public Bitcoin SV
blockchain. The system documentation is published at
satsignal.cloud/spec-mbnt and at satsignal.cloud/docs.html and is
incorporated herein by reference.
5. [Operator-witness paragraph.] On [anchor date] at
approximately [UTC time], the Satsignal system received the
SHA-256 digest [hex digest], embedded it in the proof identified
as [proof id], and broadcast transaction [txid] to the BSV
network. The transaction was subsequently recorded in block
[height] as reported by the public chain. A copy of the bundle as
produced by the system is attached as Exhibit [M].
[If the digest was submitted through the programmatic API with a
workspace API key, add: "The submission was authenticated to the
API key issued to the account of [customer organization], and the
proof is recorded against that account in Satsignal's records."
The operator-attended browser form does NOT bind a submission to a
customer account — it writes only a bundle and its metadata, with
no account-linked record — so this account-attribution sentence
applies only to API-key submissions; omit it otherwise.]
6. [Operator-witness paragraph.] Verification is independent of
Satsignal — no Satsignal software, account, or service is
required — but it has two distinct steps. (a) Confirming the
submitted document is unchanged needs only a SHA-256
implementation: any reviewer with the document's bytes recomputes
its SHA-256 digest and checks it against the digest recorded in
the bundle. (b) Confirming that digest is the one committed
on-chain is not a plain SHA-256 of the file: the on-chain value
is a 20-byte commitment derived from the bundle's canonical.json
re-encoded under Satsignal Canonical JSON v1 (SCJ-v1) — the first
20 bytes of sha256(SCJ-v1(canonical.json)) — as specified at
satsignal.cloud/spec-mbnt. A reviewer reproduces this by
re-encoding canonical.json under SCJ-v1 and comparing the
resulting commitment against the data output of the chain
transaction read from a public BSV block explorer. The in-browser
verifier performs both steps automatically; either can also be
reproduced by hand from the published specification.
7. I declare under penalty of perjury that the foregoing is true
and correct.
Executed on [date] at [city, state/country].
_________________________________
[Witness signature]
[Printed name, title]
This template makes no representation that any specific court will admit the proof on this declaration, that the declaration alone satisfies any specific authentication rule, or that prior practice supports its use. Counsel must make their own admissibility judgment with the witness and the record in front of them.
Honest limits before any court.
Nothing on this page is legal advice and Satsignal is not a forensic-evidence service. Specifically:
- No claim of self-authentication. The proof is not a substitute for the FRE 901 / 902 analysis any court will run on motion. The operator’s declaration sets out facts a witness can attest to; whether those facts plus the rest of the offering party’s foundation suffice for admission is for the court, not us.
- No claim of acceptance. Satsignal has not been certified, audited, or accepted as evidence in any specific proceeding to our knowledge. The scheme is novel; admission today realistically requires a qualified witness explaining the cryptography from first principles, and may require expert testimony under the court’s reliability standard for scientific or technical evidence.
- The operator is a small, independent project. We do not hold institutional accreditation, regulatory status, or industry-body recognition. Counsel should weigh this honestly when choosing whether the proof is the right tool for the case — for many matters a routine business-records foundation will suffice without involving us at all.
- Sealed-mode server copies can disappear. Per the privacy page, a sealed-mirror copy is kept until the proof is deleted (or, where the anchor set an explicit retention window, until that window expires). The chain transaction persists; the canonical bytes do not survive deletion unless the customer has preserved them. For sealed-mode evidence, customer self-preservation is the only reliable path to the canonical document at trial.
- The proof is not the document. A proof confirms that a specific hash was anchored at a specific moment. It does not establish the document is what it purports to be, that the offering party has personal knowledge of its origin, or that any other rule of evidence permits its use. A document that fails routine authentication does not become admissible because it was anchored.
- Long-term cryptographic durability is not addressed. The proof depends on SHA-256 being collision-resistant. For matters with long evidentiary tails (decades), counsel should consider whether a mid-tail re-anchor under a future hash function would be appropriate. We have not engineered an automated long-term-validation flow.
What Satsignal supplies is one externally checkable property in the offering party’s evidentiary record: the bytes of a specific document existed at a specific moment, and can be re-verified by any third party with the bundle, the document, and a public block explorer — without trusting Satsignal, the offering party, or any single vendor. That property is genuinely useful in some matters and unnecessary in many. It is not a substitute for any other element of the record.