Proof of accredited investorship with zkPass, Part I
Proof of accredited investorship with zkPass, Part I
Or: Proving that you are an accredited investor so you can legally buy almost any securities and receive airdrops, with zkPass
US strict regulations on cryptocurrency (or, anything that looks like securities) have a goal for consumer protection. Registered securities offer important legal protection, such as recovery rights. Such regulations, however, come with a hefty compliance cost—many cryptocurrency projects, when serving US customers, limit themselves to accredited investors (see Aleo’s testnet reward policies and Coinlist’s dedicated US staking fund for example) or refuse US tax residents altogether to be on the safe side. This is an issue both in web2 and web3. Banks in Hong Kong often decline to offer many financial products to US residents.
In other words, consumer protection has a side effect that it takes away some of consumers’ opportunities “to be rich”. Individuals may not be able to participate in token presales. What is more, today, many web3 projects do airdrops (see Celestia, Arbitrum, Optimism), but it explicitly filters out US residents. We don’t know how many US developers are disqualified from airdrops because of their tax residency, but it is of course very sad to hear.
The Securities Act of 1933, however, does provide an exception—accredited investors, the definition of which is shown in the picture above from Investopedia. This is Rule 501 of Regulation D. It gives an individual accredited investorship based on income.
(6) Any natural person who had an individual income in excess of $200,000 in each of the two most recent years or joint income with that person's spouse or spousal equivalent in excess of $300,000 in each of those years and has a reasonable expectation of reaching the same income level in the current year;
The income test is fairly approachable to people in the tech industry. According to levels.fyi, except for the most entry-level titles, software engineers in top IT companies—Amazon SDE II, Google L4, Facebook E3, Microsoft Senior SDE—usually have a qualifying income after working for a few years. To put it differently, if you meet another software person living in San Francisco or Seattle, chances are that he/she is already an accredited investor.
But now the problem is: how do they prove that?
The traditional solution in web2 is to do KYC—to request documents as income proofs, which can be tax forms or pay slips. This is a poor fit for web3, and in fact, we believe it not sustainable for web2 as well.
Lack of scalability. Since the income proofs are “unstructured data” and vary from each employer, it often requires manual inspection. But, since pay slips are easy to forge, to be certain, a landlord’s best bet is to call the employer for verification—an unsolicited phone call that is rarely welcomed—or to go for a comprehensive background check, the cost of which is above hundreds of dollars.
Lack of reliability. There are plenty of online articles teaching people, particularly landlords, to detect signs of fraudulent payslips (see 1, 2, 3, 4, 5), yet an educated adult can easily forge a perfect one. Today, one doesn’t need to be James Bond to create doctored payslips. In addition to payslips, fake IDs are not uncommon: an underage college student may already have one for getting alcohol (see this article). Law-abiding people like us just don’t know how much trust we are putting in from day to day.
Lack of privacy. Too much information is revealed. Payslips expose home addresses. Tax forms reveal marriage status, number of children, and other sources of income. Credit reports are the worst: it includes current and previous addresses, current and previous employers, and other information that is much more than “I am an accredited investor.”
The culture of web3, however, distinctly differs from that of web2.
Scalable: automated, disintermediation
Web2 has clerks and cashiers. In Web3, it is the smart contracts.
Transactions are processed in a transparent, automated manner by a network of more than thousands of nodes. 24/7. Processing time is usually less than one minute. Since everyone can create a smart contract, there is little monopolization, and fees are often reasonable.
So here is the question: How do you prove accredited investorship in web3, or, to a smart contract?
Reliable: decentralized, minimal trust
The traditional society relies a lot on trusting people to be honest until proven otherwise.
Many states in the US allow a voter without an ID to vote by signing an affidavit. But even if an ID is required, it doesn’t add much security. Most states’ REAL IDs don’t have a chip, and one doesn’t need to break any cryptography to forge one.
Our real world is an optimistic rollup. You challenge people by calling the district attorney. The fraud proof is centralized, as the so-called “data availability” is almost nonexistent for regular people so they are incapable of generating the fraud proof. Web3, however, needs to be open to verification by everybody.
So here is the question: How do you prove accredited investorship in web3 reliably?
Privacy-preserving: autonomous, pseudonymity
To create an account on a web2 website, chances are that you are asked for a phone number and at least an email address. For credit card payments, a zip code is the bare minimum, but oftentimes a billing address is needed. The prevalence of people search sites in the US (which is a legal business), such as TruthFinder, PeopleFinder, and Spokeo, renders privacy almost hopeless.
Web3 is a privacy-by-default culture. The 0x addresses have no association with one’s real-world identities. Blockchains do not care who you are, but only care about your intent.
So here is the question: How do you prove accredited investorship in web3 without revealing your life?
This calls for us to rethink how our world should be operated. If I need to prove that I am an accredited investor,
Why do I need to submit my payslips?
Why do I have to reveal my home address?
Why do I have to provide tax forms to prove my taxable income?
How many people would be able to see the documents?
The other side, who will be verifying the documents, is also struggling.
Are these payslips fake? Are they doctored?
Do I need to cold-call the previous employer for verification?
Should I ask for consent to submit a formal background check?
Do I need to manually check every line of the tax forms to see if it is doctored?
This happens to many web3 investors. Recently, I was admitted as a new member to the Zero DAO, a US-based DAO investing in zero-knowledge proofs. Prior to the admission, I went through the KYC process. The DAO is web3, but this KYC part remains web2. Although the KYC experience is smooth, I did submit a lot of documents, and I started to wonder if KYC is going to be a common routine for me if I continue working in the investment industry.
Think about it further. Even Web2 may benefit from a better solution. Imagine, probably not far in the future, you become a private equity investor and sign hundreds of SAFE agreements a day. Instead of sharing your phone number, your email address, or your home address to half of the people in the Sand Hill Road, what if you only need to open Metamask and click, click?
Today, we finally have the technology to fix that, thanks to the advancement of cryptography. I like a motto from one of our portfolio companies: “Fixing the Internet, one ZKP at a time”. And this is it.
In this series of articles, we describe a solution to prove accredited investorship with privacy and integrity, using zkPass. This comes out from a partnership between L2 Iterative and zkPass, with a goal to make zkPass a comprehensive tech stack for data ownership that can be used across web2 and web3. The code of our engineering work going to be discussed in this article series can be found at GitHub.
The first article will be focusing on the motivation—how to understand this narrative.
A tale of data ownership
We want to first conceptualize what we mean by data ownership. Particularly, we are thinking about personal data stored in third parties.
Government has the personal identification information, including photo, nationality and citizenship, date of birth, and some unique identification numbers. Some part of such information can be found in the passport.
The US tax agency, Internal Revenue Service (IRS), keeps records of the tax filings as well as wage and income transcripts, from individuals, banks, insurance providers, employers, and other corporations etc.
Ownership of social accounts—such as Instagram, Twitter, Quora, Tiktok, Discord, and Reddit—as well as the related information such as memberships or subscriptions, number of followers, and contents of posts or tweets.
Banks and credit bureaus like Equifax hold historical account balance, spending activities, and financing situations. Think about credit reports and six-month bank statements that landlords want to see for background checks.
Data protection laws such as GDPR and CCPA, passed in the past decade, provide a solid foundation for a number of rights related to data ownership:
GDPR: right of access, right of erasure, right to object, right to compensation, right to not be subject to automated individual decision-making
CCPA: right to know, right to delete, right to opt-out of sale or sharing, right to correct, right to limit use and disclosure of sensitive personal information
But this is neither sufficient nor comprehensive. There is a large scope of data rights not covered by GDPR and CCPA. For example, people have more rights when it comes to healthcare data. According to HIPAA, the patient not only has the right to access their own protected health information (PHI) from a healthcare service provider (such as a doctor), but they can also request the data to be transferred to a specific third party.
This allows a patient to easily switch between different healthcare providers by asking the former provider to share prior records (including diagnosis, x-rays) to the new provider. It has been implemented in every clinic in the US. Below is the authorization for release form from UC Eye Center for a patient to request data be shared with a third party.
Compared with healthcare, Web2 must feel embarrassed. You cannot expect the following to happen in Web2 soon:
ask a bank to send an official email to the landlord confirming your account balance
ask DMV to call the buyer to endorse that you hold a certain brand car
ask Uber to share with Lyft about your driving records so that Lyft can match your rewards tier as a driver
ask IRS to email zkPass that you are an accredited investor and should be qualified to receive airdrops
Focusing on the last point related to accredited investorship. It would be fairly convenient, just to imagine for a moment, if whenever someone doubts that you are an accredited investor, you could always call the IRS, and the IRS would immediately call he or she to confirm your accredited investorship…I used Comicai to draw a minicomic below.
Nevertheless, this is not what happens today, and likely not in the near future. The IRS has an express income verification service, called IVES, that would soon be limited to “verify the income or creditworthiness of a taxpayer who is a borrower in the process of a loan application” (see Section 2201(b) of Taxpayer First Act of 2019), which definitely does not include “airdrops”. Talk about preciseness!
This example shows the limitations of today’s data protection laws.
The laws make sure that the third parties are not “data owners”. They need to allow you to access the data. They have to delete the data if you ask. They cannot share the data without your consent. In the case of the IRS, the Taxpayer First Act is acting as a data protection law here, as it limits how IRS shares the data.
But these data protection laws don’t make the user “the owner of the data” either.
The data is still proprietary to the third party. Third parties have no responsibility to testify for the user about the data.
Users may want to customize the format of the data (such as redactions), but third parties may not have the options. For example, for accredited investorship, we only need to prove that the annual income is greater than US$200k rather than to reveal the exact number (think, what if you are a billionaire), but IRS current authorized release doesn’t have this level of granularity.
To restore the ownership to the user, here is what zkPass needs to tackle:
Enable the user to obtain data from reliable data feeds
Enable the user to prove user-specified data processing (redactions, or generic computation like checking if income >US$200k) while preserving the authenticity of the source data
With zkPass, everything can be different. The accredited investorship can be made into a soul-bound token (SBT), and the user can prove the ownership of this SBT from Metamask with a few clicks.
This sounds like a Police Benevolent Association (PBA) card for airdrop clearance, but it can be even more convenient. In fact, you don’t even need to click on Metamask—dApps that know the user’s address can use Alchemy or Ankr to automatically find out if the user has this SBT and silently removes any blocker, as if the dApps already recognize you as an VIP.
In some way, zkPass resonates with the concept of the ZK coprocessors (think Hyper Oracle, Axiom, Bonsai, Brevis, and Herodotus) that focus on history web3 on-chain data. zkPass also resonates with ZK bridges (think Polyhedra, our portfolio company), which do message passing between different chains with mathematical security. Unlike them, zkPass is a unique one that focuses on off-chain data, including web2 data.
ZK coprocessor: Verifiable on-chain data
ZK bridge: Verifiable cross-chain data
zkPass: Verifiable off-chain data
zkPass: a stack for data ownership
zkPass is a full-stack solution for data ownership, which consists of various tools and applications that enable verifiable data sharing, with privacy and integrity guarantees.
Data-feed:
HTTPS web connections (with 3P-TLS)
Data-processing:
Data-consuming:
On-chain identities
Off-chain verification
Currently, their testnet version already supports a long list of data-feeds, including internet companies, traditional industry, governments.
banks and governments: Nagarik App, ANZ Bank, Australian myGov
education: Coursera, Hubspot Academy
video games: GOG.com
social platforms: Instagram, Twitter, Quora, Tiktok, Medium, Reddit, Discord
Our partnership: RISC Zero backend and PDF proofs
We have a partnership with zkPass to create an interactive proof for IRS-reported taxable income from the IRS website, which is then used to establish the accredited investorship, through the most commonly used income test for individuals.
This can be done with privacy and integrity by having the users interact with the data requestor as follows:
prove—using zkPass 3P-TLS protocol—that he/she receives the account transcripts for the prior two years, which would be two PDF documents, from the IRS Transcript Delivery System (TDS). A redacted and desensitized sample of the 2022 IRS account transcript of the author can be found here. Since account transcripts contain sensitive personal information, such as the last four digits of the social security numbers (SSN) and abbreviated home address, the transcripts would not be revealed to the data requestor. The PDF below, which is my IRS account transcript for 2022, looks as follows.
prove—using zkPass data processing protocol, here RISC Zero backend—that the two account transcripts are:
matching the user's profile
recently issued by the IRS
matching the requested years (such as 2022)
have a taxable income larger than US$200,000
This can be illustrated with the following diagram.
The zkPass 3P-TLS protocol is used to prove the internet connections with the IRS website, which works as follows.
The user makes the usual HTTPS connection with the IRS website, with the encrypted network traffic rerouted through the validator. Validator here acts like a network proxy or, in laypersons' terms, a VPN.
After the HTTPS connection concludes, the validator asks the user to generate a zero-knowledge proof about the encrypted traffic data. The validator independently verifies the integrity of the TLS connection, through PKI certificates.
As we discussed above, zkPass supports multiproof. Several backends, including RISC Zero that we use, can be used to generate this zero-knowledge proof. This is often a selection that optimizes performance. RISC Zero is suitable for proofs that involve RAM-model computation rather than circuit-model computation.
This protocol that zkPass uses for 3P-TLS has been studied for many years, all the way starting from TLSNotary more than a decade ago (now, an Ethereum Foundation-funded PSE project). Academic work including BlindCA (IEEE S&P 2019), DECO (ACM CCS 2020), Oblivious TLS (CT-RSA 2021), MPCAuth (IEEE S&P 2023), and DiStefano from Brave Browser has moved this forward.
Next, zkPass will use the RISC Zero backend to read the PDF file.
RISC Zero takes care of processing the PDF file that the 3P-TLS protocol obtains, performing necessary parsing, decryption, and decompression, and then checks if the “taxable income” is greater than USD$200k, as shown in the code snippet below taken from our implementation.
let (tax_period_start, tax_period) = find_data(0, "TAX PERIOD: ".parse().unwrap(), ")".parse().unwrap());
assert_eq!(tax_period, "Dec. 31, 2022");
let (_, taxable_income) = find_data(tax_period_start, "TAXABLE INCOME: ".parse().unwrap(), ")".parse().unwrap());
let taxable_income = str::parse::<f64>(&taxable_income.trim().replace(',', "")).unwrap();
assert!(taxable_income >= 200000.00);The next article in our series would explain how we implement the entire thing in RISC Zero backend in a few days and how this is then integrated with zkPass, such as issuing an on-chain SBT or finishing an off-chain verification (which is sufficient for airdrop clearance).
More applications
The techniques present here, proving data on PDFs, can be generalized to a lot of settings.
An example is CeDiploma, an electronic diploma provider with clients including Stanford and UC Berkeley, which embeds the digital signature in the PDF.
This is more challenging than IRS account transcripts for zero-knowledge proofs: not only does the decompression algorithm need to run over a larger amount of data, but the main body of the PDF consists of Bézier curves that form the text body rather than the original text in English characters (I believe it is intentional), for which a mini OCR algorithm is needed here to read my name. This, however, should be fairly affordable and do not require ZKML. Particularly, since CeDiploma always serves the same PDF file, the ZK proof only needs to be done once for each degree, and then it can be an on-chain SBT that will permanently live in the web3 world.
Another example is Docusign. The signed document together with the summary document, which are two PDF documents, can be used to prove that signers with those email addresses made the signature. See here for an example SAFT agreement (from https://saft-project.org/) and its eSignature summary. In fact, Docusign can go far away, as they also have support for more authentication methods including government ID verification and SMS verification, and they can then be verified by ZK, assuming that we trust Docusign to perform the identity verification.
Adobe Acrobat also has the same functionality as Docusign offers, through Adobe Sign, which means that one can ZK-verify the identity verification done by Docusign, Adobe, or have them both.
This can effectively create “Power of Attorney (POA)” that one can appoint a smart contract for representation on chain, by digitally signing a document. Interestingly, since “an electronic signature can be used to sign a contract, which is enforceable in a court of law” as Docusign mentions, it becomes legally enforceable.
Next article
In this first article, we are mainly addressing the motivation, positioning zkPass in the current modular blockchain stack, and presenting zkPass tech stack.
In the next article, we will dive into how zkPass can be used to obtain reliable data feeds from the IRS, as well as the RISC Zero backend.
Find L2IV at l2iterative.com and on Twitter @l2iterative
Author: Weikeng Chen, Research Partner, L2IV (@weikengchen)
Disclaimer: This content is provided for informational purposes only and should not be relied upon as legal, business, investment, or tax advice. You should consult your own advisors as to those matters. References to any securities or digital assets are for illustrative purposes only, and do not constitute an investment recommendation or offer to provide investment advisory services.