Simple is important, because products need to be used to be successful. Simple things are easier to understand, use, and spread than complex things.

In crypto, for some reason we often tend toward complexity rather than simplicity. I don't know why, but we do. Multi-party computation, zero knowledge aggregation, fully homomorphic encryption, delta neutral hedging, impermanent loss, kzg commitments, loss versus rebalancing are just a few of the jargon filled words and phrases you might hear on a crypto podcast today.

Sometimes I wonder if it's because jargon preserves this sense of iykyk. Regardless of the diagnosis, it's something I have become acutely more aware of in the past couple years. It's easy to feel like you've buried your head in the sand when you work in crypto. But many of the most successful crypto networks and products can be simply described:

• Bitcoin is digital gold.

• Ethereum is a platform for decentralized applications.

• Solana is Ethereum, but faster and cheaper.

• Coinbase makes it easy to buy and sell crypto.

• USDC is a 24/7 available, globally accessible dollar.

If you can't describe what you're building and why it's important in a sentence or two then you probably need to simplify. Let's make crypto simpler.

But in order to get users, protocols have needed to attract devs who are building apps. Different protocols have attracted devs with differing tactics and varying levels of success.

• Ethereum was first. It's advantage was literally creating a new market and it took many years to cultivate the flywheel it has today.

• Solana incubated its first few protocols.

• Arbitrum hit early with GMX.

• Base hit early with FriendTech and put the full weight of Coinbase behind the L2 once it showed signs of working.

Today, competition for devs has never been higher. The cost to launch chains has gone down with RaaS providers. The cost to use news chains has gone down with embedded wallet infra, account abstraction and EIP-4844 and alt DA. So new protocols have resorted to paying hundreds of millions of $ in tokens to acquire both devs and users. In my opinion this leads to adverse selection. It's exceedingly hard to curate quality devs and no matter how much we try to meme it users rarely come for the token, stay for the product.

A strategy we're seeing more and more and starting to invest behind is that of product led protocols. Rather than attracting third party devs to your protocol, build a product first, on it's own open dedicated blockspace with the ability to transform into a vertical network. The best example of this in practice is Warpcast as the leading product for the Farcaster Protocol.

There is no reason for developers to build their own social apps on top of an open Farcaster Protocol that has no users. Dan and Varun knew this, so they have focused exclusively on building Warpcast into the primary social product for crypto twitter. With the launch of new crypto native features, most notably frames, they have been successful in pulling high engagement users to Warpcast and as a result the Farcaster protocol. As Warpcast approaches 100k DAU, there is now a direct incentive for devs to build on top of the Farcaster protocol: access to Warpcast distribution.

Warpcast -> Farcaster not the only example. Zora, for instance, has led the charge on this front with it's own rollup. Beginning with zora.co it used it's user base to transition to an open protocol where now devs are minting nfts for their own apps on Zora Network because its the cheapest place to mint nfts and where most collectors are.

I suspect this is a playbook that we will see used more and more often going forward.

Views are my own and not investment advice. Haun Ventures may have previously held, currently hold, or will in the future hold positions in projects mentioned in this post. See https://www.haun.co/disclosures.

I wasn't around as a builder during the original push towards social, but I was a user. I remember posting on FB and Twitter neurotically during middle and high school. And the feeling of using those products was not addictive or toxic, which of course is the prevailing feeling while using those apps now. It was small, fun, playful, and new.

I went back through my phone to thoroughly review the apps I spent most time on last year. With one exception my experience on most social apps is neither fun nor playful. That exception is Letterboxd. It's a simple social app for people who love movies. I watched and reviewed 60+ movies last year and hope to increase my numbers to 100+ this year. It's mid February and I'm at 15 so far.

Before Letterboxd my movie watching experience was pretty crappy. Maybe you'll find this playbook familiar. On a Saturday night if I wanted to watch a movie I didn't really know where to begin. Maybe I'd google for Top 100 Movies and comb through a bunch of lists that I had already seen before. Or maybe I'd go into my notes app and search through that random list of movies that I'd occasionally remember to update. Or worse, maybe I'd log in to Netflix or HBO and scroll for something that caught my eye. It was chaotic and usually left me watching something uninspired. I rarely finished a movie I started using this route.

Letterboxd is a really simple app that has changed my movie watching experience. I now watch more movies and engage more deeply with them. First and foremost, it's a way to track a movie watchlist and keep a diary of movies that you've watched. So it forces you to think while watching a movie. It forces you to pay more attention to the things you connected with, liked, disliked, felt, or didn't feel. In the words of Fred Wilson, it provided me with single user utility despite being a social system. And what I enjoy the most is the social component. I can keep tabs on what my friends are watching and reviewing. It's useful for gathering inspiration on movies I should be watching from the people whose taste I trust. And it's a way for me to engage or even talk shit with friends about their reactions to movies I either love, hate, or feel ambivalent about.

In contrast to other social media apps, my circle of friends on Letterboxd is quite pitiful. I have 21 followers and follow 27 people. But it's also one of the things I like most about it. It makes the internet feel small and for me there is zero noise. While most of the big social apps push broad engagement, Letterboxd creates deeper engagement. I am drawn to that.

Maybe there's a repeatable truth here?

• We've never had an open, programmable social feed. The glory days of web2 social existed while Facebook and Twitter had open APIs. I'd be willing to bet most of the folks tinkering on Farcaster were not coding during those days. So this is the first time our class of engineers, hackers, and tinkerers have had the opportunity to use a programmable social feed. And while most of the experiences are subpar, or just don't work that doesn't mean there isn't something magical happening. I have confidence that they will only continue to get better and there will be some really interesting frames that popup and meaningfully improve the product experience and change the shape of distribution on social.

• A free to use experience. For all of the frames I have used, I never once have converted when asked to connect a wallet. The most magical feeling is using a crypto product, not connecting a wallet, not paying for a transaction, and not having to go to etherscan to see if it succeeded. Yet this is the standard experience. All of the frames I have used have been completely free to use.

The first reason showcases the power of an open social network, which was clearly the intention. The second reason may have been less intentional but I think might pull harder at a global truth for crypto products. If we can make other crypto products free and easy to use, there is a fertile ground for experimentation and fast feedback from users.

While frames have supercharged a lot of experimentation with a free to use programmable social feed the truth is most of the frames are not very good experiences yet. "Minting" a frame NFT is an odd experience. Most of time it's already minted out. When I have minted an NFT it's completely untraceable.

If only there was a way to use crypto products freely, without sacrificing onchain verification! 🕵‍♂️

Another downside of frames is that they're self contained within the Farcaster protocol, so only Farcaster clients are able to create this programmable, free to use experience. But shouldn't we explore what it might look like to create a free to use experience for every crypto product? Ive previously written about vertically scaling crypto apps and my partner Chris has written about diseconomies of scale inherit to blockchains. Free to use products take our ideas to the extreme. And I think if there is something that other crypto products can takeaway from the Fames phenomenon it's what happens when you create an experience that is free to use.

In the crypto community, we hold core values such as decentralization, permissionlessness, and immutability. These are critically important, but I fear that we focus too much on how products should exist in their end state and not how to make great products in the first place. Demanding that all crypto products be built decentralized, permissionless, and immutable from the start makes it more difficult to build useful products. It presumes that we know exactly which products should exist on crypto rails, their exact form factor, and how to bring them to market. This thinking is dangerous and translates to an early stage product culture where we ossify before we iterate. Start with a whitepaper and work toward a product. Nerd snipe the researchers, then build for users. But in practice this is not how good products are built.

It’s a mistake to look at the success of early crypto protocols like Uniswap or Compound and think it’s canon to build products that way. They are outliers. Products don’t gain traction in a straight line. Sometimes the core product is not interesting to users. Sometimes a particular feature leads to a brilliant insight. Sometimes you uncover a series of dead ends and never find anything that sticks because you’re too early or too late. There is only one way to find out.

In the early days of Zora we fell into the trap of ossifying too early and it slowed us down. We spent weeks designing our ideal nft marketplace protocol and then months writing, testing, and auditing the contracts and building all of the middleware on top to support its launch. All in, it took six months to ship V1 on mainnet. Shortly after launch we discovered numerous improvements to be made and started another six month crusade for V2. From the time we started on V1 to the time we completed V2, the market looked vastly different and our ideas had not been well validated. Only later in trying to increase the top of funnel for the Zora Marketplace did we stumble upon the open editions product, where it turns out there was PMF and is now the basis for all Zora products. 

To help teams learn from some of the mistakes I’ve made and still see others make, here are a few simple ideas on how to iterate faster in the early stages of crypto product development.

1. Do more things offchain. The more of your product you decide to put onchain the more costly it will be to build and use your product. For most engineers, the crypto stack is unfamiliar. Building custom smart contracts requires fixed costs in writing, testing, auditing, and deploying new code. But also, putting more logic onchain will simply cost more for your users to use your application. Of course there are many benefits to putting things onchain. So If you must do things onchain, keep it to hardened contracts to minimize scope creep. Examples of applications that have executed well on this approach are Farcaster, Blackbird, and Hivemapper.

2. Use technology that’s available today, not what’s promised in the future. It’s easy to get excited about the latest “endgame” research topic and want to incorporate that into your strategy and product roadmap. But most research is years away from production use. It’s far more strategic to build software that allows your product to adopt a new technology when it’s ready than it is to wait for the technology to arrive. I’ve yet to see “endgame” research translate to product experience benefits to the user. A good example of this in practice is the competitive dynamics between Optimistic and ZK rollups. With the first mover advantage that Optimism and Arbitrum have, it’s been challenging for Polygon Zero, Zksync, and soon Scroll to differentiate. A rollup with faster withdrawal times, just might not be enough to a.) encourage developers to build first party apps and b.) cause users to churn from apps on optimistic rollups. The longer you wait to bring a technology to market, the more differentiation matters!

3. Focus on your onboarding experience. It’s not a hot take to say that user onboarding is still the primary issue for usage of crypto products. That’s not to say if you fix onboarding you will magically get usage for your application. But web2 like onboarding experiences will improve the top of the funnel for your product and allow you to build a healthier user funnel to get more robust feedback. Embedded wallets, L2s, stablecoins, and better onramping solutions will help tremendously here! 

4. Ruthlessly engage with your users. Many crypto teams don’t even know who their users are. I am not sure if anyone knows who is LPing in some of the largest Uniswap Pools. This is one of the double edged swords of building onchain. But it is not a good excuse. Gathering, prioritizing, and incorporating user feedback is required to build great products. Teams that do this best well have products that stand out from their competitors because they’re building explicitly for their users’ needs. 

Views are my own and not investment advice. Please see https://www.haun.co/disclosures.

Crypto apps don’t have this luxury. Unlike cloud platforms like GCP and AWS, general purpose crypto networks do not provide auto scaling as a feature. The ability of a crypto app to respond to increased user demand is constrained by the resources of its underlying network. And as we’ve seen, it only takes a modest level of adoption of a single app to actually degrade its quality of service for its users because the costs to use the app increase. For instance, as more traders want to use Uniswap, they begin to compete with one another over Ethereum blockspace and end up paying higher transaction fees to use the app. In order for crypto apps to be able to reach billions of users this must fundamentally change.

In traditional cloud there are two ways to scale an app: horizontally or vertically. Horizontal scaling refers to splitting the app workloads across multiple machines to gain performance through parallelism. Vertical scaling refers to running the app on a beefier machine with higher CPU, RAM, or disk space. While it’s early, we’ve actually seen some crypto apps try methods of scaling that look like these two familiar approaches.

Horizontal Scaling (General Purpose)

We’ve seen some crypto apps attempt to horizontally scale by deploying to multiple, general purpose chains. But attempts at horizontal scaling have not meaningfully moved the needle for crypto apps. For example, Aave V3 was first deployed to Ethereum Mainnet but has since deployed to Optimism, Arbitrum, Polygon, Harmony, Fantom, Avalanche, and Metis. Uniswap has followed a similar trajectory. But unlike cloud horizontal scaling, the multichain deployment of an app does not create a true load balancing effect. Instead, crypto horizontal scaling feels more like restaurant franchising where brand and user experience are shared, but separate liquidity and networks result in very different product outcomes. In practice this strategy has been minimally effective. The majority of usage continues to occur in the initial deployment context.

Vertical Scaling (Customized)

In contrast, we’ve seen some crypto apps attempt to vertically scale by delegating more of their custom app logic offchain and only using the underlying network, where resources are most expensive, for the most critical logic. By delegating more logic offchain, the app is able to leverage a “beefier” compute engine. That offchain logic might manifest in the form of a rollup, a sidechain, a validium, or simply a checkpointed data structure. The more logic you defer offchain the more performance you can get, but the more decentralization you trade off (assuming that offchain compute is more centralized). dydx is a good example of an app that’s attempted to vertically scale having first been deployed to Ethereum Mainnet, then StarkEX, and is now working towards its own appchain. Zora is now running a similar playbook by expanding from Ethereum Mainnet to its own L2. In both cases, the app first achieved product market fit on Ethereum, but needed to get creative with how it used Ethereum’s blockspace in order to continue to grow and provide high quality services to its users.

Don’t get me wrong, I’m excited about the many teams that are laser focused on researching and building horizontally scalable, general purpose blockspace, but I think it’s time that apps currently dealing with scaling bottlenecks take matters into their own hands and push the boundaries on more custom, vertical scaling approaches. As a founder the top priority is to provide a good product to your users. For many crypto apps, I believe that trading off aspects of centralization to increase your user base and build a better product is not only sensible but well worth the endeavor.

Views are my own and not investment advice. Haun Ventures may have previously held, currently hold, or will in the future hold positions in projects mentioned in this post. See https://www.haun.co/disclosures.

In the EVM when you want to interact with a smart contract you sign a message that sends data to a specific function on an address that contains deployed code with step by step instructions for the requested execution. You provide the inputs, but you don’t necessarily have control over the outputs because the code you’re interacting with might be stateful, etc.

However, in an intents-centric design the user merely signs their intents with a bond and will pay the bond if their intents are met. This is cool, but it’s a very different way of thinking about the world.

Interestingly, it reminds me of a class I took in college on programing languages.

For the entire semester we focused on building a Sudoku solver in what felt like every programming language ever invented. The point of the class was to show to us noobs that there were many tradeoffs one could make as a developer and depending on the problem a given programming language could yield very different developer experience, solution performance, hard to squash bugs, etc.

I started off with C++ struggling through manual memory management. As an early programer it was in this class that I gained a fond appreciation for object oriented programming and automated garbage collection that came with higher level languages. I also remember really enjoying Racket, which is a Lisp variant. Part of the reason I liked it so much was because Paul Graham wrote a lot about Lisp.

Towards the end of the semester we moved on to logical programming and were instructed to implement the sudoku solver in prolog. Prolog is an extremely weird language, but for certain problems can be very powerful and very expressive. A program in prolog describe a series of statements about what the program should accomplish, but does not provide ordered instructions for execution. This creates a very weird syntax, but it turns out it’s particularly good for solving Sudoku.

For instance, while it took me numerous days + hundreds of lines of code to write a Sudoku solver in languages like C++, Go, Python, etc. it only required three lines of code to write a valid sudoku solver in Prolog. This literally blew my mind.

So when I first met the Anoma team and then later read the Flashbots Suave whitepaper and learned more about their vision for intents all I could think about was my prolog sudoku solver.

I have to believe there are some interesting problems in crypto that would be best suited for a programming paradigm that feels more like prolog and less like the EVM. Complex combinatorial logic such as transaction ordering for mev searchers and builders could be a good example! Though I have remaining questions around the need for shared builders and shared sequencers, I am excited to see how intents environments evolve.

Whether it’s a full day with the rest of my team in the Haun Ventures office, meeting with our founders in their offices, meeting a new founder over coffee, or at a conference, I feel the most connected to this ecosystem when I am inperson. I am grateful that we made the decision last year to build an inperson culture at HV and I encourage any existing and future founders to do the same.

It makes the hard work more memorable and importantly, more fun!

What do I mean by that? We’re all familiar with the concept of dimensions in physics.

1d: a line.

2d: height and width

3d: height, width, and depth

4d: space and time

It’s hard to put in words, but I think dimensions in technology describe not just form, but also ownership, usage, and decentralization. Lower dimensional technology is more clunky, more difficult to create, obtain, transfer, and is more centralized. Higher dimension technology is native to software, native to the internet, ownable, accessible, and more decentralized.

Here are some examples.

Money

• 1d: cash → can only be used in the physical world.

• 2d: digital payments → money on the internet, but still settles to cash.

• 3d: bitcoin → internet native money, decentralized.

• 4d: defi → programmable, internet native money.

Infra

• 1d: servers → manual setup, local computation.

• 2d: cloud → centralized, programmable computation.

• 3d: blockchains → decentralized, public computation.

• 4d: zkps → private, verifiable, succinct computation.

Media

• 1d: physical media → physical manufacturing and distribution.

• 2d: digital media → make once, distribute globally.

• 3d: social media → make once, engage globally

• 4d: nfts → make once, own globally, prove provenance.

Gaming

• 1d: consoles → hardware limited, single player.

• 2d: online cloud → no hardware constraints, multiplayer.

• 3d: online ugc → multiplayer, player contributed, centrally owned (roblox / epic).

• 4d: crypto gaming → multiplayer, player contributed, player owned.

I know, it’s not a perfect analogy, but you get my point. In this framework any time a new dimension is added to a technology the incumbents get disrupted and net new possibilities emerge. I believe much of the bleeding edge research in crypto has already and will continue to add new dimensions to a variety of important technologies.

Unfortunately heterogenous monoculture exists in the real world too. Yes, in cities around the world there is a plethora of local customs, cuisines, and traditions that have been practiced and handed down over the course of centuries making each place unique. But increased globalization and tourism is changing this. You could travel to San Francisco, Paris, Seoul, or Sydney and live the exact same day. You could start your day with a Starbucks coffee, eat Chipotle for lunch, shop at Rag and Bone or Louis Vuitton in the afternoon, and head to the nearest Nobu for dinner. And sadly, many people travel from city to city doing exactly this. For the experienced traveler it’s relatively easy to go from place to place and not participate in the monoculture exploring and enjoying the local customs and most importantly the cuisines.

But in blockchains it’s not so easy to avoid the monoculture. We have all of the problems of monoculture, without the centuries of local customs to counteract. Users on any of the evm chains can swap tokens using Uniswap, borrow and lend using Aave, and swap their stablecoins on Curve. On other non-evm chains you will find the same types of core protocols and primitives, but with different names and uis. Going off the beaten path and onto the cobblestone to find the mom and pop shop on the blockchain is much more difficult. Namely because they are far and few between.

If blockchains are cities we need to build a more rich eocsystem of local customs and cuisines, not copy the ones that worked in other places. If we don’t, the world we’re building will be a lot less exciting.