Designing a zero-knowledge airdrop for Element Finance

Jon Crabb
Bootcamp
Published in
7 min readAug 15, 2022

--

Many thanks to Element’s Head of Design, Tina for reviewing drafts of this article and her work on the design itself.

This was perhaps the most fun I had working on a project so far! Hopefully people enjoy reading a case study for a real web3 design challenge.

💡 Element Finance is an open-source protocol for fixed and variable yield markets. Peaking at over $200M Total Value Locked, they are one of the largest protocols in DeFi.

In April 2022, Element airdropped non-transferable governance tokens to their community in three different ways — one of which included a secure and private zero-knowledge claim proof process. The mechanism verified community members’ engagement and involvement in the Element community by evaluating their activity on Discord, Github and other distribution channels, and let them claim their tokens without revealing any personal information.

🛠 Teamwork Makes the Dream Work

A little bit of background before we begin: I currently work for Advanced Blockchain AG who are an investor in Element Finance, among other things. I consult with portfolio companies on different aspects of their design work, which means I get to see a lot of different web3 problems. This is why I write so much about web3 and Design 😁. In this case, I worked with Element to aid the design of the airdrop, although I am not a member of their team.

🧠 The Challenge

Element wanted to allow three types of users to claim voting power for their new DAO:

  • Early users of Element Finance: Individuals that used the Element protocol to LP, Trade, or Mint
  • Community contributors: Users who engaged in meaningful conversations on Element’s Discord server
  • Ecosystem contributors: Builders who contributed to the public goods infrastructure that keeps the Ethereum blockchain running

The challenge was to allow “community users” to claim their tokens, without sharing any of their personal information.

🎯 The Brief

Design a mechanism for users to create an ID (“commitment”) associated with their Discord ID. Use this later to claim the airdrop.

1. Commitment Generation

Create two random 31-byte strings: “the key” and “the secret”.

This requires some user input to make it truly random.

The two strings are passed through a 32 byte hash algorithm to create the “commitment”. Example:

  • Key: 0x005f19a53a070505a0d72fec37b47cc4b8950092e5981275ac47980fb8fb4937
  • Secret: 0x00c7ab67dd880edbf18004ba0c40769bb0fe2f68c09fd1aac35f2c1493a3c6e3
  • Resulting hash (“commitment”): 0x154ba9f290756408dcc0a97c4e802e3db4dd18db008e7919c392e7a638b4c130

Explain to the user that they should post the commitment to a special Discord channel and keep their key + secret private. A bot on Discord will associate the commitment with their ID, and allow users to claim the airdrop later on.

2. Airdrop Retrieval

  • Enter key + secret from commitment generation
  • Click “check for airdrop”
  • If success, let the user proceed with next steps
  • If failure, display some message like “no airdrop available, sorry”
  • Click “generate proof”
  • This will take 10–60 seconds, as the proof is abstracted away to a library
  • Once the proof is complete, allow the user to press “claim airdrop” which generates a transaction and allows it to be signed by the wallet of their choice

✍️ Story Time

There were two user stories to the airdrop. Before doing anything, I wanted to make sure these were completely clear.

By creating simple user flows and marking pages, inputs, and processes, I made sure we wouldn’t miss anything.

User Story 1: Creating the “commitment”

As a member of Element’s Discord, I need to generate a commitment, in order to send it to Discord.

A user flow showing the commitment generation

User Story 2: Claiming the airdrop

As a member of Element’s Discord, I need to check my key and secret against a commitment, in order to claim an airdrop.

A user flow showing the airdrop claim process

🎨 The Process

After creating the user flows I was fairly confident I understood the mechanism and what screens I had to design.

I wanted to come up with a fun way to create a random number, and then make the process as clear as possible.

While researching random number generators, I discovered one based on mouse movement: http://www.russellcottrell.com/mousePointerRNG.htm

I wondered if this could be combined with a slider, so that micro movements of the mouse would create random numbers while the user dragged the slider to the end.

I quickly prototyped my idea and presented to the team:

This was also a good chance to play around with Figma’s smart animate function

For the design nerds:

I’m not a merkle tree expert, so a blockchain dev would have to explain that bit, but I can explain how the Figma prototype worked…

I created this with Figma’s interactive components, rather than new screens for every state. I made several nested components, each with a start and end variation. Then I added the combined component to the final screen.

The “Numbers” and “Slider” components are combined into the Key/Secret module. Drag the slider, to control the numbers; once it ends, the Next Step button becomes active.

If you’re wondering how the number generation effect was created, take a look at the demo below:

If you’re a designer, hopefully this makes sense. If you’ve never used Figma, well, you can skip this part :)

Each number in the field is a vertical strip of numbers and letters: 1,2,3,4 etc. These vertical strips are laid out next to each other in a box that is the height of one number. When you turn on “clip content” in Figma, it cuts off everything outside the box.

Then I created two states: a start position and a finished position. The start position has all the numbers in grey, neatly stacked below the box. The finished position has the strips moved up to various positions, so that a “random” string of digits is shown in the box, and the text is changed to white.

This is then connected to the slider state, so that when you drag the slider from one end to the other, it moves the numbers up and makes the field look like a tumbler.

🖼 High-Fidelity Version

The team liked the idea, so I made a high-fidelity version of the full process.

Generate ID:

I added a stepper to make the process as clear as possible, and a couple more animations, because they’re fun.

Claim Airdrop:

This song was stuck in my head during the entire design process… “I got the key, I’ve got the secret…” 🎵

The very talented Tina from Element then created the final thing. Sidenote: Tina has been vocal about the need for fun and personality in web3, which I also agree with. It makes me glad I experimented with something different for the random number generator.

🏆 Finished Version

More screenshots and information can be found on their docs page here.

You can see the concept was improved further and brought into line with their style guide.

The final version combined both steps, which streamlined it a bit
Direct link to the Discord

Overall, it was a great success, and the Element DAO Launch was discussed on the Bankless podcast!

🤔 Final Thoughts

This collaboration was a perfect example of the decentralised nature of web3. I’m in the UK, Element’s core team is in the States, and most of the ABAG team are in continental Europe. We had a handful of calls with representatives from Element, ABAG and a16z, and with relatively little co-ordination, quickly thrashed out a new UI.

Different people from around the world came together and built something super cool. I’m glad I got a chance to be a part of that and make it happen.

There aren’t many people writing about web3 and design, but I think it’s really interesting and useful to read about the process. You see a bit of writing from the engineering or protocol perspective, but not much from design. I’d love to see more documentation about user flows for privacy solutions or other unique crypto problems.

The industry is constantly evolving, and new technology brings new challenges. Concepts like zero-knowledge proofs were unfamiliar just a few years ago, but as the tech stack of web3 continues to grow, so do the opportunities for the designers working with it.

I think it’s important that designers take the time to learn about some of the harder concepts in crypto, so that they can create better solutions for the next generation of web3 products. By understanding the technology, we can build cooler apps, help onboard the next wave of users, and usher in even more mainstream adoption.

👋 About Me

I am a product designer and UX consultant specialising in web3. I enjoy scaling and leading design teams, and helping DeFi companies at all stages of their development.

If you’re after some more insights, you might want to check my competitive analysis on DEXes or my series on DeFi Design Tips.

https://twitter.com/JonCrabb
https://www.linkedin.com/in/jon-crabb/

--

--