Exploring the future of social networking in Web3 (1): from 0 to 1, using social graphs to complete the cold start of applications

By PAUL VERADITTAKIT, Partner, Pantera Capital

Compilation: Deep Tide TechFlow

This article is the first in a series of decentralized social articles written by Pantera partner PAUL.

This series explores how today's technologies and trends can solve a series of problems of decentralized social networks, and provides specific explanations and explorations for each problem.

In 2017, a group of MIT Media Lab researchers claimed in Wired that decentralized social networks "will never succeed." In their article, they cite three impossible challenges:

1. The problem of attracting (and retaining) users from scratch
2. Issues of handling user personal information
3. User-Facing Advertising Issues

In all three cases, they argue, the incumbent tech giants, such as Facebook, Twitter, and Google, simply do not leave room for any significant competition due to their extensive economies of scale.

Now that the time has come, what was once hailed as "impossible" no longer seems so far away, and we seem to be at the dawn of a shift in the concept of social media networks. In this three-part series (this is the first), we will explore how new ideas in Decentralized Social (DeSo) can solve these "old" problems, including:

1. Using Open Social Layers to Solve the Cold Start Problem
2. Use personal identification and cryptography to solve user identity issues
3. Use the token economic model and incentive mechanism to solve the income problem

Social Graph and Cold Start Problem

Social media platforms have always faced a cold start problem: attracting and attracting users without an existing user base or network effects. Traditionally, newer social media startups like Snapchat, Clubhouse or more recently Threads have tried to overcome this with strong marketing and pure marketing capabilities. By grabbing everyone's attention at the right moment, whether it's through novel UX design, media headlines, or FOMO, they unleash a massive sign-up blitz that builds user barriers on the platform almost instantly. For example, Threads managed to reach 100 million users in just 5 days.

But often these successful campaigns face an existential crisis: How do you keep all those users and keep generating new content (and profits)? This is a problem that Clubhouse faced before, and it is also a problem that Threads is currently facing. With the demise of these apps, so do the lucrative social graphs and profiles of users built by these platforms, so aspiring social media networks of the future will need to repeat the difficult marketing tactics once again to reboot their networks.


The fundamental problem behind all of this is that in a Web2 social network, the social graph (annotating the relationships between users) is inextricably combined with the social application itself (such as Facebook, Twitter or Instagram). These two levels are symbiotic: the novelty of the app drives the development of the social graph, which in turn becomes the main barrier to social media adoption. For all their problems, the reason why users don't leave Facebook, Twitter, and Instagram is simple: All our friends are there.

But what if we separate the social graph from the social application? Even after Clubhouse (or Threads) disappears, we can still leverage the social graph created on them to easily launch another social application. This is Web3's answer to the cold start problem.

Use the public chain as an open social graph


In a sense, a public blockchain like Ethereum is a social graph itself. If I look up an ENS domain name or a person's wallet address on Etherscan, I can look at that person's on-chain social profile: what assets they hold, who they transact with, and infer which communities they belong to.

This kind of on-chain social profile seems like a natural starting point for a new decentralized social network, and indeed, some companies seem to be exploring this path.


For example, Debank uses this on-chain data to initiate a message-style Social network. 0xPPL has also taken a similar route, trying to use on-chain user profiles to build a Twitter-like social network. This general strategy of making raw transactional data readable and explainable to "common" users has been accelerated by using advanced large-scale language models such as GPT-4. For example, Cymbal is said to use GPT to generate conversational summaries of transactions and trends to create a hybrid of data sources, news feeds and future social networks.

Build a native social graph protocol

One problem with relying solely on public blockchain data (such as Ethereum) is that the data is not rich enough for social applications. Because public blockchains are built first and foremost for financial applications, not social applications, data collected natively on-chain, such as transaction history, account balances, and token data, is not necessarily most useful for social networks.


Rather than just using native on-chain data as a social graph, one idea is to build a new, dedicated social graph protocol on top of public blockchains. For example, Lens Protocol exploits a key observation that in social applications, there are common factors of social interaction, which they abstract into different on-chain actions such as “post”, “comment” and “mirror” ( i.e. share or retweet).

Farcaster has similar abstractions in its social graph, such as "cast" (post), "reactions" (like), and "amp" features, where users can recommend other users worth following. The main difference between Farcaster and Lens is how they are technically implemented - Lens puts everything on the Polygon blockchain, while Farcaster puts its ID registry on Ethereum itself, with a Delta graph on L2 Form runs its social graph.

A third notable social graph protocol is Cyberconnect, which puts more emphasis on link aggregation (both on-chain and off-chain sources) through its link3 mechanism, and focuses on events and fan clubs as initial use cases.

The key to these social graph protocols is that they don't necessarily build top-level social applications like Twitter, Facebook, or Instagram. Instead, they provide the open social graph layer (essentially an SDK) needed to build and extend these top-level applications. As mentioned earlier, the core advantage of this is that even if a once successful social application disappears (like Clubhouse), the generated social graph can still be used by other developers. Therefore, it only takes one marketing campaign or one successful app to start the whole ecosystem.

Designing decentralized social media from scratch

A third strategy is to build a decentralized solution from the ground up. The premise is that social media apps are the cornerstone of our digital experience, and thus require a dedicated blockchain (or other decentralized) solution that localizes the basic operations of social media apps, rather than by supporting A protocol built on top of the infrastructure for financial use cases. In short, we need a kind of "application chain" of social media.


One of the most notable projects in this strategy is DeSo, which is building an L1 blockchain focused on social applications. Unlike other mainstream public blockchains that focus on "transactions per second", DeSo focuses on optimizing "posts per second", as well as the needs of social applications to handle communication and storage. And general purpose blockchains such as Ethereum are not necessarily optimized for this. On top of this L1 blockchain, DeSo plans to build a variety of social applications, including long-form content (such as Substack), short-form content (such as Twitter), and Reddit-like applications.

Other decentralized social media platforms, such as Bluesky and Mastodon, can also roughly follow this strategy of designing decentralized social media from the ground up. Strictly speaking, they are not blockchain-based solutions, but rely on server systems to ensure that posts are sufficiently decentralized. For example, Mastodon uses an email-like system where users can choose between different service providers such as Gmail, Hotmail or iCloud. Just like an organization can set up and customize its own mail server, each "instance" on Mastodon will be a self-managed and customizable community. On the other hand, Bluesky is an application developed based on the open source AT protocol, which is essentially an open social graph with APIs such as "follow", "like" and "post", designed for social media platforms like Twitter Optimized.

What DeSo shares with projects like Mastodon and Bluesky is that they reject the notion that existing public blockchain designs (represented by the EVM) are suitable for social networks. While this approach undoubtedly provides these projects with more granular control over design decisions and user experience, it also cuts off potential connections and cross-influence with DeFi, existing NFT communities, and other mature elements in the Web3 ecosystem. Furthermore, what remains to be seen is the extent to which these solutions are “decentralized,” especially in an environment where their decentralization is not guaranteed by a public blockchain. Will these solutions end up bundling the social graph with social apps like existing social networks do, or will they sufficiently decentralize the social graph layer and attract a variety of apps and development teams? This is a key question for the social future of Web3.