We recently released a new version of Pairwise - a fun way to vote in Retro Funding 4. Our goal is to make voting in Retro Funding Rounds fair, easy and fun!

This version is a major upgrade from our previous list generating tool for RetroPGF 3, and is on the cutting edge of web3 govtech, utilizing both Account Abstraction (AA) & zk-tech. In this post we will focus on the anonymity aspects of this new version and how we will design in future iterations. Any feedback to improve our design is welcomed!

Why bring anonymity into Pairwise?

Communities are made of people like you and me. Often, public votes are swayed by peer pressure and social norms, making it hard to express genuine opinions. This was clear from the feedback we received during RetroPGF 3—many badgeholders were uneasy about making their detailed voting preferences public in lists. That’s why we made it a priority to ensure that Pairwise allows for anonymous voting, letting you express your views without any fear of judgment.

Removing the fear of attribution allows information to be truly free.

How did we produce pseudonymity?

Our goal for this new iteration of Pairwise was to do on-chain voting, allow voters to be anonymous, and make a fun user experience. True anonymity was not possible while maintaining on-chain voting, so we made it pseudonymous instead.

Here is how we did it:
1. Voters log in with traditional web2 login methods to create an AA wallet (via Thirdweb)

2. The voters then can connect this new AA wallet to their existing OP mainnet address which holds their Superchain reputation using a zk proof (via Semaphore group managed by Bandada).

3. The OP mainnet address is never used again and the voter uses their AA wallet to create votes as attestations (via EAS), and to maintain anonymity, we sponsor the transactions.

The zk tech, to be specific, “the semaphore group” of users’ anonymous identities is what makes the Pairwise experience anonymous and the AA wallet experience is what makes the voting experience so magical. ✨

Technical architecture breakdown

To give you a clearer picture, let’s talk about the components of Pairwise that make the magic happen. The frontend Dapp has been built with Next.js and backend services in Node.js with express. Major components of the Dapp include:

Login
1. The Pairwise Dapp allows users to login with a social account using Thirdweb SDK (step 1a).
2. This creates a unique Smart Contract Wallet (SCW) for each user (step 1b) and we save the SCW Address for the user in our postgreSQL database.
Connect
1. Next, users can connect to their wallet (step 2a) which is publicly associated with them. In the current RetroFunding Round, we suggest users to connect to the wallet which holds their OP tokens and/or reputation (delegate address, badgeholder address or recipient address).
2. We then take the user’s wallet address (step 2b) and invoke the backend service for collecting voting power (step 3) for the user's wallet. As part of this, we search (step 4) the voting snapshot csv file (before the voting begins we took a snapshot of the wallet state for OP token holders, delegates, badgeholders and recipients and saved it as this snapshot csv file) and find all the badges held by the wallet. We made some rules to avoid deanonymizing the wallets based on holding too many badges.
3. Based on these we save (step 5) by mapping the user’s voting power (as collection of badges) against their SCW address. Currently, we save the user's main wallet address as well to validate our results. In the future, we plan to go fully pseudonymous.
Vote
1. To vote, the user filters the projects in the Dapp and then ranks the filtered projects and categories. Next, the final ranked projects across all categories are saved in IPFS and we use this IPFS url as the voting signal from the user.
2. We generate proof of vote using Semaphore library against this IPFS url (step 8a) and then we save the IPFS url and nullifier (a unique random string for each user to denote non-repeatable participation in voting) from the semaphore proof results into supabase db (step 8b).
3. Finally, we use Ethereum Attestation Service (EAS) to submit an on-chain vote as an attestation (step 8c). The attestation contains the proof and IPFS url as well.
So What’s Next ?
In all future versions, we will enable 100% pseudonymous voting by only keeping the SCW address and SemaphoreID in the postgreSQL, and keep the SemaphoreID, BadgeList, and IPFS URL in the Supabase.
Next phase of Pairwise
Furthermore, in future versions, we believe we can enable delegation by simply allowing the user wallet to be a delegate’s wallet. We are also currently investigating if a liquid democracy implementation is possible, where voters can delegate on a per category basis, as well as have pass through delegation if a voter’s delegate, delegates as opposed to voting themselves.

The RF4 version of Pairwise was an epic undertaking, the anonymity piece which I architected is only a small part of it. We had major contributions from the entire General Magic team, especially Griff, Zeptimus, Mahdi, Alireza, Moenick, Lovel, Marko, Ayaz, Maryjaf, Kay, MoeShehab, Stee, Anamaria, Guil, Kristina, Aubree, constant support from Bandada Team: Vivian, Andy and the many members of the Giveth and Optimism community that gave us feedback on the application as it was being developed!

Why bring anonymity into Pairwise?

How did we produce pseudonymity?

Technical architecture breakdown

So What’s Next ?

Pairwise: Empowering the Superchain with Pseudonymous Voting for Retro Funding