> For the complete documentation index, see [llms.txt](https://docs.zipwire.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.zipwire.io/zipwire-collect/signable-documents-cryptographic-proof.md). # Sign It Once, Prove It Forever [**Get started with Zipwire Collect →**](https://zipwire.io/collect) Every e-signature tool you've used runs on the same quiet promise: "trust us to remember what happened." Sign a contract in a typical e-sign platform and what you actually get is a certificate of completion — a document that says a signature took place, backed by nothing more than the vendor's servers and their willingness to keep answering queries about it. Most of the time nobody asks. But when a signature actually matters — a dispute, an audit, a court date years later — that's exactly when you don't want your proof to depend on a company's servers still existing, still holding your records, and still willing to answer the phone. **Signable Documents** sidestep that entirely. Attach a PDF to a Zipwire Collect request, have your respondent review and sign it, and both of you end up holding independent cryptographic proof of exactly what was signed — proof that stands on its own, verifiable without ever contacting Zipwire again. ## Sign once each, in order A Signable Document is actually signed twice: 1. **You sign first, as the requestor**, the moment you attach the PDF. This locks in the exact bytes of the file you're sending — before your respondent ever sees it — so there's no question later about which version was in play. 2. **Your respondent signs second**, after reviewing the document in a dedicated viewer. Their signature references yours, chaining the two together. Both signatures are backed by a Merkle tree built from the document's contents and attested on-chain, so the proof isn't a claim Zipwire makes about you — it's something you can hand to anyone and they can check for themselves. ## Nobody needs a crypto wallet to get this Every attestation is made from Zipwire's own wallet — that's true whether or not you have one. What changes is who it's addressed to: if you or your respondent already have a wallet linked, the attestation names that wallet as recipient, at no cost and no extra step for you. If you don't have one, Zipwire addresses the attestation to itself instead, witnessing the signature on your behalf. Either way, the tamper-evidence is identical: the proof that this exact document was signed at this exact time doesn't change. A linked wallet only strengthens the claim about *whose* proof it is — it's never required just to get the benefit. {% hint style="info" %} **Coming soon:** we're working on letting a wallet holder sign the attestation themselves, directly from their own wallet, rather than Zipwire signing on their behalf. That adds a small amount of friction and a tiny gas cost for the signer, in exchange for the strongest possible identity guarantee — a third party can later challenge them to prove they control that wallet. {% endhint %} ## Your signature doesn't stand alone If your respondent has already completed an ID check, `IsAHuman`, or an AML check with Zipwire, their signature doesn't arrive as an isolated claim. It automatically cross-references whatever identity evidence they already hold on-chain, so a verifier doesn't just see "this wallet signed this document" — they see a trail of independently checkable attestations backing up who that wallet belongs to. {% hint style="info" %} **Want the strongest possible proof?** Run an ID check on your respondent *before* they sign. Zipwire ranks a completed ID check above every other kind of evidence when choosing what to cross-reference — it's the single strongest thing you can add to a signature's credibility. {% endhint %} {% content-ref url="/pages/mohdewNdaWrgQQiCYViI" %} [Signer Identity Cross-Referencing](/fundamentals/security/attestations/signer-identity-cross-referencing.md) {% endcontent-ref %} ## We didn't even need to build our own verifier To prove the proof holds up, we handed a raw Zipwire proof file to Grok — a general-purpose AI with no Zipwire-specific tooling — and asked it to work out what the file meant.
Grok decoding a raw Zipwire ProofPack, correctly identifying the signer, role, timestamp and Merkle root

Grok, with no Zipwire integration whatsoever, cold-reading a signed document proof and getting every detail right.

It correctly identified the signer, their role, the timestamp, and the Merkle root behind the signature — cold, with nothing but the file itself. That's what it means for a proof to be self-describing: it explains itself to something that has never heard of Zipwire. (The file itself is a [ProofPack](/fundamentals/security/understanding-proofpack.md) — see that page for what's actually inside one.) ## Prove one clause, not the whole document The tree behind your respondent's signature is built one leaf per paragraph, not one hash for the whole file. That matters the moment a dispute is actually about a single clause — a liability cap, a payment term — rather than the entire agreement.
The Proofs tab generating a proof file that only covers paragraph_1 and the signer, not the whole document

A proof generated for a single paragraph, straight from the Proofs tab — not the whole contract.

From the **Proofs** tab, you can already select just the paragraph in question, plus the signer details, and generate a proof file that covers only that. Hand it, and the paragraph text, to whoever's asking — a court, an auditor, a counterparty's lawyer — and they can verify it against the on-chain Merkle root without ever seeing the rest of the document, using [zipwire.io/verify-proof](https://zipwire.io/verify-proof) or their own tooling. ## Why this is worth switching for * **Your proof outlives us.** It isn't stuck inside a Zipwire silo — it survives Zipwire being unavailable, discontinued, or simply not trusted by whoever's asking. * **Lower disclosure risk in disputes.** Share one fact rather than an entire contract. * **No adoption cliff.** A wallet is entirely optional — you get the full integrity guarantee with or without one. * **No one can quietly rewrite history.** Both signatures are cross-copied so each party independently holds both proofs — there's no single admin panel, ours or anyone else's, where the record could be edited. ## Where it fits Anywhere a traditional e-signature flow currently sits: freelancers and agencies signing service agreements, landlords and tenants signing tenancy documents, any two parties who need to agree to a document and might, one day, need to prove it independently of whichever platform hosted the click. {% hint style="warning" %} **Not a substitute for notarisation.** Signable Documents give you strong, independently verifiable evidence that a specific document was reviewed and attested to by a specific party at a specific time. A [notary](https://en.wikipedia.org/wiki/Notary) is a specific, licensed legal officer appointed under a jurisdiction's own laws — not just "someone who witnesses a signature." Zipwire is not a notary, does not assess anyone's legal capacity to sign, and does not provide legal advice. Whether a document needs formal notarisation, witnessing, or legal review depends on its jurisdiction and purpose — that's a question for your own legal counsel. {% endhint %} ## Read more {% content-ref url="/pages/BqZQt9m3vA2DE6ka8j2I" %} [Signable Documents](/zipwire-collect/get-started/signable-documents.md) {% endcontent-ref %} {% content-ref url="/pages/K4BLwRNETrUKpdJuaJRC" %} [Understanding Merkle Trees and Proofs](/fundamentals/security/understanding-merkle-trees-and-proofs.md) {% endcontent-ref %} {% content-ref url="/pages/HR6HCv993tyVfhflqWFi" %} [Data Portability and Proofs](/overview/data-portability-and-proofs.md) {% endcontent-ref %}