Zero-knowledge proofs for business documents, explained

The idea, without the math

A door attendant needs to know you are over 21, not your date of birth, your address or your ID number, yet the usual way to show it is to hand over the whole card. A zero-knowledge proof is the cryptographic way to show only the fact.

Business documents have the same problem. A lender needs to know a contract with a customer is signed, not its prices. An auditor needs to know an agreement was in place by a date, not its clauses. Sending the document answers the question and shares everything else with it. A zero-knowledge proof answers the question alone.

Every zero-knowledge proof system guarantees three things:

• Completeness. If the statement is true and the prover holds the information behind it, the proof checks out.
• Soundness. If the statement is false, no one can make a proof that checks out, except with a chance too small to matter.
• Zero knowledge. The proof reveals nothing beyond the statement: not the document, and not the values that make the statement true.

The parts of a proof

• The statement. What is being proven, such as "this email address signed an agreement completed on this day".
• The circuit. The exact rules the hidden information must satisfy for the statement to be true, written as arithmetic a computer can check. The circuit fixes which statements can be proven: a circuit about who signed can't be used to prove anything about a price.
• Public inputs. The values the verifier sees and checks the proof against. In Attest's agreement proofs, they include the email addresses named, the completion day and the record the proof refers to.
• Private inputs. The hidden information behind the statement, sometimes called the witness. It isn't part of the proof and can't be read from it.
• The proving key and the verification key. Each circuit goes through a one-time setup that produces both. The proving key makes proofs; the verification key, which is public, lets anyone check a proof made for that circuit. A proof made for one circuit fails against another circuit's key.
• The proof. In Groth16, the proof system Attest uses, published by Jens Groth in 2016, a proof is three points on an elliptic curve, 256 bytes on the BN254 curve Attest uses, the same size however much hidden data stands behind it, and checking it is quick.

How Attest proves who signed an agreement

Attest's Share proof works in four steps:

1. Commit. Shortly after an agreement completes, Attest adds it to a record of completed agreements as one entry: a hash of the agreement's identifier, a small tree of its signers' commitments (one per email address), the day it was completed and the document's fingerprint. The hash function is Poseidon, which is designed to be cheap to compute inside a proof.
2. Publish. The entries form Merkle trees that hold up to 65,536 agreements each. A Merkle tree summarizes all its entries in one value, its root: change any entry and the root changes. Each proof is made against the root of its agreement's tree as it stands at that moment, and Attest publishes that commitment root and anchors it on Horizen, a public blockchain, from Attest's own wallet, never from a party's. On its own, the root is a single number that reveals nothing about any agreement.
3. Prove. A signer chooses what to prove. Attest's servers make the proof from what Attest already records about the agreement (its identifier, its signers' email addresses, the completion day and the document's fingerprint), never from the document, which Attest can't read. Each signer also gets a proof made automatically when the agreement completes.
4. Verify. The proof is checked against the circuit's verification key and its public inputs, and it is submitted to zkVerify, which verifies it independently. Anyone can check it again at attest.datahubz.com/verify, free and with no account.

Public and private inputs, exactly

	"That you signed it"	"That you and another signer signed it"
Public inputs	The commitment root; your email address, as a number derived from it with SHA-256; the completion day, counted in days in UTC; and a fixed label for Attest's identity scheme	The same, plus the other signer's email address
Private inputs	Which agreement it is, the document's fingerprint, the other signers, and the paths through both trees	The same
What the circuit checks	Your commitment is among the agreement's signers, and the agreement's entry, with that day, is in the root	Both commitments are among the signers of the same agreement, the two addresses differ, and the entry, with that day, is in the root

In plain words, a proof says: "In the record anchored as this root, there is a completed agreement, completed on this day, signed by this email address (and this one)." The verify page recomputes the number for each email address it shows and checks it against the proof's public inputs, and Attest's open-source verifier checks the day and the identity label too, so the statement it reports must match what the proof was made for.

What the checks rely on

• The mathematics. Soundness means no one can make a proof that checks out for an address that didn't sign a completed agreement in the record, or for a different day.
• The record. Attest builds its trees from the agreements completed on Attest, each signed with its signers' passkeys. Each root a proof is made against is anchored on Horizen, so once anchored it is public and can't be changed, and the proof page links that transaction. The agreements themselves carry their own evidence, in the signed copy every party holds.
• zkVerify. In its own words, "a high-performant, public, and decentralized blockchain dedicated to zero-knowledge proof verification", which works by "accepting proofs, verifying them, and recording both the proof and its verification on the blockchain for future reference". Attest submits every proof there, against the verification key of its circuit, and the proof page links the result.
• The open-source verifier. The verification keys are built into Attest's open-source verifier, never read from the file being checked, so a proof's evidence file can be checked on any device without Attest.

Zero-knowledge proofs and the tools they are confused with

Tool	What it does	What the checker learns	Where Attest uses it
Fingerprint (SHA-256 hash)	Identifies exact content: change one byte and the fingerprint changes	Nothing readable, though anyone holding the file can match it	The document's fingerprint, inside the signed state anchored on Horizen, and the signed copy's pages, anchored too
Digital signature	Shows that the holder of a key approved specific data	The data that was signed	Each signer's passkey signs a statement naming the document's fingerprint
Encryption	Keeps content readable only by the holders of a key	Nothing, without the key; everything, with it	Every document, end to end, opened only in the parties' browsers
Zero-knowledge proof	Shows that a statement about hidden data is true	The statement, and nothing else	Share proof, and the other proofs below

Where Attest uses zero-knowledge proofs

Every zero-knowledge feature in Attest verifies on zkVerify:

• Agreement proofs (Share proof): that a signer signed, alone or with a named co-signer, and the day the agreement was completed.
• Compliance proofs: a claim about a security scan, such as no critical vulnerabilities, revealing only whether it holds. They run on the security-scan circuit from Hubz VCE, a DataHubz project.
• Findings-closure proofs on certificates: that every finding of an assessment was closed, without revealing how many there were or their severities.
• Verified Forms: anonymous answers from a known group, one per member, each carrying a Semaphore proof that it came from someone on the list.
• Integrations daily state proofs, for platforms that serve many organizations.

Agreement proofs come with every signed agreement, on every plan, Free included. Compliance proofs, certificates and Verified Forms are on Pro, and on free accounts that didn't sign up for signing only; DataHubz enables Integrations for each platform. Of the 21 e-signature services we compared in October 2026, Attest and 20 others, Attest was the only one offering zero-knowledge proofs.

Where a proof's statement ends

A proof proves its statement and nothing more, which is the point. It helps to know exactly where the statement ends:

• No terms. Share proof can't show an amount, a price, a duration or a clause, because none of them is part of its statement. When a recipient needs those, the parties share the signed copy, which anyone can verify for free.
• No title. The title is private too, so you tell the recipient what the agreement is, and the proof confirms who signed it and the day it was completed.
• Email addresses, confirmed by passkey. The proof names signers by email address: each signer signed with a passkey registered to that address, which confirmed they were present and verified. Attest confirms control of the email address and the passkey, not a government ID.