Farcastoooor

The Farcaster Thesis

Farcaster has recently had hockey stick growth with users, engagement, and token valuations hitting new ATHs. You might be wondering, is this a flash in the pan or does it have legs?

This post is meant to be our Farcaster thesis. After walking through what it is, how it works, and why it exists we share our thoughts on its future potential as well as limitations. 

Basics: Apps vs Protocol

Farcaster is a protocol designed to power many user-facing clients/apps (to be used interchangeably).  If you’ve ever interacted with Farcaster, chances are you’ve done it through the most popular client Warpcast. However, there are already dozens of other apps with a variety of features. If Farcaster succeeds many of these will be widely adopted. Motivations of Farcaster the protocol and its clients/apps (eg. Warpcast) vastly differ from one another.

Farcaster defines itself as a ‘sufficiently decentralized’ network. It’s run by a decentralized network of nodes known as Farcaster Hubs. The protocol, first and foremost, values credible neutrality. Its primary duty is to make sure all clients access and share the same user data, i.e. the social graph (e.g. posts, likes, follows, etc.).  The bulk of this data is stored off-chain on the hubs and never touches blockchains. Hubs collect data from clients, other hubs, and the Ethereum network. Each hub stores an entire copy of the Farcaster data (more on this later).

Launching a Farcaster Hub is permissionless. Anyone can launch a Farcaster Hub and start gossiping with peers to maintain a full copy of the up-to-date Farcaster data. Today, the resource requirements are relatively low with the initial setup taking around 30 minutes and costs about $100 per month to maintain. 

Clients/apps, on the other hand, have very different motivations than the protocol. Unlike common belief they are, more often than not, privately funded/governed for-profit applications. They may have proprietary content moderation algorithms and spam detection tools to de-prioritize/censor content and jurisdiction-dependent terms & conditions. 

Crucially, however, even when a client is entirely centralized, it doesn’t have any control over data posted on Farcaster. As mentioned above, the distribution of data is taken charge of by the ‘sufficiently decentralized’ Farcaster protocol. Decoupling data distribution from clients might look subtle but has far-reaching implications.

To see how, recall the Twitter vs Clubhouse competition that took place a few years back. Despite launching as a new viral voice chat product, Clubhouse failed to sustain the early attention it gathered for too long. When Twitter decided to enroll a similar feature with ‘spaces’, the battle became uphill for Clubhouse. Despite being the innovator of the feature, Clubhouse lost the battle to Twitter, the social media giant with unmatched distribution of hundreds of millions of users. 

The power structure between Farcaster clients looks a lot different than this. For example, despite its 95%+ market share, Warpcast has no lock-ins over any user data. In theory, tomorrow someone can plug a new voice chat feature into Warpcast, ship it as ‘Warpcast v2’, and start populating user feeds with the same Farcaster data from day one. Users could carry their followers from ‘Warpcast’ to ‘Warpcast v2’ with little effort.

By decoupling data distribution from feature set, the Farcaster aims to form a common ground where app