Litigation evidence preservation.

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 receipt 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 receipt alone.

None of the three answer the harder questions the court will also ask — whether the underlying document is what it purports to be, whether the witness offering it has personal knowledge of its origin, whether any other rule of evidence bars its admission. Those need their own foundation. The receipt’s contribution is narrower: when those answers exist, it makes one byte-level property externally checkable.

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. It contains the canonical document hash, the
#    Merkle path (if applicable), the chain transaction reference,
#    and the operator's signed metadata. Treat as you would any
#    other digital exhibit: hash it, log it, store it on
#    write-once or version-controlled media.
curl -O "https://app.satsignal.cloud/r/<bundle_id>.mbnt"
sha256sum <bundle_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 receipt; the operator does not have it.
#    Either way the offering party must produce these bytes at trial
#    or there is nothing for the receipt to bind to.
sha256sum <canonical_document> > document.sha256.txt

# 3. Note the chain transaction. The bundle carries the txid; 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.
TXID=$(jq -r .anchor.txid bundle.json)
echo "https://whatsonchain.com/tx/$TXID" > chain_reference.txt

# 4. Verify end-to-end yourself, before depositions, and again
#    before trial. The verifier walks the same path a court-appointed
#    witness will walk. Print the result.
curl -O "https://proof.satsignal.cloud/verify"
# (or use the JSON endpoint at proof.satsignal.cloud/verify_json)

# 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.

The bundle and the document together let any third party reproduce the verification independently. The bundle alone proves a hash was anchored at a moment but not which document — the canonical bytes are load-bearing.

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] caused the Document to be
   submitted to the Satsignal anchoring service operated at
   satsignal.cloud, which produced a receipt bundle identified
   below ("the Bundle"). The bytes of the Document submitted at
   that time were preserved by [organization] and are byte-for-byte
   identical to the bytes of Exhibit [N].

4. [Operator-witness paragraph.] Satsignal is an anchoring
   service that, for each submission, computes a SHA-256 digest of
   the canonical document or commitment, 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 a
   submission from the account of [customer organization],
   computed the SHA-256 digest [hex digest], produced bundle
   [bundle id], and broadcast transaction [txid] to the BSV
   network. The transaction was confirmed in block [height] mined
   by [miner pool name as reported by the chain]. A copy of the
   bundle as produced by the system is attached as Exhibit [M].

6. [Operator-witness paragraph.] The SHA-256 digest in
   paragraph 5 above is computable directly from the bytes of the
   canonical document or commitment submitted; no Satsignal
   software, account, or service is required to reproduce it. Any
   reviewer with the bytes of the document and a SHA-256
   implementation can confirm the digest matches; any reviewer
   with the bundle, the document, and access to a public BSV
   block explorer can confirm the chain transaction matches the
   bundle.

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 receipt 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.

The operator-witness paragraphs (4–6) describe facts Satsignal can verify from internal records: the SHA-256 was computed on the submitted bytes, the bundle was generated by the system, the transaction was relayed. Mail hello@satsignal.cloud with the bundle ID and a description of the proceeding to arrange a witness declaration. We respond to legitimate counsel inquiries; we cannot and do not attest to facts outside our own system records.