Publication integrity
Don't just read the report. Verify it.
A published ChainsEdge report can be checked against the cryptographic record created for that exact artifact. If the file changes later, the verification no longer matches.
The report is not stored on Bitcoin. The signed publication commitment is timestamped through OpenTimestamps and can be verified against Bitcoin when the proof reaches verified status.
Status: the verification chain described on this page is implemented and independently runnable. Publication is a deliberate, operator-initiated step rather than something that happens automatically on every report, so a given report carries a verification record only once it has been published through it.
How it works
From report to verifiable historical record.
The critical point is that Bitcoin does not need the report itself. ChainsEdge commits to the exact report fingerprint inside a signed publication event, then timestamps the event ID. The resulting chain lets a holder test whether a later copy is the same artifact that was originally committed.
01 · Report artifact
Published PDF
The exact completed bytes of the report as it was issued.
02 · Fingerprint
SHA-256
A digest over the completed artifact. A changed file produces a changed digest.
03 · Signed publication
Nostr event
The event carries pdf_sha256, payload_hash and core_receipt_hash, and is signed with a BIP-340 Schnorr signature.
04 · Time proof
OpenTimestamps
The commitment is to the signed event ID — no report content is written to Bitcoin.
05 · Independent check
Bitcoin block header
The attestation is checked against an actual block header by merkle-root equality. The proof becomes verified only after that check passes.
No report content is written to Bitcoin · the OTS commitment is to the signed event ID · Bitcoin verification is status-bound.
What alteration does
The file can be edited. The original commitment cannot be made to match it.
Verification recomputes SHA-256 over the supplied PDF bytes and compares it with the fingerprint inside the signed event. A one-character change produces a different fingerprint. That copy can still exist, but it can no longer pass as the artifact ChainsEdge originally committed.
Original copy
Fingerprint matches
The recomputed PDF hash matches the pdf_sha256 carried by the signed publication event.
Verification passes
exact-byte match
Altered copy
Fingerprint changes
The edited file generates a different SHA-256. It does not match the fingerprint in the original signed publication.
Verification fails
PDF bytes do not match
Someone can copy or edit a report, but an edited copy cannot verify as the exact report ChainsEdge originally committed to.
Why it matters
You do not have to rely only on our current database.
An offline publication verifier checks the supplied PDF bytes, the Nostr event ID, the Schnorr signature, the expected ChainsEdge public key and the report commitments. It runs without network access and without reading our database. Bitcoin timestamp verification is a separate proof step once the OpenTimestamps proof is verified.
01 · Artifact
Exact-byte integrity
The PDF fingerprint is SHA-256 over the completed artifact. A changed file produces a changed digest.
02 · Authorship
Signed publication
The expected public key is supplied independently and checked before the signature, so a valid signature under an unexpected key still fails.
03 · History
Bitcoin timestamp proof
When the OTS proof reaches verified status, its attestation is checked against an actual block header rather than accepted on assertion alone.
What this proves — and what it does not.
It proves integrity and publication history: that the supplied file matches the committed artifact, that the publication signature is valid, and — when OTS is verified — that the publication commitment is anchored in Bitcoin history.
It does not prove the market analysis itself is correct, that source data was correct, or an exact wall-clock creation time. Those are separate questions.
Integrity ≠ prediction accuracy
How it works