“Compliance” is inevitable for web3 and crypto – it’s in all of our interests to act now and make our ecosystems “safer” instead of waiting on targeted regulation that eliminates innovative solutions and imposes the same societal ills as web2 regulation.
It’s important to dig in on what we think “compliance” means because that term is thrown around a lot without enough clarity. We approach “compliance” in web3 and crypto at a fundamental level – the details flow directly from the government’s overarching purposes of protecting investors and consumers from bad actors who would otherwise cause them harm. There are many detailed, frequently old, rules, regulations, processes, and controls that exist currently for many different industries, but the reason for those requirements is to further the broader protective spirit and purpose. We think too much time is spent debating the nuances around the rules (e.g., whether they apply, whether an entity can actually comply), and too little time is focused on how to make our products “safer” to avoid innovation-crippling, detailed regulation that is clearly on the horizon.
Like it or not, all signs point to mandatory “compliance” coming for most layers in web3, albeit in different forms, and the only real question is whether we can collectively meet government expectations without departing from core web3 values like real privacy. We are at a critical moment in our history: governments are still figuring out how to handle crypto and web3, and we have time to showcase how our technology can enable a better and safer version of life online – while putting user privacy front and center.
That’s why we built Violet alongside Humanbound Tokens (HBTs). We think Violet satisfies the spirit and purpose of government regulation generally as well as checking the existing, critical boxes in truly web3 and crypto native ways.
Violet remains in a closed-beta stage, and features described here may be in various stages of implementation and development. All features are intended to be live by the end of 2022. Please check our documentation or reach out to us on Discord if you are interested in the closed beta!
Violet is our compliance and identity management infrastructure that we will be able to readily customize and adapt as specific legal requirements change in the future. We’ve explained previously how we approached solving the hard problem of privacy-protective compliance, but it’s worth restating that we can confidently issue on-chain compliance credentials and access tokens confirming that a particular wallet is linked to a specific human that passed certain compliance checks without leaking any personal information on-chain or to the third party using Violet.
At this stage, Violet is in closed beta, but we are developing it into a plug-and-play, off-the-shelf solution that any protocol, platform, service, or product can readily utilize regardless of industry. Relying on a user’s HBT and their consent to Violet’s checks, we are able to do the following instantly every time our contracts are called for a registered wallet address, and we only issue the required access token if the checks are passed to our satisfaction:
Know Your Customer (KYC): We confirm a user’s identity during their HBT enrollment, and we use 2FA to ensure that the same human that enrolled is the one conducting each and every transaction that requires Violet. (We are actively working to add Know Your Business Customer (KYBC) capabilities!)
Traditional, Off-Chain Sanctions: We screen users against current sanctions lists before issuing an HBT, and we continue to perform these traditional checks for every new transaction involving that human as well as every 24 hours per industry standard. (It’s not sufficient to screen a person once for sanctions or AML compliance as the lists and people’s activities that may subject them to sanctions are always evolving.)
Know Your Transaction (KYT): We screen registered wallets directly with sophisticated partners to ensure that no on-chain activity has occurred that would prohibit the transaction – such as the wallet address being on a sanctions list even if the human isn’t – or that materially increases the risk as a transaction partner in a way that we cannot support.
Anti-Money Laundering (AML): AML requirements generally are risk based and ongoing obligations, and what’s appropriate will depend on your protocol, platform, product, or service. We reasonably believe Violet will meet these risk-based requirements in many circumstances based on our combination of KYC, traditional sanctions, and KYT. Through detailed KYC and our 2FA requirements, we have a reasonable belief that we know the true identity of the human behind every transaction, and we persist that data in an encrypted off-chain storage vault. Second, through a combination of our traditional sanction screening and KYT process, our system is reasonably designed to detect and enable reporting of suspicious activity.
If your protocol, platform, service, or product requires you to file Suspicious Activity Reports, you would need to separately get affirmative consent from the human behind the wallet and prove that consent to us before we’d be able to provide the personal information required to file such a report. We take our user’s privacy extremely seriously, and we require all data access and disclosure to be done on an informed-consent basis absent a legal order compelling disclosure.
Violet offers a comprehensive, on-chain and off-chain compliance picture that you can rely on even though it is conducted programmatically and anonymously from your perspective. We will never compromise on that last point absent informed consent from a particular user – our native web3 compliance service only works if we are truly trustworthy and stand behind our data access promises, which we intend to prove to our users in their dashboards in real-time.
Knowing and verifying a user is central to preventing money laundering and other types of financial crimes. One example (out of many) comes from the Bank Secrecy Act, which according to the Federal Financial Institutions Examination Council’s BSA/AML manual, requires certain financial institutions to collect and verify things like a customer’s (1) name and residence, (2) date of birth, (3) contact information, and (4) an identification number.
But KYC-like requirements are not limited to traditional financial institutions. Under the Markets in Crypto-Assets Regulation (MiCA), the EU will require customer due diligence for crypto-asset service providers, which includes identifying customers based on documents and verifying the information. EU DeFi regulation is anticipated in 2023, and MiCA is expected to be a reference point even if the regulations differ in some ways.
Zooming out even farther, there are laws requiring various levels of KYBC in an effort to curb fraudulent sales and product practices. For example, with respect to commerce, the EU’s forthcoming General Product Safety Regulation will impose various types of KYBC on online platforms. And the United States is following suit with bills like SHOP SAFE that would require certain platforms to verify the identity and contact information of certain sellers of goods. KYBC support is coming quickly to ensure those requirements can likewise be met by anyone using Violet.
There’s no doubt that global policy overall has moved towards more identity verification in order to combat illicit financial activities and fraudulent activity online. Violet intends to functionally satisfy these requirements as they evolve, and broadly speaking, we believe it meets the requirements of existing laws.
As part of the HBT enrollment process, a user’s wallet address, name, date of birth, location of birth, nationality, ID card type, ID card expiration, ID card issuer, ID card number, mobile phone number, and facial image are all used to verify the user’s identity, although biometrics are purged immediately after. We then store user personal data in “atomic” Verifiable Credentials. A second authentication factor is enrolled at registration and must be used to verify each and every future transaction – this is a critical step required for identity continuity so to avoid wallet “whitewashing,” and that solutions are incomplete if they do not require confirmation of a second authentication factor for each transaction.
Everyone in the world is subject to sanctions laws, both people and businesses. The United States, United Kingdom, and Europe often receive the most attention for their sanctions lists and policies. For example, all three groups have adopted comprehensive sanctions against Russia and its citizens in response to the war in Ukraine and the Democratic Republic of North Korea related to nuclear weapons development. Critically, government sanctions regulators now list both people and businesses under traditional identifying criteria (e.g., a name) AND wallet addresses, including smart contracts themselves (see: Tornado Cash).
Violet is built to send the most trusted sanctions compliance signal possible. Before permitting each and every transaction, we confirm that (1) the human behind the transaction has not been sanctioned, and (2) the associated wallet address for the transaction has not been sanctioned.
Traditional AML rules – like those imposed by the Bank Secrecy Act in the United States – incorporate KYC and sanctions compliance, but can require more. FINRA Rule 3310, for example, provides that entities subject to the Rule must use “risk-based procedures” for ongoing diligence to (1) understand “the nature and purpose of customer relationships” in order to develop a risk profile, and (2) monitor transactions “to identify and report suspicious transactions” in addition to maintaining and updating customer information.
Again, these are risk-tailored requirements, so exactly what’s necessary will depend on the nature of your product, its use case, and the nature of your users. Violet is capable of providing an ongoing, 360-degree view of a human at the time of every transaction, covering both on-chain and off-chain risk vectors. We have the ability to use a default risk score to determine whether a transaction may go forward under our credential, which we set at a level that gives us sufficient confidence the transaction is not illicit.
We would not disclose our risk score to anyone other than the HBT credential holder absent explicit, informed user consent or a legally binding order – we would treat these scores just like user data.
We see “compliance” as an opportunity for crypto and web3 to prove that you don’t need stringent, detailed government regulation of every product or service in order to meaningfully protect investors and consumers. Out of the box, HBTs + Violet will provide more protection against illicit and fraudulent conduct than any similar solution we are aware of in web2 or web3 without compromising a user’s privacy. By leveraging off-chain and on-chain information, we have a comprehensive understanding of a person’s risk, but critically, we do all of that without revealing the person’s identity to anyone else – it’s up to the person whether they want to identify themselves for some other purpose.
Let’s make crypto safer on our own, leveraging financial-institution level “compliance” that comes without mass data exposure or significant friction, and spend our time showcasing how web3 and crypto are fundamentally better ways to organize society.