Subscribe to HeimLabs
<100 subscribers
Subscribe to HeimLabs
<100 subscribers
“In tech, ‘good enough’ is never good enough for long.”
For Farcaster, a decentralized social protocol “good enough” once meant a messy, but functional, system. But as the network grew, that fragile foundation started to crack under pressure.
The answer? A bold re-architecture.
That led to Snapchain, a blockchain-like data layer designed specifically for social systems.
Farcaster was always conceived as a decentralized social protocol. The idea was to let users own their identity, own their social graph, and give developers a base on which to build social apps free from centralized gatekeepers. Identity and high security operations (like account creation) remain on-chain, but most user data posts, follows, likes, profile updates are stored off-chain.
To manage that off-chain data, Farcaster originally used a system called “Deltagraph” , a gossip or CRDT(Conflict Free Replicated Data Type) based network.
Under this system:
Every user action (post, follow, like, profile update…) was treated as a CRDT operation.
When a user did something, their node immediately applied the change locally, then “gossiped” it out to peers.
There was no global coordinator, no strict ordering, just peer-to-peer gossip and eventual consistency.
Early on, Farcaster reportedly served a modest user base; the network managed something like 100,000 users and ~500 transactions per second (TPS), with roughly 2 GB/day of state growth.
It worked but only up to a point.
As usage grew, more users, more apps built on top of Farcaster Deltagraph started to show significant weaknesses. The decentralized, gossip-based system began failing in ways that matter to real users.
Here’s what went wrong:
Because CRDT operations are unordered and asynchronous, there was no canonical “source of truth.” If two nodes had differing data (e.g. due to message loss, network partitions, or delays), there was no reliable way to reconcile automatically. A node could only detect divergence by comparing all transactions with every other node, a task that becomes utterly unmanageable at scale.
As the number of nodes and messages ballooned, keeping everyone in sync became infeasible.
Nodes sometimes miss messages (gossip failures), meaning some users’ data became inconsistent or out-of-date. Because CRDT offers only eventual consistency, there was no guarantee when (or if) nodes would catch up.
Moreover, and perhaps most troubling, the state size kept growing relentlessly. Every post, like, follow, profile change, all piled up. For active usage, that meant storage demands growing day by day.
Eventually, running a node became so resource-intensive (bandwidth, storage, compute) that only big players could realistically keep up. That starts undermining the decentralization promise.
The result? Deltagraph, once “good enough,” was no longer good enough. Farcaster needed rethinking.
Watch the video on snapchain :
Rather than patching the problems, the Farcaster team went for a full pivot: they replaced gossip-based CRDT with a brand-new system, Snapchain.
Snapchain is not a generic blockchain. It’s a blockchain inspired, social optimized data layer built specifically to handle social media workloads (posts, likes, follows, profile updates) rather than financial transactions.
What changed, and why this architecture works better:
Ordered, block-based transaction processing: Instead of random gossip, user actions are grouped into blocks. Each block is signed, linked to the previous block, and includes a global “state root” (via a Merkle-trie over account states). This ordering provides a canonical source of truth. Syncing becomes trivial: if you miss a block, just fetch it no need to diff massive histories.
Account-scoped transactions, non-Turing complete: Snapchain transactions are limited to social-native actions (post, like, follow, profile update, delete, etc.), each affecting only one account. No arbitrary smart contracts, no cross-account side effects. That simplifies validation and makes sharding by user account straightforward.
Sharding & pruning (garbage collection): Because each account’s history is isolated, the network can split accounts across multiple chains, improving scalability dramatically. Meanwhile, Snapchain supports pruning: old or reversed transactions (e.g. unlike deleted posts) can be removed after a certain time, preventing unbounded state growth.
Storage-rent model instead of per-action fees: Rather than charging gas per post/like (which would discourage frequent use), Snapchain opts for a “storage rent” model: users pay a fixed annual fee for storage. Within limits (e.g. number of transactions or storage quota), they can act freely. When limits are exceeded, older transactions get pruned. For typical social use, this feels effectively “unlimited.”
The result: a social-data layer that remains decentralized, but massively more scalable, reliable, and manageable.
With Snapchain live (mainnet launch in 2025), Farcaster unlocked capabilities that were previously difficult or impossible:
High throughput: Snapchain is designed to handle 9,000–10,000+ transactions per second (TPS), a level comparable to large centralized platforms and far beyond typical blockchains.
Millions of daily users: The architecture supports large-scale usage. Estimates suggest a capacity for 2 million daily active users on Farcaster apps.
Strong consistency & real-time sync across nodes: Because of block ordering and canonical state roots, nodes stay in sync reliably. No more “some nodes missing messages forever” missed blocks are detectable and fetchable.
Decentralization + accessibility: With pruning and sharding, running a node becomes more feasible for a wider set of participants. The network stays decentralized but scalable, avoiding the “only big servers” trap.
User-friendly experience: No gas fees per post or like, just a predictable storage rent. Users can behave like on traditional social media: post, like, follow, without worrying about per-action cost or blockchain latency.
In short: Snapchain reclaims the promise of decentralized social media not just as a technical novelty, but as a serious, usable alternative to centralized platforms.
No design is perfect. Snapchain makes deliberate tradeoffs to optimize for social use. Here’s what you should know.
Limited transaction expressiveness: Snapchain only supports a fixed set of “social primitives” (posts, likes, follows, profile updates, deletes). There’s no support for Turing-complete smart contracts, arbitrary logic, or complex multi-account transactions. This keeps things simple but less flexible compared to general blockchains.
Ephemeral history (due to pruning): Because the system prunes old or reversed transactions, the full historical record may not be kept forever. For typical social media usage, that may be fine (old likes/unlikes are rarely revisited), but it means history isn’t guaranteed to be immutable or permanent.
New complexity, new failure modes: Snapchain introduces block production, consensus, validators, and sharding, a step up from simple gossip. That adds complexity to the protocol, and potential points of failure (validator downtime, shard coordination, consensus bugs, version upgrades).
Storage-rent model tradeoffs: The “rent + prune” model means that heavy or long-term users may need to pay more (buy extra storage units), and some data might get dropped if quotas are exceeded. Also, different transaction types (posts, likes, follows) have separate quotas, which may lead to wasted capacity for some users.
In short: Snapchain sacrifices universality (no general smart contracts), permanence (pruning old data), and simplicity (added consensus/sharding complexity) but gains scalability, usability, and predictable performance for social use.
Snapchain shows that scaling decentralized social wasn’t just a performance problem, it was an architectural one. By replacing gossip with a purpose-built data layer, Farcaster proved the model can evolve without abandoning decentralization.
If Snapchain holds up under real adoption, it could pave the way for user owned social media at true Web2 scale. And that possibility alone makes this shift one of the most important experiments in Web3 right now.
Snapchain website
Snap V1 is our first no-code solution that brings fast finality to the OP Stack. We help deploy, manage and scale this integration for your chain, so you can focus on building the best experience for your users.
Discover new people, projects and tokens on Farcaster, the decentralized crypto social network and wallet for Base, Solana, Monad, BSC and more.
Revolutionize your business with HeimLabs' blockchain development solutions. Our expert team offers end-to-end services for smart contracts, DApps & more.
Follow HeimLabs for unapologetically practical Web3 dev content.
Twitter, LinkedIn.
“In tech, ‘good enough’ is never good enough for long.”
For Farcaster, a decentralized social protocol “good enough” once meant a messy, but functional, system. But as the network grew, that fragile foundation started to crack under pressure.
The answer? A bold re-architecture.
That led to Snapchain, a blockchain-like data layer designed specifically for social systems.
Farcaster was always conceived as a decentralized social protocol. The idea was to let users own their identity, own their social graph, and give developers a base on which to build social apps free from centralized gatekeepers. Identity and high security operations (like account creation) remain on-chain, but most user data posts, follows, likes, profile updates are stored off-chain.
To manage that off-chain data, Farcaster originally used a system called “Deltagraph” , a gossip or CRDT(Conflict Free Replicated Data Type) based network.
Under this system:
Every user action (post, follow, like, profile update…) was treated as a CRDT operation.
When a user did something, their node immediately applied the change locally, then “gossiped” it out to peers.
There was no global coordinator, no strict ordering, just peer-to-peer gossip and eventual consistency.
Early on, Farcaster reportedly served a modest user base; the network managed something like 100,000 users and ~500 transactions per second (TPS), with roughly 2 GB/day of state growth.
It worked but only up to a point.
As usage grew, more users, more apps built on top of Farcaster Deltagraph started to show significant weaknesses. The decentralized, gossip-based system began failing in ways that matter to real users.
Here’s what went wrong:
Because CRDT operations are unordered and asynchronous, there was no canonical “source of truth.” If two nodes had differing data (e.g. due to message loss, network partitions, or delays), there was no reliable way to reconcile automatically. A node could only detect divergence by comparing all transactions with every other node, a task that becomes utterly unmanageable at scale.
As the number of nodes and messages ballooned, keeping everyone in sync became infeasible.
Nodes sometimes miss messages (gossip failures), meaning some users’ data became inconsistent or out-of-date. Because CRDT offers only eventual consistency, there was no guarantee when (or if) nodes would catch up.
Moreover, and perhaps most troubling, the state size kept growing relentlessly. Every post, like, follow, profile change, all piled up. For active usage, that meant storage demands growing day by day.
Eventually, running a node became so resource-intensive (bandwidth, storage, compute) that only big players could realistically keep up. That starts undermining the decentralization promise.
The result? Deltagraph, once “good enough,” was no longer good enough. Farcaster needed rethinking.
Watch the video on snapchain :
Rather than patching the problems, the Farcaster team went for a full pivot: they replaced gossip-based CRDT with a brand-new system, Snapchain.
Snapchain is not a generic blockchain. It’s a blockchain inspired, social optimized data layer built specifically to handle social media workloads (posts, likes, follows, profile updates) rather than financial transactions.
What changed, and why this architecture works better:
Ordered, block-based transaction processing: Instead of random gossip, user actions are grouped into blocks. Each block is signed, linked to the previous block, and includes a global “state root” (via a Merkle-trie over account states). This ordering provides a canonical source of truth. Syncing becomes trivial: if you miss a block, just fetch it no need to diff massive histories.
Account-scoped transactions, non-Turing complete: Snapchain transactions are limited to social-native actions (post, like, follow, profile update, delete, etc.), each affecting only one account. No arbitrary smart contracts, no cross-account side effects. That simplifies validation and makes sharding by user account straightforward.
Sharding & pruning (garbage collection): Because each account’s history is isolated, the network can split accounts across multiple chains, improving scalability dramatically. Meanwhile, Snapchain supports pruning: old or reversed transactions (e.g. unlike deleted posts) can be removed after a certain time, preventing unbounded state growth.
Storage-rent model instead of per-action fees: Rather than charging gas per post/like (which would discourage frequent use), Snapchain opts for a “storage rent” model: users pay a fixed annual fee for storage. Within limits (e.g. number of transactions or storage quota), they can act freely. When limits are exceeded, older transactions get pruned. For typical social use, this feels effectively “unlimited.”
The result: a social-data layer that remains decentralized, but massively more scalable, reliable, and manageable.
With Snapchain live (mainnet launch in 2025), Farcaster unlocked capabilities that were previously difficult or impossible:
High throughput: Snapchain is designed to handle 9,000–10,000+ transactions per second (TPS), a level comparable to large centralized platforms and far beyond typical blockchains.
Millions of daily users: The architecture supports large-scale usage. Estimates suggest a capacity for 2 million daily active users on Farcaster apps.
Strong consistency & real-time sync across nodes: Because of block ordering and canonical state roots, nodes stay in sync reliably. No more “some nodes missing messages forever” missed blocks are detectable and fetchable.
Decentralization + accessibility: With pruning and sharding, running a node becomes more feasible for a wider set of participants. The network stays decentralized but scalable, avoiding the “only big servers” trap.
User-friendly experience: No gas fees per post or like, just a predictable storage rent. Users can behave like on traditional social media: post, like, follow, without worrying about per-action cost or blockchain latency.
In short: Snapchain reclaims the promise of decentralized social media not just as a technical novelty, but as a serious, usable alternative to centralized platforms.
No design is perfect. Snapchain makes deliberate tradeoffs to optimize for social use. Here’s what you should know.
Limited transaction expressiveness: Snapchain only supports a fixed set of “social primitives” (posts, likes, follows, profile updates, deletes). There’s no support for Turing-complete smart contracts, arbitrary logic, or complex multi-account transactions. This keeps things simple but less flexible compared to general blockchains.
Ephemeral history (due to pruning): Because the system prunes old or reversed transactions, the full historical record may not be kept forever. For typical social media usage, that may be fine (old likes/unlikes are rarely revisited), but it means history isn’t guaranteed to be immutable or permanent.
New complexity, new failure modes: Snapchain introduces block production, consensus, validators, and sharding, a step up from simple gossip. That adds complexity to the protocol, and potential points of failure (validator downtime, shard coordination, consensus bugs, version upgrades).
Storage-rent model tradeoffs: The “rent + prune” model means that heavy or long-term users may need to pay more (buy extra storage units), and some data might get dropped if quotas are exceeded. Also, different transaction types (posts, likes, follows) have separate quotas, which may lead to wasted capacity for some users.
In short: Snapchain sacrifices universality (no general smart contracts), permanence (pruning old data), and simplicity (added consensus/sharding complexity) but gains scalability, usability, and predictable performance for social use.
Snapchain shows that scaling decentralized social wasn’t just a performance problem, it was an architectural one. By replacing gossip with a purpose-built data layer, Farcaster proved the model can evolve without abandoning decentralization.
If Snapchain holds up under real adoption, it could pave the way for user owned social media at true Web2 scale. And that possibility alone makes this shift one of the most important experiments in Web3 right now.
Snapchain website
Snap V1 is our first no-code solution that brings fast finality to the OP Stack. We help deploy, manage and scale this integration for your chain, so you can focus on building the best experience for your users.
Discover new people, projects and tokens on Farcaster, the decentralized crypto social network and wallet for Base, Solana, Monad, BSC and more.
Revolutionize your business with HeimLabs' blockchain development solutions. Our expert team offers end-to-end services for smart contracts, DApps & more.
Follow HeimLabs for unapologetically practical Web3 dev content.
Twitter, LinkedIn.
Share Dialog
Share Dialog
HeimLabs
HeimLabs
2 comments
Snapchain just changed everything for decentralized social. @farcaster quietly rebuilt its entire backend, this might be the biggest shift in Web3 social yet. Here’s the breakdown you actually need ⬇️ https://paragraph.com/@heimlabs/snapchain-how-farcaster-rewired-social-media-for-a-decentralized-future
Farcaster shifts from Deltagraph to Snapchain, a social-optimized data layer using ordered blocks, account-scoped actions, and pruning. With sharding and a storage-rent model, it aims for high TPS, real-time consistency, and scalable decentralization for millions of daily users. @heimlabs