Signable Documents: Proof That Doesn't Need Us

15 Jul 2026

15 Jul 2026 by Luke Puplett - Founder

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. If you ever need to prove that signature happened, you're not really proving anything yourself. You're asking a third party to vouch for you, forever, on the strength of a database you can't see.

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.

We've just shipped a way to sidestep that entirely. It's called Signable Documents, and it's a new item type inside Zipwire Collect.

The payoff: proof you can walk away with

With a Signable Document, both sides of a signature end up holding independent cryptographic proof of exactly what was signed — not a certificate issued by us, but a self-contained proof that can be verified without ever contacting Zipwire again. If Zipwire vanished tomorrow, the proof wouldn't. That's the whole point.

How it works, in plain language

A Signable Document starts life inside a Zipwire Collect request. A requestor — the person building the data-collection request — attaches a PDF: a contract, a policy acknowledgement, whatever needs a signature. Zipwire reads the document (OCR and extraction) and splits it into its constituent paragraphs, storing them alongside the original file.

From there, it's a two-signature flow:

1. The requestor signs first, to lock in the exact file. Clicking "Sign" builds a small Merkle tree covering the precise bytes of the uploaded PDF — a deterministic hash of the file's contents — plus metadata about who signed and when. The root of that tree is attested on-chain via the Ethereum Attestation Service (EAS). This step is specifically about file integrity: it fixes, permanently, which version of the document is about to be sent. A collection can't even be opened or sent to the respondent until every Signable item inside it has been signed this way.

2. The respondent signs second, to agree to the content. Once notified, the respondent opens the document in a dedicated full-page viewer, reads it, and signs. This builds a second Merkle tree — but this time with one leaf per paragraph rather than a single whole-file hash, and it references the requestor's earlier attestation, chaining the two signatures together.

Once both signatures exist, the two proof trees are cross-copied: the requestor's tree is copied into the respondent's own protected storage, and the respondent's tree is copied back into the requestor's. Each party ends up independently holding both proofs in their own "Proofs" tab. There's no single shared, vendor-controlled audit trail sitting on our servers — no admin panel where either party, or we, could quietly edit history.

A wallet strengthens the claim, but isn't required

In both steps, the attestation is always made from Zipwire's own wallet — that part doesn't change. What differs is who it's addressed to: if the signer has a linked crypto wallet, the attestation names that wallet as recipient, at no cost and no extra step for them. If there's no linked wallet, Zipwire addresses the attestation to itself instead, witnessing the signature on the signer's behalf.

The integrity guarantee — that this exact document was signed at this exact time — is identical either way. A linked wallet only strengthens the claim about whose proof it is; it isn't required to get the tamper-evidence benefit. That matters because it removes the usual adoption cliff: you get the full guarantee on day one, wallet or no wallet. (We're also working on letting a wallet holder sign the attestation themselves, directly from their own wallet, rather than Zipwire signing on their behalf — a small amount of extra friction and a tiny gas cost, in exchange for a guarantee a third party can later challenge someone to prove they control that wallet. That's coming soon, not yet shipped.)

A network of supporting evidence

A signature is stronger when it doesn't stand alone, and Signable Documents already do something about that quietly, in the background. If a respondent has previously completed an ID check with Zipwire, or holds an IsAHuman, HasClearAML, or age attestation, their signing attestation doesn't ignore that history — it cross-references it.

Here's what happens under the hood. When a respondent signs, Zipwire looks up every identity-interesting attestation already linked to their wallet, and does two things with what it finds. First, it picks the single strongest one and writes its attestation ID directly into the new signing attestation's on-chain refUID field — a native EAS mechanism for pointing one attestation at another. Second, it lists every attestation it found — not just the one that won the refUID slot — in a metadata leaf on the signing tree itself, so a verifier can see the fuller picture and independently check each one on-chain.

"Strongest" isn't arbitrary. There's a priority order: a completed ID check outranks everything else, followed by IsAHuman, then HasClearAML, then an age attestation, with the freshest attestation breaking ties within the same tier. An ID check wins because it's the richest, most information-dense piece of evidence available — a boolean "yes, this is a human" is weaker corroboration than a verified passport.

The practical upshot: if you want the strongest possible proof out of a Signable Document, run an ID check on your respondent before they sign. It costs nothing extra to the signature flow itself, and it's the single biggest lever you have over how well-corroborated the eventual proof turns out to be. If they haven't done a check, the signature still stands on its own — the leaf is simply omitted, not filled with placeholders — but it won't carry that additional layer of independently verifiable identity evidence.

This is entirely additive, and it costs the signer nothing extra: no additional prompts, no extra transaction, no user-facing step. It's Zipwire doing the legwork of connecting evidence that already exists, rather than asking anyone to re-prove something they've already proven.

We didn't even have to build our own verifier

We handed a raw Zipwire ProofPack file — with no Zipwire-specific tooling — to Grok, an unrelated third-party AI, and it correctly decoded the signer, their role, the timestamp, and the Merkle root, cold.

That's what "self-describing proof" actually means in practice: the format explains itself to something that has never heard of Zipwire. Under the hood, that proof is a JWS/JWT — the same standard token format used for web logins and API auth, which is exactly why it's so legible to tools that have never heard of Zipwire, and why Grok didn't need any special training to read it.

Why paragraph-level trees matter — and this part is already shipped

Building the respondent's Merkle tree at paragraph granularity, rather than as one hash for the whole document, isn't just an implementation detail — it's what makes selective disclosure possible. Imagine a dispute over one clause: a liability cap, or a payment term. With a traditional e-signed PDF, "proving" that clause was agreed to means handing over the entire contract to whoever's asking — a court, an auditor, an opposing lawyer — even though they only needed one paragraph.

Because the tree has a leaf per paragraph, and this is live in the product today, a party can go to their Proofs tab, select just that one paragraph plus the signer details, and generate a proof file covering only that.

Worth remembering as a lesson in this kind of feature write-up: check what's actually shipped, not just what the design docs describe. It's tempting to assume paragraph-level disclosure is still on the roadmap, right up until a screenshot of the Proofs tab shows it downloading a file named for exactly the paragraph selected.

Who this is for

Anywhere a Web 2.0 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.

The benefits behind the benefit

The headline is "cryptographic proof of what was signed," but the more interesting payoffs are second-order:

• Portability. The proof 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. Paragraph-level trees mean you can share one fact rather than a whole contract, today, not eventually.

• No adoption cliff. The wallet is entirely optional. You get the full integrity guarantee on day one, with or without one — crypto adoption isn't a precondition for value.

• No single party can rewrite history. Two independent, cross-copied proofs — one on each side — mean no one admin panel controls the record.

• Evidence compounds instead of resetting. A prior ID check doesn't just sit unused in a wallet — it automatically strengthens the next signature that wallet makes, at no extra cost to anyone.

An important disclaimer

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. That is not the same thing as legal notarization. A notary is a specific, licensed legal officer, appointed under a jurisdiction's own laws — not just a general term for "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 given document needs formal notarization, witnessing, or legal review depends on its jurisdiction and purpose — that's a question for your own legal counsel, not for us.

What we can promise is that the proof itself won't depend on us being around to back it up.

Related reading

Signable Documents build on the same selective-disclosure primitives behind ProofPack. If you want the deeper technical comparison, see ProofPack vs. W3C Verifiable Credentials. For a look at how the same paragraph-level, blockchain-attested approach applies to timesheets rather than contracts, see Verifiable Timesheets with Selective Disclosure. And for how this kind of self-describing proof fits into automated, agent-driven compliance checks, see AI Gates: Privacy-Preserving Compliance.

For the full technical breakdown of the refUID priority order and the signerIdentityAttestations leaf structure described above, see Signer Identity Cross-Referencing (E-Sign) in the docs.

Get started with Zipwire Collect →

---

Learn more