Signable Documents
Zipwire Collect can attach a PDF to a collection item and have your respondent cryptographically witness it, so you both end up with tamper-proof evidence of exactly what was signed.
What is a signable document?
When you're designing a collection request, you can add a Signable document item and attach a PDF that your respondent needs to review and sign, for example a contract, policy acknowledgement or agreement.
Unlike a normal upload, a signable document isn't just filed away. Zipwire reads the paragraph structure of the PDF and builds a Merkle tree from it, a cryptographic structure that lets anyone later prove exactly what the document said, paragraph by paragraph, without needing to re-share the whole file.
When your respondent signs, that Merkle tree's root is attested on-chain using the Ethereum Attestation Service (EAS):
If your respondent has their own crypto wallet, they can send the attestation themselves, directly from their wallet.
If they don't have a wallet, Zipwire's platform wallet acts as a cryptographic witness on their behalf, attesting to the same Merkle root.
Once complete, both you and your respondent keep a copy of the PDF, the Merkle tree, and the attestation UID(s) in your own protected Zipwire storage. Either party can later reconstruct a Merkle proof and look up the on-chain attestation to prove exactly what was signed and when, independently of Zipwire.
Two signatures: yours, then theirs
A signable document is actually signed twice, once by each side of the request:
You sign first, as the requestor. After you attach a PDF to a Signable document item, a Sign button appears in the designer. Clicking it builds a small Merkle tree covering the exact bytes of the file you uploaded, plus who you are and when you signed, and has Zipwire attest to that tree's root on-chain. This is a file-integrity signature: it locks in and proves that the file the respondent is about to see is byte-for-byte the one you uploaded, and it cryptographically witnesses your intent to send it. You can't send the collection to your respondent until every Signable item in it has been signed this way.
Your respondent signs second. Once they open the collection and reach the signable item, they review the extracted document and sign it themselves, in the same wallet-or-witnessed manner described above. Their tree references your earlier file-integrity attestation, so a verifier can see that both signatures concern the exact same file.
This two-step design mirrors how a paper contract works: the party requesting a signature effectively "sends" a specific, fixed version of the document, and the signer then signs that exact version, not some version that could have changed in transit.
Attestation, not notarisation
Zipwire's role here is to provide the cryptographic plumbing, not a legal service. We anchor a fingerprint of the document to the blockchain and, where needed, act as a witness — we don't assess anyone's legal capacity to sign, and an attestation is not a substitute for legal advice or a statutory notarial act.
Disclaimer of Notarial Status: Zipwire is a decentralized technological platform. It provides cryptographic attestation, digital witnessing, and blockchain-based data integrity services. Zipwire is not a notary public, law firm, or legal professional. It does not provide legal advice, subjective capacity assessments, or statutory notarisation services. The automated verification and attestation protocols provided by Zipwire do not constitute a public act of notarisation as defined by global statutory authorities. Users are solely responsible for ensuring that blockchain-backed attestations meet the specific legal and regulatory criteria of their target jurisdiction.
Why a Merkle tree?
Building a Merkle tree from the document's paragraphs, rather than just hashing the whole PDF, means a proof can later be generated for the document as a whole while still allowing tamper-evidence down to individual paragraphs. It's the same selective-disclosure approach used elsewhere in Zipwire, such as in Your Digital Identity on the Blockchain, applied here to contracts and agreements instead of identity documents.
Proving one clause without revealing the rest
Because the tree is built one leaf per paragraph, a Merkle proof doesn't have to cover the whole document — it can cover just one paragraph.
That means someone holding the signed PDF and its Merkle tree can later produce a small proof for a single clause, say, "clause 7 says X", and hand that proof to a verifier along with the paragraph text itself. The verifier checks the proof against the Merkle root that was attested on-chain at signing time. If it checks out, they know that exact clause was genuinely part of the document both parties signed, without ever seeing clauses 1–6 or 8–N.
This is the same idea as revealing a single fact from a passport in Zipwire Attest, applied to a contract: you share the one term that matters and a proof of its authenticity, not the whole document.
It's useful anywhere only one term is in dispute, or only needs verifying, for example proving a specific payment clause or liability cap was agreed, without handing an entire contract to a court, an auditor, or a counterparty's lawyer who only needs that one fact confirmed.
This capability is not yet built. The paragraph-level Merkle tree that makes clause-level proofs possible is part of this feature's design, but the tooling to generate and share an individual clause proof doesn't exist yet. Today, both parties can only prove or reconstruct the document as a whole. This page will be updated once selective disclosure for signable documents ships.
Last updated