It’s time to prove your worth in DAO — SSI using MetaMask Snaps, Part 2/3

7 min readAug 11, 2022

This is the second part of the blog series SSI using MetaMask Snaps. Make sure to check out all parts:

What happened in Part 1?

The previous blog post outlined the problem of plutocracy in almost all DAOs and how we can take a step towards meritocracy using the SSI principles. We explained what SSI is, what we can do with DIDs, VCs, and VPs, and how the whole concept integrates into DAOs with our solution. We showcased how the MetaMask Snaps system enables us to extend the functionalities of MetaMask, to support the management of DIDs and VCs. Similar to what Vitalik Buterin outlined, our idea is that reputation should be hard to earn and non-transferable.

While the previous article showcased how to obtain a reputation in the form of VCs, this post goes one step forward and describes how to use VCs and VPs in dApps. In the first part of this article, we talk about our Secret Room concept — an introduction of an easy yet exciting use case with VPs. After that, we demo our Snapshot story and invite you to try our SSI Snap to enhance the DAO governance process.

Some things changed since Part 1

Since the previous update, we’ve worked hard to improve the SSI Snap. We’ve officially implemented version 1.1.4. Most notably, we’ve stopped using additional delegated DIDs for signing VPs. Instead, they are now signed directly in MetaMask, using the EIP-712 signature. This makes the user experience, as well as implementing the snap, much more straightforward and more intuitive. We also restructured the whole project to make it more similar to other Snap projects (Filsnap, Btcsnap, …). Another big milestone is launch of SSI Snap Connector, a library that allows dApps to easily install and use SSI Snap with the use of SSISnapApi. Aside from these big changes, we’ve implemented countless minor improvements and bug fixes.

We have plenty of exciting upgrades in the pipeline and we can’t wait to share them with you. Among them will be new ways of storing data (ceramic network, cloud, etc.), syncing among wallets, the configuration of the SSI Snap by the user (what DID method to use, where to store VC), and much more. But more on that in the part 3.

Secret Room — Access Hidden Resources

We created the so-called Secret Room for demonstration purposes, where users must present a VP (representing a VC received in the Part 1) to enter the secret room. In our example, the required issuer and VC schema are hardcoded in the application. However, using the same practice, one could create an infinite amount of applications, accessible only with specific credentials. The hidden page becomes available when the user generates and presents an appropriate VP instead of entering their username and password.

Upon connecting the MetaMask wallet and establishing a connection, the application requests a specific VP to enter the room. Presenting a VP is carried out entirely through MetaMask’s UI. The user selects a VC, which is used to generate the VP. Under the hood, Veramo library takes care of generating and the VP. Another critical thing to note is that the Secret Room doesn’t store user data and has no central database. Figure 1 shows a user selecting and approving a VC to generate a VP.

Figure 1: Approving the selected VC to generate a VP.

The generated VP must now be signed. MetaMask prompts us again, this time for a signature.

After the VP has been signed and presented, the website sends it to the backend to check the validity of the VC and its data. That includes the issuer, holder, expiration date of the VC, and the schema of the VC. If it meets the requirements, the user is allowed to enter the secret room. After the VP has been validated, the user enters the secret room, which is showcased in Figure 3.

Figure 3: Successfully entered the the secret room.

Snapshot — Prove Your Worth in DAO

With our beliefs dictating that voting power should be earned, not bought, we integrated the SSI Snap functionality to work with Snapshot — the most renowned DAO governance platform. With Snapshot, users owning an ENS domain can create their own space where the project’s proposals and governance live. Proposals can be made and voted on by anyone that conforms to the requirements (e.g., hold specific ERC20 tokens, present the required VP, etc.). For more information on how the governance platform works, check their website and docs.

Figure 4: Example of a space in Snapshot.

We implemented a DID plugin for Snapshot that enables the creation of proposals that use VPs as a voting mechanism. Only people with credentials that meet the requirements defined by the proposal owner can vote. These requirements include the issuer and the schema of a VC. The creators set which issuer and schema are valid. For example, BCLab:UM wants to create a proposal regarding the future of SSI Snap, where only people with a specific credential can vote. BCLab:UM defines the specific credential requirements by setting the issuer to “did:ethr:0x123…” and the schema to “https://beta.api.schemas.serto.id/v1/public/consen-sys-hackathon-2021-participant/1.0/json-schema.json".

By moving from counting the voting power based on the number of tokens to an SSI-based approach, we establish a meritocratic system where the power cannot be bought. VCs are non-transferrable and bound to the user’s DID, stored locally in a wallet (or somewhere else if user decides). Of course, this example works with a “dummy” credential, but in a real-world setting, VC should be hard to obtain (e.g., diploma).

To create a working demo, we had to fork, host, and tweak some repositories to support the VCs and VPs:
1. snapshot-ssi-demo: this is a parent repository that connects all the forked snapshot repositories we used to build our demo
2. snapshot: extended the vote UI to support selection of VCs
3. snapshot-hub: added support for veryfing VPs
4. scores-api: added support for veryfing VPs

You can find the working demo here.

We added additional steps to the current Snapshot flows. These steps are executed when the DID plugin is detected in a proposal. Plugins are added to the space and are automatically used in all proposals, but in our case, we also added the option to ignore it in certain proposals if needed. Now, let’s take a look at the proposed workflow.

First, we start by creating a proposal and defining the issuer and the required VC schema when presented with the DID Plugin UI, as seen in the image below.

Figure 6: Proposal creation with DID plugin.

After defining the issuer and the VC schema, we are ready to publish the proposal. As seen in the following image, when clicking on publish, we need to sign a message to publish the proposal. The additional information regarding the DID Plugin is saved into the proposal’s metadata on IPFS. Currently, only two properties of the VC must match in the future, we could add more properties, such as specific values in the properties of credentialSubject.

This IPFS link shows an example of a proposal’s metadata with included DID Plugin info — an issuer and a VC schema.

With our proposal published, users with required VCs can now vote. When voting, the user must select the required VC from the drop-down, as seen in the image below. The user is then prompted to accept the VP generation from the selected VC. A newly signed VP is sent to the snapshot backend server, where it is verified. If the VP is valid, the user can cast his vote, with a voting power of 1.

Figure 8: Selecting the VC from the drop-down menu.

The last step requires a user to click the Vote button and sign the proposed message. This can be seen in Figure 9. The generated VP is stored in the vote’s metadata on IPFS.

Figure 9: Example of signing a vote with the selected VC.

When visiting the proposal’s page, only votes made using valid VPs/VCs are recorded, and the people voting on these proposals are now expected to earn their power and worth, not buy them.

Figure 10: Final votes with on the proposal.

Demo video

Next Steps

That’s all for the second post. We will end this blog series with a third post, where we will open source all the components and invite you to join the discussion on our Discord server Blockchain Lab:UM (and maybe even contribute on GitHub :) ). Part 3 will also contain the future outlook of SSI Snap.

Stay tuned!