Forking (Content Graph)

Any user can initiate a fork without requiring approval from the original graph's creators or administrators. This is achieved by calling a smart contract function, which creates a new, separate Content Graph instance. The process is gas-efficient and typically involves a small transaction fee. This ensures the ecosystem remains open and resistant to censorship or centralized control.

The new forked graph inherits a complete, immutable snapshot of the original graph's state at the block height of the fork. This includes all indexed data, entity relationships, and schema definitions. Post-fork, the two graphs evolve independently; updates to the original graph are not reflected in the fork, and vice-versa. This creates a verifiable historical lineage.

The fork operator gains full control over the new graph's governance parameters. This includes:

• Curation Rules: Defining new criteria for data inclusion or modifying scoring algorithms.
• Fee Structures: Setting new fees for queries or data writes.
• Upgrade Path: Independently deciding on protocol upgrades and feature additions.
• Access Control: Implementing new permission models for contributors.

Forking enables several key scenarios:

• Experimentation: Developers can test new indexing logic or economic models without risk to the mainnet graph.
• Specialization: Creating niche graphs optimized for specific data types (e.g., only NFT metadata, only DeFi events).
• Disagreement Resolution: Community factions can fork to implement alternative governance or feature roadmaps.
• Incentive Competition: Fork creators can design new tokenomics or reward systems to attract indexers and curators.

Forking is implemented via a smart contract factory pattern. The core contract stores the graph's Merkle root or state commitment. Forking involves:

1. Proving the current state via a Merkle proof.
2. Deploying a new graph contract with the proven state root.
3. Initializing the new contract with forked parameters. This ensures the process is cryptographically verifiable and trust-minimized.

Content Graph Forking is conceptually analogous to a blockchain hard fork but operates at the application layer. Unlike a chain fork that splits consensus, a Content Graph fork splits data provenance and curation logic. The original and forked graphs can coexist and serve different applications, similar to how Ethereum and Ethereum Classic coexist as separate networks with shared history.

The technical act of forking a data graph involves several key steps, common across protocols:

• Schema & Logic Replication: Copying the data schema, indexing logic, or transformation rules from the source.
• Independent Deployment: Deploying the copied logic as a new, separate executable unit (subgraph, squid, pipeline).
• Data Source Specification: Pointing the new fork to the same or a customized blockchain data source (RPC endpoint, archive node).
• Network & Incentives: Choosing where to host the fork—on a decentralized network (The Graph), a managed service (Goldsky), or a self-hosted indexer. This decision impacts cost, performance, and decentralization.

This mechanism ensures data sovereignty and prevents single points of failure or control in the data layer.

A hard fork is a permanent divergence from the previous version of a blockchain, creating two separate networks. Nodes that do not upgrade to the new protocol rules are incompatible with the new chain.

• Examples: Bitcoin Cash (from Bitcoin), Ethereum Classic (from Ethereum).
• Requires all nodes to upgrade to remain on the consensus chain.
• Results in a permanent split of the network state and token.

A soft fork is a backward-compatible upgrade to a blockchain's protocol. New rules are a subset of the old rules, so non-upgraded nodes can still validate new blocks (though they may not understand them fully).

• Examples: Segregated Witness (SegWit) on Bitcoin, the London upgrade on Ethereum.
• Does not split the chain; it tightens the consensus rules.
• Requires only a majority of miners/nodes to upgrade to be effective.

The consensus mechanism is the core protocol that determines how network participants agree on the state of the blockchain. It is the rule set that defines valid transactions and blocks, and its alteration is the primary reason for a fork.

• Examples: Proof of Work (PoW), Proof of Stake (PoS), Delegated Proof of Stake (DPoS).
• A fork often occurs when there is irreconcilable disagreement over changing these rules.

A chain split is the concrete outcome of a hard fork, where the blockchain's transaction history diverges into two independent and valid chains. Each chain has its own native token and community.

• Key Event: Occurs at a specific block height.
• Token Duplication: Holders of the original token receive an equal balance on the new chain (e.g., ETH holders received ETC).
• Creates replay attack vulnerabilities that must be addressed.

Governance refers to the formal or informal processes by which a blockchain community proposes, debates, and implements protocol changes. Forks are often the result of failed governance or a mechanism for enacting change outside the existing framework.

• On-chain governance: Uses the protocol itself for voting (e.g., Tezos, Polkadot).
• Off-chain governance: Relies on social consensus among developers, miners, and users (e.g., Bitcoin, Ethereum).

A contentious fork is a hard fork that occurs due to a deep, unresolved conflict within the community, often over philosophical, technical, or economic principles. It results in a permanent community split.

• Defining Characteristic: Lack of broad consensus; two viable factions emerge.
• Contrasts with a planned upgrade (non-contentious hard fork) where the community agrees to the change.
• Examples: Bitcoin/Bitcoin Cash, Ethereum/Ethereum Classic.