[REPOST] What does "the final signed document" really mean? A conversation about hash-consistency across DocuSign delivery channels

[Posted originally on Partner Innovation Community, but this is probably a better place to post]

Hi all — Rafa from Simple Proof here 👋
 

Quick intro: we're a DocuSign ISV partner. We've built an Extension App that generates cryptographic proofs of completed envelopes and anchors them to the Bitcoin blockchain. In plain terms — when an envelope completes, we hash the final signed PDF and create a tamper-proof timestamp that anyone in the world can independently verify, forever, without trusting us or DocuSign. Our customers include government agencies and election authorities who need that level of integrity assurance.

I want to open up a conversation about something we've run into that I think has broader implications for any partner working on audit, compliance, archival, or integrity tooling.

The puzzle

For a cryptographic proof to mean anything, the document we hash has to be byte-identical to the document the signer holds. If a recipient downloads the signed PDF from their email, computes its SHA-256 hash, and that hash doesn't match the one we anchored on-chain — the proof breaks down. Not because anyone tampered with anything, but because the two binaries were never the same to begin with.

And that's what we're seeing. Our Maestro workflow (Envelope Completed trigger → File Output Cloud Storage Extension App) receives a PDF that is not byte-identical to the PDF DocuSign emails to recipients for the same envelope:

• They look identical when you open them.
• Their SHA-256 hashes differ.
• For example, on one test the PDF mod_date metadata differed by ~22 seconds, with the Maestro version being slightly more recent.
• We don't transform the file on our side — we decode, hash, and store as-is.
• It's reproducible across many envelopes.

So it appears DocuSign produces distinct binary artifacts of the same completed envelope depending on the delivery channel. Which raises a question I find genuinely interesting:

Within DocuSign's architecture, is there a single canonical "final signed document" — or does each delivery path (email, Connect, Maestro, REST API) materialize its own version on demand?

Where I'd love your perspective

• For anyone building integrations where byte-level consistency matters (records management, regulated industries, blockchain anchoring, long-term archival) — how have you thought about this? Which channel did you settle on as your source of truth, and why?
• Has anyone tried canonicalization workarounds — re-flattening the PDF post-receipt, hashing only the content stream rather than the full file, or finding a specific endpoint that's stable across channels?
• More broadly: would a server-side canonical hash exposed by DocuSign as a first-class field on the completed envelope be useful for what you're building? Curious whether this resonates or whether others have solved it differently.

Happy to share the sample PDFs and hash values with anyone who wants to dig in, and I'll report back what we find on the REST API path.

Really looking forward to the discussion 🙏

— Rafa CTO & Co-founder, Simple Proof