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.
Last updated