Remember the days when your Facebook feed was filled with virtual farms, crops, and livestock? Zynga's Farmville wasn't just a game; it was a social phenomenon that demonstrated the immense potential of integrating gaming with social media. With millions of daily active users at its peak, Farmville's success was a testament to the power of Facebook's social graph. However, for many developers this reliance on a centralized platform came with significant risks and challenges. Today decentralized social graph protocols like Lens and Farcaster offer a glimpse at a better medium for social game developers to build upon without the platform risk. In this article, I’ll delve into the intricacies of these protocols, exploring their unique approaches to decentralizing the social graph. I'll compare their traction, examine their technical foundations, and talk about some of the reasons why we’re excited about the ecosystem. To get a pulse on the developer side I built a custom Farcaster client inside of CCP’s Project Awakening. This leverages Farcaster channels to provide a token-gated, moderated in-game broadcast system to extend an alliance’s reach outside the game. The aim of the project was to demonstrate how games can permissionlessly “plug into” decentralized social networks in order to aid discovery and distribution, as well as extend gameplay beyond the boundaries of the game.

Anyone on Facebook in the late 00’s will likely remember playing Farmville. Developed by Zynga, the farming simulator game was wildly successful. Although not the first game to launch on Facebook, the success of Farmville brought a lot of attention to Facebook as a gaming platform. Within 4 days of launching the game had over 1 million daily active users (DAU) and at its peak boasted ~30 million DAU. These numbers were made possible by leveraging Facebook’s social graph for user acquisition (UA) and engagement. For a social graph explainer see appendix A. Developers could drive virality for their games by encouraging social activity between players, such as inviting friends, visiting other farms and sharing content.

However, by building on top of Facebook, game developers were taking on significant platform risk. This reared its head when Facebook enabled users to filter out gaming content in response to complaints that the spam these games incentivised users to create was degrading the feed for the ordinary user. Just like that, the primary UA mechanism for games on the platform was significantly restricted. We saw this platform dependency backfire again when, in an effort to drive additional revenue through monetized ads, Facebook introduced Facebook Credits in 2011. The platform henceforth required all 3rd party developers to process payments through these credits, allowing Facebook to take a 30% cut of every transaction. As many of these businesses relied on the distribution Facebook provided they had no choice but to stomach the hit to their profit margins. 

Zynga was able to achieve outsized success because they had a special relationship with Facebook who would ensure they hit their monthly active user (MAU) targets by controlling distribution across the network. In exchange Facebook required exclusivity and exerted control over what launched, when it launched and how successful it could be. This relationship further exacerbated the issues other smaller Facebook game developers were facing, as they could no longer compete on a level playing field. Ultimately, the success of Zynga’s titles, regardless of their dependency on Facebook, enabled them to fast-track to an IPO in late 2011 at a valuation of $7 billion. 

This tells a cautionary tale for developers. Leveraging platforms that aggregate users and sell their attention is a very effective way to acquire and monetize players. However, the platform's incentives are not necessarily aligned with those of 3rd party developers. Entire business models can be flipped on their head by a single parameter change made to an algorithm. The platforms hold all the power in this scenario. 

But imagine if these sorts of businesses could be built without the platform risk, where the social graph is decentralized and collectively owned by its participants. Where the rules governing it are transparent and subject to community governance. This is the promise of web3 social networks.

There’s a lot being built in the web3 social space. This article will focus solely on decentralized social graph protocols, specifically Lens Protocol (from hereon shortened to Lens) and Farcaster.

The goal of both Lens and Farcaster is to decentralize this social graph at the protocol level and separate it from the app level, thereby enabling permissionless 3rd party app development. The following section highlights the differences in approach and traction of both protocols.

Lens is uncompromising on decentralization. The core team deployed an initial set of onchain primitives then left it to the community to build their own clients. This has resulted in a diverse and grassroots network, with community governance (albeit without a token) dictating the roadmap. Over the past few weeks, the protocol’s DAU has ranged between 20k and 30k with the majority of users split across three clients: Phaver (~50%), Hey (~25%) and Orb (~15%). The data also shows that despite users being able to seamlessly move between clients, over half the active users stick to a single client, with ~20% using two clients and ~20% using three or more clients.

The Farcaster ecosystem on the other hand is primarily driven by a single team, whose approach is more aligned with how traditional software is brought to market, i.e., centralized execution, fast dev cycles and regular user feedback. The team started with a “sufficiently decentralized” social network, only putting the bare minimum onchain (see tech overview section). The same team are also building Warpcast, a Twitter-like client, which they use to develop and test new features before enshrining them in the protocol. Although there are other teams building Farcaster clients, such as Supercast and Farcord, the vast majority of users are currently interacting solely with Warpcast. At the time of writing the Farcaster protocol has ~80k DAU (~3x that of Lens).

There are pros and cons to both approaches. One may consider Lens’s decentralized approach more in line with web3 values. Compared with Farcaster, Lens has significantly more logic encoded in smart contracts, whereas much of what users interact with on Farcaster are features of the centralized Warpcast client. However, as there is single team driving execution on both Farcaster’s protocol and client layers, time-to-market for new features is quicker and the product generally feels more cohesive. This approach does require an element of trust that the team will make good on their promises to progressively decentralize features from Warpcast into the protocol layer.

As a result of the decentralization-first approach, Lens has a diverse and vibrant community who are balanced across multiple clients. This makes the network more resilient, as it’s less dependent on any single client or centralized entity. There is also a thriving creator economy on Lens thanks to the content monetization options enabled through modules (more on this later). However, bootstrapping a grassroots network takes time. This may be why Lens has significantly less DAUs than Farcaster, despite having been in development a year longer. Furthermore, even with portability between clients, the data shows that a lot of users still only use a single client. Given the relatively small user base of Web3 social networks, spreading them too thinly across multiple clients at this stage may actually degrade user experience, hurt retention and mask adoption. As the majority of Farcaster users are currently aggregated into the Warpcast client, the experience is more in line with what users expect from a Web2 social media platform.

Finally, there are open questions around sustainability and value accrual. Does value accrue at the app level or the protocol level? Can multiple clients targeting the same set of users on a protocol exist simultaneously without cannibalizing each other? Or will we see specialized clients that cater to a specific niche, e.g. sports fans. In order to create a thriving ecosystem, incentives probably need to be aligned through the protocol layer. Moreover, these social graph protocols are not yet interoperable with each other, i.e., your Farcaster account cannot access content you’ve created on Lens and vice versa. Without some way to unify a user's onchain identity we risk recreating the siloed experience we currently have in Web2. 

At this stage we think it’s useful to give a brief architectural overview of both Farcaster and Lens to help readers contextualize the broader thesis we’re outlining in this piece. We’ll keep it high level but will include more detail in the appendix where applicable.

Farcaster is a “sufficiently decentralized” social protocol. The team have made a number of strategic tradeoffs to maximize scalability and performance whilst decentralizing core pieces. Onchain components include several registries to track account ownership, storage allocation and signer keys generated by 3rd party clients. 

The social graph is stored as a Conflict-Free Replicated Data Type (CRDT) and replicated across a network of peer-to-peer nodes (a.k.a. Hubs). Whilst this data is not onchain, it is distributed and therefore resilient and available. Furthermore, offchain systems are able to achieve sufficient security guarantees by requiring cryptographic signatures from onchain systems. 

Channels

Channels are currently a feature of the Warpcast client, but will soon migrate to the protocol layer and become available for all clients to use. In a similar fashion to subreddits, channels provide separate feeds for users to come together around a common topic. Admins can also optionally assign human or bot (e.g., automod) channel moderators.

Frames

Frames allow any cast to be transformed into an interactive app, and their introduction in January 2024 resulted in a surge of developer activity on Farcaster (see fig.1).

Frames extend the Open Graph (OG) protocol, which was developed at Meta in 2010 to enable any web page to become a rich object in a social graph. The protocol specifies meta tags that can be added to web pages to customize how information is displayed when the page is shared on social media. Frames add dynamic image tags, as well as button tags that when clicked trigger a callback. In addition to executing some arbitrary backend logic, the result of a button click could be the returning of a new image and set of buttons. Through this simple mechanism developers can construct lightweight apps that run directly in the social feed. Furthermore, when the user clicks a button, the subsequent payload sent to the Frames server contains a cryptographic signature, proving the action’s authenticity. This can be used to trigger onchain transactions, opening up many possibilities including onchain mini-games, frictionless in-feed minting and e-commerce.  

These apps are running on the developers own servers and can be displayed in any client able to parse the meta tags and submit signed payloads. Clients like Warpcast simply parse and display the OG tags, and allow users to send signed payloads. Although the client is able to censor a specific frame, or stop supporting frames altogether, the app will remain functional and usable across all other clients on the protocol. 

Although Farcaster was the first to introduce frames, their success has led to other protocols exploring integrations, including Lens.

Lens has been live on Polygon’s PoS chain since May 2022 and went permissionless in Feb 2024. On Lens, everything is tokenized. A user’s Lens profile and handle are represented as NFTs and grant the holder ownership over their content and social graph (stored on Arweave). The links between profiles are tracked onchain using Follow NFTs, which are issued to users who follow an account. 

Modules

A key component of the Lens stack are modules. These are governance whitelisted smart contracts that allow custom functionality to be triggered when various onchain actions are performed such as following, referencing, collecting or tipping. Follow modules allow users to specify conditions around who can follow them, e.g. subscription fees. Reference modules allow users to define rules around who can comment on or reshare their content, e.g. only paying followers. Open Action modules extend logic around actions like tipping, voting or collecting content (e.g. pricing and scarcity). Modules are particularly powerful for content creators, as they enable direct monetization through the protocol in a flexible way.

Supporting Infrastructure

When building an onchain protocol designed for mass adoption, scalability is a key consideration. The core Lens Protocol contracts are currently deployed on Polygon PoS with execution handled by an optimistic L3 network called Momoka. 

However, recently the team announced they will migrate to their own chain built using ZK Stack, a modular, open-source framework based on the zkSync Era code. We’ve previously written about the scalability afforded through the use of zero knowledge (zk) cryptography so we won’t expand on that here. Lens will initially launch as an EVM-compatible validium and convert, in a 3-phase rollout, to a volition zkEVM network. For an explanation of the differences between zkRollups, validiums & volition, see appendix B.

So why does all this matter to us as gaming investors? 

An open and permissionless social graph allows a vibrant open source community to develop around it. We’ve seen throughout history that open source development typically results in diverse ecosystems and more robust software, just look at Linux. From niche utility apps created by solo developers to enterprise-grade products, the freedom from relying on tools (and permission) from a centralized entity broadens the scope of what’s possible.

That being said, due to the superior distribution and unit economics (e.g., CAC/LTV ratio), as well as readily available tooling of platforms like Meta, many devs consider the risks worth it. Clearly, decentralized social protocols have a long way to go before coming anywhere close to challenging the incumbents. However assuming they do reach critical mass, they can potentially offer the advantages of Web2 social networks without the platform risk. 

So how do Web3 social networks reach critical mass? Obviously there are UX improvements that need to happen and there’s some really interesting developments on this front happening in the chain abstraction space. However, the ability for tokens to bootstrap user liquidity, drive behavior and align incentives should not be overlooked. There’s much we could discuss here but one interesting social primitive to emerge in Web3 social is tipping. 

The Degen token was initially airdropped to early participants of the Farcaster ecosystem. Users receive a daily Degen tipping allocation on Farcaster based on their level of social activity. They can send a proportion of this allocation to any users they deem to be creating value. This is done by commenting something like “333 $DEGEN” under another user’s cast. No tokens exchange ownership here, however subsequent airdrops of Degen are allocated proportionally to the amount of tips users received. This simple mechanism helps creators monetize their content whilst fostering a healthy and genuine network.

The initial Degen airdrop brought a lot of attention to the community and this resulted in a number of developers building applications that supported the Degen token, and in March 2024 the Degen L3 chain was announced. Built using the Arbitrum Orbit stack along with custom pre-compiles, the chain aims to provide a better platform upon which developers can launch social applications and games. The Degen token sits at the heart of the ecosystem and is used to pay for gas. The space is very early but dapps currently deployed on the chain include a short form video app called Drakula, a prediction market Perl and others.  

Degen is a great example of how a fairly-allocated airdrop, coupled with an open social graph, can be used to drive community growth and developer activity through the alignment of incentives. All this was deployed without having to ask the Farcaster team for permission. We will likely see this playbook attempted by many app developers (including game studios) to acquire new players based on their existing social activity and onchain gaming history. Importantly, in this scenario users are the direct beneficiaries of marketing spend which would otherwise have gone to adtech providers in a Web2 paradigm. All this being said, it will be interesting to see how retention tracks once the Degen airdrop campaigns conclude. 

SocialFi refers to a category of social apps that allows users to financialize their profiles through the tokenization of the social graph. One notable example is Friend.tech which allows influencers to sell tradable keys granting holders access to exclusive private chats. The more popular the influencer, the higher the market is willing to bid for the keys along a bonding curve. As influencers receive a percentage of every key trade, they’re incentivized to provide the best content and alpha in order to drive the value of their keys. Another example that gained popularity recently is Fantasy Top. This is a trading card game where user X profiles are each represented as collectable NFT cards, with stats that are dynamically updated based on the influencers recent levels of engagement. Players collect cards to build decks, which they can then use to compete against each other in a Top Trumps-style PvP game to earn rewards. 

Both of the above SocialFi examples are built using the X social graph but we’ve seen these products inspire similar launches on Farcaster. Alfafrens are building a Friend.tech like product that leverages the Farcaster social graph and the Degen token to subscribe to private group chats. Farcards employs a similar mechanism to Fantasy Top, whereby every user has a card that others can collect. Importantly the primitives that both these products build upon are owned by the users. Moreover, building SocialFi on top of an inherently financialized platform like a blockchain creates more opportunities for composability with existing DeFi applications, opening up the design space for more novel use cases. 

SocialFi in its current form is largely driven by speculation. Friend.tech saw sharp rises and falls in engagement following announcements such as the Paradigm investment and $FRIEND airdrop. The majority of users appear to be purchasing keys not to participate in private chats, but with the hope they can flip them for a profit. Fantasy Top has also seen a drop off in activity in recent months, as user attention moves onto the next shiny thing. One may look at this speculative behavior in a negative light as it tends to attract mercenary capital that aims to extract as much value from the ecosystem as possible. Right now there’s clearly a retention issue, however it’s interesting to note that this speculative premium has allowed mid-tier creators to earn multiples more through trading fees than they would otherwise earn through primary sales of content and subscriptions. 

On Meta ads pricing is based on an auction system where ads compete for impressions based on bid and performance. This mechanism could be made transparent and provably fair through the use of smart contracts. Assuming a Web3 version of this uses a protocol token alongside volatility-resistant pricing mechanisms, developers could potentially offset some opex against token appreciation over time. Furthermore, through holding tokens developers maintain an ownership stake in the protocol, which typically translates to governance rights. Furthermore, the immutability and transparency of smart contract-based logic offers a level of comfort that business models won’t be nerfed on a whim of a centralized entity. We believe this, combined with healthy DAU growth, will progressively make these platforms more attractive to developers. 

Until recently the way users typically found out about new mints was through posts on X or Discord. However, with the rise of decentralized social graphs, developers are able to build social features directly into their existing apps and games. Startups like Daylight simplify this by offering a transaction recommendation engine based on what a user's friends are interacting with onchain. Through these recommendations, users can see what assets their friends recently minted or what games they’ve played onchain. This makes the user experience personalized and relevant, aiding discovery and increasing the likelihood of users sticking around.

At the time of writing Warpcast is experimenting with narrowcasts on Farcaster. A narrowcast is a cast that is only shown to followers of specific channels. This avoids the aforementioned issue on Meta of gaming content spamming user feeds who’re not interested in it. Combine this with bots that trigger server-based game functions upon detection of a specific phrase/command, and the channel has now become the game interface. Frames, with their limited controls, need only provide a way for players to query game state and receive feedback. 

This could have big implications for fully onchain games, sometimes referred to as “headless games”. In a similar fashion to how multiple clients can permissionlessly interface with a decentralized social graph, a social feed could serve as a client for the onchain game world. This may also help solve the lack of distribution many fully onchain games suffer from right now. 

It remains to be seen whether multiple general purpose clients like Warpcast on Farcaster, or Hey and Orb on Lens, can co-exist sustainably on the same protocol. As DAUs grow we will likely see a proliferation of clients dedicated to specific verticals like gaming, art and sport, with a UI/UX tailored to the target demographic. From a user perspective, they will be able to interact with any of these clients and still have access to the social graph they’ve spent time and effort cultivating. We’re already starting to see early signs of this with startups like Farworld Labs. The team started by building Farworld, a frame-based onchain monster collection/battler RPG. Now they're working on a dedicated Farcaster gaming client and suite of developer tools called Farcade. The platform will help developers to build and launch frame-based games that integrate with the Farcaster social graph. Gamers will be able to play the games directly where they already are, i.e., in the social feed, or in the dedicated Farcade client for an enhanced UX.

Due to their limited interface, Frames may be better suited as in-feed top-of-funnel marketing tools, as opposed to full fledged games. Studios can reduce player acquisition friction by removing the need for users to browse to external sites and connect wallets. By nature of having an account on Farcaster, users already have their wallet connected. For instance, players could mint in-game items from their feed, making them more likely to visit the game to use them. As frame actions are signed by the user, minting and even game account creation could be abstracted away for the player.

As part of my research process into a new area I like to get into the trenches with the devs and build something. I find this to be a very effective way of getting to grips with the ecosystem and tools. To compliment this piece I participated in the Project Awakening hackathon for CCP’s upcoming blockchain-powered, single-shard survival game set within the EVE universe. The game uses the MUD framework to manage the universe's onchain state. This allowed CCP developers to define the immutable rules of the universe (aka digital physics) through a set of smart contract systems. Furthermore, through the use of hooks, 3rd party developers can trigger custom code when certain functions are executed, such as depositing an item into a storage unit.

Over several weeks I built a stripped-back Farcaster client inside the game that allowed any player holding a specific in-game ERC-20 token to cast to a predefined Farcaster channel. As is the case with any Farcaster client, this requires players to first generate a signer key, permitting the client to post on their behalf. To achieve this the dapp presents players with a QR code they can scan with their phone to create a signer on OP mainnet. Upon successful creation of this signer, the user’s Farcaster ID (FID) is added to a MUD table inside Project Awakening. Finally, a moderator bot operating inside the client, polls the Farcaster channel and checks the FID of every cast against the FIDs stored in the MUD table. Only casts from players who have authenticated in-game are promoted to the “Main” channel feed.

One could imagine a feature like this being used by an Alliance to extend comms outside the game to recruit players, spread propaganda, post bounties etc. A lot of "gameplay" within the EVE universe is played outside the boundaries of the game already, in spreadsheets, discord servers and other 3rd party software. Integrating with decentralized social graphs seems like a logical next step.

The point of this hackathon project was to show that any game can permissionlessly “plug into” a decentralized social graph and effectively become its own standalone client. By interfacing with these networks, games can benefit from the distribution and engagement they potentially bring.

Readers can learn more by visiting the GitHub repo or watching a short demo video.

Farmville’s success underscored the power of leveraging social networks for game distribution and engagement, but it also highlighted the inherent risks of depending on centralized platforms. Changes in Facebook’s policies dramatically impacted developers, revealing the precarious nature of building on such platforms. Decentralized social graphs promise to shift the balance of power back to developers and users, offering a more resilient and equitable framework. By decoupling the social graph from the application layer and leveraging the transparency of the blockchain, these protocols mitigate the platform risks that plagued earlier social games. 

That being said, Web3 social networks are still in their infancy, and currently do not offer meaningful distribution for studios. As a result many developers still consider the risk of building on a centralized network a worthwhile tradeoff. Tokens are a great mechanism for driving behavior and bootstrapping user liquidity, which could help grow these decentralized networks over time to a point where they can challenge the incumbents. Tokenization of social profiles along with other assets, opens up an interesting and relatively unexplored design space. Although we’ve yet to see a sustainable model, the speculation-driven premium of gamified SocialFi could help creators to monetize their brand more effectively. This could lead to a flywheel effect where better monetization attracts creators, who compete for the attention of users by delivering high quality content, which in turn attracts more users.

Having the user’s onchain identity as an open core component gives developers a lot of flexibility around what they can build. Some ideas will work, some will not, but the important point is that these protocols open up the ecosystem and allow more shots on goal. This increases the likelihood of someone building a unique and novel experience that is only possible by leveraging onchain primitives. Furthermore, every successful app and experience launched helps to strengthen the underlying protocol. With good incentive alignment this could lead to the creation of robust and sustainable ecosystems. 

To understand what a social graph is first we have to define what a graph is. A graph is an abstract data type that consists of vertices (a.k.a. nodes) connected with edges (a.k.a. links). The image below shows how social actions can be structured as a graph data type, hence social graph.

The nodes in the graph (shown on the left) represent data objects like accounts and content. The links show the relationship between nodes, such as Bob liking, sharing and/or commenting on Alice’s post. This data structure is very effective at representing relationships between people and every piece of content they interact with in a network. These graphs can get very large and complex as the network grows. Check out the visualization below showing a single user’s Meta social graph.

Validiums and zkRollups are very similar but sit at different points on the data availability (DA) spectrum. Both are L2 networks where user transactions are executed in batches (rolled up)  and settled to Ethereum to transition the network to a new state. During this process a validity proof is produced that mathematically guarantees the accuracy of the computations in a batch. 

The state of the L2 network, including all user account balances, is represented in a Merkle tree data structure. The storage of this data is where validiums and zkRollups differ. validiums only post the Merkle tree root (aka the state commitment) along with the validity proof to Ethereum. This allows the Ethereum smart contracts responsible for managing the L2 state to verify the proof and progress the network state. The rest of the Merkle tree is stored on an offchain network of nodes known as a data availability committee (DAC). zkRollups on the other hand post the entire Merkle tree to Ethereum, along with the validity proof.

So what are the tradeoffs? validiums offer significant cost savings by not posting the full rollup state to Ethereum. Additionally, as the data is not put onchain, they enable private state (crucial for DMs in a social protocol). However, using a DAC for DA introduces trust assumptions, as it’s possible that node operators could collude to withhold data. Whilst this would not allow a malicious actor to steal user assets, it would freeze access. They are therefore not suitable for securing high value assets. Conversely, zkRollups rely on Ethereum for DA, which comes at a higher cost but also no offchain DA trust assumptions. This makes zkRollups better suited for securing higher value assets.

A volition network allows apps to choose between both DA mechanisms depending on the cost/security tradeoff deemed suitable for a transaction. For example, liking your friend’s latest post on Phaver has little intrinsic value so can be handled by the validium and offchain DA providers. Sending your friend ETH or creating your onchain identity does require higher security guarantees, so this part of an app's functionality can be handled by the zkRollup. This setup aims to give developers the tools to build both cost effective and secure onchain applications.