Define the claim.
Then build the proof.

Write the statement first.

“We use zero-knowledge proofs” describes a mechanism, not a product guarantee. Begin with a sentence a reviewer can challenge: “The sender belongs to this group, without revealing which member they are.” Then name the public inputs, the private witness and the party that checks the result. If the team cannot agree on that sentence, implementation is premature.

A proof system’s security properties and assumptions determine what verification establishes. The Ethereum introduction explains completeness, soundness and zero-knowledge. None of those properties makes unrelated application data private. An email address written to an analytics event is still an email address, regardless of how carefully the proof was constructed.

Make the assumptions inspectable.

Setup requirements differ between constructions. Some proof systems require a trusted setup; transparent constructions avoid that particular requirement. That distinction is a starting point, not a complete security assessment. Verification still depends on the chosen protocol and a correct implementation.

Prepare an explicit record for a security review: the claim, public inputs, proof-system version, verification parameters, dependencies and responsibility for upgrades. List what an attacker is allowed to control. Ask who could accept an invalid result through a configuration mistake, and which boundary would catch it. These questions connect the mathematics to the system people will actually operate.

Use a narrow example.

Semaphore is a concrete reference for anonymous group membership: a member can send a message without revealing their identity within the group. It also provides mechanisms for preventing repeated signaling. That is a useful example because both the claim and its boundary can be stated plainly.

For a hypothetical private feedback tool, first decide who maintains the group and what one allowed submission means. A proof of membership alone is not a universal answer to spam, eligibility or account recovery. Those are application rules. Document how the surrounding product enforces them, and what is intentionally outside the proof.

Map the whole journey before committing to an architecture: joining, generating a proof, submitting it, handling rejection and recovering from a lost credential. Include the waiting and failure states. A private workflow that silently loses a person’s contribution has not solved the experience.

Plan for the next version.

A proof and a verifier must belong to a compatible protocol version. Treat that compatibility as a release decision. Specify which versions remain accepted, how a client learns it must update and how the service behaves if the verifier is unavailable. Do not let an infrastructure error look like a successful submission.

1. Test rejection deliberately. Include altered public inputs, malformed proofs and unsupported versions, alongside valid examples.
2. Review what is recorded. Decide which operational signals are necessary and which values must never reach logs or analytics.
3. Write the upgrade path. Keep an explicit acceptance policy for existing data and a recovery plan for a faulty deployment.

These are design and review questions, not evidence that a particular system is secure. Before production, the actual protocol, implementation and deployment need specialist review against the stated threat model. The aim is a guarantee that can be explained, inspected and maintained.