Inherited security is based on building on top of another secure blockchain.

Inherited security refers to a design pattern in blockchain architecture where a new protocol or system leverages the security guarantees of an existing base layer, rather than establishing its own security model from scratch. In cryptocurrency, this usually means building on top of a well-established blockchain like Bitcoin or Ethereum and relying on its consensus mechanism, validator set, or proof-of-work to ensure the integrity of transactions and data.

This approach has become central to the design of many Layer 2 networks, sidechains, rollups, and interoperability protocols. The appeal is straightforward: by building on top of a secure, decentralized base layer, new systems can focus on scalability, flexibility, or novel functionality without recreating the foundational elements that make a blockchain trustworthy.

There are several forms of inherited security in practice:

• Rollups and Validity Proofs
  Rollups (both optimistic and zero-knowledge) inherit security from Ethereum by publishing compressed transaction data to the main chain. In this model, Ethereum acts as the arbiter of truth, with fraud proofs or validity proofs providing accountability. This setup means users can rely on Ethereum’s security even when interacting with much higher throughput environments.
• Bitcoin Sidechains
  Some Bitcoin-focused Layer 2s claim inherited security by using Bitcoin’s block headers, proofs, or miners as checkpoints for their state. However, Bitcoin’s design makes these setups more limited in scope compared to Ethereum-based rollups. In many cases, trust assumptions reappear at the bridge or peg-in/peg-out layer. Still, efforts like drivechains and merged mining attempt to provide stronger links to Bitcoin’s security model.
• Shared Validator Sets
  In some multi-chain ecosystems, smaller chains inherit security from a larger validator set. Cosmos’ Interchain Security and Polkadot’s shared security model fall into this category. These designs tie the security of child chains to the staking and governance activity of the base chain, creating a direct economic and operational dependency.
• Economic Finality and Bridging
  Some systems use economic incentives to anchor finality into the base chain. For instance, finality gadgets or bridges might post checkpoints to Ethereum and rely on slashing or challenge mechanisms. This offers partial security inheritance, depending on the integrity of the bridge logic and the incentives around it.

Tradeoffs and Limitations
While inherited security offers a shortcut to decentralization and trust, it introduces dependencies. Any degradation in the base layer’s security affects the dependent system. Conversely, new attack surfaces can emerge in the connection layer—especially in bridges and relays—which are often the weakest link.

Further, inherited security can constrain design. A rollup must conform to Ethereum’s data availability and fee structure. A sidechain using Bitcoin headers must accommodate Bitcoin’s slow finality and scripting limits. These constraints may limit the expressiveness or performance of Layer 2s.

Inherited security is a pragmatic response to the difficulty of bootstrapping trust in new blockchain systems. By building on top of established networks, developers can avoid reinventing consensus and focus on usability, performance, and new features. But this model isn’t free: it introduces complexity, depends on the stability of the host chain, and requires careful bridge design. As the industry matures, how projects manage inherited security—and the tradeoffs that come with it—will shape the evolution of scalable and composable crypto systems.