> For the complete documentation index, see [llms.txt](https://bitcoin-scaling-labs-docs.gitbook.io/ipc-btc-scaling-docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://bitcoin-scaling-labs-docs.gitbook.io/ipc-btc-scaling-docs/overview/how-it-works.md). # Subnet hierarchy and communication **Overview** Our Bitcoin-IPC scaling solution is designed to achieve unparalleled scalability while maintaining Bitcoin’s foundational principles of decentralization and security. This is accomplished by creating independent blockchains, called *subnets*, tailored to specific workloads. The subnets are managed by the Bitcoin-IPC stack and form a highly flexible, efficient, and secure ecosystem for building advanced applications. *** **The root network and the hierarchy** In Bitcoin-IPC terminology, each network (including the Bitcoin L1) has *child subnets*. This implies a hierarchy: Bitcoin is on top, underneath are the L2 subnets (whose number is dynamic and evolving), each L2 subnet is allowed to have its own child subnets (which are L3 subnets), and so on. Bitcoin is the *root* network, the foundational layer in a hierarchical blockchain system. It is the ultimate source of truth for all interconnected subnets, providing a secure and decentralized foundation for the entire ecosystem. * As the root network, Bitcoin aggregates validated and checkpointed states from child subnets, holding a comprehensive and unified view of the network hierarchy that all subnets can reference. * Bitcoin’s consensus mechanism ensures that checkpointed states are immutable and universally accepted, becoming the definitive and trusted version of the network state. * It enables fault recovery by storing checkpointed states, allowing child subnets to retrieve their last valid state in the event of a disruption. *** **Communication between subnets** Seamless communication between Bitcoin and its child subnets is critical. This interaction occurs bidirectionally: * **Top-down communication**: Includes commands or updates from Bitcoin to Layer 2 subnets, such as validator set updates, deposits of BTC to the subnet, etc. * **Bottom-up communication**: Subnets report aggregated data, periodic checkpoints back to the Bitcoin mainchain, outgoing transfers to other subnets, and withdrawals of BTC. * **Horizontal cross-subnet communication:** It is implemented by combining a bottom-up part (from a source subnet to Bitcoin) and a top-down part (from Bitcoin to the destination subnet). It enables interoperability and cross-subnet transfers, expanding the network’s use cases. A *relayer* is a process run by each validator of a subnet. A relayer connects (1) to the local Fendermint instance of the validator, so as to obtain finalized checkpoints, and (2) to the Bitcoin full node used or run locally by the validator, so as to submit the finalized checkpoint messages. *** **Trustless bridging** Each subnet requires that at least ⅔ of its total validators' stake behaves honestly. If at any point during the lifecycle of the subnet this does not hold, the subnet will be able to censor user transactions or finalize invalid transactions. However, due to the native **checkpointing functionality** of the Bitcoin-IPC protocol, the state of the subnet is always anchored to Bitcoin L1 (by periodically finalizing the digest of the state). Hence, when safety is restored in the subnet, the state can be reverted to a point in time when the subnet was operating normally. More importantly, bridging between subnets (transferring wrapped BTC or *any* other custom ERC20 token) **does not require any additional trust assumptions**. A client that receives a cross-subnet transfer only needs to trust the subnet it is using and the sender subnet. No additional bridge committee or bridge operators are involved. What is more, even if the sender subnet is corrupted, a *firewall* property is in place: the corrupted subnet cannot send more funds than what it has received from other subnets. In other words, subnets cannot generate funds out of thin air. This property is achieved because cross-subnet communication is routed through the Bitcoin network. *** **The Fendermint engine** Currently, in the core of L2 subnets lies the **Fendermint consensus and execution mechanism**, specifically adapted to provide lightweight, modular, and highly performant consensus for the Layer 2 extensions. Fendermint integrates [CometBFT](https://github.com/cometbft/cometbft)'s proven framework for consensus, enabling low-latency transaction finality, high throughput, and robust fault tolerance, and the EVM execution engine.