Back in 2021, I joined Balancer, the popular AMM on Ethereum. I joined at a time when they had gained product market fit for the protocol but the v1 app left a lot to be desired. I was recruited to lead their frontend/product efforts and build out a v2 of the web app.

The Balancer leadership at the time were very ideological about decentralization at all layers of the stack and so pushed for the v2 app to be as decentralized as possible. What did that mean?

• Static app — The idea being that it can more easily be deployed on decentralised file hosting networks like IPFS.

• No API — Restricted to fetching data from Subgraphs, which were supposed to be the decentralized alternative to a caching API layer, and also onchain calls.

The thought process at the time was that we were moving towards an internet where this would be the norm for DeFi protocols and that the complexity and UX problems would reduce over time. I guess it was also thought that decentralized access points (domains) to these decentralized hosting networks would become more popular, i.e. pointing an ENS address at an IPFS hash and expecting users to access apps that way.

This did not play out.

Unfortunately, the world didn’t go this way. Primarily because the technology didn’t improve enough to make the UX better than a typical web2 app, in fact, it’s still much worse if you try to build this way.

The critical point is that decentralizing frontends is pointless unless the access points are decentralized. I talk more about this in my post about why frontends won’t be decentralized (anytime soon).

A new start

Balancer v3 gave us the opportunity to rethink everything. We looked at the decisions we’d made in the past and the disappointing results of those decisions when it came to UX. It became clear we had to ditch the decentralized frontend philosophy and build and open-source ‘web2’ app. By web2 I just mean leveraging web2 tech as much as possible when building a web3 app, e.g. a server-rendered app instead of a statically built app. This change in direction allowed us to pick the best tech for the job.

So with that context, here is how I would build a web3 app in 2024.

Ditch Static Apps: Decentralization theatre

Again, tl;dr; pick the best tech for the job. If the access point (domain name) is not decentralized everything else is irrelevant. For now, leverage the latest frontend tech or build with whatever allows you to optimize for UX, for us it was a server-rendered Next.js app. If decentralization of all layers of the stack is important to your project then open-source the app, make it as easy to deploy as possible and write good documentation.

Keep the Frontend Dumb, Push Logic to SDK and API

In Balancer v2 we made the mistake of cramming a lot of caching and extractable logic into the frontend codebase. In self-contained web2 apps this is easier to avoid, with fairly well established patterns for separation of concerns. As with web2, the ideal is to keep the frontend as dumb as possible.

We pixel monkeys just want to make rectangles look pretty! Nothing more nothing less.

In web3 separation of concerns is a little harder to define. Generally, you also want to keep your API as dumb as possible and just cache and format onchain data there. The logic leftover needs to be carefully separated between an SDK and the frontend.

Build a protocol SDK

Move any pure logic that helps the frontend interact with the smart contracts into a protocol SDK. If it’s useful for the frontend, it will be useful to other developers who may want to interact with the underlying protocol. The more you make the underlying protocol accessible to developers the greater the network effects. From a frontend dev perspective, the goal here is to extract as much isolated protocol logic as possible so that the frontend code can be really dumb.

Cache & format onchain data in an open-source API

It shouldn’t be much more complicated than the title suggests. I’m not an expert on the tooling in this department but I know it’s rapidly improving. Use subgraphs and or other available services to cache the raw onchain data and feed those into an API for formatting and any further data processing. Make the API open-source so that others can spin it up alongside your frontend, if decentralization is important to your protocol.

The frontend stack

Just use React

I made this mistake for v2. Vue had already been chosen when I joined Balancer to lead the v2 build-out. At the time I was more proficient with Vue than React so I was quite happy with that choice. The problem is, network effects. Like it or not Web3 is a niche tech vertical. There just aren’t enough people building dev tooling in our niche to span all framework ecosystems equally, so by the law of network effects the best tooling is in the React ecosystem. It’s also where the best people are for hiring, with exceptions of course.

Don’t make it harder than it needs to be, just use React.

Frameworks are your friend

Don’t reinvent the wheel. If you’ve gone with React… then go with Next.js. Use whatever framework does the most for you. There is enough engineering to do to get Web3 apps working nicely without worrying about typical web2 problems.

Component libraries, don’t reinvent the wheel

Continuation of the above point. Try to minimise the time spent working on typical frontend/web2 problems like component building, so you can spend as much time as possible working on web3 flows and UX. There are plenty of challenges there that will take up your time.

Web3 tooling

As of writing this post, there are clear winners in this space. Pick Viem/ Wagmi as your core web3 packages, these are for interacting with your smart contracts and constructing transaction flows.

Then, pick a wallet provider that is built on top of wagmi. Two popular choices here are RainbowKit and ConnectKit. We used RainbowKit in Balancer v3 but I don’t think there is a clear winner here yet.

Whatever you do, don’t build your own wallet provider. It may seem simple at first but it’s a Pandora’s box of edge cases.

A final comment on web3 tooling: don’t forget smart accounts. This is especially true if you are building a DeFi app where your primary users are likely to be interacting with the dapp via a multi-sig like Safe.

Building a DeFi app in 2024 is still surprisingly difficult. This is especially true if your dapp is data-heavy and requires some non-trivial smart contract interactions. I expect this to get easier over the next few years but it depends on how the wider crypto ecosystem plays out. The core problem at the moment is chain fragmentation, especially in the Ethereum ecosystem. If good chain abstraction can be achieved at the tooling layer then building mult-chain DeFi apps will become quite a bit easier. But I struggle to see how that works in practice at this point in time.

I also want to point out that nothing I’ve included here is groundbreaking… Most of this is just common sense. As engineers, it’s so easy to get caught up trying to build fancy solutions. For DeFi apps the key is to focus in on the core interactions and how you manage those, i.e. the transaction flows and presenting onchain data.

I have specifically included the year in the title of this post because I expect it to become redundant. At least I hope it does. Maybe in 2025 or 2026 there will be a common way to access fully decentralized apps and common patterns for how to build them.

What's the point of decentralization?

If you have a bar of gold under your mattress and the government decides they want that gold, you can fight to keep it or try to get out of the country with it.

Tokens on sufficiently decentralized networks like Bitcoin and Ethereum are no different to that bar of gold. However, unless you're a technical wizard, moving those tokens around requires an interface, typically a web interface.

So in the context of DeFi, the point of decentralization is censorship-resistant access and control of your assets.

The government should not be able to control your access to your assets.

The problem with decentralizing access to your onchain assets is that governments can control the access points to web interfaces through DNS.

The DNS problem

Imagine the internet as a huge city, and websites are buildings in this city. DNS is like the city's information desk at the town hall. When you want to visit your friend's house (a website), you only know their name, not their address. So you go to the information desk and ask, "Where does John Smith live?" The friendly clerk at the desk (the DNS server) quickly looks through their records and tells you, "John lives at 123 Main Street.".

The problem is the clerk at the town hall. The government employs her and if the government doesn't want anyone to visit John, because he's organizing a protest, the government can tell the clerk to deny any requests for John's address.

This doesn't completely block you from finding John, but because everyone typically goes through the information desk at the town hall, it puts 99% of people off going any further. People are busy, they don't have time to walk the streets searching for John's house. So John's protest dies.

To decentralize access truly, we must first tackle this centralization at the heart of the internet. Enter the Ethereum Name Service (ENS), the best attempt to provide a decentralized alternative to DNS. However, here's the catch: getting the entire internet to switch from traditional top-level domains (TLDs) to ENS domains is like asking the world to start driving on the left side of the road tomorrow. It's a massive, disruptive change involving significant shifts in infrastructure, browser compatibility, and user behaviour. It's just not going to happen anytime soon.

So what alternative solutions do we have?

The mess with mirrors

Some might argue that mirrored sites could offer a solution. These are alternative URLs hosting the same content, providing redundancy and resisting censorship. But this is where the theory diverges from reality. Users trust websites based on familiar domain names and the brand reputation tied to them. Introducing many different, unfamiliar domains breeds confusion and mistrust.

Moreover, mirrors are far from bulletproof. They can be taken down, and keeping them synchronized is a logistical nightmare. Users are left questioning whether the mirror they’re using is safe or has been compromised, hardly the seamless experience we aspire to provide.

Local app stores?

Another proposed solution is to have local DeFi app stores. That is, a way to download entire web apps onto your computer and for those apps to only rely on non-centralized supporting services for fetching data and performing operations with your assets.

Whilst this again seems like a good idea, in practice, it just doesn't work:

1. It forces DeFi protocols to build extremely limited apps that will inevitably have worse UX than typical web apps. This is not going to help convince the masses to use DeFi...

2. It again, like ENS, requires a massive disruptive change involving significant shifts in infrastructure and user behaviour.

So now what? It all seems kind of hopeless, right? We're on this path with the development of the internet which appears to only lead to centralization and censorship.

If you're disappointed in this summary of our options, good, so am I, and unfortunately, I don't have a smoking gun to offer in this post.

The only current solution we do have in this fight is to open-source everything.

By making the code for DeFi apps open-source and easily deployable, we don't decentralize the access itself, but we distribute the power and control over its deployment and maintenance.

Open-source projects thrive on transparency and trust. Anyone can inspect the code for vulnerabilities or backdoors. Developers can fork the project, create their own versions, and host them independently. This ensures the project's resilience and longevity. But let's be honest—this approach relies on the technical acumen of users and developers to deploy and maintain these apps.

It’s not a practical, long-term, solution for the future of censorship-resistant finance.

Originally published at https://dappness.com.