Here is what angel investing should be:
Send USDC from a wallet with your ENS to the entity’s ENS and get digital mirror assets back into your wallet. These assets are held in a mirrortable, which is an on-chain replica of a primary cap table maintained in an off-chain system like Carta for compliance purposes. The terms of these assets are kept current via periodic updates of the mirrortable's smart contract.
If you understand all the concepts in this statement, consider working on this problem or joining a team in the space! If you aren't familiar with any of the terms in that sentence, like ENS, look at the definitions in the appendix. Or just read on.
There’s been a recent debate about web3 that’s operated at a 30,000 foot and 280 character level. To bring it back to earth, I want to talk about one very concrete problem: the tangle of angel investing. This is an area where off-chain web2 tools like Docusign, Hellosign, Carta, and AngelList could be profitably augmented with on-chain web3 tools that have matured over the last several years — particularly the Ethereum blockchain, the USDC stablecoin, and the Ethereum Name System (ENS).
To do this, we'll introduce a concept called a mirrortable, an on-chain representation of a traditional capitalization table. A mirrortable is to a cap table what a stablecoin is to a fiat currency. That is, the on-chain version provides 24/7 uptime, international wallet support, and integration with smart contracts, while the off-chain counterpart provides legal compliance and compatibility with legacy systems. In other words, mirrortables radically improve programmatic interactions with cap tables, just as stablecoins have done for fiat currencies.
But why do we need to “streamline programmatic interactions with cap tables”?
Motivation: Angel is Vertical
As motivation, angel investing is through the roof. With the physical decentralization of technology away from Silicon Valley, the simultaneous acceleration of many tech trends, and the money released by a slew of liquidity events, there are more high net worth individuals writing more checks into more tech startups in more countries than ever before.
- 10X investors. There’s a surge in the number of investors per round. Party rounds are now standard.
- 10X startups. There’s a rise in the number of high quality startups. We see amazing people every week.
- Increased complexity. There’s an increase in contract complexity. It’s not just vanilla SAFEs anymore, it’s all manner of complicated token and warrant agreements.
- 10X jurisdictions. And there’s a huge expansion in the number of jurisdictions, now that places like India, Nigeria, and Latin America are coming up in a big way.
That last point is why this isn’t about solving a problem for the idle rich. If you were one of the idle rich, you’d just be idling. The non-idle rich are putting their capital at risk to invest in the ascending world. And automating that means we can do much more of it…because right now the current system of PDFs, emails, and spreadsheets is an antiquated mess that is breaking under load.
Status Quo: The Current Angel Investing Process
Here is the current process from an angel investor’s perspective:
- Meet a founder.
- Talk to them via email or one of many chat apps, like Twitter DM, WhatsApp, Telegram, or Signal.
- They email docs.
- Review those docs: a vanilla SAFE, a token sale, an advisory contract, or something more exotic.
- Sign those docs via Docusign or Hellosign, or sometimes print, sign, and scan.
- Download the countersigned, timestamped PDF and put it into a giant investing spreadsheet in Google Sheets or Notion.
- Get their wire info.
- Initiate the wire, which is actually a bit of a hassle.
- Sometimes, for countries like India, go through an interminable KYC process.
- Confirm they received the wire.
- Now you get a stream of documents over the next several years from the startup on a irregular basis.
- After the round closes, you get a stock certificate in one of several systems like Clerky, Carta, Shareworks, etc.
- You can also download closing documents if the round is completed on AngelList, Republic.co, etc.
- Periodically, you get notifications on new rounds, months or years later, with the possibility of investing at a higher valuation and/or maintaining your stake.
- Or you get a notification of an exit, M&A, liquidation or shut down event, where you need to sign docs.
- Exits usually have well organized paperwork, but you need to sign fast and send them wire information.
- Shut downs are often chaotic, but you want some documentation for the capital loss.
This may not seem like a big deal, but what happens is that each investment you do isn't just a one-click expenditure of $X today. It's $Y in ongoing maintenance cost to keep up with a stream of irregular documents. It's not uncommon for angels to accumulate dozens if not hundreds of investments over the years. At a certain point the maintenance burden starts to cut into time that you'd rather spend evaluating new investments.
Status Quo: The Current Angel Investing Tech Stack
What is the tech stack people currently use to manage this process?
- Messaging apps. A bunch of messaging apps all open on their computer and phone. These can be either individual apps or a meta layer like texts.com. There are also newer group messaging tools like getcabal.com for investor updates.
- Shared inbox. A shared inbox with a huge email queue, like a shared Gmail address or front.com.
- E-signature apps. An e-signature tool like Docusign or Hellosign. Often you actually have to ask the startup’s lawyers to set up a Docusign, as they will otherwise ask you to download and sign a PDF and then scan it.
- Giant spreadsheet. A giant spreadsheet with one row per deal and many columns, like Google Sheets + Google Drive, or Notion.
- Shared bank account. A bank account to wire from, often a startup bank like Mercury Bank or Arival.
- Shared crypto wallet. A shared crypto wallet like Metamask or MyCrypto used in "enterprise" fashion, or a shared exchange account to send USDC from. The whole area of enterprise wallets is a related and crucial thing to innovate on.
- Many logins. A bunch of logins for the various cap table systems of record, like Clerky, Carta, and AngelList — if the company even uses them. Many cap tables are still maintained in Google Sheets or even Excel. This complexity keeps increasing because as an angel, you have minimal input on what choice of platform a founder uses. You can ask, but you can't really expect them to standardize on (say) Carta just for you.
- A small back office. A single person or small back office team that syncs up all of this.
So, this is kind of a mess because the details of the investment are spread across many different apps. And certain kinds of seemingly simple things (like getting a portfolio valuation) become extremely difficult, as you need to ping every entity in your portfolio.
The Desired New Angel Investing Process, using Web3
Here is the desired new process and web3-enabled tech stack:
Send USDC from a wallet with your ENS address to the entity’s ENS address, and receive digital assets back into your wallet. These digital assets are
The key construct here is the idea of the mirrortable. Let's describe it in more detail.
Mirrortables and Mirrorshares
A mirrortable is a way to take a legally compliant cap table held in a system like Carta and mirror it on the blockchain. It consists of an on-chain smart contract and a bidirectional interface that syncs changes made on-chain to the off-chain cap table and vice versa. In this it is similar to a stablecoin, which similarly links an on-chain asset like USDC to a legally compliant set of off-chain USD bank accounts.
Because a given company usually keeps all their fundraising rounds within the confines of a single platform like Carta, that platform could easily write a mirrortable for a company’s cap table to the Ethereum blockchain and maintain it through the life of the company. Shareholders would then receive mirrorshares to their ENS addresses. Note that the off-chain cap table and associated legal documents would still be primary for legal purposes; they would still be the things that you used for compliance with the legal system. But the mirrortable would be what everyone used on a daily basis, due to its feature set.
In practice, it wouldn't just be one platform like Carta writing mirrortables for all companies, but also AngelList, Clerky, LTSE Equity, Pulley, and any other off-chain platform with a critical mass of private cap tables. All of them would be reading and writing mirrortables to the Ethereum blockchain, using it as a form of shared state. This is somewhat similar to how Coinbase, Binance, Kraken, and the like all read and write transactions to the Ethereum blockchain, but with one major difference: each platform would be creating mirrortables and their associated mirrorshares, not just moving pre-existing digital assets like ETH around.
Features of the Mirrortable
There are three parties involved in the operation of a mirrortable: the founder, the investor, and the platform like Carta which (a) maintains the bidirectional linkage between the off-chain cap table and the mirrortable and (b) provides the user interface to both founder and investor.
Using that terminology, here is what the mirrortable would give you from the perspective of an investor.
- Send to ENS. If you want to invest, the founder just sends you an ENS address to send money to (company.eth or perhaps companyseedround.eth)
- Confirm recipient. You can easily confirm that it is their address (company.eth), reducing the possibility of typos in routing number, wire number, or crypto address.
- Sign and wire. Signing and wiring become the same thing when sending from your ENS, so long as only you have access to the private keys.
- Confirm receipt. Both you and the founder can confirm they received the money by viewing the on-chain transaction on a block explorer like Etherscan, without needing to send a wire confirmation to a bank and do a trace.
- Handle compliance and KYC on-chain. If only accredited investors or people satisfying other compliance conditions can invest in the round, the platform can handle this in the mirrortable too. They can have each investor go through a KYC product like Jumio, and then use that product's KYC API to write the relevant verification to an ENS custom text record. The point is that each investor only has to go through KYC once so long as a given platform's mirrortable format works with that KYC provider.
- International applicability. Once you pass the KYC checks, you can in theory invest in any founder in any country using a mirrortable which honors that particular KYC provider. The founder can then use a local exchange to turn the received cryptocurrency into their local fiat. Note that this only handles the flow of funds; as with stablecoins, there may be other legal details to solve over time on the off-chain side. But the more jurisdictions that adopt something like Wyoming's DAO law, the more inter-jurisdictional compatibility there will be.
- Handles transfer restrictions and lockups. The founder can configure the smart contract for the mirrortable through the platform's interface to implement various kinds of restrictions in the on-chain mirrorshares. For example, it can allow or disallow asset transfers between entity names, allow them under certain conditions, or only allow vested assets to be transferred.
- Handles entities and individuals. The ENS name you send "from" is debiting from the entity’s wallet you are investing from. That is, if you have two wallets, where one holds myname.eth and the other holds myfund.eth, you don't need to remember which pocket you invested from, or whether it was a fund investment or personal investment.
- Social proof. You can see whether others actually have invested by looking at the other ENS addresses that have sent in funds, if this is a selling point for you. The founder can also prove that people have invested, which is helpful to them.
- Visible actions and deadlines. You can view the deadline to close the round in the mirrortable in a block explorer like Etherscan, if any. You can also get pings to your wallet from the mirrortable in the event you need to take some action with respect to your mirrorshares, like a shareholder vote.
- Exact share count and terms. You see the exact amount of shares you got in a given round, and what was issued in a new round, and when.
- Recordkeeping. The blockchain records the date you invested, what entity you invested out of, what stablecoin or asset you sent, where you sent it to, and so on. You can use that (provable!) on-chain information to pull related metadata, like the price of an asset at an exact time and date.
- Instant valuation. You can instantly compute your portfolio valuation with a loop over your digital wallet, no emails required.
- Contract updates. You can rely on founders to simply update the mirrortable when new terms come in. For example, if they issue new shares, or the price changes, this information is entered into the platform's interface and synced to the on-chain mirrortable. All digital wallets held by investors then see updated price and share count information for the corresponding mirrorshares, and can compute an updated fully diluted % ownership and asset valuation.
- Contract history. Contract details are also visible in a block explorer like Etherscan, as well as past versions, so you can see if and when the founders updated the price or made other edits to terms (eg via shareholder votes).
- Contract automation. Various complexities like lockup terms, liquidation waterfalls, preference stacks, and the like can be encoded in the mirrortable.
Producing a similar list of benefits for the founder and the platform (like Carta) is left as an exercise for the reader, but should be fairly self-evident.
The interface between fiat currency and cryptocurrency was a huge economic opportunity. Crypto exchanges are worth hundreds of billions and on pace to be worth a trillion. The interface between other pieces of the fiat system and the corresponding crypto system will be too. And one of those areas is the interface between fiat equity and crypto equity. That starts by taking online cap tables and putting them on-chain as mirrortables, automating the backend of angel investing by building an interface between web2 and web3.
Appendix A: FAQ
Just to address some points that came up on Twitter…
Is anyone already working on this?
The concept of the mirrortable and the full feature set outlined here is new to my knowledge, but there are several adjacent web3 projects like The LAO, Syndicate Protocol, Sign And Wire, and EthSign. And of course many of the web2 companies are adjacent to this problem, especially AngelList, Carta, Clerky, and LTSE Equity, as are all the major crypto exchanges including Coinbase.
I'm sure I've missed some, so let me know in Twitter DM.
Why doesn't this just centralize on one off-chain platform like Carta or AngelList?
Short answer: too much ongoing international legal complexity for one company to manage every cap table in the world. Also, lack of on-chain integration means mirrorshares can't be included later in smart contracts or programmed against like everything else on the Ethereum blockchain.
Longer answer: I think the best analogy is crypto exchanges. There are large crypto exchanges like Coinbase, Binance, and Kraken. But there are many small exchanges too worldwide. Each exchange provides an interface between fiat currency and cryptocurrency, between the legal system in the countries they operate and the blockchain systems with which they interoperate.
Similarly, if we are talking about all cap tables in the whole world, in every legal jurisdiction, no one entity appears likely to win the entire global market. There are so many entrants already — Carta, AngelList, LTSE Equity, Clerky, Shareworks, Pulley, and arguably Stripe Atlas in the US, Vestd in the UK, Ledgy for the EU, Toppeq, Qapita, and MyStartupEquity in India, and so on.
That last bit starts to give an intuition for why it'll be unlikely for one company to win a global monopoly on every cap table in the world. Too many different legal jurisdictions to keep up with. But a company can, say, reasonably focus on wrangling all the complexity of Indian corporate law and managing Indian cap tables on-chain via mirrortables.
There is an alternative approach, namely to ask every team in the world to do remote incorporation via a tool like Stripe Atlas to standardize on a Delaware C-corp, and then run that through one of the US tools. But this doesn't fully solve the problem, because founders are diverging away from Delaware to places like Wyoming, terms are becoming more complex in general, and foreign founders running a US company from abroad often need to have some kind of foreign parent for local compliance, which again brings in their local legal regime.
Oh, also, the number of cap tables will also likely explode because startup culture has gone global, and everyone becomes a "business, man" via personal incorporation. So in short, due to the ongoing increase in the number of startups, jurisdictions, complexity, and investors, cap table management is unlikely to centralize on one platform.
What happens if someone loses the keys to their ENS? Do they lose control of their securities?
There are various new technologies like social password recovery that are becoming more popular which will make inadvertent loss of private keys harder. With that said, the mirrortable has bidirectional syncing and it has an unapologetic root administrator of the contract: namely, the company itself. If need be, each company can annul any mirrorshares issued on-chain to a lost ENS address and re-issue them to a new ENS address, updating the off-chain records accordingly.
Why not just go fully on-chain right away?
To motivate the mirrortable, we need to introduce the concept of the primary and the mirror. Think about newspapers in the mid 90s. At that time, the primary was the physical newspaper and the mirror was a little website. Only a few articles were online. Gradually, over time, the newspaper’s website became more and more central. And new online-only things started to appear, like interactive charts, or integration with social media. Today it can fairly be said that the primary is the online newspaper, and the mirror is the physical paper — which is essentially just a printout of the newspaper’s website at a given time. But by gradually shifting weight between the primary and the mirror, it wasn't an overnight migration. There was time for technological feasibility and societal precedent to evolve. So too for the mirrortable.
What about privacy? Wouldn’t mirrortables make the cap table public?
If the founders want to keep their cap table private, the simple way of doing it would be for the platform to facilitate not a single visible ENS address like
company.eth but rather N different single purpose Ethereum wallets (
0x5250CF9B36bc15721A56a115e74c67Cc27753C05, ...), one for each investor.
Each of those N Ethereum wallets would be given to an individual investor to send USDC into. If they wanted to further protect their privacy, the investor could likewise set up a single purpose Ethereum wallet on their end, or perhaps use something like TornadoCash. Most crypto transactions are on-chain, including token sales, and privacy workarounds like this have proven sufficient for the last several years.
A more sophisticated way of doing it would be for the platform to permission the mirrortable with viewing keys, such that the cap table was visible on-chain to anyone with the right viewing key. And you could generate different versions of viewing keys for detailed cap tables, summary cap tables, and so on. You might even use some fancy zero knowledge stuff, though I think view keys should be sufficient for most purposes.
But…do you really need to keep the cap tables private? Many companies announce all the angel investors anyway in funding announcements. Many founders want to advertise their angel investors to provide social proof to raise rounds. Many investors would like a single canonical source to prove their portfolio, and link to in order to record all their disclosures. Many organizations like Crunchbase and CB Insights publish cap tables in partial form already, reporting that (say) a VC invested $30M and angels kicked in $5M. And S-1s eventually disclose exact share counts and terms.
So, fully private cap tables may not be a showstopper, at least for a v1, because the cap table ultimately does become transparent. Many folks would take the privacy tradeoff for the time savings that total automation of the system of record gives, especially if they have the partial workaround of single-use wallets.
What about updating cap tables and corporate documents in new rounds? Aren’t blockchains immutable?
Short answer: the social conventions around many Ethereum smart contracts are roughly on par with corporate documents — not completely immutable, but not casually mutable either, and highly visible when mutated. So, when a new round is raised, the founder updates the mirrortable parameters for things like share prices. And now all mirrorshare holders have a new number for their investment’s valuation.
Longer answer: People will argue about how immutable blockchains are. Early in its history, Bitcoin had an inflation bug that required an emergency soft fork. And Ethereum had the famous DAO hack in 2016. But for the last several years, both Bitcoin and Ethereum have been essentially immutable in the sense of no contentious developer-initiated soft forks for fund recovery. Parity, for example, was unable to gain community support for a hard fork to get back what is now billions in Ethereum.
So let's suppose Ethereum itself is immutable for our purposes. We can also add in some smart contracts like Augur v2 which have no admin keys. That kind of immutability is distinct from the infrequent mutability of smart contracts built atop Ethereum which retain admin keys. While people rightfully argue over whether admin keys should exist for defi contracts, and if so for how long, the presence of admin keys for maintainers of mirrortable smart contracts is a feature, not a bug. Because the off-chain cap table is still canonical, so if the mirrortable gets out of sync that admin key enables a fix.
Why is it important to scale the backend of angel investing?
Because it’s important for the decentralization of wealth creation. Why do people do $100M rounds in US-backed tech companies? Part of the reason is that it’s operationally hard to do 10,000 $10k investments in founders around the world while remaining legally compliant. 500 Startups and YC and AngelList have helped with this, but we can do far more if we go on-chain. The seeming unsexiness of automating the backend via mirrortables is key to helping the ascending world rise.
Why does this work legally?
Again, these start out as mirrorshares in a mirrortable. We aren't talking about issuing new digital assets here, just mirroring an off-chain cap table on-chain.
Docusign and Hellosign and Clerky and the like have all spent effort making sure their e-signatures and cap tables are legally binding, so the primary cap table and documents are still in your web2 system of record for a while. Eventually you want to get something like the Wyoming DAO law in place to allow for legal recognition of on-chain cap tables, just like we’ve gotten online cap tables recognized.
Why does this work socially?
The early users of web3 fall into two categories: the power users of money and the marginalized.
The power users of money are developers and investors. They are trying to solve a problem like “how do I send $10,000 to 100 people in 100 different countries in a week”. The marginalized are the unbanked, the unbankable, the deplatformed, and the international. They are trying to solve a problem like “how do I get a bank account and even become part of the global financial system.”
In different ways, both of these are pushing on the edges of the financial system. The backend automation described in this piece combines both, by allowing power users of money to invest directly in smart people in previously marginalized countries.
What about the SEC? Are you saying tokens are equity!?!11!?
First, as noted above, we’re talking about a mirrortable, an on-chain representation of a normal cap table. The shares represented in this table are mirrorshares, on-chain mirrors of normal shares in a paper company, not natively digital assets. It’s just like the relationship of USDC to USD, of on-chain stablecoins to merely online fiat currencies.
Second, tokens are not equity. They are more similar to API keys, as detailed in this piece from 2017 that I think mostly holds up well today.
Third, the internet has had a track record of legalizing and decriminalizing many forms of information transfer, and that will likely happen with value transfer too:
Fourth, crypto equities are a natural extension of cryptocurrencies. While it is ludicrous that we are still using orange groves and tulip bulbs to inform our discourse about blockchains, it is likely that we will eventually fully legalize on-chain issuance of equity. The stockchain will eventually cometh.
The reason is because technological progressives are winning the argument on crypto in places like Wyoming, Miami, Colorado, Texas, NYC, and El Salvador. And the obvious administrative simplicity that mirrortables afford will win the argument on non-ideological efficiency grounds. You don’t need to want to End the Fed to end the process of emailing 100 founders for a valuation update.
Could you do this on another chain?
Yes. We've assumed Ethereum herein, but there are many aspects of this that can be varied. You could do it on Solana rather than Ethereum, using the Solana Name Service, USDC-SPL, and so on. You could do it on another L1 chain. You could try to do it with one of the Bitcoin-only smart contract services, like Rootstock, which is a forked version of the Ethereum Virtual Machine and thus compatible with Ethereum smart contracts. And you could send BTC or ETH rather than a stablecoin like USDC. But you get the gist.
How might this work with a web3-first approach?
What we’ve described above is a web2-first approach, where you start with a working web2 product like Carta or AngelList and then interface with the blockchain via a mirrortable.
A web3-first approach might start with an ENS-based social network for angel investors and founders, where the primary social action was just investing in each other. Group chats could contain everyone who invested in a given company. I think this kind of web3 social network could start out with a small group of investors and founders, and then get surprisingly big if you could figure out a way to reduce the minimum amount someone could invest, bringing it down to $100 or $1000, as republic.co has done. Perhaps this could be done via automated setup of special purpose vehicles (SPVs) or something similar.
Appendix B: Definitions
Angel investing. An angel investor is an individual who invests in startups, often as a serious hobby while doing something else, like being a CEO. An angel investor is not a professional venture capitalist (VC), who usually works at a firm that has raised money from outside investors. As individuals, angels move faster and write smaller checks than VCs. However, many of the concepts from this article are also applicable to VCs, though these reforms will likely initially be adopted by flexible individuals before moving to more formal institutional VCs.
Capitalization tables. A capitalization table, or cap table for short, is the record of who owns what securities in a company. It's basically a giant spreadsheet where rows are shareholders and columns are securities. The cap table is in a sense the most important data structure in technology, because it determines things like who gets what money when in the event of an exit (via the liquidation waterfall) and who has what say in important corporate decisions (via shareholder votes). Here's a visual of what a cap table looks like.
Carta and cap table software. Historically, despite their importance, cap tables were managed via manual updates to Excel files held at the offices of a company's law firm. Even though broken cap tables could affect the fate of millions or even billions of dollars, there wasn't a lot of technology put into maintaining them. That has changed with the advent of web2 platforms like Carta, which manage cap tables online. Here's a visual of what that looks like.
Smart contract. A smart contract is a piece of code that runs on a programmable blockchain like Ethereum. It generalizes what can be done on a blockchain from simple debits and credits of a digital asset to small but real programs that can manage things like loans, or any valuable asset.
ENS. The Ethereum Name System, or ENS for short, is a sophisticated smart contract that gives human readable names for Ethereum addresses. If you know how the Domain Name System (DNS) works, we replace a hard-to-remember numerical IP address like 184.108.40.206 with a human readable website address like balajis.com. ENS works similarly, where we replace a hard-to-remember Ethereum address like 0x0916C04994849c676ab2667Ce5bbDF7CcC94310a with a human-readable address like balajis.eth. ENS simplifies payments, but it does much more than that. It consolidates usernames, domain names, logins, social profiles, and many other kinds of functions.
USDC. Cryptocurrencies are known for their volatility. Stablecoins are a way to get all the programmability benefits of cryptocurrency with the (relative) stability of fiat currency. They are basically a way to represent a dollar or another fiat currency on-chain. USDC is a very popular stablecoin, which we launched at Coinbase with Circle in 2018 via the CENTRE consortium. The design is simple: every US dollar represented on chain is backed by dollar-denominated assets of at least equal fair value to the USDC in circulation, in segregated accounts with US regulated financial institutions. So, with USDC you can send and receive dollars just as easily as you can send and receive Bitcoin or Ethereum. It is thus a mirror of the existing system that handles billions in transactions per week. And we can extend this concept to go from mirroring off-chain currencies via stablecoins to mirroring off-chain cap tables via mirrortables.