If you’re reading this post, you’ve hopefully already seen the Humanbound Token (HBT) announcement. If you haven’t, then we definitely encourage you to go check out that blog post to learn how HBTs work and why we take the view that identity must be bound to a human instead of just an account or a wallet.

Quick refresher: HBTs are tokens that are tied to a human, rather than to a wallet. Through multi-factor authentication we ensure identity continuity across on-chain transactions – while preserving privacy through encrypted off-chain data storage. Violet is our highly customizable compliance and identity management infrastructure. The purpose of Violet is to provide a standardized method to issue and authenticate compliance credentials on-chain.

In this post, we wanted to detail how we think about data protection and privacy not just with HBTs but also with the compliance challenges Violet is addressing. Using HBTs and Violet, you can readily implement identity-based compliance in web3, as much or as little as you want, while preserving user anonymity – let’s unpack how that’s possible, and where we can go from here.

Violet = Native Web3 Compliance

Regulatory and compliance requirements affect everyone, including web3 companies, protocols, and our users. The Tornado Cash sanctions are a stark example of what can happen when regulators confront a new technology they are convinced is a problem. And most crypto users have experienced at least one rug pull or pump-and-dump scheme. These are real issues that need to be solved.

We started building Violet to help solve those problems by focusing on identity and compliance management on Ethereum. We want to provide optionality for compliance in a decentralized, programmatic, privacy-preserving way. It’s our belief that users and businesses should have the ability to meet existing and future legal or regulatory requirements. If you aren’t interested in compliance or think the government should keep out of crypto entirely, we aren’t here to convince you otherwise – we equally support your right to engage in transactions based on your own risk assessment and support the developers building those solutions. But we firmly believe in choice, and providing compliance optionality in web3 will benefit everyone through reduced fraud and government antagonism.

Compliance is really hard to address in a web3 native way. User anonymity is hard to maintain because a lot of legal obligations depend on significant knowledge about, and verification of, the person that wants to engage in a transaction. Architecturally, a flexible compliance infrastructure is hard to build because the laws and regulations are all different: know your customer requirements, know your business customer requirements, know your transaction rules, sanctions rules, anti-money laundering rules, obligations like the transfer of funds regulations, plus the innumerable new laws being debated.

We believe we’ve solved these issues by combining the best of on-chain and off-chain technology. Today, we can confidently issue credentials and access tokens confirming that a particular wallet is linked to a specific human without leaking any personal information on-chain. In the future, we imagine evolving this platform to increase privacy even more using zero-knowledge proofs.

Violet = User-Controlled Privacy

Compliance is never more important than protecting and preserving user privacy. Fundamental to web3, and to us, is that users own their data and personal information, not Violet. We’ve filed regulatory comments making our position public (check Matt’s Twitter for the filing!), and we will continue to loudly stand behind that foundational principle.

In developing HBTs and Violet’s compliance approach, we made a few core decisions about how best to protect user data:

• We will never store personal information on-chain.

• We rely on an encrypted, off-chain data vault, hosted by Privy, where identity and compliance information is securely kept. Data is stored in the cloud, encrypted, and neither Privy nor the cloud provider ever have access to plaintext data. We maintain an audit log of all access to your data.

• Only you and Violet have permission to access your unencrypted data. We are committed to transparency on this topic – check out our Privacy Policy and Guidelines for Third-Party Information Requests.

We think these were the right decisions, and let’s talk about why.

First, HBTs were designed with limited on-chain disclosure – only the token ID is stored on-chain – to provide you with maximum privacy protections. It’s up to you what personal information you share with the world or a transaction counterparty – if you obtain an HBT, a transaction using your credential only discloses your wallet address paired with an access token signaling that you, the human behind the wallet, have registered with Violet and, if you engage in a future transaction, that you meet whatever is required for that particular smart contract.

Second, to eliminate personal information leakage on-chain, HBTs and compliance checks rely on an encrypted, off-chain data storage system. Our Privacy Policy and documentation specifically list what’s currently stored in the off-chain vault. We store user personal data in “atomic” Verifiable Credentials. We are working to allow users to use and compose these credentials in order to give them the freedom to choose which data they want to disclose to third parties directly without Violet being involved.

Third, we have limited access to unencrypted user data to everyone other than the user and Violet. All data collected at registration is purged by our verification partner immediately after enrollment, and our compliance partners are not permitted to access or use your data for any purpose other than running the compliance checks that you have agreed to. Users have routine “read” access to their data through the self-service portal, which we included at launch so users know, at any time, what’s being stored in their data vault.

We intentionally made the decision that Violet should have a set of keys to the encrypted data vaults for expressly limited purposes. We did not make that access decision lightly. To be clear: other than the compliance checks users ask us to run for them, Violet will not access user unencrypted data unless we are legally required to do so under compulsory legal process. Which begs the question: “what do you mean by compulsory legal process?”

Governments and private lawyers routinely try to figure out who is affiliated with a particular wallet address, especially when the wallet address is connected to a bad act like fraud. Identity services, whether centralized or decentralized, are ready targets for those legal demands whenever they are affiliated with a suspect wallet address. Our expectation is that anyone obtaining an HBT from us isn’t a bad actor and won’t be receiving such a request, but sometimes mistakes happen.

We kept access to user unencrypted data in order to help resolve these demands for our users, otherwise they’d be forced to respond to it personally or risk additional legal penalties in the form of contempt. And to be blunt: web3 ultimately needs governments to accept the innovation, which at a minimum requires acknowledging their legal demands specifically targeted to suspected bad actors’ wallets. Our full approach, and strong commitment to our users about disclosing these requests, is available here.

Lastly, we wanted to express our firm belief that informed consent is critical. For example, we would never mint non-transferable tokens to a user’s address or on their behalf without their expressed consent. We are not interested in sharing user data, and in no case would we share it without their prior permission.

Violet’s Next Steps

We are very excited about the future of HBTs and Violet! True to our ideals of optionality, choice, and informed consent, we are actively working to expand the user customization options for Violet. Here are a few examples of projects we have in mind, and how we are thinking about them:

• User-Only Access to Unencrypted Data. We recognize that users may not want or need us to assist with legal access requests and would opt to eliminate our access to their unencrypted data for that purpose and others. We are actively working on a way to provide this optionality while maintaining the compliance capabilities.

• User-Accessible Audit Logs. We believe users should not only be able to see their stored data in realtime, but they should be able to see for themselves the audit logs confirming the access they agreed to. There shouldn’t be secrets from users about who accessed their data or why.

• Expanded Compliance Services. There’s more to compliance than verified identity and sanctions. We are focused on infrastructure that would facilitate those different checks in our privacy protective way.