We are excited to announce the shift of Sismo’s entire focus towards making zero-knowledge proofs (ZKPs) available for all builders! ZK Badges were a powerful tool loved by many, yet it is Sismo Connect that will unlock a whole new design space for the next generation of apps.

In this article, we walk through our experimentation with ZK Badges, our learnings and how they led to Sismo Connect.

Aggregation and Selective Disclosure of Personal Data via ZKPs

In our everyday lives, the personal details we share are dependent on the situation we find ourselves in. For example, the details we share at work might differ greatly from what we share with our closest family members or friends. In this sense, we own our identities and have the power to selectively disclose them to others.

Despite being a foundation of human interaction, the ability to selectively disclose aspects of our identity is absent in the digital world. On web2, our identities exist in isolated ecosystems so that tech giants can sell our data to the highest bidder. Web3 gives us sovereignty through ownership of our data, but presents users with a dilemma: create permanent public links between our accounts or segregate them forever.

Sismo enables users to aggregate their identities in a private, local and sovereign Data Vault, allowing them to selectively disclose personal data to other users and applications. Only the Data Vault’s owner has a high-level view of their aggregated identity. Meanwhile, applications can request access to this information, pending user approval, through Sismo Connect and zero-knowledge proofs (ZKPs).

Sismo’s mission is to provide developers with the tools they need to empower users—unlocking their social capital. We deeply admire builders and are committed to supporting them with developer-centric libraries to create the next generation of apps.

Privacy-Preserving Attestations

On web3, users have genuine ownership of their accounts and are responsible for bringing their data to apps. They must do so by sending a verifiable attestation, such as a signed message from a wallet address, to the app in question—thus proving ownership.

For users to bring diverse data originating from varying sources, attestations need to be privacy-preserving. For example, a user may want to reveal that they are a Twitter influencer and financially solvent without revealing the associated Twitter account and banking account or wallet.

In Sismo’s first blog post from October 21, 2021, we described our initial approach with privacy-preserving tokenized attestations:

Sismo enhances your Ethereum profile with anonymised attestations derived from your other accounts. Sismo issues ZK Badges (non-transferable NFTs) to your public Ethereum profiles (ENS names). These are Zero-Knowledge (ZK) attestations of facts imported from your other accounts (Ethereum accounts as well as Twitter or GitHub). You can consolidate your reputation, confidentially, on your public profile.

When we started, Vitalik was already vocal about the need for attestations and hadn't yet introduced the concept of Soulbound Tokens (SBTs) or published his article about employing zk-SNARKs for privacy. Coincidentally, these two articles explained in precision what has been Sismo’s main focus for months. We encourage you to check out this content as they give a good context on:

• Why privacy-preserving attestations are worth building.

• The nature of Sismo’s ZK Badges: non-transferrable/Soulbound tokens in general.

• How ZK Badges are generated: users generate ZKPs attesting membership in a group (e.g, I’m part of ENS DAO Voters Data Group).

ZK Badges: Tokenized Attestations

On June 11, 2022, we unveiled Sismo’s attestation protocol, which allows anyone to create new ZK Badges by defining a Data Group—the Merkle tree of eligible accounts for a ZK Badge. Users, within their Data Vault, can ZK prove their membership in this group to mint the Badge (an non-transferrable ERC1155 tokenized attestation).

Since the launch of our ZK Badges minting application:

• Over 65k individual users have minted ZK Badges.

• A total of 160k ZK Badges have been minted.

• The community has created 244 unique ZK Badges.

This application will be sunset on September 1, 2023.

Example: GR15 Gitcoin Contributor ZK Badge - Creation and Minting Process

• We created a Data Group containing all Gitcoin Grant Round 15 contributors on the Sismo Factory — which pushed it onchain as a Merkle root.

• Users, with an eligible source account in their Data Vault, can generate a ZK proof of inclusion in this group.

• The proof is sent to the ZK Attester contract, which performs three simultaneous operations:

  • It verifies the ZK proof.

  • If the proof is valid, it mints a ZK Badge to the user-specified destination account.

  • It saves a 'nullifier,' an anonymous deterministic identifier for the user Vault, preventing the minting of two Badges from the same Data Vault.

Crucially, the source account used to generate the ZK proof remains undisclosed throughout the process.

Applications Don’t Need ZK Badges

Promptly, we understood the limitations of ZK Badges and comparable standards for onchain attestations. They aren't adequately suited to manage an application's access control and reputation systems—Sismo's longstanding vision.

For clarity, consider three applications that could use the GR15 ZK Badge to privately limit usage to GR15 contributors:

• An onchain voting system

• An NFT airdrop

• A Discord bot controlling access to a private channel

Three primary challenges emerge:

Attestations should be application-specific to prevent unintended cross-application disclosures: For instance, what if I want to vote from a public wallet but receive the airdrop on a separate private wallet? With written attestations tied to a specific wallet, this isn't feasible—I can only access both services with the same wallet holding the attestation.

Attestations need to be accessible by all applications: Suppose the onchain voting system and the airdrop contract are deployed on different blockchains. In that case, I'm compelled to mint 2 ZK Badges on both chains.

Applications do not need persistent attestations: Applications only need access to the underlying information at execution time. If they need persistence of the information, it's their prerogative to store the result in their local system.

• The voting contract only requires the attestation during a vote submission. The enduring record is the ballot, not the attestation.

• The airdrop contract requires the attestation when verifying a user claim, not before or after. What remains is the record of NFT ownership.

• The Discord bot relies on the attestation when determining a user's eligibility. It then stores the user's Discord ID in its user rights management database.

Verifiable Proofs are What Applications Need

Let's unpack how the ZK Attester smart contract issues ZK Badges.

It's a two-step process: the contract first verifies the proof, and then mints the ZK Badge. The real magic—the true essence of the attestation—happens at the verification stage. The minting step is just the recording of this attestation in its written form.

Like the ZK Attester, the onchain voting system simply needs to verify the ZK proof of GR15 contribution and subsequently record the vote. Similarly, both the airdrop contract and the Discord bot can verify the same ZK proof. While the airdrop presents users with NFT awards, the Discord bot provides access to the Discord channel.

Applications fundamentally require two components: the user-generated proofs and the corresponding verifier function. This is precisely what Sismo Connect offers to all applications, whether they operate onchain or offchain.

ZK proofs are generated offchain, in a user’s Data Vault and can be sent to any system. Similarly, the verifier function is code that can be deployed anywhere, in smart contracts, backends or in p2p clients.

Sismo Connect: enabling applications to request and verify users’ ZK Proofs

In April 2023, we released the beta version of Sismo Connect— the crypto-native SSO. It consists of a set of developer-friendly libraries that abstract away ZK proof generations and verifications, making it easy for developers to request access to data from users’ Vaults.

Since its launch, more than 100 Sismo Connect apps were created during hackathons and by early adopters.

With Sismo Connect, applications can request data from multiple sources at once. There are two types of requests that can be made:

• Authentication: ZK proof of Data Source ownership (e.g. Ethereum wallets, GitHub, Twitter or Telegram accounts).

• Disclosure of anonymized personal data: ZK proofs of Data Source inclusion in a specific Data Group (e.g. GR15 contributor).

Visit the docs to get started on Sismo Connect!

What’s Next for ZK Badges?

Don’t be mistaken; written attestations are still a great tool to curate public and persistent profiles such as our ENS and doxxed wallets! We welcome any projects like Ethereum Attestation Service (EAS) or Badges platforms to use Sismo Connect to build powerful attestations leveraging users’ aggregated data.

With the release of Sismo Connect, we realized that the best value we can bring is to enable all applications to request and verify proofs from users.

Thus on September 1, legacy ZK Badges, that were issued by the legacy ZK Attester will no longer be available to mint, and the application on app.sismo.io will be sunset.

We just released on the Sismo App Store our “Early Sismo Community NFT”, claimable by all 77k users that helped us build Sismo! We hope you will enjoy this token of appreciation!

Follow Sismo on Twitter to stay tuned for the latest updates and subscribe to our blog!

To learn more about Sismo Connect:

• Read the documentation

• Try Sismo Connect apps in the App Store

• Check additional resources