Building a DeFi Moat - Part 1: What’s a Moat When You Move the Castle?

An economic moat is a sustainable competitive advantage that allows a company to fend off competition.

Perhaps the most widely referenced methodology for evaluating a moat is based on Buffet’s three step process for investing in defensible companies. In short:

1. Find a company that has held a competitive advantage for a long period of time (a moat)
2. Figure out what has allowed it the company to maintain that competitive advantage (externally and internally) so as to be able to gauge the likeliness for it to be extended into the future
3. Understand how capable the ‘lord of the castle’ is at holding the castle (is management capable of maintaining control of the castle from within?)

Moats & DeFi

The question of how to build and maintain a moat is especially important to blockchain protocols, where competition is sky-high, user loyalty is low, and where code can be copied with minimal effort. In addition, to continue to iterate might mean requiring your users to continuously migrate their capital, and sometimes this is an expensive ask.

While blockchain protocols can certainly gain a competitive advantage for long enough to attract liquidity and users, it remains unanswered whether there are any competitive advantages sustainable over the long-run.

Let’s explore the following in an attempt to understand defensibility in DeFi:

• Susceptibility to forks
• Major protocol upgrades that require user migration of capital
• Governance: holding the castle
• Constructing a DeFi moat (see Part 2)

Susceptibility to Forks

Just about every successful protocol has been forked, and if it hasn’t yet it will be soon. There are a few major drivers that facilitate forks.

Most Code is Open Source

Search and replace, deploy. Copying code is often easy and low risk. If you copy a great idea and get traction, the payoff is impressive. If you don’t get traction, you lose a few days and nights.

Specialization and the Emergence of Niches

In a multi-chain world with tribal communities, it is quasi-impossible for protocols to replicate their product everywhere at once. This creates opportunities for believers in a new protocol to launch a proven product on top. For example, we can look at Quickswap, which cloned Uni v2 and launched on Polygon while the Polygon network was still young. Quickswap was able to focus its entire team’s energy on its Polygon implementation of Uniswap, while Uniswap was focusing on their Uni v3 development and rollout. And of course, even before this, we saw Sushi’s vampire attack on Uniswap, which revolved initially around a simple change to one core Uniswap parameter (where the fees go).

Going one step further, we see forks with network-based improvements. For example, a fork of an Ethereum mainnet app may include auto-compounding when launched elsewhere, now that gas is not a factor. This opens up opportunities for entrepreneurs to improve user experience in the context of the environment where it is launched. A team like Uniswap, which has already been slow to embrace many blockchains, would face an enormous management challenge to have individual teams customizing app features for every unique environment.

And, as the market grows, new niches emerge! This is a fundamental aspect of any economy. Larger markets are able to sustain (or facilitate the invention of) sub-markets or niches. Clipper Exchange is a great example of this. Many types of traders exist on Ethereum, and Clipper decided to focus on making swaps under $10,000 as cheap as possible. Since the number of traders swapping under $10,000 is a sufficiently large number, Clipper has been able to capture a large percent of these trades.

Proven Models on a Platter

Tokenomics can be hit or miss, and when everything’s transparent, forkers can rest assured that their fork has potential, since it has worked before. If you saw PancakeSwap fork Uniswap and achieve a multi-billion dollar valuation, why not do the same thing on the next L1 to launch? In the web2 world, finances are typically opaque and there is therefore less incentive to invest in copying a product, not knowing whether it is profitable or not.

Diminishing Community Incentives Create an Incentive to Fork

As community incentives from a successful protocol launch level off, it leaves room for another protocol to syphon off some of the TVL, however ephemeral. Any half-decent fork with its own token can bring in a few million dollars of TVL by giving away its tokens. If it is able to overcome the deflationary pressures by finding new buyers, it may have a chance at success.

Moving the Castle (Protocol Upgrades & Capital Migration)

Major DeFi protocol upgrades typically require users to not only withdraw and re-deposit their assets to the new smart contracts, but also to adopt a new interface and go through the risk/reward evaluation process again.

This process, from a user journey perspective, may include the following:

• Invest time in understanding the protocol changes, including new risk/reward factors
• Withdraw capital, often including incurring gas costs
• Compare to alternatives
• Decide whether this is the best place to continue allocating capital (user is forced to re-evaluate the current investment’s performance and is given an opportunity to take the capital elsewhere)
• Reestablish trust that the upgrade will not result in exploitable vulnerabilities or unforeseen losses due to underestimated risks
• Deposit capital back into the protocol and monitor to ensure expected behavior

In addition to asking a lot from the protocol’s community, there may be significant efficiency risk in a major protocol upgrade. For example, Uniswap v3’s capital efficiency improvements were enough to convince a sufficient number of LPs to migrate, but what about smaller capital improvements? If a protocol’s new version must ‘start from zero’ and reach a certain threshold of TVL to make it worth the migration, it opens up opportunities for competitors with less to lose to compete, especially when liquidity is a commodity within aggregators!

As we can see, this is a big ask to a product’s community, and has the potential to lead to serious churn, or worse.

So is liquidity really a moat if it must be sourced for the next upgrade? And how meaningful is trust or battle-tested status if it must be continuously re-established with each major iteration?

A Few Examples

We’ll look at a few examples in the perpetuals space, only because I’ve been thinking about them over the last couple days.

Perpetual Protocol recently migrated from xDAI to Optimism and has yet to add support for all of its v1 pairs - trading volume on their v2 version is also lagging despite being around two months since its launch, and the platform has only seen around $30 million in LP deposits. At the time of writing this, their v1 app continues to generate about twice the volume of their v2.

Dydx, the first major perps platform on a zkRollup, has also signaled interest in moving from its own siloed rollup to StarkNet in order to reduce barriers of entry. Meanwhile, launching only a few months ago, ZigZag has moved quickly in establishing its name as the leading zkRollup exchange with presence on both StarkEx and zkSync. ZigZag’s ability to move quickly and iterate has allowed it to move faster than long-established competitors which might have been thought to have established significant moats.

In a successful example of continued migration, the widely adopted protocol Uniswap has transitioned from v1 to v2 to v3 while retaining majority market share of liquidity and volume.

Governance

New and unproven governance structures provide yet another question mark when considering how sustainable a moat is over the long-run. Can the lord defend the castle from within?

We have recently witnessed Sushi go through some turbulence in management, and the lack of structure and processes for replacing core members and scaling out the protocol to distinct teams has stalled Sushi’s progress on many fronts (we are now 4 months after the ‘Trident launch imminent’ twitter announcements).

In the next section we'll discuss ways to build defensibility into your protocol.