A sidechain is a separate blockchain with its own validation rules, consensus or block-production system, transaction history, and nodes. It can be connected economically to Bitcoin through a peg or bridge, but it is not part of Bitcoin's own validated chainstate.
That definition creates the most important boundary in this guide. A Bitcoin full node validates Bitcoin blocks, Bitcoin transactions, and Bitcoin's UTXO set. It does not automatically validate Liquid blocks, Rootstock contracts, or another sidechain's state. A sidechain full node performs that separate validation under the sidechain's rules.
The connection between the systems is usually economic rather than a single object moving between two ledgers. Bitcoin is locked or controlled under a Bitcoin-side mechanism. A corresponding representation is issued, unlocked, or recognized on the sidechain. Returning to Bitcoin requires the sidechain representation to be removed or locked and a Bitcoin transaction to release funds from the peg.
Why sidechains are created
Sidechains let developers choose rules and functionality that Bitcoin does not provide in the same form. A sidechain can use different block intervals, transaction formats, privacy features, asset systems, smart-contract execution, fee rules, or governance processes.
This separation can allow experimentation without changing Bitcoin consensus. It also isolates sidechain activity from Bitcoin's block space and chainstate. The cost is that the sidechain introduces another network to operate, another rule set to validate, and another security model to understand.
A sidechain may use bitcoin as its economic unit or recognize a one-to-one denominated representation. That does not make its security identical to Bitcoin. Denomination, backing, consensus, withdrawal control, and operational availability are separate questions.
Independent blocks and nodes
A sidechain has its own genesis state, blocks, transaction ordering, and active chain or finality rules. Its block producers may be a federation, merged miners, proof-of-stake validators, or another mechanism. Its nodes check the rules chosen by that system.
A public user may be able to run a sidechain full node and verify that sidechain's blocks and supply rules. This is valuable, but it does not necessarily grant the user unilateral authority over bitcoin held by the peg. Self-validation of a sidechain and control of the Bitcoin-side funds can be separate security boundaries.
Running only a Bitcoin node does not validate sidechain state. Running only a sidechain node does not replace independent Bitcoin validation. A user who wants to verify both systems may need both node stacks and a clear understanding of how peg evidence crosses between them.
Consensus, reorganization, and finality differ by chain
Bitcoin uses proof of work and accumulated chainwork among valid candidates. A sidechain can use different block timing and finality rules.
Faster blocks do not automatically provide stronger finality. A one-minute block signed by a federation and a thirty-second merged-mined block represent different security conditions from a Bitcoin block. A system may limit reorganizations by signer policy, use probabilistic proof-of-work settlement, or define checkpoints and long peg delays.
When comparing finality, ask what event is considered settled, who can reverse it, what evidence nodes verify, and what happens during network partitions or deep reorganizations. Sidechain transaction settlement and peg settlement may require different waiting periods.
A two-way peg is two coordinated accounting processes
A two-way peg is a mechanism for entering and leaving a sidechain while maintaining a defined relationship between locked bitcoin and the sidechain representation.
A peg-in normally begins with a Bitcoin transaction that locks bitcoin under the peg's control. After the required Bitcoin confirmation period, the sidechain recognizes or creates the corresponding representation for the user.
A peg-out works in reverse. The user creates a sidechain transaction that destroys, locks, or otherwise retires the representation and requests a Bitcoin destination. The peg mechanism then authorizes a Bitcoin transaction spending from the locked pool.
The same UTXO does not travel between chains. The Bitcoin UTXO remains governed by Bitcoin scripts and signatures. The sidechain maintains its own state. The peg coordinates changes across the two systems.
This means withdrawal security depends on who or what can authorize the Bitcoin spend. A federation may hold threshold keys. A hardware-assisted federation may sign only after observing sidechain consensus. A proposed drivechain would give miners a voting role over withdrawal bundles. Each model creates different liveness, censorship, and compromise assumptions.
Fees, capacity, and functionality are local properties
Sidechains can increase transaction capacity by processing activity outside Bitcoin's blocks. Users pay sidechain fees under the sidechain's rules, while peg-ins and peg-outs also consume Bitcoin block space and fees.
Capacity is not free. Sidechain nodes store and validate sidechain data. Block producers need infrastructure. Bridges need monitoring, signing, liquidity, and recovery procedures. High demand can still raise fees or create congestion under the sidechain's own limits.
Features such as Confidential Transactions, issued assets, or EVM-compatible contracts are sidechain capabilities. They do not alter Bitcoin consensus. On Liquid, Confidential Transactions hide output amounts and asset types, but the transaction graph, input and output counts, and fee remain visible. Counterparties and anyone given the relevant blinding keys can learn protected details. Confidentiality is not complete anonymity.
Federated sidechain model: Liquid and Elements
Liquid is a deployed federated sidechain built with Elements. It uses a Strong Federation rather than proof of work to produce and sign Liquid blocks. Public users can run Elements-based Liquid nodes and validate Liquid transactions, blocks, and the relationship between issued L-BTC and bitcoin held by the peg.
As documented on July 19, 2026, Liquid had 15 functionary operators and required an 11-of-15 quorum to sign blocks. The same functionary hardware supports two distinct roles. Block signers validate and sign Liquid blocks. Watchmen manage the Bitcoin peg and participate in threshold authorization for Bitcoin transactions.
Those roles should not be collapsed. Validating a Liquid block establishes sidechain state under Liquid's rules. Releasing bitcoin requires a Bitcoin transaction authorized under the federation's peg controls.
#### Liquid block production and finality
Functionaries take turns proposing blocks on an approximately one-minute schedule. A block needs the required signer quorum. The signer hardware tracks prior signed heights and parents to constrain deep reorganizations. Liquid documentation treats two confirmations as final under the functioning federation model.
This is deterministic signer finality, not Bitcoin proof of work. If too many functionaries are unavailable, block production can stop. If a quorum signs invalid sidechain data, correctly functioning public Liquid nodes should reject it under their validation rules, but liveness still depends on enough authorized signers producing acceptable blocks.
#### Liquid peg-ins and peg-outs
A Liquid peg-in sends bitcoin to a federation-controlled address derived for the user's claim. The wallet must retain the associated claim script and later provide the Bitcoin transaction and Merkle proof, although supported wallet software can automate that process. Current Liquid documentation requires 102 Bitcoin confirmations before the L-BTC claim is accepted. The long delay protects the pooled peg from a deep Bitcoin reorganization.
Peg-outs retire L-BTC and ask the watchmen to release bitcoin. The peg currently uses an 11-of-15 Bitcoin multisignature arrangement and Peg-out Authorization Keys, or PAKs. Direct public peg-out access is restricted. Federation members or authorized participants can perform direct peg-outs, while general users usually rely on a member or service. Current documentation estimates the watchman processing phase at 11 to 35 minutes, depending on network conditions; Bitcoin confirmation follows under Bitcoin's own timing. A member, exchange, or swap service can add separate custody, liquidity, fee, and availability assumptions.
One-to-one backing can be audited by a Liquid node, but it does not guarantee immediate redemption. Redemption still depends on authorization rules, functionary availability, transaction construction, Bitcoin fees, and Bitcoin confirmation.
Liquid also includes an emergency recovery design using a timelock and a separate set of three emergency keys after extended federation nonfunctionality. Recovery is not an automatic user withdrawal path; it still depends on those keys and an operational process. The mechanism reduces lockup risk but adds separate key, governance, and execution assumptions.
#### Federated security boundaries
A federation can provide predictable blocks and a threshold rather than one custodian. It also concentrates special authority in a known set of operators and hardware.
The main risks include quorum unavailability, coordinated censorship, threshold-key compromise, software flaws, HSM failures, membership changes, and emergency recovery failures. Public node validation can detect invalid Liquid state, but it does not let every user independently sign a Bitcoin peg-out.
A federated peg is therefore more structured than a single-company account, but it still contains member, threshold-key, hardware, and governance assumptions that Bitcoin itself does not have.
Merged-mined sidechain with a separate peg: Rootstock
Rootstock is a separate blockchain with EVM-compatible smart contracts and a bitcoin-denominated native asset called rBTC. Rootstock blocks are merge-mined with Bitcoin, while the PowPeg controls movement between BTC and rBTC.
These are related but separate security boundaries. Merged mining helps order and secure Rootstock blocks. The PowPeg authorizes release of bitcoin from the Bitcoin-side pool.
#### Merged mining reuses work without merging validation rules
Rootstock and Bitcoin both use double SHA-256 proof of work. Mining pools can place a commitment to a Rootstock candidate in a Bitcoin coinbase transaction. A hash can satisfy Rootstock's target even when it does not satisfy Bitcoin's higher target, or it can satisfy both.
Bitcoin nodes treat the Rootstock commitment as data in a valid Bitcoin transaction. They do not validate the Rootstock block, execute its contracts, or enforce its state transition rules. Rootstock nodes verify Rootstock blocks and the merged-mining proofs under Rootstock consensus.
Rootstock's documentation reported participation exceeding 85 percent of Bitcoin hashpower when accessed on July 19, 2026. That figure is time-sensitive and project-reported. It describes observed mining participation, not independent proof that the PowPeg has the same security as Bitcoin or that Bitcoin nodes validate Rootstock.
Any user can run the RSKj node software to validate Rootstock. Mining pools need Rootstock-aware pool or delegated merged-mining infrastructure to obtain Rootstock work and submit proofs, but Bitcoin nodes require no changes and individual miners do not necessarily run Rootstock nodes. This is operational delegation, not BIP 301 blind merged mining. Rootstock retains its own block timing, difficulty, transaction rules, contracts, and chain-selection behavior.
#### rBTC and the PowPeg
In a peg-in, bitcoin is sent to the PowPeg address. The Rootstock Bridge, a precompiled contract in Rootstock consensus, tracks relevant Bitcoin evidence and recognizes rBTC after the required process. Current Rootstock documentation updated June 22, 2026 states that peg-ins require 100 Bitcoin blocks. The current native peg-in minimum is 0.005 BTC.
For a peg-out, the Bridge accepts the request, waits for Rootstock confirmation conditions, builds the Bitcoin transaction, and coordinates signing. The same documentation states that peg-outs require 4,000 Rootstock blocks, described as approximately 200 Bitcoin blocks under its timing assumptions. Current documentation lists a 0.004 rBTC minimum, and the Bridge can reject and refund requests when estimated Bitcoin fees leave an uneconomic output.
Pegnatories operate PowPeg nodes and PowHSM devices. The hardware protects one key in the multisignature set and is designed to sign only when a requested peg-out is backed by sufficient cumulative Rootstock proof of work. The Bridge selects transaction inputs and outputs under Rootstock consensus rules. PowPeg membership and the Bitcoin signing threshold are active Bridge state rather than permanent protocol constants. They can change through federation updates, so current values must be read from the live Bridge rather than inferred from a genesis key list or an older documentation count.
This arrangement limits direct human discretion, but it does not eliminate operational assumptions. Peg-outs require enough PowHSMs and PowPeg infrastructure to remain online, follow the expected chain, and sign. Hardware, firmware, node software, attestation, membership changes, and deep-chain assumptions all matter.
#### Chain security is not peg security
An attacker attempting to rewrite Rootstock state faces the merged-mining security model. An attacker attempting to release locked BTC faces the Bridge, PowHSM, threshold-signature, confirmation-delay, and operational controls of the PowPeg.
High merged-mining participation can make long Rootstock reorganizations expensive. It does not give ordinary Rootstock full nodes the Bitcoin multisignature keys. It also does not make a peg-out unilateral for each rBTC holder.
Likewise, a correct PowPeg balance does not prove that every Rootstock smart contract is safe. EVM functionality expands what can run on the sidechain and creates its own application and execution risks.
Proposed drivechain model: BIP 300 and BIP 301
Drivechains are proposals, not deployed Bitcoin mainnet functionality. BIP 300 and BIP 301 are both listed as Draft specifications in the official BIPs repository as of July 19, 2026. They propose Bitcoin consensus changes and are not listed among the BIPs implemented by Bitcoin Core.
#### BIP 300 hashrate escrows
BIP 300 proposes hashrate escrows that hold sidechain funds in designated Bitcoin UTXOs. Sidechain users would form withdrawal bundles. Under the current Draft specification, a bundle starts with 26,300 blocks remaining, succeeds after reaching at least 13,150 net ACKs, and is removed when its lifetime expires or it can no longer reach that threshold. These are proposed consensus rules, not deployed Bitcoin behavior.
The design moves withdrawal authorization away from a fixed federation and toward miner signaling. It deliberately uses long, visible withdrawal periods. Its security depends on assumptions about miner incentives, user monitoring, censorship, and whether miners approve only valid sidechain withdrawals.
A BIP document is a specification proposal. Its publication does not show activation, broad agreement, or safe deployment. BIP 300 would require new consensus behavior before ordinary Bitcoin nodes could enforce its escrow messages and withdrawal rules.
#### BIP 301 blind merged mining
BIP 301 proposes blind merged mining. Sidechain users assemble candidate sidechain blocks and bid through Bitcoin transactions for a miner to include one chosen sidechain block commitment in the Bitcoin coinbase.
The Bitcoin miner can collect the bid without running the sidechain node. The sidechain users remain responsible for constructing and validating sidechain blocks. This separates block assembly from hash commitment.
BIP 301 does not make Bitcoin nodes validate the sidechain's contracts or complete history. It defines a proposed Bitcoin-layer bidding and commitment mechanism. It is designed to work with BIP 300, but block production and withdrawal authorization remain distinct concepts.
#### Drivechain disagreement is part of the model
Supporters argue that miner-governed escrows can enable many sidechains without fixed federations. Critics focus on miner custody incentives, withdrawal theft or censorship, complexity added to Bitcoin consensus, and changes to miner and user responsibilities.
Those disagreements are not resolved merely because BIPs have assigned numbers. A responsible comparison labels BIP 300 and BIP 301 as Draft proposals and separates reference implementations or test networks from Bitcoin mainnet deployment.
Sidechains compared with Lightning and Ark
Lightning is a network of bilateral Bitcoin payment channels. Channel participants update enforceable Bitcoin settlement states, and routed payments use directional channel liquidity. Channel opening and closing use Bitcoin transactions and fees, and a participant can enforce a valid channel close on Bitcoin without asking a sidechain peg authority. Lightning does not create an independent global blockchain with its own block producers.
Ark uses operator-coordinated VTXOs and shared Bitcoin batch outputs. Its users depend on batch timing, operator service, expiry management, and the transaction data needed for unilateral exits. Ark does not create independent sidechain blocks or a separate peg whose key holders authorize withdrawals, so it is not a sidechain in the same sense as Liquid or Rootstock.
A sidechain creates its own chain history and node validation environment. It may offer broader execution or asset features, but users accept separate consensus and peg assumptions. These systems can all be called Layer 2 in broad conversation because they move activity away from ordinary Bitcoin transactions, but the label does not describe one shared security model.
The useful question is not simply whether a system is Layer 2. It is which rules Bitcoin validates, which rules another network validates, who orders state, who controls withdrawals, what data users must retain, and what happens when cooperation or infrastructure fails.
A practical comparison framework
Before relying on a sidechain, separate these questions:
- Sidechain validation: Can users run a full node, and what rules does it enforce?
- Block production: Who proposes and finalizes blocks, and what can halt production?
- Peg custody and authorization: Which scripts, keys, hardware, contracts, or miner votes release bitcoin?
- Liveness: What threshold or infrastructure must remain available for deposits, transactions, and withdrawals?
- Censorship: Who can delay or refuse blocks or peg-outs?
- Reorganization risk: Which chain can reorganize, and how do deep reorganizations affect the peg?
- Recovery: Are there emergency keys, timelocks, migration procedures, or no recovery path?
- Verification: Does a user validate both Bitcoin and the sidechain, or rely on hosted services?
- Functionality: Which privacy, asset, or contract features are provided, and what new risks accompany them?
- Deployment status: Is the mechanism deployed, experimental, proposed, or absent from Bitcoin Core?
Sidechains can expand design space, but they do not erase tradeoffs. The security description must name the specific sidechain consensus model and the specific peg model. Claims that a sidechain simply inherits Bitcoin security hide the parts users most need to understand.