Summary: Zupass is best understood not as a single identity app, but as a user-held container and query interface for proof-carrying data. Its core mechanism is an open PCD abstraction: claims plus attached proofs can be stored in a passport-like client, requested by third-party apps, and transformed into privacy-preserving responses without every application reinventing credential plumbing. That makes Zupass a useful comparison class for Sismo, Human Passport, Sign Protocol, and Semaphore-adjacent tooling. The key control surface is not only which credentials exist, but who defines PCD types, which apps can query the passport, how popup/API flows shape user consent, and how much of the system remains portable versus anchored to the hosted passport server and its interface conventions.
What it does:
Lets users store, organize, and present Proof-Carrying Data, meaning cryptographically verifiable claims such as signatures, Merkle proofs, zk proofs, hash commitments, and keypairs
Provides a passport-style web application that can respond to third-party queries about a user’s proofs and can also accept newly issued proofs back into the user’s wallet
Exposes a developer SDK and interface packages so applications can request proofs through popup / redirect flows instead of building custom identity-wallet UX from scratch
Supports a wide range of proof types and example use cases, including ticketing, anonymous group membership, gated communities, event attendance, wallet ownership, WebAuthn attestations, and import of offchain account data into zk-friendly proofs
Uses packages such as @pcd/semaphore-group-pcd, @pcd/webauthn-pcd, and @pcd/ethereum-ownership-pcd, making it a broad proof transport layer rather than one narrowly scoped credential scheme
Includes both client and server components, with the server handling items like email confirmation, encrypted backups, participant management, and large assets for the passport app
Key claims:
Zupass’ most important primitive is the PCD abstraction itself: a claim plus a proof of correctness, exposed through a common interface. That is more analytically useful than treating the product as just a Zuzalu passport or an event-ticketing wallet.
The official README makes the scope unusually broad. Zupass is framed as a system where third parties can query a user’s proof wallet for many kinds of data, and the docs explicitly say that, in principle, any query is possible so long as an appropriate zk circuit exists.
The passport interface package is a key control surface because it standardizes how outside apps ask for proofs. The popup-redirect flow, URL constructors, and hosted zupass.org endpoint mean portability lives partly in shared interface conventions, not just in local cryptography.
The package list is revealing because it shows Zupass is less a single credential issuer than an aggregation layer over multiple proof families: Semaphore membership, WebAuthn attestations, Ethereum ownership, signatures, and future proof packages.
The server-side docs matter because they show the system is not purely local-wallet software. The passport server handles encrypted backup and operational functions, which creates a meaningful infrastructure layer even if the product is marketed as user-centric proof storage.
Zupass is a strong corpus entry because it helps separate a missing layer in many identity discussions: the proof container and query middleware that sits between credential issuance and downstream application verification.
It is especially useful for comparison against Sismo and Human Passport. Those systems emphasize credential aggregation and app-facing scoring or badges, while Zupass emphasizes a more general proof wallet plus app-query transport layer.
Whitepaper: No canonical standalone Zupass whitepaper or litepaper surfaced in this pass. The strongest primary materials were the official PCD SDK docs, Zupass repository README, interface-package README, and developer resources; see ../whitepapers/zupass-primary-sources-2026-05-10.md.