> 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/subnets.md). # Subnets and their lifecycle #### **Hierarchy Trees** Subnets in our system are organized in a hierarchical tree structure that begins with a chosen **rootnet**. In our case, the **Bitcoin mainnet** serves as the rootnet. From the rootnet, child subnets can be spawned, and the rootnet becomes their parent subnet. Key characteristics of the hierarchy: * **Parent-child relationship**: Each subnet can spawn any number of child subnets, while each child subnet has only one parent subnet. * **Infinite scalability**: Subnets can scale infinitely, enabling layer two and beyond for applications with diverse scalability requirements. * **Native communication**: Subnets within a single hierarchy tree have native protocols for asset and state transfers, eliminating the need for custom bridges. *** #### Creation of subnets A *subnet* in our Bitcoin-IPC protocol is an independent blockchain that users can spawn from a parent subnet in a permissionless and on-demand manner, depending on their scalability requirements. Subnets operate with their consensus algorithms and cryptoeconomic rules, separate from their parent subnet, ensuring flexibility and modularity. These subnets are also firewalled from the parent network to provide robust isolation and security. A Bitcoin-IPC subnet is created in a decentralized and open manner, by posting dedicated transactions on the Bitcoin mainchain. The transactions configure its validator set, collaterals, and operating parameters. Bitcoin-IPC subnets are designed to be lightweight, allowing them to spin up rapidly to meet temporary or permanent demand spikes. Their modular design ensures they can be tailored to specific applications or even shard single applications to optimize cost and performance. Developers can also deploy smart contracts on subnets to manage application-specific logic and operations. *** #### **Lifecycle of a subnet** The following picture graphically shows the lifecycle of a subnet.
**Creating a subnet** A subnet is created when a user (who is called the *subnet creator*) posts a dedicated create-subnet transaction on Bitcoin. Any user can become a subnet creator. Once the create-subnet transaction is finalized on the Bitcoin chain, the subnet is considered *initialized*. The create-subnet transaction defines the following: * A **minimum collateral** for validators that join the subnet. * A **whitelist**. While the subnet is in the *initialized* state, only the whitelisted validators are allowed to join. * A minimum number of validators, **min\_validators**, that are required to join the subnet before it is considered *active*. * Finally, the fee for the Bitcoin transaction creating the subnet is paid by the subnet creator. **Joining an *****initialized***** subnet** Whitelisted validators are allowed to join an *initialized* subnet. Validators joining the subnet must deposit the required collateral. The collateral is locked under a multisig with threshold **min\_validators** among the **whitelisted** validators. **Subnet becomes *****active*** A subnet is considered *active* once **min\_validators** have joined. From this point onwards, the validators start running the subnet consensus protocol, and the subnet executes transactions and produces blocks. **Joining an *****active***** subnet and updating the collateral** After the subnet becomes *active*, validators can permissionlessly join — except if the subnet creator has explicitly created a permissioned subnet. Existing validators can also update their collateral — add or remove stake — as long as the **min\_collateral** requirement is satisfied. When joining an active subnet, the collateral is locked under a multisig with threshold ⅔ among the current validators of the subnet. The validator set of the subnet may be updated when the subnet creates a *checkpoint*. Validators that want to join a subnet announce their intent on Bitcoin, and current validators monitor Bitcoin for new validator announcements. All validator-set changes must be signed by at least ⅔ of the current validator set in order to be approved. **Terminating a Subnet** The validators can collectively sign transactions to terminate, or, in Bitcoin-IPC terminology, *kill* the subnet. The subnet is first moved to a *to-be-killed* status — a grace period during which users can withdraw their funds — and finally to *killed* status, after which all collateral is returned to validators. *** ### Validator collateral **Staking** In Bitcoin-IPC, a validator secures a subnet by locking native BTC as collateral directly on Bitcoin L1 — not in an L2 contract. The *join-subnet* transaction sends the collateral into the subnet's Taproot multisig, jointly controlled by that subnet's validator set; staking more or unstaking are likewise plain Bitcoin transactions. A validator's locked collateral sets its weight in both the subnet's consensus and the multisig signing threshold (a ⅔ majority of total weight). Spending from that multisig requires the threshold of signatures from the current committee, so only validators presently in the set can move the collateral — no departed member or outside party can. **Slashing** Slashing penalizes provable misbehavior, chiefly equivocation — a validator signing two conflicting blocks or checkpoints — which the consensus layer surfaces as cryptographic evidence. The offending validator's collateral is reduced by the slashed amount at the next checkpoint, and that reduction is enforced when the validator later tries to withdraw. The penalty is derived deterministically from the on-chain evidence, so all honest nodes compute the same result. Slashing is planned but not yet implemented. The current MVP enforces the staking and collateral\ mechanics, but it does not yet apply automatic penalties for misbehavior. The mechanism described here reflects the intended design, to be finalized in a future release.