The playbook for competitive moats for traditional companies has already been written. Hamilton Helmer’s ‘7 Powers’ has emerged to be a popular favorite, but other frameworks abound.

When you’re building in web3, you’re (hopefully) buying into the web3 ethos: open, permission-less innovation and avoiding user lock in. You’re building, knowing full well that anyone can fork your code, copy and paste it and even vampire attack your users. Not all of the seven powers work in web3.

So which powers do work in web3? How do you build a competitive moat? How can you make sure that the problems that have plagued incentivizing open source and public goods funding doesn’t afflict you?

Wen Token?

Tokens have been a popular choice: offering an economic incentive to contribute, build and stick to a specific platform. Marc Andreessen has said it outright: that tokens add an economic layer to web protocols.

Unfortunately, we’ve seen tokens fail time and time again. Apparently, using purely economic incentives for behavioral change is harder than it seems (for reasons I’ll discuss elsewhere)

So beyond a token, how can web3 protocols and companies build competitive moats that help them capture part of the value they’re creating?

Below is a ‘five power’ framework on moats that web3 projects can utilize, beyond tokens. I’ll explore each one and use Uniswap¹ as an example for each of the five powers. These aren’t unique to web3 companies, but each has unique aspects in implementation for web3 projects vs web2 companies.

I hope this framework will help entrepreneurs evaluate their projects, moats and long term viability and encourage the disuse of tokens when they’re not needed.

The five powers are:

The 5 power framework for web3 moats

1. Brand

Brand in web3 is critical. Despite being a ‘trust-less’ system, the reality is that web3 is the Wild West. New projects are launched each day. Some are real, some are stupid, some are well intentioned but faulty and some are outright scams. It’s impossible to sift through the noise, especially when to really understand and verify a protocol you have to go layers deep.

For example, you could dive deep into Aave, a trusted protocol, verify everything about it including the sources of liquidity, code and team, and still miss that they rely on Chainlink’s oracle for their only price feed. And Chainlink’s feeds are controlled by one 4/9 multsig. Your entire due diligence is useless without understanding that one fault. And this is a good case, with a well trusted brand. Most people don’t have the time or ability to dive into protocol and smart contract details and rely on — brand.

This is why trust in web3 is so critical. The Lindy effect, which states that the longer something survives the greater its chances of are of continuing to survive, has never been more true than in web3. The longer a project is out there and hasn’t suffered a breach, a hack or a scam, the more trustworthy it is.

In web2 you might be tempted to try the newcomer. In web3 you don’t mess around — you go for the blue chips or risk losing your funds.

Brand matters in a world that’s built on trust where trust and legitimacy is a scarce asset.

While in web2 being first to market can mean releasing a glitchy MVP and seeing a fast follower catch up, in web3 it means earning trust, especially when you’re the team inventing a new protocol design.

It means that your brand is what’s recognized with the innovation, that you’ve had the most time to build, test and iterate and have the deepest understanding in the space. All of these build trust.

Uniswap Example

While many DEXs have forked the original Uniswap contract, Uniswap’s brand is still by far the most trusted and well known DEX brand out there. More tokens are swapped on Uniswap than any other competitor DEXs, despite having been forked and vampire attacked. The ecosystem knows that the Uniswap team are the OGs, are the original innovators and the first to market with new innovations. They’ve built up and earned trust.

Builder questions:

2. Economies of scale and flywheels

Throughout the 20th century economies of scale were a major moat. In the web2 SaaS world, it’s been left along the wayside. It matters far less to a B2B SaaS built on AWS how many clients it services (although for businesses like AWS economies of scale matter quite a lot).

Web3 protocols can be far more similar to AWS than your classic B2B SaaS. One of the key features of web3 is tokenization and bringing liquidity to where there previously was none. Liquidity follows economies of scale. The more liquidity you have, the easier it is to get more liquidity and the easier it is to build other products on top (It’s not a classic network effect, as nodes in the network don’t necessarily gain a benefit the more nodes join).

Uniswap Example

Uniswap liquidity pools benefit from economies of scale. Liquidity begets more liquidity, and they can offer deeper liquidity in their pools and therefore lower slippage costs than any other DEX, which in turn causes more users to swap on Uniswap.

Builder questions:

Web3 moats: the fiver power framework, a case study of Uniswap

3. Network effects

Network effects are always tricky. Both in web2 and web3. If you can achieve them, it’s a huge competitive moat, especially for an early mover. Web3 network effects aren’t very dissimilar to web2 ones. You first have to understand who or what are the nodes in your network and based on that, work to incentivize those nodes to join. Remember, the definition of a network effect is that the value of the network grows with each additional node, like a telephone network (many companies confuse economies of scale, or flywheels with network effects).

Does Web3 lend itself better to NFX? I”m not convinced. Web3 is all about ownership and ownership and social networks or network effects don’t necessarily go together. There’s also an anti network effect at the blockchain level, where more demand, i.e nodes on the network, actually drive up congestion and prices in the form of gas fees. You have to carefully examine your product and natural ‘node’ to see if there is a network effect.

Uniswap Example

Uniswap’s core ‘node’ is a liquidity pool. The more pools, the more utility one gains from using uniswap as a whole. If there was only an ETH<>USDC pool, there wouldn’t be much utility. Each additional liquidity pool (USDC<>DAI, DAI<>WBTC etc) adds utility to the network as a whole and to each new user. Be aware that after covering the top XX liquidity pools, adding new nodes has a marginal benefit (similar to adding the billionth Facebook user)

Builder questions:

4. Viral go to market

Some of the best web3 use cases lend themselves naturally to a viral go to market which is an incredibly powerful moat. These use cases tend to be ‘utilities’: foundational building blocks of the web3 ecosystem. These are building blocks, ‘web3 lego’s’ that other protocols use in what they’re building and drive users to your protocol.

Utilities can be DeFi primitives, oracles or even game elements². It’s essentially a viral B2B2C go to market.

Uniswap Example

Uniswap enables other protocols to add liquidity to their projects, and the easiest way to do that is by…creating liquidity pools with Uniswap! By building a utility for other web3 projects, those projects then send users back to Uniswap. Naturally, the more projects integrate Uniswap, the more brand, economies of scale and network effects come into play.

This is where permission-less innovation shines through and web3 gives monetization options to things in web2 that didn’t have any. Open source libraries are just as critical building blocks in web2, but they don’t benefit from the same market forces that web3 enables.

Builder questions:

5. Non extractive mindset

While the first four elements of this framework exist in web2, this last one is uniquely web3. Web2 companies achieve customer lock-in through non portable data, closed software and organizational practices (not that these are necessarily bad — just different). In web3, that’s not the case and anyone can either leave your protocol, or worse — fork it and compete. With the added benefit of having a complete list of all of your users and early adopters. The only way to avoid forks and vampire attacks that compete directly with what you’re building is by adopting a non extractive mindset. If you’re extracting unneeded rent, there’s room for a fork that will compete those margins away. By adopting the Bezos mindset of ‘your margin is my opportunity’ and assuming from the get go a ‘low margin’ protocol, you’re avoiding future forks and competition and increasing your moat.

Uniswap Example

Uniswap’s swap fee is incredibly low. So low that it’s borderline worthwhile to be a liquidity provider, and there’s not much room for Uniswap’s ‘take rate’. Had Uniswap’s fee been much higher, the incentive to fork and implement a lower fee fork would have been high and Uniswap’s margin would been cut.

Builder questions:

How to build web3 moats

If you’re wondering how to build a moat in web3, this ‘five power’ framework offers a way to think about it. Look at your project through the lenses of: