The Union bridge
A replacement route for moving bitcoin into Rootstock, built on BitVMX, and designed around a markedly weaker assumption than the PowPeg's: that one participant is honest, rather than a majority. It is a real design with a real paper — and what currently runs on testnet is not yet that design.
The assumption it changes
The PowPeg is secured by making a majority of its signers hard to compromise at once — hardware custody, a proof-of-work gate inside each device, jurisdictional spread. It is defence in depth around an honest-majority assumption.
Union attacks the assumption itself. Its claim, from the abstract:
a multi-party variant of BitVMX, an optimistic proving system on Bitcoin, to create a bridge that operates securely under the assumption that at least one participant remains honest. This 1-of-n honest approach is strikingly different from the conventional honest-majority assumption adopted by practically all federated systems.
The difference is large. Under honest-majority, compromising half the signers plus one takes the funds. Under 1-of-n, an attacker must compromise every single participant; one honest party anywhere in the set is enough to stop a false withdrawal, because that party can challenge it and win.
Peg-ins work the other way round and it is worth being precise about it. Setting up a
peg-in requires all functionaries to sign and then permanently delete their
keys — n-of-n. That is an availability requirement, not a security one: any single refusal
blocks a deposit, but no coalition short of everyone can steal one. The paper's framing is
that this ensures that the peg-in process also operates under the 1-of-n honest
assumption
.
BitVMX, underneath
Bitcoin cannot evaluate an arbitrary program, which is why bridges normally fall back on a committee vote: somebody has to decide whether a withdrawal is legitimate, and Bitcoin cannot work it out. BitVMX removes the vote by making the claim disputable instead.
It is described as a new design for a virtual CPU to optimistically execute arbitrary
programs on Bitcoin
— supporting conventional architectures such as RISC-V or MIPS. The
word doing the work is optimistically:
- Someone asserts a result and puts up a bond. Nothing is executed on Bitcoin.
- If nobody objects before a timeout, the assertion stands.
- If somebody does object, a challenge-response game runs. Execution is committed to as a hash chain of program traces, and an n-ary search narrows the disagreement down to a single instruction — which is small enough for Bitcoin Script to actually evaluate. Whoever was lying loses their bond.
So Bitcoin never runs the program. It only ever adjudicates the one step two parties cannot agree on, and only when they disagree. No consensus change is required: the challenge graph is built from pre-signed transactions, which emulates the covenants Bitcoin does not have.
BitVMX positions itself against the earlier BitVM designs: it needs no Merkle trees of
CPU instructions or memory words, and does not rely on signature equivocation, which the
paper argues makes it a compelling alternative to BitVM2
. It is developed by
Fairgate Labs alongside RootstockLabs, with the code at
github.com/FairgateLabs — most of the Rust stack MIT-licensed, with
some components under Apache-2.0, GPL-3.0 and CC0.
What Union verifies through this machinery is a function the paper calls
checkChain: given a sequence of Rootstock block headers, a proof that a deposit
was included on Bitcoin, a proof that a withdrawal was included on Rootstock, and the
accumulated difficulty, is this a valid chain linking the two? Committing whole header
sequences on-chain is impractical, so what gets asserted is a succinct proof of that
function — and that assertion is what a verifier may challenge.
How Union works
A peg-out does not wait for a committee. One functionary acts as operator and simply pays the user on Bitcoin out of their own funds, then reclaims it by asserting — with a proof — that the withdrawal was genuine. The other functionaries are verifiers and may challenge. If none does, the operator takes the locked funds after a timeout.
The user, notably, is not a participant in the dispute: they are paid up front, and the argument about whether that payment was justified happens afterwards between the functionaries.
Three mechanisms in the paper make this workable at scale:
| Term | What it is |
|---|---|
| VMXO | A UTXO secured by a BitVMX setup. The unit everything else is built from. |
| Packet | A group of VMXOs sharing one set of security deposits, initialised together with the same functionaries. It is what makes the bridge capital-efficient: the deposit need only cover a single VMXO rather than the total locked across all of them. The constraint that makes this safe is that within a packet, a functionary can be operator for at most one peg-out at a time. |
| Enabler | A participation token: a purpose-built UTXO that must be spent to act. Each functionary holds one operator enabler and n−1 verifier enablers per VMXO. Lose a dispute and all your remaining enablers are burnt, which ejects you from that packet entirely. |
| Stop watch | A shared clock rather than a chain of fixed timeouts. Naively, m protocol steps each with timeout T could take m×T; instead the watch accumulates only the time a party actually spent failing to respond, recorded with Winternitz one-time signatures. Exceed the threshold and your enablers burn. It bounds the total dispute time while still protecting each party from censorship. |
Taken together these address the obvious objection to bonded bridges — that securing
x bitcoin requires bonding something like x bitcoin. The paper's stated
goal is that the capital required to disincentivize functionary misbehavior grows
sub-linearly with respect to the amount of value locked
.
The paper's security rests on more than the honesty assumption. It also assumes both chains are secure, that block producers do not collude with functionaries, that messages are eventually delivered, that Rootstock carries a working Bitcoin relay, and that the proving system itself is sound. The 1-of-n headline is the interesting part, but it is one line in a longer list.
What actually runs today
What is live is not the design described above. Rootstock's own
announcement is unambiguous: Dispute resolution and fraud-proof mechanisms are not yet
implemented
, and this first release is experimental and not production-ready
.
That matters more than it might sound. The challenge-response game is the security model — it is the entire reason one honest participant suffices. A Union deployment without it is a bridge whose operators are simply trusted, exercising the plumbing while the mechanism that would constrain them is still being built. It is a useful milestone and it is not yet a trust-minimized bridge.
rootstock.io — Introducing Union Bridge on Testnet, 27 May 2026
The published plan is testnet V2 later with dispute resolution and challenge-response, then a gradual mainnet rollout from 2027 under strict transfer limits that rise over time.
rootstock.io — BitVMX Bridge roadmap
What has activated on-chain
One piece is real and consensus-enforced: RSKIP502, "PowPeg and Union Bridge integration". It is PowPeg-side plumbing rather than the bridge itself — it lets the PowPeg hand RBTC to a Union contract under an increase-only locking cap, tracks the net amount transferred, and provides a pause switch for both directions.
This site's own chain-derived data agrees with the announcement, which is a useful check: RSKIP502 activated on testnet only, in Reed 8.1.0, at block 7,139,600. It has not activated on mainnet, and the RSKIP's own status is Adopted (Testnet).
Two details in that proposal say a good deal about the stage Union is at: the
method that sets the Union contract address will only be available on testnet and regtest
environments and will not be enabled on mainnet
, and the motivation notes plainly that
the Union Bridge is still in development, and its contract address is likely to
change
.
Its relationship to the PowPeg
The Union paper does not mention the PowPeg. Not once — the word does not appear in it, nor does "pegnatory". It contrasts Union against federated bridges in general, never against the specific bridge it is being built for.
So everything in this section comes from Rootstock's blog and product pages, not from the peer-facing design document. That is a real difference in standing and it is worth keeping in view.
On those sources, the two are intended to coexist rather than for one to replace the other: Union is described as becoming the primary withdrawal verification layer, with the PowPeg kept as a complementary route for high-value transfers, and the two running side by side during rollout.
Mechanically, today, Union is downstream of the PowPeg rather than an alternative to it. Union does not mint RBTC — under RSKIP502 the PowPeg hands it RBTC within a capped allowance, and the Bridge tracks the net amount. On testnet, Union's RBTC is derivative of the PowPeg's.
No migration plan has been published. RSKIP502 contains none and gives no mainnet timeline; rootstock.io lists the two bridges as separate products without describing how they relate long-term. Nothing found says the PowPeg will be deprecated.
Papers and code
| What | Detail |
|---|---|
| Union: A Trust-minimized Bridge for Rootstock | Amela, Mishra, Lerner, Álvarez Cid-Fuentes. arXiv:2501.07435, v2 of 14 January 2025. The design document. |
| BitVMX: A CPU for Universal Computation on Bitcoin | Lerner, Amela, Mishra, Jonas, Álvarez Cid-Fuentes. arXiv:2405.06842, 10 May 2024. The proving system Union is built on. |
| bitvmx.org | The BitVMX project site, by Fairgate Labs. Its papers page lists the wider family of related work. |
| BitVMX papers | Thirteen related papers, including ESSPI (arXiv:2503.02772) on signed program input. |
| FairgateLabs/BitVMX | The implementation index. Mostly MIT; the README states the projects are under active development, not production-ready and not audited. |
| rsksmart/union-bridge-contracts | Union's Solidity contracts, MIT. The README calls the project experimental and says not to use it in production. |
| BitVM 2: Permissionless Verification on Bitcoin | The design BitVMX positions itself against. Worth reading beside the BitVMX paper for the contrast. |
There is very little genuinely independent technical critique of either Union or BitVMX. What exists is largely written by the same people, and the most credible scepticism is in the BitVMX paper's own conclusions, which list extending beyond a single verifier and studying the crypto-economic security as open problems. If you know of outside analysis, please send it.