From Variant fund by Alana Levin

We’re seeing the emergence of a new social graph in real-time: Farcaster. Up until two weeks ago, today’s most popular client (Warpcast) looked, at face value, similar to a Twitter clone. Then the team launched Frames and it kicked off a wave of growth as it became clear that Farcaster’s permissionless infrastructure enables a new distribution channel. 

But even beyond Frames, there’s a rich stack of layers that the Farcaster network has unbundled and made open to developers. And with that unbundling comes new opportunities.

In my view, there are four layers of the Farcaster stack. At each layer, there are different jobs to be done and different resources that exist. From bottom to top:

Modified from the Farcaster Documentation, courtesy of Omer Demirtas

Good news for startup founders: there are open opportunities at every layer of the stack!

At the onchain layer live resources like storage contracts and accounts. These are net-new assets—and where there are assets, there are opportunities for issuance and exchange. The Farcaster team controls issuance, but maybe venues for exchange will emerge. We’re already starting to see some marketplaces pop up for trading accounts, where accounts that were early to the network (denoted by their Farcaster ID, aka FID) are selling at premiums. We haven’t yet seen markets for renting out unused storage (in part because storage units are permissioned), but I could see that maybe changing at some point in the future.

At the Farcaster protocol (offchain) layer, the main resources are the fnames and the data generated by the API (maintained by hubs). We’ve already seen one company—Neynar—emerge as a one-stop shop for making it easy to build on Farcaster: it runs hubs on behalf of clients, maintains a version of the API, helps with creation of tools like bots and Frames, and more. It’s basically “Farcaster-support-as-a-service.” FaaS is a category where I anticipate there could be multiple winners, especially as the network grows.

To my knowledge, no one has really experimented yet with fnames — probably because the Farcaster team owns the registry. But maybe this is an opportunity. Would it be possible to fork the registry? One could imagine a new protocol maintaining a resolver between their forked namespace and the canonical f-namespace to keep user accounts synced. The benefit might be something like making the offchain namespace more permissionless, or adding company-specific features to how certain names on the network interact. Currently, the Farcaster team can revoke fnames from accounts (example motives would be if someone is squatting on a popular brand name or is impersonating someone else). These are valuable features, but there may be a design space in forking the registry to test other elements of what is and isn’t allowed with the names.

The clients and headless layers are what I’m personally the most excited about. Today, they look like two distinct layers: clients have their own feeds, while headless apps live within others’ feeds. Two of the most net-new things about Farcaster are that users’ data isn’t restricted to a single interface, and that every account is connected to a wallet. Clients leverage the first; headless projects capitalize on the latter.

If we anticipate a world where there are many engaging Farcaster clients, the question becomes, how do we get there? One route is for developers to directly build new clients: find a media type that isn’t a first-party citizen and build a client to give it a first-class experience. One could argue that this is how we saw popular apps in web2 find fit, from Instagram (images) to Twitter (micro-blogging) to YouTube (video) to Vine (very short-form video). Maybe there will be a similar pattern with new Farcaster clients as well — but I’d look for the emergent data types (like assets or Frames) as opposed to media types that developers have had years to iterate on. Twitter started out as micro-blogging but is now multimedia. Same with YouTube, Spotify, and many others. Thus, the unlock is probably in the new stuff: a first-party client for a data type folks haven’t yet mastered.

If I were starting a “client” company today, though, I’d start headless. In practice, this means finding a tool that meets and provides value for users where they are today, while cross-populating a new client with whatever content that tool generates. 

We’ve seen this work before: YouTube started by giving users a tool to embed videos on their personal sites. As that catalog of content grew, YouTube cross-posted it on the YouTube site—generating a valuable reservoir of videos that created a first-order reason for consumers to visit YouTube’s site. The same thing could be true of headless apps: build a bot (or frame) to perform a service within existing feeds, but use that initial engagement to gradually drive adoption of another interface. Bountycaster is my favorite example to date. I’m optimistic there will be more!

There’s a lot of opportunity. It’s very exciting. Six months ago, Farcaster looked very different from how it looks today. And six months from now, it’ll probably look even more different (in a good way!) than it does today. Sheryl Sandberg has a quote: “If you’re offered a seat on a rocket ship, don’t ask what seat.” Farcaster is a rocket ship. Starting a company in the ecosystem is, in effect, building your seat. Maybe still ask yourself what seat you’d be excited to build, but the takeaway from this piece should be that there are indeed many seats to build.  

And finally, if you got this far without yet knowing what Farcaster is, you can (and should!) sign up for an account here.