Most new blockchains shouldn't exist. The ones that should share a common trait: their domain logic must live at the consensus layer, not the application layer. Here's a framework for telling them apart.
Between 2021 and 2023, the industry launched dozens of alternative Layer 1 blockchains. Most were general-purpose EVM-compatible chains differentiated by marginally different parameters—faster block times, cheaper gas, a slightly different consensus algorithm. Few had a structural reason to exist. They were fundraising vehicles first and infrastructure second.
But not every new chain is unjustified. Hyperliquid, Filecoin, Celestia, and Arweave all have defensible reasons for being separate chains. The question is how to distinguish the ones that need to exist from the ones that don't.
A new chain is justified when the domain logic must live at the consensus layer, not the application layer. Three criteria, in descending order of strength:
Block production or validation encodes domain-specific work that can't be expressed as a smart contract. Filecoin miners prove they're storing data. Helium nodes prove physical wireless coverage. This is the strongest justification for a separate chain, because it is the one criterion that an L2 or rollup cannot satisfy by definition—rollups inherit their consensus from the base layer.
If you removed the domain logic, there would be no consensus mechanism left.
Diagnostic: If validators stopped performing domain-specific work during block production, would the system still function? If yes → does not meet C1.
The chain's core data structures cannot be efficiently represented as contract storage on an existing chain. Concrete indicators: the domain requires non-account-based indexing (provenance graphs, spatial-temporal data), protocol-level privacy defaults (state that is encrypted by default rather than public), custom cryptographic primitives baked into the state layer, or data velocity so high that a general-purpose chain would treat the traffic as spam.
Diagnostic: Would representing this domain's state as contract storage on a general-purpose VM be either technically infeasible or economically irrational? If no → does not meet C2.
The application requires co-optimizing block times, transaction ordering, and throughput in ways impossible as a tenant on another chain. "Existential" means the system would produce incorrect results, lose solvency, or fail under normal peak conditions—not that it would merely be slower or less profitable. Two variants: app-specific C3, where a single application needs to own the entire stack (Hyperliquid), and general-purpose C3, where the execution environment itself is re-engineered for all applications (Monad).
Diagnostic: Would deploying this system on an existing fast chain cause it to fail—not underperform, fail—under normal peak conditions? If no → does not meet C3.
The conventional counter-argument is that application-specific rollups can serve many of these needs. There is a structural limitation: an L2 inherits its consensus from the base layer by definition. C1 is therefore impossible to satisfy with a rollup. If the domain requires validators to do something specific during block production, no amount of L2 engineering can deliver it.
For domains that require only C2 or C3, the question is whether the rollup architecture delivers the needed properties without introducing equivalent trade-offs—centralized sequencers, fragmented liquidity, bridge risk. In many cases, deploying on an existing fast L1 is simpler and achieves the same result.
If the domain logic can be fully expressed as a smart contract on an existing performant chain, and running it on a separate chain primarily improves the token story rather than the user experience, it doesn't need a chain. It needs a protocol.
Most things that feel like they need a chain actually need a protocol that uses chains for the parts where chains add value—identity, settlement, persistence—and conventional infrastructure for everything else. Chat doesn't need a chain. Social media doesn't need a chain. Most DeFi protocols don't need a chain.
If a protocol depends on owning transaction ordering as a core economic primitive, it must meet the C3 bar: an existing fast chain would cause the system to fail under normal peak conditions, not merely that controlling the sequencer is commercially advantageous.
Two axes matter when evaluating existing chains: whether the architecture justifies a separate chain, and whether the execution has validated the architecture. These are orthogonal. A chain can be architecturally justified and fail in practice, or succeed commercially without structural justification.
Chain | Domain | Criteria | Justification | Architecture | Outcome |
|---|---|---|---|---|---|
Hyperliquid | Onchain orderbook | C3 | A matching engine requires sub-second finality, deterministic ordering, and burst throughput during liquidation cascades. Being a tenant introduces latency that is existential for a trading platform. App-specific C3: the chain exists to serve one demanding use case. | Strong | Validated |
Filecoin | Incentivized storage | C1, C2 | Proof-of-spacetime consensus requires miners to continuously prove they are storing data. The consensus mechanism is storage verification. State tracks storage deals, sectors, and proofs—not token balances. | Strong | Mixed |
Arweave | Permanent storage | C1, C2 | SPoRA consensus rewards miners for storing and retrieving data. The blockweave—where blocks reference both the previous block and a random historical block—is a data structure no EVM could natively handle. | Strong | Validated |
AO | Parallel compute on Arweave | C2 | Hyper-parallel compute using holistic process state rather than global shared state. Processes communicate via async messages; Arweave serves as the immutable log. A fundamentally different computation model than shared-state VMs. | Moderate | Early |
Celestia | Data availability | C1, C2 | Data availability sampling is a distinct consensus concern. The chain exists to answer one question: was this data published? It deliberately has no execution layer. Its state isn't a ledger—it's a timestamped bulletin board for blobs. | Strong | Early |
Monad | High-performance EVM | C3 | Pipelined execution, async I/O, and optimistic parallel execution require re-engineering the runtime from scratch. General-purpose C3: the argument is that the EVM should be faster for everyone, not that a specific application needs to own the stack. | Moderate | Pre-launch |
Story Protocol | Programmable IP | C2 | IP provenance graphs, licensing DAGs, derivative work relationships, and automated royalty flows require non-account-based indexing that is alien to EVM state. Consensus-level argument is weaker—validators don't do anything IP-specific during block production. | Moderate | Early |
Helium | Wireless DePIN | C1 | Proof-of-coverage requires nodes to verify physical wireless hotspot presence. Domain logic is inherently physical-world. Migrated token layer to Solana—domain proofs needed custom infrastructure, settlement did not. | Strong | Hybrid |
Berachain | Liquidity-secured DeFi | C1 | Proof-of-liquidity embeds DeFi incentive distribution into block production. Validators direct emissions to liquidity pools as consensus-level behavior. Non-transferable governance token enforced at protocol level. | Strong | Struggling |
Render | Distributed GPU compute | C1 | Proof-of-render verifies GPU output quality. Job scheduling and bandwidth optimization are domain-specific. Like Helium, migrated settlement to Solana. | Moderate | Hybrid |
The Helium and Render migrations are instructive. Both concluded that domain-specific proofs justified custom infrastructure, but token settlement did not require a bespoke chain. This suggests a hybrid model for many C1 domains: custom consensus where domain logic demands it, existing fast L1s for everything else.
Berachain's architectural justification is strong—proof-of-liquidity genuinely requires its own chain. Its execution has been poor: TVL dropped from $3.5B to under $150M, the token fell 96%, and the PoL flywheel reversed. Architecture and outcome are separate questions.
Filecoin's architecture is also strong, but adoption has been underwhelming relative to thesis. The network is technically functional—real miners, real storage deals, real revenue—but most stored data has been incentivized through Filecoin Plus rather than organic demand. The vision of becoming a decentralized alternative to S3 hasn't materialized at scale.
Concept | Domain | Criteria | Why It Would Need Its Own Chain | Hard Problem |
|---|---|---|---|---|
Proof-of-Inference | Verifiable AI | C1, C2 | Consensus verifies bounded correctness of AI inference via fraud proofs or probabilistic verification. State tracks model hashes, inference proofs, and audit trails. Slashing challenges for incorrect inference need consensus-level adjudication to prevent chain halts during heavy GPU verification. | Floating-point non-determinism across hardware and driver versions makes exact reproducibility infeasible. Fraud proof systems for inference are an open research problem. |
Genomic Data | Privacy-preserving biodata | C2, C1 | State stores encrypted genomic sequences, consent graphs, and computation permissions—private by default rather than public by default. Consensus requires ZK proofs to verify that queries executed correctly on encrypted data without validators seeing plaintext. Protocol-level privacy as a requirement, not an option. | Fully homomorphic encryption is too slow for practical use. Regulatory frameworks don't yet recognize on-chain privacy guarantees. |
Physical Attestation | IoT sensor truth | C1, C2 | Consensus verifies physical-world sensor data through cross-attestation of hardware enclaves. State is a spatial-temporal graph of attested measurements. Data velocity is high and per-datum value is low—general-purpose chains would treat the traffic as spam. | Hardware trust assumptions are fragile. Sybil resistance for physical sensors is unsolved. |
Energy Grid | Real-time energy markets | C1, C3 | Consensus validates metered energy production and consumption. Validators are also grid nodes, enabling the chain to reject transactions that violate physical constraints—a general-purpose chain has no concept of line loss, reactive power, or thermal limits. The consensus layer must be physics-aware. | Utility regulation. Grid operators are unlikely to cede control to decentralized consensus. |
Spectrum Allocation | Dynamic RF management | C1, C3 | Consensus coordinates real-time radio frequency allocation across geographic regions. Block production is spectrum assignment—validators verify non-interference. Requires sub-second finality tied to physical propagation constraints. | Regulatory capture by telcos. Licensed spectrum bands require government cooperation. |
Identity / Reputation | Portable reputation | C2 | State is a graph of attestations, credentials, and reputation scores with selective disclosure. Needs native ZK primitives for proving attributes without revealing them. Reputation decay and context-dependent scoring don't map to EVM patterns. | This is the weakest case in the set. It meets only C2. To justify an L1, it would need mandatory ZK proofs for every state transition or consensus-level revocation enforcement—neither of which is proven necessary. This may be a protocol on a fast chain, not a chain. |
Several hypothetical domains—IoT attestation, energy, spectrum—share overlapping physical-world verification requirements. They might converge into a single "cyber-physical consensus" chain rather than existing separately. That convergence is itself a useful signal: if two proposed chains overlap heavily, neither may need to exist independently.
The framework reduces to three diagnostic questions, applied in order:
First: if validators stopped performing domain-specific work during block production, would the system still function? If not, the domain needs its own chain. This is C1, and no rollup can satisfy it.
Second: would representing this domain's state as contract storage on a general-purpose VM be either technically infeasible or economically irrational? If so, there is a case for a separate chain—though the case is weaker if C1 is not also met.
Third: would deploying this system on an existing fast chain cause it to fail under normal peak conditions? If the answer is merely "it would be slower" or "it would be less profitable," C3 is not met.
Everything that fails all three tests is an application. A protocol deployed on a fast chain. Not a new chain with a token and a pitch deck.