Network clients
Rootstock's consensus rules are written down as RSKIPs, but they are enforced by a program. There are two implementations: one that effectively the whole network runs, and one experimental reimplementation whose purpose is to disagree with it.
Repository data collected 8 Nov 2026 · how
Why the client matters
A blockchain's rules are only as precise as the program enforcing them. An RSKIP can say what a change is meant to do; the client decides what it actually does, including in the cases the specification did not anticipate. Where the two differ, the network follows the code — so on Rootstock, as on Bitcoin, the reference implementation is the de facto specification.
That matters practically for anyone running infrastructure. A node validates every rule for itself: merged-mining proofs, difficulty adjustment, gas accounting, the peg's SPV checks, and the activation height of every RSKIP. Trusting someone else's node means trusting their copy of all of that.
The two implementations
| Client | Role | Language | Licence | Latest release | Last commit | Started |
|---|---|---|---|---|---|---|
| rskj | Reference implementation | Java | LGPL-3.0 | VETIVER-9.0.4 | 2026-11-06 | 2017-05 |
| Rustock | Experimental reimplementation | Rust | MIT (stated) no file | no releases | 2026-11-08 | 2026-09 |
rskj — the reference implementation
The Java node that defines Rootstock. Every network upgrade ships as an rskj release, and the consensus rules are in practice whatever this program does — the RSKIPs specify the intent, rskj settles the detail. Essentially all of the network runs it.
- Written in Java and built with Gradle; it runs anywhere a JVM does.
- It is also the merged-mining server: the mnr_* JSON-RPC methods a pool needs are served by this node.
- Because it is the only production client, a consensus bug in rskj is a consensus bug in Rootstock. There is no second implementation to disagree with it and so expose the error.
Where to get it
- Source: github.com/rsksmart/rskj — Java, licensed LGPL-3.0.
- Releases: github.com/rsksmart/rskj/releases — currently VETIVER-9.0.4, 6 Aug 2026. Each network upgrade is one of these; the RSKIPs page maps them to the proposals they activated.
- Running a node: dev.rootstock.io — node operators.
Rustock — a second opinion
An independent full node written in Rust, which follows mainnet and validates every consensus rule for itself. Its value is exactly that it was written separately: where it and rskj agree, the rule is probably understood; where they differ, one of them has found something.
- Validates merged-mining proofs, difficulty adjustment and the activation-height-gated RSKIPs independently of rskj.
- Deliberately not a wallet: eth_sendTransaction, eth_sign and the personal_* namespace are unimplemented. Transactions are signed elsewhere and submitted with eth_sendRawTransaction.
- Experimental. It is not a drop-in replacement for rskj and should not be relied on to mine, sign or custody anything.
Experimental. Rustock follows mainnet and validates it, but it is not a production node and is not a drop-in replacement for rskj. Nothing that mines, signs or custodies value should depend on it.
Where to get it
- Source: github.com/SergioDemianLerner/rustock — Rust.
- Project site: rustock.dev.
Disclosure: the figures elsewhere on this site that are read from a Rootstock node are read from a Rustock node. Where that matters — the PowPeg history especially — the results are cross-checked against the Bridge's own getters before publication, and the method page says how.
Licences
Both are open source, under different licences with materially different obligations.
| Client | Licence | In short |
|---|---|---|
| rskj | LGPL-3.0 | Copyleft. Changes to the library itself must be released under the same licence; software that merely links to it need not be. |
| Rustock | MIT (stated) no file | Permissive. Use, modify and redistribute, including commercially, provided the copyright notice is kept. |
Rustock: the project states MIT in its README, but there is no licence file in the repository root on main, so GitHub reports no licence.
The distinction is between a project that is licensed and one that says it is: automated tooling, package registries and corporate review processes all read the file, not the README. The collector checks for the file directly on every run rather than inferring its absence, so this note disappears by itself once one is committed.
One client is a risk
Essentially the entire Rootstock network runs rskj. That has an obvious consequence: a consensus bug in rskj is a consensus bug in Rootstock. There is no independent implementation to disagree with it, and a rule that every node gets wrong in the same way is indistinguishable from a rule that is right.
Rootstock has felt this. The June 2024 outage came from a 12-byte signed field in the Bridge's view of Bitcoin's chainwork overflowing at a specific Bitcoin block height. It was not caught by review or by testnet; it was caught by Bitcoin reaching that height. A second implementation, built from the specification rather than from the same source, is one of the few things that finds that class of error before the chain does.
That is what makes a reimplementation worth having even while it is experimental. The point is not that Rustock is ready to replace anything — it is not — but that the act of writing it independently tests whether the rules are written down well enough to be implemented twice.
These are the only two Rootstock node implementations known to this site. If another exists, the suggestion form is the place to say so.