DIP regarding PCD-based Ticketing for Devconnect


Throughout the past few years 0xPARC has been experimenting with various ZK and ZK Identity projects. As part of this experimentation we developed and funded the development of many apps, such as Dark Forest, double-blind, ETHdos, zk-email and ZKonduit. In early 2023, we identified an internal need for a unified framework that would help us build, and connect these and other experimental cryptographic applications to each other.

Working backwards from our desire to build a broad set of cryptography-enabled applications, we surveyed existing ‘identity’ frameworks. To make sense of what we saw, we settled on a tier system that let us categorize these solutions based on their expressiveness:

  • Tier 1: Signatures and attestations.
    • This is the lowest tier of expressiveness, and allows you to make statements like “Entity X attested to data Y”.
  • Tier 2: Specific SNARK-ID protocols. This tier subsumes Tier 1.
    • The functionality of signatures can be fully encapsulated by some particular ZK schema, but SNARK-ID protocols can also do more things. For example, they let you prove group membership without revealing your identity, or selectively reveal only a portion of an attestation.
  • Tier 3: General-purpose cryptographic protocols. This tier subsumes Tier 2.
    • This is the highest tier of expressiveness, as it is not locked into a particular ZK Protocol, but rather provides a substrate in which many different protocols that belong to Tier 1 and Tier 2 could co-exist, interoperate, and communicate with each other.

We saw many examples of solutions that belong to the first two tiers. However, we found that none of the existing solutions were flexible enough to support the types of cryptographic claims we want to use in our applications, as they all use either signatures, or a particular ZK Protocol. This realization led to the conception of the third tier of expressiveness.

To give an example of a type of claim that is not representable in existing identity solutions: zk-email lets people make privacy-preserving yet verifiable claims about emails that they received. Concretely, one could make a verifiable claim like ‘I received a password reset email from Twitter, which contained the twitter username XYZ’, without revealing the entire email, which could contain sensitive information like the recipient’s email address. This claim could then be used as proof of ownership of a particular twitter account, or as part of a scheme that lets users prove they own an account from some set of accounts. ZK Email proofs are not possible to represent in Tier 1 systems given the fact that they are ZK proofs, not signatures. They are also not possible to represent in existing Tier 2 systems, given the fact they are themselves particular SNARK-based protocols that are not compatible with the SNARK-based protocols embedded in the Tier 2 identity solutions.

To summarize, we did not see a framework supporting Tier 3 expressiveness, which is the tier we needed for the types of apps that we want to build. As a result, we decided to build a Tier 3 system ourselves.

PCD Framework

To bring our vision of a Tier 3 framework to life, we developed three new pieces of technology that interlock to create a maximally expressive system for representing and working with cryptographic proofs and attestations:

  • A new primitive we’re calling PCD (proof carrying data). At its core, a PCD is a self-evident and cryptographically verifiable claim. PCDs can be attestations, ZK proofs - anything that can be ‘proven’ and subsequently ‘verified’. Any cryptographic primitive can be wrapped in a PCD and thus encapsulated in a uniform interface. In short, ‘PCD’ is the general purpose atomic unit of cryptographic data that our framework operates on. Some examples of current and future PCDs are:
    • A Semaphore Protocol identity.
    • A Semaphore Protocol group message proof. To create this PCD, one would need a Semaphore Group, a Semaphore Identity, and a message that is being ‘signalled’.
    • A WebAuthn authentication as specified by the W3C protocol.
    • A ZK Machine Learning proof that proves knowledge of an image that classifies to a bird using a deep neural network.
    • An Ethereum signature of a string.
  • A framework for developing programmable cryptography applications that we’re calling the PCD SDK. The PCD SDK defines the software interfaces needed to actually use and define new types of PCDs. For example, the SDK enables developers of cryptographic primitives (various ZK proofs, signature-based schemes, etc.) to wrap their primitives in “PCD Packages”, that contain all the functionality needed to instantiate (i.e. ‘prove’) and verify these primitives. It also enables developers of programmable cryptography applications that depend on these cryptographic primitives to use them via simple and uniform interface, which greatly simplifies the development of this class of applications. For example, a developer that wants to incorporate ZK-Email PCDs into their application would be able to import the corresponding PCD package from npm, and easily request and interpret ZK-Email PCDs from users without having to understand how its underlying cryptography works.
  • A cryptographic secret manager/wallet for PCDs. The first version of this app is called Zupass, and was developed for Zuzalu. Zupass is a web-app that lets users store PCDs, and perform operations on them such as instantiating ‘derived PCDs’. Given that it is built for the PCD framework, it supports arbitrary signature and proof schemes, with no lock-in into any specific cryptographic protocol. Third parties, such as a physical event host or a digital website can request arbitrary cryptographic proofs (such as signatures or zkSNARK proofs) about data in a user’s secret manager using the PCD interface.

The strength of this PCD-based framework lies in its flexibility. We believe that it is a sufficiently general framework such that it could encapsulate existing identity protocols. Not only that, it could greatly expand the surface area for experimentation within ‘programmable cryptography’ applications by being a tractable and legible substrate into which cryptographic primitives that don’t fit into existing identity frameworks could be incorporated.

If the PCD framework is successful, it could bring about the following outcomes:

  • The PCD abstraction could serve as a common language for communicating cryptographically meaningful data between existing identity frameworks, other data silos, and applications.
  • More broadly, it could give individuals the power to own and move their data between any digital systems - social media platforms, digital banking networks, peer-to-peer messaging apps, biometric registries, blockchains, and more.

We are hoping to nudge the future of the World Wide Web in a direction where all data is universally accessible, interpretable, verifiable, and semantically meaningful - a Web without artificially-gated APIs, built on neutral and privacy-preserving mechanisms for user data.

Deployment of the Framework

Our first use-case for the PCD abstraction and associated software was a community event called Zuzalu, which was a “first-of-its-kind pop-up city community” that took place in Montenegro between March 25 and May 25, 2023. You can think of Zuzalu as a long conference or ‘pop-up Stanford’ for members of the extended Ethereum community. It is similar to Devconnect in its decentralized and self-organizing nature, but also different from Devconnect in that the community was smaller, and the event itself lasted for two months rather than a single week.

For Zuzalu, we built Zupass: the first iteration of the cryptographic secret manager mentioned earlier; under the hood, Zupass is a general-purpose PCD manager. At Zuzalu, Zupass was the primary method of digital and physical authentication. It was used daily to access gated physical event spaces and venues via a QR code. It was also used to authenticate into online digital experiences via an OAuth-like integration flow. For example, event participants could login to the official Zuzalu website using their Zupass, much like one is able to login to the Devcon forum using their Google account. Once logged in, participants were granted access to a private portion of the website - the Zuzalu schedule. There, participants could view the schedule, and add events to it. 100% of all Zuzalu residents (~200 users) and Zuzalu visitors (~600 users) onboarded onto Zupass, and used it daily for ZK-based digital and physical authentication over two months.

We designed Zupass with ecosystem development in mind, and seeded/facilitated other identity and community experiments on top of the infrastructure that we built. Here’s a list of some of the projects that emerged on top of/alongside Zupass:

  • Zupoll (https://zupoll.org/) - an anonymous voting platform restricted to just Zuzalu participants, where residents could create straw polls, and organizers could create referendums. One notable use-case for these polls was as a way to measure the community’s sentiment towards Zuzalu and its programming during weekly in-person “town halls.” These official community referendums regularly drew 30%+ voter turnout across all Zuzalu residents.
  • Zucast (https://zuca.st/) - an anonymous farcaster-like forum. This was built in a week during Zuzalu by a community member that wanted to experiment with the affordances of anonymous social media. Zuzalu community members made nearly 700 posts over 3 weeks.
  • Rubber Ducky - a telegram bot built and maintained by a community member that used GPT-4 to answer questions about Zuzalu. It used Zupass anonymous login to restrict its usage to just Zuzalu participants.
  • PCD Stamps - a NFC-based PCD distribution mechanism that allowed community members to distribute POAP-type attestations to attendees of Zuzalu.

It’s important to note that Zupass is ‘permisionlessly interoperable’ - developers of third party applications do not need our permission to integrate with the PCD framework. The entire thing is open source, and exposes easy-to-understand and easy-to-incorporate APIs.

Overall, we were very impressed with the variety and amount of experimentation our framework led to throughout Zuzalu. We believe the future of this framework is promising, and we will continue to develop and experiment with the PCD abstraction, the PCD Passport (known currently as Zupass), and the PCD SDK.

Proposal for Devconnect

Thus, we are proposing that Devconnect adopt Zupass for some of its ticketing needs (which we are planning to rebrand to not reference Zuzalu, let’s call it PCDPass for now).

Here is an outline of a possible integration between PCDPass and Devconnect:

  • Similar to Zuzalu’s event spaces, we could make it possible to check in to the Devconnect coworking space using PCDPass.
  • PCDPass would transition from being just a web app to a suite of versions: a mobile app, a set of browser extensions, and potentially a PWA (progressive web app).
  • Purchasers of tickets to the coworking space would be able to instantiate a PCDPass account using the same email they purchased their ticket to create a new anonymous identity that is granted ticket-holder permissions. To check in to the coworking space, a user would show their PCDPass QR code to event staff in exchange for a wristband that lets the come and go as they please.
    • Alternatively, we could require a QR code scan every time an attendee visits the coworking space. This would require us to build features that prevent QR codes from being reused, which could be challenging to do securely.
  • In addition to ticketing the coworking space, 0xPARC is going to be using PCDPass for ticketing its own Devconnect subevents. The implementation would be almost equivalent to the one the coworking space uses, made possible by a shared Pretix instance.
  • Finally, we are going to make available our PCDPass ticketing solution to other subevents at Devconnect, so that their attendees can plug in to the broader PCD application ecosystem.

In addition to being able to check in to physical event spaces at Devconnect, holders of PCDPass would also be able to sign in to online digital experiences such as the ones we saw built for Zuzalu - Zupoll and Zucast in particular.

Apart from maintaining Zupoll and Zucast, we are excited about facilitating the development of other digital experiences by third party developers, and about designing/developing other apps ourselves, with the intention to make Devconnect more fun and interconnected for its attendees. Additionally, because of the flexibility of the PCD abstraction, other cryptographic attestation schemes can easily be made interoperable with PCDPass and a wider ecosystem of applications and tools emerging around it.

To conclude, we believe a collaboration between the PCD efforts at 0xPARC and Devconnect would be beneficial to both sides. On our end, we believe that this project would be a great opportunity to get further feedback on PCDs and our tools/apps. On Devconnect’s end we believe this ticketing solution is more powerful and extensible than existing ticketing solutions, and would be a great opportunity for the event to dogfood an impactful piece of technology.

All code for the PCD project can be found here: GitHub - proofcarryingdata/zupass: Zuzalu Passport


Sounds very exciting.:+1:
On thing, since PCD is “a Tier 3 framework”, will it be better to demonstrate the power via connecting other Tier 2s and Tier 1s? Example: Applying PCD on top of the existing attestation based ticketing solution DIP-6 (it is using EAS format now).


This sounds very interesting!
Unfortunately I did not attend zuzalu - so I need to try out the tooling now - so far after some minutes of getting my hands on it stumbled into this:

will try to dig deeper and get some hands on experience. Technically this all sounds very interesting and think this could be a route to go in the future. Just not yet sure if it is mature enough to use at DEVCon(nect)
Ticketing is on the critical path for the event and it is important it works. I also think @Victor928 's suggestion is to be explored - this way we could slowly migrate to the solution instead of going all in. If e.g. polling does not work it is not so critical as if we do not know who to let in at the entrance :wink:
Also not yet sure about what you write for DEVConnect:

  • PCDPass would transition from being just a web app to a suite of versions: a mobile app, a set of browser extensions, and potentially a PWA (progressive web app).

this sounds like a lot of work for the time to DEVConnect. Did this work already start? Is it possible in the time?
Thanks anyway for the suggestion - and really hope we will be able to use some of the tools you created!

What could also really help is if people that really used the tools at zuzalu can chime in here with their experience.


Hi ligi,

Thanks for checking out the projects!

To address the issues you’ve mentioned:

To add a bit of context, our current focus is entirely on transitioning the software suite to support a ticketing use-case for the events we’re running at Devconnect. As a result, Zupass and related projects are not currently actively used and maintained, and some of the pieces of infrastructure are undergoining a lot of changes that are not entirely backwards compatible with how they worked at Zuzalu.

Regarding the mobile app, I agree that it is a lot of work. Based on our discussions with the Devconnect team, it seems that a mobile app is a less-than-ideal mechanism for checking-in anyways, so we’ve deprioritized it and are no longer planning on shipping it before Devconnect begins.

Hi all, as a Zuzalu core organizer, I’m in huge support of seeing this used at Devconnect.

Zupass revolutionized ticketing through their zero-knowledge proof application. The application enhanced security, added convenience, anonimity, and established an identity layer for the Zuzalu community. We appreciate so much of the simplicity of Zupass for the end user, all while keeping their data private.

We’re hoping TL belp 0xParc with testing in the short term.

Thanks and excited for this.

1 Like

Thanks @Janine_Leger for chiming in from an organizer perspective!
Can you elaborate how the application enhanced security (e.g. which attack vectors where closed) and added convenience?
Would also really love to try out the check-in process - is this possible?

1 Like

Thanks @Janine_Leger @ligi for chiming in here with notes - we had a great experience ticketing ZuConnect and Devconnect in 2023, in large part due to your efforts!

Just want to add our tentative high-level roadmap for the ticketing experience in the coming year. Note that we ended up consolidating the name ‘PCDPass’ under the Zupass brand.

  1. One-click Zupass onboarding, where the user can click a single link in their email to automatically create their Zupass account and access their QR code, without having to both with email codes or passwords.
  2. Having the ability to add change or add multiple emails to your Zupass account , which would help with folks who want to migrate from old work accounts or have multiple email addresses.
  3. Explore options for a native mobile app or a progressive web app (PWA).
  4. Further improve app performance and add more features to offline mode.
1 Like