The PowPeg

Rootstock's two-way peg with Bitcoin, and the hardware that signs it. This page reconstructs the complete history of the peg's signing federations from the Bridge contract's own events — 17 federations across 16 handovers — and sets it beside what Rootstock publishes about the devices and their firmware.

Chain figures collected 8 Nov 2026 · how

What the PowPeg is

The PowPeg is the mechanism that moves bitcoin into Rootstock and back out again. It is a hybrid: peg-ins are verified by the network, and peg-outs are signed by hardware.

A peg-in sends BTC to the PowPeg's Bitcoin address. The Bridge — a native contract at 0x0000000000000000000000000000000001000006 — verifies the Bitcoin transaction by SPV proof and credits the equivalent RBTC on Rootstock. Peg-in requires 100 Bitcoin confirmations (roughly 2,000 Rootstock blocks). Federation members act as watchtowers and usually inform the Bridge on the user's behalf, but a user who is missed can register the peg-in themselves.

A peg-out sends RBTC to the Bridge. After 4,000 Rootstock blocks the Bridge builds the Bitcoin transaction itself and selects the UTXOs, then asks the signing devices to sign it. The people who operate those devices — the pegnatories — do not hold the Bitcoin keys in any form they can extract or use at will. The keys live inside a PowHSM, a purpose-built firmware that will only sign what the Rootstock chain, proved to it by cumulative proof of work, says it should sign. That is where the "Pow" comes from.

dev.rootstock.io — PowPeg

Defense in depth

The PowPeg is not built on one clever mechanism. That is a deliberate choice, and Rootstock's chief scientist has written up the reasoning more than once. The argument against the single-mechanism approach is that it concentrates the risk in something almost nobody can check:

Other pegs rely on a single all-encompassing cryptographic protocol that solves a multi-party custody problem in an intricate way — which very few entities can audit… thoroughly. Rootstock instead relies on multiple defenses, or layers, with each layer relatively simple to understand and test.

Sergio Demian Lerner and Sebastian Lindner, "Building the Most Secure, Permissionless and Uncensorable Bitcoin Peg", 2 December 2020

Three strategies are named as running concurrently: defense in depth, coordination transparency and public attestation. The first is defined more narrowly than the phrase usually implies — it is about separating responsibilities, not stacking redundant copies of the same control:

Defense-in-depth is realized by a careful separation of responsibilities so that compromising the system requires more than just compromising one element or one actor. The miners alone cannot steal the funds of the peg, neither can the pegnatories, nor the PowHSM manufacturer, nor the developers.

The goal state has a name — vetocracy: a system of governance whereby no single entity can acquire enough power to make decisions and take effective charge. And the rule for maintaining it is that layers accrete rather than get swapped: well-functioning security components should not be replaced, so that if one layer fails, it can be removed while having a safety net of the remaining layers working.

The layers, and what each is for

A layer is only meaningful against a specific attack, so they are listed here with the one they exist to stop.

The doctrine, stated as doctrine

The clearest statement is not in an article but in a proposal — RSKIP198, which writes the peg's security assumption as a formula in order to attack its weakest term:

The current security of the Powpeg against invalid peg-outs relies on the assumption that: (the majority of the RSK hashrate is honest OR the majority of the Powpeg functionaries are honest) AND the PowHSM manufacturer is honest AND the PowHSM is tamper-proof. Assuming of the honesty of the HSM manufacturer and lack of vulnerabilities in the device is Powpeg's strongest assumption.

The defense-in-depth strategy adopted by the RSK community states that there should be no single point of failure. While the probability of the described attacks is very low, the defense-in-depth strategy demands that an additional protection layer exists. This new layer should keep the system secure even in case the HSM manufacturer is compromised.

That proposal — Minpeg, a second multisig weighted by mining power and ANDed into the peg script — is the answer it offers to its own question. It names four ways a manufacturer could fail: a key leaked through a covert channel in ECDSA signatures, a backdoor colluding with functionaries, code that quietly skips the proof-of-work check, and a power-glitch side channel. Enumerating those is the point: they are precisely what the hardware layer cannot defend against, which is why another layer is argued for.

Two things that are not layers

Worth stating, because both get cited as security properties and neither is:

• Watchtowers are a convenience, not a defence. The term is used only for peg-ins, where pegnatories inform the Bridge on a user's behalf — and it is explicitly optional, since the user issuing the peg-in transaction can inform RSK if the Powpeg members fail to. It protects liveness, not funds.
• There is no peg-out size or rate cap. The only cap described is on peg-ins, and it is a refund condition rather than a theft defence. Peg-out batching (RSKIP271) is motivated by cost and UTXO efficiency, not by limiting value at risk.

Where the idea came from

The instinct predates the PowPeg by four years. Arguing in 2016 that merge-mined sidechains and drivechains have near-identical security — a mining majority can defraud either — the conclusion drawn was to stop relying on one: what RSK did to improve drivechains to have the 'pure' sidechain-like security is to add a second layer of security: the requirement that cross-chain transactions are also signed by a set of notaries. Everything above is that move, repeated.

Sergio Demian Lerner, "Drivechains vs Sidechains", bitslog, 7 October 2016

Sergio Demian Lerner, "Armadillo: More Consensus Security for RSK", bitslog, 1 August 2019

Sergio Demian Lerner, "Measuring RSK Security", 6 April 2022

The next bridge changes the assumption

Everything above defends an honest-majority assumption as thoroughly as it can be defended. The Union bridge takes the other route: built on BitVMX, it aims to need only one honest participant, because a single honest party can challenge a false withdrawal and win. It is not a replacement yet — what runs on testnet today does not have the fraud proofs that would make that true — but it is where the peg is heading.

Checking it against outside opinion

Everything above is the design as its authors describe it, which is a necessary source and an interested one. Three independent readings are worth setting beside it:

• The only published audit of the signing hardware — NCC Group's 2022 powHSM assessment, which reported five low-severity findings and one informational, all fixed.
• Two Bitcoin-side reviewers walking through the federation-to-PowPeg change without a stake in it: Bitcoin, Explained, December 2020.
• A risk review written for someone deciding whether to deploy capital — LlamaRisk, for Aave governance, 2025, which rates the PowPeg against the weaker token bridge beside it.

More in the reading list, including the 2017 Trail of Bits review of rskj and both peg-out incident post-mortems. Note what is not there: no public audit of the Bridge contract itself appears to exist.

These four figures are read live from the Bridge on a Rootstock mainnet node (getFederationSize, getFederationThreshold, getFederationAddress) and cross-checked against the reconstruction below. If they ever disagreed, the collector would fail rather than publish either.

There is no retiring federation at the moment: getRetiringFederationSize() answers −1, so no migration of funds is in flight.

Every federation, from genesis

This table is not transcribed from anywhere. It is rebuilt from the Bridge's commit_federation event, which fires on every handover and carries the outgoing key set, the incoming key set and the height the new federation activates at. Because each event names the set it replaces, the whole chain of handovers can be checked rather than trusted: every outgoing set must equal the previous incoming set. All 16 of them do.

Reading the table:

• Federation 0 is the set that signed before any handover — it is the first event's outgoing set, which is how the table reaches genesis without a special case.
• Committed at is the block where the handover was voted in. Active from is the later block where it took effect; the gap is the consensus-enforced delay, currently 40,320 blocks (about two weeks) under RSKIP383.
• The three earliest federations have no Bitcoin address because the pre-Iris event encoding carried only a hash160. The address column fills in from federation 4 onward, when RSKIP146 changed the event to the ABI encoding.

Two things stand out. The federation ran at 15 members from genesis until 28 Feb 2020, when it dropped to 9 — then briefly returned to 15 for 29,402 blocks (about 11 days) on 15 Jun 2020 before settling back. And it has held steady at 9 since 27 Sep 2022: 11 of the 17 federations have had that size, and the handovers since have rotated keys rather than changed the count.

How the threshold is set

The number of signatures a peg-out needs is not chosen per federation. It follows from the size by consensus rule:

M = floor(N / 2) + 1

So the observed sizes map to: 8→5, 9→5, 13→7, 15→8. The live Bridge reports 5 of 9, which is what the rule gives, and the collector re-checks that every run.

dev.rootstock.io — PowPeg FAQ, "M = N / 2 + 1"

Functionary keys over time

45 distinct public keys have been part of a Rootstock federation. 39 of them appear in more than one federation; the rest appear exactly once. The keys below are the ones that persisted longest.

PowHSM firmware versions

The PowHSM firmware is developed in the open at rsksmart/rsk-powhsm. (rsksmart/powhsm, the name most people guess, does not exist.) It runs on two very different platforms, and a single PowPeg may mix them: Ledger Nano S devices, and Intel SGX enclaves on servers. SGX support arrives in 5.4.0; everything before that is Ledger only.

The latest release is 5.6.2 (22 Jul 2026), out of 26 versions on record.

rsksmart/rsk-powhsm — releases

Attestation

Attestation is how a PowHSM proves what it is and what it is running, to someone who does not have to trust its operator. It answers two questions, depending on platform:

• Ledger: that this is a genuine Ledger Nano S, endorsed by Ledger's own issuer key, running specific UI and Signer versions. The device's attestation keypair signs a message that begins with a header naming the version — for example HSM:UI:5.6 — and the Signer's message begins POWHSM:5.6::.
• SGX: that this is a genuine Intel SGX enclave running a specific codebase, proved by an ECDSA DCAP quote chaining to Intel's root of trust. The powHSM message is carried in the quote's custom_data.

Either way the signed message includes the hash of the authorised public keys, the Rootstock best block hash the device has advanced to, and the last BTC transaction hash it was authorised to sign. So an attestation is not just "this firmware is genuine" — it is "this firmware is genuine and here is the chain state it believes in".

The attestation file is JSON. Version 1 is the Ledger shape, with targets: ["ui","signer"]; version 2 is the SGX shape, with targets: ["quote"]. Verification is a command in the repository:

# Ledger
python adm_ledger.py verify_attestation -t attestation.json \
    -r <Ledger issuer public key> -b public-keys.json

# SGX
python adm_sgx.py verify_attestation -t attestation.json \
    -r https://certificates.trustedservices.intel.com/Intel_SGX_Provisioning_Certification_RootCA.pem \
    -b public-keys.json

It prints the installed UI hash and Signer version, or for SGX the installed MRENCLAVE and MRSIGNER.

rsk-powhsm — docs/attestation.md

rootstock.io — PowPeg, section 08 "Public proofs"

What each pegnatory actually publishes

These are not descriptions of attestations. Each row below is read from the signed attestation file that pegnatory publishes, together with the build parameters naming the firmware its device is running. 8 of the 9 federation members publish one.

Every file behind the table is linked from each member's page, and the attestations can be verified independently with the command above. What is not published is any history: each page shows the device's current state, with no record of previous firmware or when it changed. Rootstock's page says future versions will include periodic on-chain proofs; today the proof is a file on a web server, and this site re-reads it rather than quoting it.

rootstock.io — PowPeg, section 08 "Public proofs"

Attestations collected 9 Nov 2026 · how

Who holds devices

The chain knows 9 public keys. It does not know any names. The list below is what Rootstock publishes, and it is the only published list — the developer documentation declines to name anyone, saying only that public operators include independent entities across mining, custody, DeFi, and infrastructure.

rootstock.io — PowPeg

dev.rootstock.io — PowPeg member updates

How a member actually changes

Composition changes run in three phases, per the developer documentation:

1. Voting. Each existing pegnatory can accept or reject the change.
2. Delay. A consensus-enforced wait — RSKIP383 sets it at 40,320 blocks, about two weeks.
3. Migration. Funds move from the old multisig to the new one.

Both the vote and the activation are visible in the table above: committed at is the vote landing, active from is the delay expiring.

dev.rootstock.io — PowPeg member updates

The emergency multisig

RSKIP201 adds a time-locked escape hatch, in case the majority of PowHSMs fail simultaneously. It is a second branch in the peg's Bitcoin script, spendable only after an OP_CSV timelock expires — so it cannot race the normal path, only outlive its failure.

It was activated as part of the Iris upgrade. RSKIP225 requires each signatory to publish an emergency xpub and to prove possession of it, not more often than once a year.

RSKIP201 — Time-locked emergency multisig