Which is better?

I recently saw this claim: “If a smart contract is feature-oriented, then it is a product, not a protocol.” I thought this was an interesting distinction worth exploring in more detail, especially given the current trend of people advocating for the development of more primitive, base layer-type protocols.

Distinctions

The traditional definition of a protocol is a set of simple rules determining how information is transmitted between different parties or devices. The Internet (i.e. TCP/IP) is perhaps the best known set of protocols in existence today. Protocols can be extraordinarily valuable, but they seldom extract value. The Internet would not be what it is today, for example, if it had an in-built fee switch or tried to extract value from those who built on top of it. Protocols are usually unopinionated and minimalistic, targeting a broad user base, and designed to last for a long time.

The Internet stood the test of time because it didn’t try to build in complex features. If it had, most of those features would have quickly become out-of-date technical debt and it would have become obsolete. Protocols usually form the base layer of a stack on top of which more complex operations can be performed and more complex *products* can be built. The Internet became valuable because it targeted a broad user base and millions of people felt comfortable staking their future on it by building products on top of it.

In contrast to protocols, the best products are usually extremely opinionated and feature rich, have a very specific target audience in mind, and are not designed to last forever. They always seek to create and extract value from users too. Steve Jobs is the canonical master of building great products.

The rise of product-protocols

So, what are DeFi smart contracts? Protocols or products? I think there’s an argument DeFi has led to the creation of a new class entirely: the product-protocol.

DeFi smart contracts are definitely protocols, in the sense that they provide a strict set of rules determining how information is transmitted between different parties, but they are often feature-rich products too. Some protocols are closer to the original meaning. Others are more product-like. Is this good or bad?

Recently, a narrative has formed around the idea that feature-rich products are somehow inherently bad. I can’t agree. To be bearish on products is to be bearish on composability of protocols, and the entire premise of DeFi, for there’s not much point in building a protocol if it isn’t used to build great products on.

At the core of this narrative seems to be the view that simple protocols are more secure than products. At some level, this is trivially true. It’s easier to build something secure in itself if it only does a couple of small tasks. When it comes to writing secure code, the less complexity the better is a good rule of thumb. So, let’s all build simple protocols and stay away from complex products?

Well, no. Protocols are great for developers to build on, but ordinary end users typically don’t just want great protocols, they want great products. And if products are the desired end state, then you get them one way or another in a system over time, regardless of who builds in that complexity.

Protocol developers might be able to sleep better at night knowing that their protocol is so simple it can’t possibly fail. But as they push the risk and requisite skill required to design and bring to market products further up the stack, they should also be prepared to relinquish the rewards that development of those products brings. The Internet is incredibly valuable, but it was famously not that valuable to its developers.

Modular product development

The security argument for protocols is really an argument for the benefits of modularity. Modules are simple and do a few things well, and nothing else. They are easy to understand and easy to test. In this regard, protocols can be thought of as base layer modules. Good products usually build on base layer modules and add further features and complexity in a modular fashion.

Whilst modularity may help with security, there are very different flavours of modularity. Consider the different ways that Mac and PC were originally brought to market. Both systems used modular design principles. However, whereas Mac famously opted to build all its modules in-house, PC famously opted to let anyone build products on top of it.

There was a stark difference in pace of growth, but also in the final product. PC grew rapidly, but ended up feeling like a jumbled mess, plagued by a proliferation of rent-seeking apps, inefficiencies and security issues. Mac grew much slower, but ended up feeling like a cohesive product, largely free from value extracting apps and security issues.

There’s an important lesson here for smart contract developers. Modularity per se is not enough to bring about great products in the long-term. You want *cohesive* modularity, not chaotic modularity. There’s a risk that the proliferation of DeFi primitive protocols, each with their own governance system and their own fee extraction mechanisms, is simply replacing middle-men with middle-protocols.

Example

Let’s consider an example. One of the most popular use-cases for lending protocols is to compose them with a DEX in order to build a leveraged long or short position. A user will borrow assets and swap them on the DEX, redeposit the swapped assets in the lending protocol, borrow more, swap again, and so on, up to their desired risk/reward tolerance.

There are many advantages to having the lending protocol and DEX built in a modular fashion by entirely different specialised teams. Indeed, the fact that two different protocols built by different developers from different parts of the world can be composed together inside a single transaction is one of the major benefits of DeFi over traditional finance. However, there are important downsides to this way of building things too.

If both lending protocol and DEX extract fees and demand governance by entirely different communities, each with their own interests, the end user experience could be suboptimal. The modularity might not be cohesive if the use-case didn’t have a tailor made solution. Furthermore, if the end user needs to pay UI fees and lending protocol fees and DEX fees and hook fees, and so on, is DeFi really living up to its disintermediated claims?

Conclusions

Overall, I broadly agree with claims that many DeFi projects today look more like products than protocols. I’m not sure this is a bad thing. There’s clearly some truth in the idea that simpler, more primitive, protocols are inherently more secure than complex products. But I’m sceptical of the idea that simply building lots of primitive protocols will result in a more secure decentralised finance ecosystem and better user experience in the long-run. I expressed a similar view in a thread about oracle-free lending protocols a little while ago. Users want products, and this requires complexity at some level. If you’re only building primitives, don’t expect to be able to extract value from users at that level.

Stay tuned to see what we’re building at Euler Labs. Spoiler alert: both primitive and more feature-rich developments are on the roadmap. Cohesive modularity is our design goal.

References

https://x.com/euler_mab/status/1667190907161182210?s=20

https://x.com/delitzer/status/1661755779240841222?s=20

https://twitter.com/PaulFrambot/status/1696900204727791999?s=20

https://twitter.com/MorphoLabs/status/1697579533875261465?s=20