Authored By: Caleb Potter, Backend/DevOps Engineer at Tellor
Social forking is a community-driven response to disagreements or failures in a blockchain’s governance, validator set, or protocol direction. It has played a pivotal role in blockchain history, serving as a last-resort tool when communities face irreconcilable differences. Unlike technical forks, which are driven by code changes and upgrade proposals, a social fork relies on consensus among the people who use and validate the chain to diverge and establish a new one with a modified history or validator set.
One of the most iconic examples of a social fork is the 2016 split of Ethereum and Ethereum Classic, triggered by disagreements over how to handle the DAO hack and whether to roll back the chain. This event cemented social forking as a mechanism for communities to assert ideological or ethical boundaries. Another notable instance is the Bitcoin Cash fork in 2017, which stemmed from disputes within the Bitcoin community over block size and scalability.
Even within the Cosmos ecosystem, we’ve seen early examples of social divergence. The 2023 split of the Juno community after controversy surrounding a whale’s token allocation nearly resulted in a community-led fork. These examples underscore how social consensus, not just code, is what ultimately defines a blockchain’s future.
In the Cosmos ecosystem, social forks can be a powerful tool to recover from validator collusion, governance capture, or technical stagnation. This article focuses on the practical side: how to execute a social (or hard) fork on a Cosmos SDK-based chain. Drawing from my experience setting up and testing forks on our chain, Tellor, I’ll walk through the full process and highlight common pitfalls. If you’d like to learn more about social forks, I highly recommend reading this article series as a starting point.
If you want to see it in action, you can try out my code that performs a fork on Tellor here.
Step 1: Exporting Chain State
The first step of any social fork is exporting the state of the chain at the height agreed upon by the forking group. This state is a JSON representation of every module’s genesis state, which includes critical data such as account balances, delegation amounts, and more. With the ability to edit all of this data, you can remove malicious validators, take away tokens from bad actors who exploited the chain, or reshape the chain to reflect a new consensus starting point.
In a Cosmos SDK chain, the exported state is determined by each module’s ExportGenesis function. All blockchain data is important for the chain to operate, but not all of it is necessary for preserving the current state in a fork so don’t be confused if not every piece of data is there. The genesis state of a module contains the minimum required data for the chain to function—like delegations, balances, or the current validator set. As a developer, you’ll need to determine which data is essential in each of your modules.
For example, our chain’s oracle module stores data from every report ever made, and it makes up the majority of the data stored on Tellor. However, that information isn’t included in the genesis state because, while it’s valuable to users, it’s not critical for initializing a fork. On the other hand, we do export the cycle list, the rotating list of queries that pays out time-based rewards, since it evolves through governance and should persist in a forked chain.
A Word on Exported State Size
As mentioned above, the export command runs every module’s ExportGenesis function and combines their output into a single JSON file. If your chain has custom modules or stores large amounts of historical data (like oracles or reports), the resulting file can be massive. When I first started testing forks on Tellor, I made the mistake of exporting everything to the genesis file. The file became so large that I couldn’t even open it in VS Code.
This caused two major problems: first, not being able to inspect the file made it difficult to verify the exported state or the changes made—an essential step for transparency during a fork. Second, CometBFT has compression limits that can prevent the chain from initializing with a bloated genesis file.
If preserving more data is essential, there’s a workaround using upgrade migrations. I modified our export functions to create separate module data files that can be imported during a post-fork upgrade. This lets you bring over additional data that isn’t critical to the chain’s initial boot, but is still important. I also recommend including a way to verify that data’s integrity. In our case, the exported files are checksummed inside the function, so anyone can independently verify the data without trusting us.
Step 2: Editing the Genesis File
Every fork has its own reasons and goals, so how the genesis file is edited depends on the specific situation. Generally, though, this is when you define the starting point of the forked chain. You might restore user balances, remove tokens from attackers, or eliminate validators from the set so the active ones can carry the chain forward after an attack.
Editing the genesis file involves two key steps: collecting data and modifying the file. The data collection phase is often the most time-consuming, requiring investigative work and access to a running RPC node. The information you’ll need varies depending on the context, but often includes validator addresses, consensus addresses, account addresses, and consensus states.
Let’s walk through what I would do in the event of a chain halt caused by one-third of validators going offline to give a sneak peak into the process.
First, I’d identify which validators are preventing consensus. This involves monitoring the consensus state while the chain continues attempting to progress. In Cosmos SDK chains, validators are ordered by voting power and address, which means consistent missing votes at the same index of the validator set across multiple rounds can reveal which validators are unresponsive. From there, you can extract their consensus addresses and public keys to locate all related data.
Once that data is collected, it’s time to edit the genesis file directly. The main steps are:
- Remove the inactive validators from the consensus set
- Update the bank module if you are reclaiming or redistributing their stake
- Remove any delegations to those validators
After you’ve modified the relevant module states, all that’s left is to configure the chain metadata for your forked network and spin it up.
Final Thoughts
Social forks are high-stakes operations that challenge both your technical ability and your community’s cohesion. They can be politically sensitive, technically complex, and emotionally charged. But when done carefully, they offer a powerful way to reclaim or reshape a chain’s direction.
Whether you’re recovering from validator misbehavior, enforcing a community decision, or experimenting with a new governance path, the steps outlined here should give you a grounded starting point. Document everything, collaborate openly, and above all, treat the chain state with the weight it deserves.
If you’ve been through a fork or are planning one I’d love to hear your insights or compare notes.
