The Graveyard of dApps

This Halloween 2024, I’m opening the “dApps” I used in 2021. And it is really scary: Domain expired. Deployment suspended. Page not found. Service unavailable.

Wait a minute. These were supposed to be dApps — decentralized apps. Apps that don’t depend on centralized entities, apps that are free (as in beer), free (as in speech) and censorship-resistant. Apps that make web3 The New Internet.

These apps are all dead. OK, not all, but most of the ones that I used two years ago. Their ghosts still live somewhere on the blockchain. If only you could find the right contract address and guess the magic calldata spell.

Why does it happen? Where did things go wrong? What can we do?

Let’s look at the ancient scrolls we found from the prehistoric times (2016).

“dApp” stands for “Decentralized App”. It’s the idea that you can make a web application (using open technologies like HTML/CSS/JS) and host it on a decentralized and permissionless infrastructure (like IPFS). The dApp talks to the blockchain through your wallet. You can get the latest data and send transactions without relying on centralized companies.

This makes the dApps practically unstoppable. Free, permissionless, decentralized. The real dream of the real punks.

But most people don’t care about decentralization and permissionlessness. They want the app to be useful (and the number to go up).

The web3 devs quickly realized that they are fighting for user attention against beautifully crafted, fast and sexy web2 apps on web2 territory where the decentralization doesn’t give them much.

Nerds who understand the details know that blockchain is a real paradigm shift. But everything on the blockchain is “open source”, it can be forked, and thus it becomes a commodity. There’s no moat. Anyone can deploy Uniswap contracts anywhere. Heck, anyone can deploy their own L2!

The real differentiation is in the brand, distribution, network effects, and in user experience. Among billions of Uniswap deployments users are going to pick the ones they trust (brand), the ones they can reach easily (distribution), the ones other people are using (network) and the ones that look good (UX).

I mentioned the UX last, but it’s not the least important. Bad UX hurts. Every e-commerce store owner knows that they’ll lose 10% of users for every 100ms of latency. You can’t build a premium brand on shitty UX. You can’t retain users if your app is annoying to use.

But even if most users don’t care about decentralization, the true crypto punks still do. Not in a “everybody should be a decentralization maxi” way, but “because it’s the right thing to do”. It gives people power and agency even when the centralized entity becomes hostile or censored.

Here’s a pickle. Making sufficiently decentralized apps with good UX is hard. But it’s hard for the wrong reasons. It’s hard because we (the developers) got lazy.

Let’s look at a typical “dApp” today, and the pieces of technology it relies on. I’ll roast my own creation — BasePaint. In some way, it should be a “web3 dApp”: it uses blockchain (Base L2) and relies on user wallet to interact with it. But it’s not enough to provide a good UX, so I had to add some non-decentralized stuff. A lot of it, actually.

Here’s a list of centralized tech I had to use:

• Domain name. I want people to easily find us and access the website. Browsers don’t support ENS, so I had to purchase a domain name from a domain name registrar and configure DNS to point to the right place.

• Hosting. I need to put the app (my HTML/CSS/JS files) somewhere. And that somewhere should be fast and accessible. IPFS is appealing, but most browsers don’t support IPFS, the gateways are slow and URLs are not user-friendly (ever tried to type QmRxM6Fz3jYBNLTNn59Whtj8uiFodC53Z5nEep6eSkwf8Von your phone?)

• Database. Blockchain is a great database for some things, but it’s not practical for all cases. For example, we store chat messages in a Postgres database instance because it’s much cheaper and faster to do. We could try to put it onchain, but this will never be faster than centralized database.

• Backend. BasePaint also does a bunch of computations that don’t fit Ethereum. For example, generating videos, synchronizing cursors of other people who are on the site at the same time, checking permissions to access chat, etc. Also, we need to keep some secrets, well, secret (e.g. database connection credentials, private tokens, etc.)

• Ethereum JSON-RPC Provider. In theory, we could use user’s wallet to access blockchain. But this means people who don’t have a “web3-enabled” browser can’t see anything. What’s even worse, every wallet RPC provider is different from others in subtle ways. For example, QuickNode limits logs queries to 10k entries, Alchemy computes request limits using their own compute units, etc. Using wallet’s RPC means dealing with all these subtle differences.

• Indexer. It’s expensive to store things on the blockchain. BasePaint gets around it by not storing the pixels in contract storage. Instead, it emits Painted events with all the necessary data. You could reconstruct any canvas by querying the smart contract events. But imagine doing this for the BasePaint Gallery page (where we display hundreds of canvases!). To make this UX smooth, we run an indexer that keeps track of blockchain events and stores data in a way that’s easy for us to query quickly.

• Other Services. We use Reservoir for secondary markets data and cross-chain minting, Cloudflare as CDN, R2 for video storage and cache, DataDog for logging, PostHog for analytics, Neynar for looking up Farcaster users’ wallet addresses. Every such service saves us weeks or months of engineering time, but makes our app less decentralized. On top of that, many tools don’t have sustainable business models, so they can shut down any moment.

• Credit Card. This one always cracks me up. Did you know you can’t pay for most crypto SaaS products with crypto? When my credit card runs out of funds or expires, my domains, databases, servers, RPC endpoints and other SaaS products will be taken offline.

As a web3 developer today, here are the options I see:

1. Ditch centralized tech and build a hardcore dApp that only depends on decentralized services. Maybe it’s viable for things like Tornado Cash, but for a consumer product it means a UX handicap that will deter most users.

2. Keep the centralized app and build a separate minimal dApp that only depends on decentralized tech stack. This means maintaining two separate apps. Double engineering effort, double the cost.

3. Embrace “progressive enhancement”. Start with a minimalistic dApp, but if the server is available, lean in and make things faster. This depends on a great deal of discipline and doesn’t save too much time vs option 2.

4. Open source the code and let users run it (this is the direction we picked). In practice though, just booting up that stack requires non-trivial software engineering chops. It’s orders of magnitude more complicated than loading a page from IPFS.

All options require considerable effort. It’s not the default. Look at any dApp tutorial or template, none of them even raise these questions.

It doesn’t have to be this hard. Making dApps should be easy. What if we push the complexity down into the infrastructure layer?

We could try to address decentralization on the infrastructure level. Add ENS support to getaddrinfo. Make all browsers natively understand IPFS. Make IPFS as fast as state of the art CDNs. Evolve Ethereum’s JSON-RPC to make it more useful for dApps. But these are the easy parts.

To replace centralized databases and servers we’d need to figure a whole bunch of tech that doesn’t exist today. Maybe some ZK-powered distributed compute that gets rewarded for running our code, a megabrain Ethereum that efficiently executes general purpose x86 instructions.

We’ll also need to figure out a decentralized solution for all the services that are built around crypto. We’ll have to come up with new incentives — who will pay for all that compute? Current SaaS business models won’t work in truly decentralized system. (But hopefully the fees for using these services can be paid with native crypto and don’t require a credit card.)

On top of all that, we’d have to make the Development Experience of this new way at least as good as the DX of centralized platforms. The platforms that have spent billions of dollars worth of engineering time to polish things up, and just as much in marketing budget to fill internet with tutorials to convince everyone that their solution is the best.

Your scientists were so preoccupied with whether or not they could, they didn't stop to think if they should — Jurassic Park

But does the app layer have to be decentralized?

Nouns have shown us that maybe blockchain decentralization is enough. Nouns have a thriving ecosystem of apps that all talk to the same contracts. You can cast you votes via Camp, or via Agora, it doesn’t matter. Pick the interface you like.

Most likely, to reach billions of users, crypto will have to become a well shaped building block that fits the existing systems. This means that the ideal crypto experience is when users don’t even know they are using crypto, it’s so abstracted away that it doesn’t matter. Tap your phone — get your coffee, who cares if it was USDC or Visa network.

The market has already found the local optimum:

• The fundamental layer (blockchain) is decentralized. It secures trillions of dollars worth of value. It provides strong primitives for ownership and censorship resistance.

• The app layer is centralized. Companies build centralized apps that give users the best UX. Their closed source systems create moat against competition. But they still talk to the same blockchain.

I just wish this equilibrium was shifted a little bit more to the decentralized side. I wish it was easy to run my own version of Nouns Camp (or Agora) locally, as easy as clicking a link. I wish we had the tools for making these decentralized apps easy to build, all without compromising the user experience.

BasePaint has blown mind. It’s a self-sustaining ecosystem: artists make arts, collectors pay for it and profit on secondary, owners have voting power to influence what happens every day. This works, we’ve distributed more than a million dollars to creators this way.

The weakest link of it all is us, the team. It requires considerable effort to keep the app maintained. Bugs fixed. UX improved. And it also requires effort to try to make things more decentralized. Make the app easier to self-host. Give up permissions instead of gatekeeping them.

Maybe there’s no way around it. If an app is important enough, people will find ways to keep it running. If nobody cares, it dies. It’s just that the bar for caring is really high today.

The dApps are dead. The benefits of “decentralized” is just not something the users care about (yet), and the punks have to adjust. We stopped building tools for making our apps decentralized.

Fortunately, the underlying infrastructure is stronger than ever. Better fundamentals, exciting roadmap. We actually have a shot at building a global computer.

Unfortunately, nobody is talking about making the user interface part of this story just as strong. The dApp idea is put on ice, for now…