The Mirrortable

Mirrortables are to cap tables what stablecoins are to fiat currencies. They streamline and internationalize the logistical mess of angel investing.

The mirrortable is an on-chain representation of a traditional capitalization table. A mirrortable is to a cap table what a stablecoin is to a fiat currency.

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.

The Problem

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:

1. Meet a founder.

2. Talk to them via email or one of many chat apps, like Twitter DM, WhatsApp, Telegram, or Signal.

3. They email docs.

4. Review those docs: a vanilla SAFE, a token sale, an advisory contract, or something more exotic.

5. Sign those docs via Docusign or Hellosign, or sometimes print, sign, and scan.

6. Download the countersigned, timestamped PDF and put it into a giant investing spreadsheet in Google Sheets or Notion.

7. Get their wire info.

8. Initiate the wire, which is actually a bit of a hassle.

9. Sometimes, for countries like India, go through an interminable KYC process.

10. Confirm they received the wire.

11. 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.

12. Also, you need to periodically email them to get valuation numbers, which is a pain for all parties involved as it’s like emailing Coinbase to find out the value of each coin.

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?

1. 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.

2. Shared inbox. A shared inbox with a huge email queue, like a shared Gmail address or front.com.

3. 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.

4. Giant spreadsheet. A giant spreadsheet with one row per deal and many columns, like Google Sheets + Google Drive, or Notion.

5. Shared bank account. A bank account to wire from, often a startup bank like Mercury Bank or Arival.

6. 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.

7. 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.

8. 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 mirror assets logged in an on-chain cap table we call the mirrortable. The primary cap table is maintained in an off-chain system like Carta for compliance purposes.  And the entity periodically updates their smart contract as new rounds are raised, so you always know the value and terms of your assets.

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.

1. 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)

2. 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.

3. 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.

4. 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.

5. 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. (More detail in the FAQ!)

6. 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.

7. 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.

8. 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.

9. 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.

10. 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.

11. 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.

12. 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.

13. Instant valuation. You can instantly compute your portfolio valuation with a loop over your digital wallet, no emails required.

14. 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.

15. 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).

16. Contract automation. Various complexities like lockup terms, liquidation waterfalls, preference stacks, and the like can be encoded in the mirrortable.

17. Backwards legal compatibility. Unlike most proposals for security tokens, mirrortables don't require any changes to the law because they are riding on top of compliant web2 cap table platforms. It's just like an Ethereum API to an existing platform. See FAQ for more details.

Producing a similar list of benefits for the founder, the employees, the other shareholders, and the platform (like Carta) is left as an exercise for the reader, but should be fairly self-evident.

Conclusion

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…

What teams are 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 startups & web3 projects like The LAO, Syndicate Protocol, Sign And Wire, PartyRound, Fairmint, 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.

No, really, why not just go fully on-chain right away? Use tokens not equity, use DAOs not companies, completely exit the legacy system!

Of course, this is also a reasonable approach. Purely on-chain things are great too. We wouldn't be here without them.

But think about how important stablecoins are. They are a wildly popular bridge between off-chain fiat currencies and the on-chain environment. Billions in transactions per day.

And think about how important exchanges like Coinbase are. They are a wildly popular bridge between the legacy banking system and the cryptoeconomy. Worth easily >$100B in cumulative valuation today, if you just sum Coinbase, Kraken, FTX, and Binance, with plenty of room ahead.

This is a general theme: the fiat-to-crypto bridge is underestimated because people tend to be either 100% pure fiat, or 100% pure crypto, but it's often where all the value is. You need to take the right approach, though: enterprise blockchain and security tokens and the original DAO were hybrids that didn't work, because they went either too fiat ("pass a law first") or too crypto ("automate and decentralize everything").

You mention security tokens. How are these different from security tokens? Do they require changing the law?

Short answer: unlike security tokens, the mirrortable approach is set up to require zero legal changes in any jurisdiction. So long as you have an already legally compliant off-chain platform like Carta that generates all necessary documents and signatures for each off-chain cap table update, you just mirror that on-chain. Regulators should not care about the introduction of an on-chain mirrortable, as it's just a convenience function for Carta's customers. In a sense, it's like adding an Ethereum API, or a mobile client. The existing legally compliant process remains unchanged.

Longer answer: There were many different approaches to security tokens starting in the mid/late 2010s, but most of them started with the goal of "let's change the legal system". That actually did work in places like Wyoming and El Salvador and Miami, but it took years and enormous on-chain traction before the off-chain world responded. And that kind of technologically progressive reform is still on the edges of the system. It's growing, but still at the subnational and international levels, at the level of US states and cities, and small countries like El Salvador.

Thus, much of the art is figuring out how to first achieve as much traction as possible without changes to the legal system, and to then periodically knock on the legal system's door each quarter in a hundred countries and a thousand cities, graphs in hand, showing how much traction we have. Then one city or country flips, decides to take a risk, and changes their mind. We show benefit in that city or country, the cryptoeconomy gets even more traction, and that precedent can be used in yet more jurisdictions.

This is the motivation behind the mirrortable approach. It's accepting the existing legal system in each country as-is, and counting on the Cartas and Clerkys and Angellists of the world to handle off-chain compliance. The combination of their efforts worldwide will demonstrate the massive operational efficiency improvements granted by mirrortables. We should see the time to get a portfolio valuation reduced by 1000X, the time spent doing KYC reduced by 10X, and so on. It's just like digitizing any formerly paper-jammed process. And with those traction graphs, we can provide evidence as to why fully on-chain equity should be legalized.

To summarize: unlike security tokens, we can do mirrortables without changing the law. We remain compliant with the law, establish efficiency improvements, and then appeal to change the law.

What about KYC? How do you do on-chain KYC for mirrortables?

Short answer: we can put KYC on-chain with ENS custom records and a KYC API like Jumio.

Long answer: first, you need to understand a bit about ENS. The thing about ENS is that it merges features of domain names with open social network profiles, as you can see from looking at brantly.eth. The particular feature we'll use for on-chain KYC are ENS custom records, which allow any site to define custom fields on individuals. We'll be using that for recording on-chain KYC information. Here's a visual of how they work (click here https://balajis.ghost.io/content/images/2021/12/ens-custom-text-record.gif if gif isn’t rendering).

With that as preliminary, I mentioned this in point 5 above, but here's a little more detail on how the KYC process for mirrortables would work.

• Investor logs into a platform like Carta with their ENS name, so they log in as alice.eth

• Carta asks them to complete KYC, using an API like Jumio

• Here's the magic. Jumio (or Carta on behalf of Jumio) then writes that API confirmation to the Ethereum blockchain using ENS custom records. The syntax likely varies, but conceptually the key three fields are something like this:

us_accredited_investor.jumio.alice.eth = true

accreditation_date.jumio.alice.eth = "Nov 12, 2021"

signature_to_confirm_with_jumio.jumio.alice.eth = "SbX_t_4Bp..."

• Now anyone who looks at alice.eth's ENS record in a block explorer will see that Jumio is testifying that (a) alice.eth is an accredited investor, (b) that accreditation was valid as of Nov 12, 2021 and (c) if anyone doubts this, Jumio wrote an on-chain hash that you could put into a Jumio.com API that would confirm that Jumio indeed wrote that data (vs an impostor).

• And, any other mirrortable online maintained by AngelList or Clerky can accept this Jumio KYC, so the investor need not do KYC over and over again.

There are many variations on this basic concept.

• You could probably make it possible for jumio.eth to somehow sign that ENS custom record, obviating any off-chain verification step.

• You would probably represent the accreditation date as an ISO 8601 timestamp, not a string.

• You might need to reverify after an accreditation gets stale, perhaps once a year.

• You would likely have more than three fields in a production system. Or you could compress into something very compact to save blockspace.

• You would have more verification complexity if Carta was writing this on behalf of Jumio, something where both carta.eth and jumio.eth would need to sign.

And so on. But the point is that after you do KYC once, that KYC is logged with your consent in an on-chain ENS record, which you can use to log in elsewhere. This solves the problem of international KYC for angel investing. Write once, invest anywhere.

OK, that's how we deal with KYC. But can we really treat an on-chain transaction as equivalent to an off-chain signature?

So, there are two scenarios here. Worst case, the platform's UX makes you click an embedded Docusign at the same time you are sending the USDC. Not the end of the world, a little more clunky.

But ideally, sending from yourname.eth is considered logically, technologically, and legally equivalent identical to clicking a Docusign sent to you@yourname.com. Why? Because you can establish bidirectional equivalence between an ENS name and an email address as follows.

a) Show that the ENS name controls an email address. Within an ENS record, you can set an email address. A concrete example is for brantly.eth as shown below.

b) Show that an email address controls an ENS name. Conversely, you can send an email to a given email address with a link such that the person with the password to that email could verify control over the ENS name, similar to how DNS contact verification works. A concrete example is shown from dnsimple.com below.

If you know basic logic, when you show that x → y and y → x, you have established that x ↔ y. That is, if the person who controls the ENS name can put the email address in their ENS, and if the person who controls the email address will click a link confirming that they control the ENS name, then you can infer that the same entity controls both (a) the private keys to the ENS name and (b) the password to the email address.

So, if clicking a link sent to that email is a legally binding e-signature, then sending a digitally signed message from that ENS along with the funds should count. You could also do a separate digital signature out of band if you wanted. Indeed, digital signatures on Ethereum are arguably more rigorous than the already legally binding e-signature process, because control of the private keys is true control of funds in the wallet containing that ENS...not just possible indirect control via control of an email address.

Ok, that's the logical and technological argument for equivalence. You need lawyers to bless that as a legal argument, and a sufficiently enlightened judge in the event of an issue, but it's not that much of a stretch.

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 (0xc92f8366730aFd730770f7BDA05D3a377d52b1D0 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.

Conversely, could mirrortables actually be better for employees? Open cap tables (with some privacy protections) may give them more insight into their compensation.

Why yes, I'm glad you asked. See the thread below.

As context, the current process of making money as a startup employee from equity is fraught with a variety of pitfalls, as detailed in Zach Holman's excellent Guide to Equity Compensation. Various tools for modeling exercise strategies have come up, but simply putting cap tables on-chain could make the value proposition for employees far more transparent. Right now they often don't know what common stock is, their percentage ownership, the full set of liquidation preferences, and so on. There's an argument for taking the hit and just putting this into public view, like doing an S-1 early on. Buffer.com and Gumroad are similarly doing open board meetings. Feels like it could be a trend.

You'd still want some way to protect employee financial privacy, so you might make stock awards to pseudonyms or something like that. As per the previous FAQ, viewing keys and zero knowledge could come in handy here.

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!?

No 🙄

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.

In subsequent rounds, do you need to alter the mirrortable's smart contract or merely its state?

This is an implementation decision.

As much as possible, you want to just update parameters in the mirrortable smart contract — like the price per share, the number of shares, and things like that. That's usually better than upgrading the contract itself.

However, as you do more and more mirrortables, and companies grow from clean seed stage deals (that all look the same) to later stage entities with complicated capital structures (which all look different), you will likely need to update the mirrortable smart contract to accommodate things like warrants and other kinds of company-issued securities.

Eventually you'd end up with a sophisticated mirrortable library with many modules for handling the parts of corporate law relevant to tech financings and exits. Because this library would be on-chain, it could be used and improved by people in many countries. Eventually, by 2030 or so, that mirrortable library might be a global compatibility layer for the US, UK, India, and other legal systems. Similar to how Skype and then WhatsApp made international internet telephony "just work".

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 151.101.3.7 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.