rskj is the Java node behind the Rootstock sidechain

A node implementation, not a library for reading a chain

rskj is a Java implementation of the Rootstock node, and the project points readers to the Rootstock website for a conceptual overview and to the Rootstock white paper for a complete description of the platform. That framing matters for scope. A node is a full participant in a blockchain network, not a client library that reads a public API. It validates blocks, participates in consensus and maintains the state of the chain, which means it needs persistent storage, a peer network, a synchronisation mode and careful handling of untrusted input from the network. The audience for rskj is therefore two groups. The first is operators who want to run a node, and the second is teams building on Rootstock in Java who need the node implementation as a component. A third group, people who just want to look up contract state, is not served by this repository, and reaching for a node when a client would do is the most common way to take on far more operational weight than the task needs.

Reproducible builds are the centre of the build story

The most substantial part of the project documentation is about how to produce a build that anybody else can reproduce and verify. The idea is simple and the execution is careful. The .git directory is excluded from the Docker build context, so the commit hash and branch cannot be picked up automatically and must be passed explicitly as build arguments to be embedded in the produced jars. The documented sequence for a given version and version name, 9.0.0 and vetiver in the example, looks like this:

$ docker build \
    --build-arg COMMIT_HASH=$(git rev-parse --short HEAD) \
    --build-arg COMMIT_BRANCH=$(git rev-parse --abbrev-ref HEAD) \
    -t rskj/9.0.0-vetiver .
$ docker create --name rskj-temp rskj/9.0.0-vetiver
$ docker cp rskj-temp:/var/lib/rsk/. ./artifacts/
$ docker rm -f rskj-temp
$ cd artifacts/
$ sha256sum *.jar *.pom

The last command prints the checksums of the artefacts, and the documentation shows what that output looks like for the all jar, the javadoc jar, the sources jar, the plain jar and the pom. For a blockchain node, this is not decoration. If you are going to run software that signs and validates blocks, you need to be able to convince yourself that the binary matches the source, and a build you can rebuild and compare hashes against is the mechanism for doing that.

The container verifies its own inputs before compiling

The Dockerfile shows how that verification is built in, and the mechanism is worth understanding because it is stricter than most project containers. The build stage is based on a pinned eclipse-temurin 17 JDK image referenced by digest, and it installs curl, git and gnupg. A dedicated unprivileged user is created, the source is copied with matching ownership, and the commit hash and branch are passed in as build arguments with unknown as the default. Then the build verifies the checksums of its own inputs before it compiles anything, fetching a public key from the project's keyserver, verifying the SHA256SUMS.asc signature, and checking every file against SHA256SUMS. Only after that does it run configure.sh and the Gradle build. The version number and modifier are then read out of a version.properties file with sed, and the shaded jar is copied to rsk.jar, with all jars and poms copied into an artifacts directory. The runtime stage is a pinned eclipse-temurin 17 JRE image by digest, again running as a non-root user, with the working directory at /var/lib/rsk. The container even sets the default JVM options to a four gigabyte initial heap, which is a reasonable indicator of the memory a node expects.

Two ways to run the node: the RPC bind address decides

The runtime configuration in the image shows the operational shape of the node. The system properties that ship as defaults restrict the JSON-RPC web provider to a narrow set of interfaces, binding the address to 0.0.0.0 while listing localhost, 127.0.0.1 and the IPv6 loopback as the only allowed hosts. The upstream intent is that the RPC interface is not casually reachable, and the configuration makes that explicit rather than leaving it to the operator. The final JVM options, the log properties that set stdout to INFO, and the main class are all passed as environment variables so they can be overridden at run time without rebuilding the image. There is also a distinction between the jar and the shaded all jar, and the build copies both the consolidated rsk.jar and the individual artefacts out of the build stage, so a deployment can pick the single jar it needs. For a system that holds a copy of a chain's state, running the node as a non-root user inside a pinned, digest-referenced image with a restricted RPC surface is the shape you want, and this project has already made those choices for you.

The security signals are in the file list, not the marketing

The repository top level is unusually telling for a blockchain node. There is a SECURITY.md with a vulnerability reporting guideline that the project documentation points to for how to contact them, a FUZZING.md, a coding-principles.md, a CONTRIBUTING.md, a CODE_OF_CONDUCT.md, and a SHA256SUMS.asc file that is signed and checked inside the Docker build. The badge set backs the same impression, with a build and test workflow, a separate Rootstock Integration Tests workflow, a CodeQL workflow, an OpenSSF Scorecard badge and a SonarCloud quality gate badge. A fuzzing document at the root of a node implementation is a serious signal, because a node parses blocks and transactions from strangers, and the failure mode of a parser bug is a crash or a consensus problem rather than a bad user experience. The integration test workflow is the other half, since a node that passes unit tests but cannot synchronise with the network is not much use. None of this tells you the code is correct, but it tells you the project treats hostile input and network agreement as first class concerns.

Release naming and the LGPL are the two things to settle first

Two practical details will shape your adoption decision. The first is the release naming. The recent releases are not versioned as 9.0.x but as Vetiver releases, with VETIVER-9.0.4 on 2026-08-06, VETIVER-9.0.3 on 2026-06-18 and VETIVER-9.0.2 on 2026-06-12. Vetiver is the code name carried in the jar names, in the shape rskj-core-9.0.0-VETIVER.jar, and the version.properties file that the build reads carries a versionNumber and a modifier. If you write scripts that parse artefact names, that naming is worth understanding before you start rather than after. The last push to the repository was on 2026-10-20 and the repository is not archived, so work is current. The second is the licence. rskj is licensed under the GNU Lesser General Public License v3.0, with the text included in the repository in the COPYING.LESSER file. LGPL is a middle ground: modifications to the library itself must be published under the same terms, while applications that merely link against it are not forced open source. For a node that most people run unmodified, that is a workable arrangement, and it is also the reason the project ships it this way rather than under a permissive licence. The stable versions are published in the releases section, and compilation and running instructions live in the Rootstock Developers Portal.

Editorial conclusion

Adopt rskj if you need to run a Rootstock node or embed one in a Java system, and you want reproducible, verifiable artefacts rather than a jar pulled from a build server. Do not adopt it if you only need to read Rootstock data, since a node is a much larger commitment than a client. Before you build, check the release series you are targeting against the Vetiver release notes, read the FUZZING.md and coding-principles.md files to see how the project handles untrusted input, and confirm your environment meets the memory expectation implied by the container setting of a four gigabyte initial heap.

Frequently asked questions

Official sources

1. License: LGPL-3.0
2. Project website
3. README
4. Releases
5. rsksmart/rskj on GitHub