> 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/get-started/signable-documents.md).

# Signable Documents

## 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), always from Zipwire's own attester wallet:

* If your respondent has a wallet linked, the attestation is addressed to that wallet as recipient — free and frictionless, with no signing action or gas cost on their part.
* If they don't have a wallet linked, Zipwire addresses the attestation to itself instead, acting as a **cryptographic witness** on their behalf.

{% hint style="info" %}
**Coming soon:** wallet holders will be able to sign the attestation themselves, directly from their own wallet, instead of Zipwire signing on their behalf. That adds a small amount of signing friction and a tiny gas cost, in exchange for the strongest possible identity guarantee.
{% endhint %}

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:

1. **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.
2. **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.

## A network of supporting evidence

If your respondent already holds other Zipwire attestations — an ID check, `IsAHuman`, `HasClearAML`, or an age tier — their signing attestation doesn't stand alone. Zipwire looks up every identity-interesting attestation already linked to their wallet and:

* references the single strongest one directly, using the attestation's on-chain `refUID` field, and
* lists every one it found in a `signerIdentityAttestations` leaf on the signing tree, so a verifier can see, and independently check on-chain, the full picture, not just the one that got the `refUID` slot.

The strongest evidence wins the `refUID` slot, in this order: a completed **ID check** first, then `IsAHuman`, then `HasClearAML`, then an age attestation, with the freshest attestation breaking ties within the same tier.

{% hint style="info" %}
**For the strongest possible proof, run an ID check before the document is signed.** An ID check outranks every other kind of evidence here — if your respondent completes one first, it's what gets referenced, and it's the richest, most independently verifiable evidence a signature can carry.
{% endhint %}

If your respondent has no other Zipwire attestations at signing time, this leaf is simply omitted from the tree — nothing extra to see, and the base signature is exactly as strong as described above.

{% content-ref url="/pages/mohdewNdaWrgQQiCYViI" %}
[Signer Identity Cross-Referencing](/fundamentals/security/attestations/signer-identity-cross-referencing.md)
{% endcontent-ref %}

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

A [notary](https://en.wikipedia.org/wiki/Notary) is a specific, licensed legal officer, appointed under a jurisdiction's own laws to formally witness signatures, verify identity and capacity in person, and certify documents in a way that carries statutory legal weight. It's a defined legal role, not a general description of "someone who witnesses signatures" — which is why what Zipwire does, however similar it may look, isn't notarisation and can't stand in for it.

{% hint style="warning" %}
**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.
{% endhint %}

## Why a Merkle tree?

Building a [Understanding Merkle Trees and Proofs](/fundamentals/security/understanding-merkle-trees-and-proofs.md) 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](/zipwire-attest/zipwire-attest.md), applied here to contracts and agreements instead of identity documents.

## Proving one clause without revealing the rest

Because the tree is built one [Understanding Merkle Trees and Proofs](/fundamentals/security/understanding-merkle-trees-and-proofs.md) per paragraph, a [Understanding Merkle Trees and Proofs](/fundamentals/security/understanding-merkle-trees-and-proofs.md) 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 [Understanding Merkle Trees and Proofs](/fundamentals/security/understanding-merkle-trees-and-proofs.md) that was attested [Crypto & Blockchain Basics](/fundamentals/security/crypto-and-blockchain-basics.md) 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.

<figure><img src="/files/DYGyQM75WK3HCT9QKZwk" alt="The Proofs tab generating a single-paragraph proof file, selecting only paragraph_1 and the signer metadata"><figcaption><p>Generating a proof for a single paragraph from the Proofs tab — the downloaded file only covers <code>paragraph_1</code> and signer metadata, not the rest of the document.</p></figcaption></figure>

You can do this today: from the **Proofs** tab, pick the specific keys you want to disclose — for example just `context.document.paragraph_1` plus the signer details — and generate a proof file covering only those. Anyone holding that file and the paragraph text can verify it against the on-chain Merkle root without ever seeing the rest of the document.

The proof file itself is a [Understanding ProofPack](/fundamentals/security/understanding-proofpack.md) — Zipwire's general-purpose format for exactly this kind of selective-disclosure, blockchain-attested proof.

[Blockchain Attestations](/zipwire-collect/idsp-idvt-kyc-kyb-and-aml/blockchain-attestations.md)

For the pitch on why this is worth switching to, see [Sign It Once, Prove It Forever](/zipwire-collect/signable-documents-cryptographic-proof.md).