Mon, August 15, 2022

User Education and Consent in Decentralized Applications

Jill Gunter

Jill Gunter | 4 min read

Last week, several key players in the cryptocurrency and Web3 ecosystem halted assets or stopped providing services to certain wallets in an effort to ensure compliance with new sanctions against the privacy-preserving smart contract application, Tornado Cash. Circle (the creator of major stablecoin USDC) froze over $75,000 of the asset linked to sanctioned addresses associated with the mixer, Tornado Cash. DeFi applications including Aave and reportedly others like Uniswap and Balancer blocked addresses that had recently received funds from the Tornado Cash smart contract.

Based on the backlash that ensued across social media, this was the first time many crypto users and enthusiasts realized that some assets can be frozen and addresses could be blocked. On one hand, it is understandable how all the crypto-talk of decentralization and censorship-resistance might leave people confused by this move. On the other hand, this was not the first time these types of actions were taken by the companies around these products. Circle has been transparent in both its marketing and its code about its freezing functionality and has even previously used its ability to freeze its USDC product. Tether does the same. Most decentralized finance protocols have long leveraged blockchain analytics firms like TRM to block sanctioned addresses.

The scale and widespread implications of these actions, however, do mark an important moment to reflect on the issues of user consent and education. Crypto as an industry touts values like decentralization, censorship-resistance, privacy, and security that are not uniformly delivered on across products.

 This is an issue we have thought a lot about in the development of our first product, CAPE (Configurable Asset Privacy on Ethereum).

CAPE empowers asset creators like stablecoin providers or NFT artists to design policies (or custom rulesets) for the assets they offer users. Some of these policies can include:

-       Making the asset private to the public, while keeping transaction details visible to them as the asset creator

-       Creating NFTs with hidden properties that can be selectively revealed.

-       Keeping transaction details private if the amount transacted is below a certain threshold (for example below 3,000 USD-equivalent in accordance with travel rule guidance)

-       Reserving the right to freeze assets they created

-       Delegating other parties to be able to view or freeze transaction details

We have designed the system with flexibility and pragmatism in mind for average users with average needs around privacy. The product is not designed to be suitable for those in extreme situations with extreme privacy needs. For this reason, we also expect the product will be rejected by those with strong ideologies. We are happy to co-exist with the people and products who are building for stronger needs around privacy. Instead, we are seeking to enable asset creators to innovate in new ways and to empower users with more choices for how they use, custody, and transact crypto assets.

If we are to empower users with more choices, though, those users need to be educated about what those choices are. This education can happen through content via blog posts (like this one!) or social media engagement, through documentation (here), and through choices made in the design of the user interface. Today, the UI for CAPE that we have developed surfaces information to users about who can see and do things related the asset.

blog image

This is okay, but we know there is a lot of room for improvement in making it clear and obvious to users what they are opting into. Some ideas include: translating view keys and freezing keys to be human readable wherever possible so users know what institutions or individuals are behind them; adding “verified” tick marks to assets that known institutions have created; surfacing information about the privacy pool to users; showing curated lists of the most popular CAPE assets; and more.

 There are also inherent challenges in all of this. Many of these designations are subjective (who decides who is verified?) and therefore problematic for any one party to work on. Additionally, CAPE has been designed such that anyone will be able to spin up their own front-end. This makes it impossible to control how much of this information will get surfaced to users through alternative interfaces.

We think the conversation around user education and consent is an important one and we’d love to have it with all of you. 

What should the terms and conditions look like for Web3 applications? How can we better educate users about what they are opting into and out of? What do you want to know in the CAPE interfaces? Write to us on Twitter or in Discord to start the conversation and let us know.

Articles you may be interested in

Sign up to get invited to our product releases