Most losses in Bitcoin-adjacent systems do not start on Bitcoin itself. They start at the edges where the Bitcoin network is exposed to other systems.
Whether it’s the bridge that moves BTC onto another network and back again, the vendors who handle customer records, the firmware that is supposed to generate unguessable keys or the signers who release coins because a request looked valid.
It’s this complex intersection where signing authority, consensus assumptions, supply-chain shortcuts, and operational trust meet where issues arise.
- Bridges fail when a withdrawal can be authorised without enough independent checks on the originating chain.
- Air-gapped hardware fails when seed generation is weaker than the user was told
- Hardware and accessory ecosystems fail when the device is sound but a fulfillment partner exposes names, phone numbers, and home addresses to hackers.
₿ Tick tock, next block
In each case Bitcoin’s base layer kept producing blocks. Honeybadger doesn’t care.
The break is always in the systems built around Bitcoin. And Rootstock’s PowPeg protocol was designed around that fact. Cryptographically tied to the Bitcoin network, secured by the same Proof-of-Work and protected by a defence in depth approach to security that continues to evolve.
Currently available through Atlas as one of the main routes into Rootstock, the PowPeg protocol has been live since early 2018, with no successful exploits, breaches, or loss of funds to date.
Its security does not rest on a single committee deciding when Bitcoin can move. It rests on layered checks that bind a peg-out to Rootstock consensus, and bind that consensus to Bitcoin’s hashpower through AuxPoW merge mining.
In practice that means two things.
- Rootstock blocks are produced by Bitcoin miners using the same work they already expend on Bitcoin. A large share of Bitcoin’s hashrate currently merge-mines Rootstock, so rewriting the chain that authorizes a withdrawal is not a cheap side-network attack.
- The devices that hold the Bitcoin keys do not sign because an operator asked them to. They sign only after independently verifying that a peg-out came from the Rootstock chain and that enough cumulative proof of work has been built on top of it.
That combination of merge-mined consensus plus delayed, hardware-enforced signing is why the PowPeg is less susceptible to the failure modes that usually appear at cross-chain boundaries.
Here are 10 commonly asked questions about the security behind Rootstock’s PowPeg.
₿ 1. Why does Rootstock wait ~36 hours before signing a peg-out?
A peg-out needs 4,000 Rootstock blocks before the PowHSMs will sign. That is about 33–36 hours and about 100 Bitcoin blocks of cumulative work.
The cumulative work required by the PowHSM also works as a rate limiter or forced time delay for any attack: Rootstock now has over 85% of Bitcoin’s hashrate through merge-mining so the amount of cumulative difficulty required to “cheat” the PowHSM into confirming a peg-out over a malicious forked branch would require a large scale collusion by some of the major Bitcoin mining pools for a duration of multiple days.
Multiple actors within the Rootstock ecosystem including RootstockLabs have monitoring systems in place to track PoWPeg movements so an alarm can be raised with sufficient time to intervene if needed.
₿ 2. Who holds the keys to the locked Bitcoin?
The keys sit inside tamper-proof PowHSMs, run by nine members in different jurisdictions. Signing is 5-of-9. Members include firms such as Xapo Bank, Luxor, and RootstockLabs.
Those organizations cannot export or freely use the keys. The hardware generates the key inside a secure element and never lets it out. Even a majority cannot spend BTC without a valid, work-backed Bridge command.
The federation is also set to grow: the Reed network upgrade raises the maximum number of PowPeg pegnatories from 9 to 20, with a published long-term path toward 60, further spreading signing power across independent members.
₿ 3. What gets checked before Bitcoin can move?
Both chains check each other. The Bridge contract runs a Bitcoin light client. It tracks Bitcoin headers, difficulty, and the best chain, and only credits a peg-in after an SPV proof of a real BTC lock.
Each tamper-proof PowHSM runs a Rootstock light client in SPV mode. It checks the best chain, block linkage, difficulty, and cumulative proof of work. Because Rootstock is merge-mined with Bitcoin via AuxPoW, that work comes from Bitcoin miners.
A peg-out is signed only if it came from that Rootstock chain and has enough work on top of it. Neither side signs on trust alone.
₿ 4. Can miners or pegnatories move the Bitcoin themselves?
No. Miners do not have the keys. They only supply the proof of work the hardware checks.
Members operate geographically dispersed PowHSMs but cannot export the keys or sign arbitrary transactions. Attacking or destroying one device is meant to take that key share offline, not hand it to the attacker. One dead box does not meet the 5-of-9 threshold. Miners provide work. Hardware holds keys. The Bridge defines which peg-out is even a candidate.
₿ 5. What can happen in that ~36-hour window if something goes wrong?
BTC does not move yet. Work still has to accumulate, and the HSMs still have to sign. Miners can stop merge-mining Rootstock. Members can take devices offline so 5-of-9 cannot be reached. Monitors can alert the network. The point is to intervene before a Bitcoin transaction becomes signable.
₿ 6. What if the PowPeg has to stay offline?
Halting signatures can protect funds. If normal signing cannot be restored for over 365 days, a separate Emergency Recovery Protocol exists. That path is a different timelocked release that only activates after about one year of inactivity on the relevant Bitcoin UTXOs. If triggered the end state would be that funds are returned to the original depositors.
₿ 7. Is the 36-hour delay the only defense?
No. The delay is one layer within a broader security architecture.
The PowPeg combines
- Bitcoin-backed proof-of-work,
- delayed signing,
- hardware-protected private keys,
- independent validation inside the PowHSMs,
- threshold participation and
- an emergency recovery path.
Rootstock is also continuously monitored, key components of the system are open source, and RootstockLabs operates a public security bug bounty.
The point of that design is not to assume that any single defense can never fail. It is to make security depend on multiple independent safeguards rather than one.
The ~36-hour peg-out window is one of those safeguards, and it reflects a simple principle: When Bitcoin is at stake, time can itself be a security control.
₿ 8. What if most PowPeg members collude?
Even if multiple Rootstock PoWPeg members collude they still cannot steal the funds. Keys never leave the tamper-proof HSMs, and the devices will not sign an arbitrary transaction. All of the pegnatories are publicly known players within the Bitcoin ecosystem. The boxes are also spread across locations and jurisdictions, so compromising one site is not enough.
In a worst case scenario a colluding majority could temporarily halt peg-outs by refusing to sign. That is an availability failure, not a drain. The one-year emergency recovery protocol is what covers a lasting halt. Miners alone cannot steal either.
₿ 9. Can anyone check that the peg is solvent and the hardware is genuine?
Yes. Locked BTC is in a public Bitcoin multisig, while circulating rBTC is visible on Rootstock, allowing the backing of the peg to be independently observed.
HSM firmware attestation allows outsiders to verify that members are running approved firmware on genuine, tamper-proof devices.
Core components of the system are open source, including the PowHSM firmware and middleware, the PowPeg node, and RSKj.
RootstockLabs also operates a public bug bounty through Immunefi, giving independent security researchers an incentive to identify and responsibly disclose vulnerabilities.
₿ 10. Is there an automatic cap that stops a huge or abnormal peg-out?
No separate “too large, reject it” rule. Every native peg-out waits the same ~36 hours and the same work threshold.
That delay is the rate limit. If a peg-out looks valid to consensus but should not move BTC, miners and members can still stop work and signatures before the transaction is signed.
Have a look for yourself. RootstockLabs runs a public bug bounty for the PowPeg and the rest of the Rootstock protocol through Immunefi: https://immunefi.com/bug-bounty/rootstocklabs/information/
