The computer science case for web3

Software systems live and die by their underlying data structures¹. Good data structures are a force multiplier giving 100x gains in output. Poor data structures will doom your company. If you don’t believe me, ask Steve Jobs why dumped billions into migrating Apple to Unix. Or ask AltaVista how it turned out pitting OracleDB and Solr Search against Google’s BigTable.

If you’re not a computer scientist, you are not sensitive to the differences between competing data structures. Data structures are abstractions upon abstractions, and a linked list sounds as good as a hash table. You don’t care about this topic.

But you should. Understanding data structures was how I knew Ethereum was going to be a success, distinct from dozens of altcoins at the time. Ethereum made only one significant change to bitcoin’s data structures: it switched from a stack based data structure to a Turring complete data structure. Everything else was noise, but this single change unlocked $100 of billions in value.

Today, my thesis on DeFi is based on the same logic. The data structures used in the traditional financial system are fundamentally flawed and meet the requirements of digital finance. Refactoring the legacy system is too labor intensive. In contrast, a blockchain based system with a single shared virtual machine is the correct foundation for digital finance. As a consequence of this superiority, a huge transfer of economic activity will take place from traditional finance to a web3 system in DeFi. Investors and entrepreneurs are well positioned to profit from this transition.

Yes, it’s a technology problem

I’ve talked to finance industry veterans about web3, and the skeptics usually tell me: “You don’t understand. This is not a technology problem. It’s a political problem.” Or a regulation problem, or a legal problem.

They are wrong. Technology and law are in a two way interaction. Sometimes, law impose restrictions on technology. Other times, new technology upends law, and imposes its will. It depends on the technology, and the law.

Encryption was a munitions problem until RSA made it a technology problem. Copyright was a legal problem until Napster made it a technology problem. World War II was a military problem until the atomic bomb made it a technology problem.

Bitcoin changed finance, and it’s a technology problem now.

Traditional finance is a weak technology, with little or nothing to offer in the way of data structures. This is why it is so easily controlled by the law. Anyone from a finance background is primed to assume that all technology is so easily controlled, but they are wrong. They are biased by their past experience.

Kludges all the way down

The legacy financial system is built on a flawed foundation, so how does it even work? Insofar as it does, it’s because of millions of man-hours invested into hacks and kludges that address very specific use cases.

Example: it takes three (!) days for a stock sale transaction to settle, and in that time you cannot spend the proceeds from the stock sale. Robinhood implemented a kludge fix to this by turning all accounts into margin accounts, and lending you money equal to the pending sale that you can use for new stock purchases. This fixes the user’s problem of “I want to sell a stock Apple and buy Tesla on the same day,”, but it’s a Leaky Abstraction. You still can’t withdraw the money for three days, and the feature interacts with real margin in unexpected ways.

Let's look at the specific flaws in the legacy system.

Flaw #1: Not respecting DRY principle

“DRY” in computer science stands for “Don’t Repeat Yourself.” It means don’t copy and paste your code. When you have two identical workflows, you should use the same code in both cases. This is more maintainable: make a fix once, and it applies to both places. If you find a third workflow that’s also identical, you just add it in with the other two. Engineers constantly change and rework their code to reduce repetition to get a force multiplier on their productivity.

Traditional finance does the opposite. If you want to trade foreign currencies, you do it on a foreign exchange market. If you want to trade stocks, you do it on a stock exchange. This is incorrect. Currencies and stocks are both fungible tokens. They should be traded on the same exchange.

Ethereum correctly treats all fungible tokens identically, as ERC-20 tokens. Dollars and euros and DOGE all trade the same on Uniswap.

Flaw #2: Siloed and inconsistent ledgers

By default, a TradFi ledger is visible to your bank, the government, and no one else. Each bank maintains its own ledger, and transaction ordering is not consistent across those ledgers. 

While this is good for privacy, it’s a flaw for transacting efficiently.

The simplest example is when I pay you: if I write you a paper check, how do you know I have money in my account to pay you? You don’t. The check could bounce, and you don’t get paid.

Another example: if you have ever bought a house, you paid for title insurance. Title insurance protects against unknown liens or claims on the house. Perhaps the previous owner used the house to secure a bail bond, or there is a distant cousin who has an inheritance claim on the house. All these claims are on separate private ledgers, and there’s no easy way in traditional finance to reconcile them. Kludges like title insurance and the statute of limitations lessen the pain, but they don’t fix the fundamental flaws in the system.

Generally speaking, reconciling private ledgers is time consuming and inefficient. How do you find all the ledgers? What if someone keeps a ledger secret until an opportune time? The data structures in traditional finance offer no solutions.

In contrast, a blockchain based system is easily reconciled and always consistent. For any asset, you can scan the entire history of the blockchain and discover any encumbrances. If a specific allocation of ETH is subject to liquidation in a loan, you will see it on the public blockchain. Anything outside the blockchain is null and void.

Flaw #3: Non-atomic transactions

Transactions in traditional finance are default non-atomic. While each bank and exchange has its own internal ordering scheme, there is no mechanism for atomic transactions across institutions. There is no way to perform transaction A with exchange X, and then perform transaction B with bank Y, with a guarantee that A happens exactly after B, and only if A clears.

Atomic transactions are a necessity for digital finance. If I’m selling an asset, I want to transfer it to you if, and only if, I receive the payment.

As usual a few use-case specific kludges exist in TradFi. A mortgage is an atomic transaction for both a sale and a loan. But there is no general system for atomic transactions across two institutions, let alone three or four.

In blockchain transactions are consistently ordered, each transaction executes atomically, and can interact in this atomic fashion across multiple institutions.

Flaw #4: Non-bearer instruments

The only bearer instruments in the traditional financial system are paper money and gold. Everything else is custodial. My balances are nothing but promises.

Like the previous flaw, this has advantages. If it's not a bearer instrument, I don’t have responsibility for its safety. Suppose a hacker drains my E-Trade account and transfers all my shares into his. I can call up E-Trade, and ask them to reverse the transaction. The shares are in their custody, and they reverse transactions at their discretion.

This custodial model comes at a large cost. Satoshi can explains it in his whitepaper:

While the [custodial] system works well enough for most transactions, it still suffers from the inherent weaknesses of the trust based model. Completely non-reversible transactions are not really possible, since financial institutions cannot avoid mediating disputes. The cost of mediation increases transaction costs, limiting the minimum practical transaction size and cutting off the possibility for small casual transactions, and there is a broader cost in the loss of ability to make non-reversible payments for nonreversible services.

Satoshi was thinking about microtransactions when he wrote this, but it applies doubly to DeFi. How can I wrap an option on top of a futures transaction, if the underlying asset may be pulled out under me? If a financial system is a tower, the strength of the tower is defined by weakest link.

In contrast to TradFi, a blockchain based system is a default bearer instrument. Possession of the private keys for an account is possession of the related assets. This comes at a cost (bring your own security), but also huge benefit: transactions settle with certainty.

Custodial instruments can be built on top of a bearer system, but not vice versa.

Flaw #5: Gated APIs

If bearer instruments are the backbone of an electronic financial system, APIs are the blood. Computers communicate through APIs, and access to open APIs is necessary for hackers to start new apps.

The APIs available in TradFi are 100x worse than DeFi. This is not an exaggeration, and it is no crypto boosting. This is an objective fact.

The first major flaw in TradFi APIs is that they are gated. You can only use these APIs at the permission and pleasure of the counterparty. The API provider can terminate your access at any time, disrupting and potentially kill your startup.

Plaid and Stripe are the state of the art in terms of TradFi APIs. Getting production access in Plaid.com has a one day turnaround, is subject to compliance review, and is subject to their terms of service. Stripe is similar.

Below are excerpts from each of their Terms of Service:

Client will not…attempt to discover the source code, object code, or underlying structure, ideas, or algorithms of the Services

You certify that you, your officers, directors, shareholders, direct and indirect parent entities, subsidiaries, and affiliates… remain in compliance with all applicable import, re-import, sanctions, anti-boycott, export, and re-export control laws and regulations

You agree not to…scan or test (manually or in an automated fashion) the vulnerability of any Plaid infrastructure without express prior written permission from Plaid

You agree not to…modify, translate, or otherwise create derivative works of any part of the Services

You may not use the API for any purpose, function, or feature not described in the Documentation or otherwise communicated to you by us

Not establish minimum or maximum amounts… or condition Charges for use of payment cards, and not discourage the use of one payment card brand over another

You authorize Stripe to provide any Data… to Wells Fargo

Their API terms of services are dozens of pages each. Check them out.

In contrast, blockchain based systems are default open for all APIs access. Setting up an account takes seconds: you just make a private key. You are welcome to any API calls allowed under the rules of the system. Unlike Plaid, you are welcome to scan for security vulnerabilities. There are no authorized or non-authorized use cases, only individual accounts asserting their terms of participation in the system.

Open access is critical for an innovative financial system. Founders and hackers are outsiders with different ideas from insiders. When access is gated by insiders, it excludes innovation from outsiders with new ideas.

If you’re an investor, which system would you bet on: one openly invites hackers from around the world, or one that gates access based on your use case and region?

Flaw #6: Use case specific APIs

Supposing you get past the first flaw in TradFi APIs, you will be hit by the second: the APIs are use case specific. You can never reach under the hood.

This is bad for practical reasons. You can only use Stripe in ways that Stripe has thought of. You can only access Bank of America in ways that Bank of America has thought of. Thus, hackers and founders are limited to ideas that were invented by corporate workers and big tech employees. If you want to recombine financial asset primitives in a new way, it is impossible. It only becomes possible once Stripe or Bank of America thinks of it and deploys it globally to all their customers. Not a great position for a startup.

This is also bad for philosophical reasons. The best hackers always want to look under the hood and break assumptions. A hacker sees a computer and thinks, “Ok, but how does it get the dots on the screen.” Hackers want to break down the abstractions, look at the building blocks, and recombine them in new ways. Not only is this prohibited by the terms of service, it’s impossible. All the APIs are pre-selected and pre-approved.

A blockchain based system is the opposite. Instead of starting with use case APIs, it starts with the building blocks. Bitcoin actually doesn’t have a way to send money. It has a way to sign messages, verify signatures, and perform arithmetic. Ethereum doesn’t have a way to lend money, it has a way to execute bytecode operations on a shared virtual machine.

You can build use cases on top of building blocks. You can’t make building blocks out of use cases.

Flaw #7: Regional variation

The traditional financial system is subject to regional variation. Stripe is available to 47 countries in a world of over 200. Their global map has half the world in the dark. Plaid is available in 7 countries, and lists more countries as coming soon than they list as active. API availability varies between countries.

This regional variation is not because Stripe and Plaid suck, but because they are patching a broken foundation. The regional variation accurately reflects two realities of traditional finance: variation in legal jurisdictions, and variation in APIs across regions.

Different legal jurisdictions vary in how they implement banking laws. Some countries are in treaty with the United States for KYC and AML, some are not. Some tightly control the flow of capital in and out of their banking system. Political disputes can upend the status quo. Any startup building in this environment is subject to whims of politicians they cannot control or understand.

API variation across regions is a reflection of the previous flaws. Because APIs are use case specific, they vary from country to country. The use cases allowed and implemented by Russian banks will differ from those allowed and implemented by Nigerian banks. Even if they converge on the same uses cases, the implementation will vary in some details. Refer again to the Law of Leaky Abstrations. No matter how hard they try, the engineers in big tech will never make a unified consistent global API for even the most basic financial transactions.

Compare this to the blockchain: no matter where you are, who you are, the exact same API is available 24/7.

Objective comparison

Consider two financial systems.

The first system operates in private silos for each institution. It is based on trust between transacting parties with adversarial interests. Its digital API is limited to specific use cases, and is accessible only to approved parties. It is only available in a minority of countries, to a minority of the population, with inconsistencies across legal boundaries.

The second system is default public, and default open to all. Its foundational layer is based on trust in an algorithm rather than trust between counterparties. Its APIs make building blocks available. Its APIs are globally accessible and globally uniform.

Which one would you pick for your financial system and your startup?

1.  Computer scientists will notice that I’m using the term “data structure” in a broad sense, and as a synonym for “system architecture” or “system design”.