Merge mining

Rootstock has no miners of its own. Bitcoin miners produce its blocks as a by-product of mining Bitcoin, by committing a Rootstock block hash into the Bitcoin coinbase. This page explains the mechanism, shows what the chain actually says about who is mining it, and gives the current steps for a pool that wants to start.

Mining measurements collected 8 Nov 2026 · how

How it works

A Bitcoin miner adds one extra output to its coinbase transaction. That output is an OP_RETURN carrying the ASCII tag RSKBLOCK: followed by a 32-byte commitment to a Rootstock block header:

6a 29 52534b424c4f434b3a <32-byte Rootstock commitment>
│  │  └─ "RSKBLOCK:"       └─ hash of the Rootstock block header
│  └──── length: 0x29 = 41 bytes (9 + 32)
└─────── OP_RETURN

Two rules apply to where it goes. It must be the last output of the coinbase, there must be at most 128 bytes after the commitment, and those trailing bytes must not themselves contain the string RSKBLOCK:. The tag can also appear by accident inside ExtraNonce2, which is harmless as long as the pool appends the real tag after that field.

The miner then hashes as normal. Because Rootstock's difficulty is far lower than Bitcoin's, a given hash attempt has three possible outcomes:

• below the Bitcoin target — a Bitcoin block, which also satisfies Rootstock;
• below only the Rootstock target — submitted to Rootstock as a Rootstock block;
• below neither — an ordinary pool share.

The Rootstock block then carries its own proof that this happened. The last three fields of every Rootstock header are the Bitcoin block header (80 bytes), a merkle proof linking the coinbase to that header's merkle root, and the partial Bitcoin coinbase transaction containing the tag. Any node can check the chain of commitments without talking to Bitcoin at all.

dev.rootstock.io — merged mining, getting started

dev.rootstock.io — mining architecture

Who is mining it, measured

Rootstock says that over 85% of Bitcoin's hash power merge-mines it (dev.rootstock.io) or over 80% (rootstock.io). Neither figure can be checked from a Rootstock node, because a node cannot see Bitcoin blocks that did not carry a tag. What a node can answer exactly is who produced the last few thousand Rootstock blocks and what they were running.

The figures below are counted from the 4,000 blocks between #9,389,856 and #9,393,855 — about 34.9 hours ending 8 Nov 2026.

How the pool behind an address is established

The names above are measured, not taken from a list, and the method runs from Rootstock to Bitcoin rather than the other way.

Every Rootstock block carries the 80-byte Bitcoin header its miner was working on. Most of those meet Rootstock's difficulty and nothing more — but about one in a hundred also meets Bitcoin's, because the miner found a Bitcoin block and a Rootstock block with the same work. For those, the double-SHA256 of the header is the Bitcoin block's identifier, with no conversion at all, and that Bitcoin block's coinbase carries the pool's own name. The Rootstock coinbase address on the same block is the other half of the pair.

Whether a header qualifies is decided locally, so only genuine candidates cost a lookup. Over 6,000 Rootstock blocks, 64 headers also met Bitcoin's target — about 1.1% — and 6 of 6 addresses were named from them.

rootstock.io — mine BTC with Rootstock

What the miners are running

Every Rootstock block header carries an extraData field in which rskj writes its own build identifier. Counting those over the same sample shows which client builds are actually producing blocks:

All of the production in this sample is on Vetiver builds, which is the upgrade currently active on mainnet — different commit hashes of the same release, as different operators build at different points.

How to merge mine today

The work happens on the pool side. A Rootstock node serves work; the pool folds it into the jobs it already sends its miners. Nothing changes on the Bitcoin node.

1. Run a Rootstock node with the mining module enabled

The four merged-mining RPC methods live in the mnr module, which must be enabled in the node configuration for the node to answer them.

2. Ask it for work

curl -X POST -H 'Content-Type: application/json' \
  --data '{"jsonrpc":"2.0","id":1,"method":"mnr_getWork","params":[]}' \
  http://127.0.0.1:4444

This returns the current Rootstock block information, the target the solution must meet, and the data to commit to. Poll it every 2 seconds, and push a mining.notify to your miners whenever new Rootstock work appears.

3. Put the tag in the coinbase

Append the OP_RETURN output described above as the last coinbase output, after your ExtraNonce2 field.

4. Submit solutions

Four methods exist; Rootstock's documentation recommends mnr_submitBitcoinBlockPartialMerkle, which it says has optimum performance, and is preferred among other available methods.

Reference implementations

Rootstock publishes pool-side integrations rather than asking operators to write their own:

• rsksmart/ckpool
• rsksmart/eloipool
• rsksmart/stratum

dev.rootstock.io — merged mining, getting started

dev.rootstock.io — JSON-RPC methods

How miners get paid

Rootstock has no block subsidy. RSKIP15 puts it plainly: RSK will be the first blockchain based on proof-of-work consensus that has no subsidy. Miners are paid out of transaction fees, denominated in RBTC — which is bitcoin, held by the peg.

Fees do not go straight to the miner of a block. They are paid into a native contract called REMASC, which holds them and distributes them on a delay, splitting a share with the miners of sibling blocks so that producing an uncle is not worthless. The delay — a maturity period of 6,000 blocks, roughly 16 hours in RSKIP15's description — exists so that a reorg cannot leave a reward paid to a miner whose block no longer counts.

RSKIP15 — REMASC

rootstock.io — rewards are paid in Bitcoin from Rootstock network fees

What has changed over the years

The core of merged mining — a tag in the Bitcoin coinbase, a proof in the Rootstock header — has not changed since launch. What has changed around it:

Which of these took effect, and in which release, is on the RSKIPs page. Of the list above, RSKIP290 and RSKIP291 are the only two tied to a release — Hop 4.0.0, on both networks. RSKIP15, RSKIP177 and RSKIP180 are Adopted, and so are in force, but no upgrade RSKIP claims them; they appear under Adopted, but no release on record instead. RSKIP110 is the only one of the six that never activated.

The share of Bitcoin hash power involved has grown a great deal. RSKIP110, written in 2019, notes that merged mining as of March 2019 is has over 35%. Rootstock's current pages claim over 80–85%. Both are quoted here with their source because, as noted above, neither is checkable from a Rootstock node.