What Running a Solidus Node Actually Requires Today

This page walks the exact steps to verify a solidus-node release before you run it as root, and it also tells you, plainly, the one thing that verification does not prove.

Everything below proves the binary is authentic. Nothing below proves it is live. Those are different claims, and this page keeps them apart, because a self-operator who conflates them is the reader most likely to get burned by it.

That distinction is the entire reason this page exists. A signature check and a synced chain client are two different technical facts, produced by two different tests, and only one of them has actually been run. If you're about to ssh into a box you own and run this as root, you should know exactly where the evidence stops, not have it blurred into a single reassuring paragraph.

Nothing here needs your trust in the messenger. Every value in this page, byte counts, hashes, key fingerprints, is something you check yourself against the live source, not something you take on the strength of this page saying so. That's the point of publishing exact numbers instead of a description.

Hardware envelope

The stated design target is 2 GB RAM. That is a design target, not a benchmarked production requirement: nobody has load-tested solidus-node at scale, and this page won't imply otherwise by omission. Treat it as the floor the software was designed around, not a number backed by production traffic under real validator load, real peer counts, or real state growth. No other hardware minimum is confirmed at write time; this page won't invent a CPU count, disk size, or bandwidth figure that isn't in the source docs. If you're provisioning a box, size it above the floor and watch it, rather than treating 2 GB as a guarantee.

The verification chain

The release pipeline is: an installer script, a signed manifest, a binary. Each step is independently checkable, and each one only proves what it proves, don't collapse them into a single "it works" conclusion. This is a fail-closed chain: if any one link doesn't match, the honest move is to stop, not to proceed on the assumption that the rest is probably fine.

1. Fetch and inspect the installer

curl -sI https://releases.solidus.network/install.sh

This returns 200 and a Content-Length of 7323 bytes. Confirm the byte count matches before you look at the script itself, and read the script before running it, don't pipe it straight into a shell. This page deliberately does not give you a one-line curl | sh command: skipping straight to install-and-trust is exactly the shortcut that erases the distinction this page exists to preserve. Save the script locally, open it, and confirm what it actually does, fetches the manifest, resolves the platform-appropriate binary URL, checks the hash, before you execute anything.

2. Fetch the signed manifest

curl -s https://releases.solidus.network/stable/latest.json

The manifest is Ed25519-signed against the release public key (fingerprint prefix 4554f96c…, armed 2026-06-07), and it carries "rollout_percent": 100 and "version": "v0.1.0". Import the release key and verify the signature before trusting the JSON body:

gpg --import release-pubkey.asc
gpg --verify latest.json.sig latest.json

A passing verification tells you the manifest, the version string, the rollout percentage, the hash it publishes for the binary, was signed by the holder of that key. It does not tell you anything about the chain the binary will try to talk to. rollout_percent: 100 means this release is the one the pipeline is currently pointing everyone at; it says nothing about whether "everyone" can currently sync.

3. Fetch the binary and check its hash

Take the URL from the manifest you just fetched rather than guessing it: the binaries map keys a per-platform URL and SHA256 by target triple, which is exactly what the installer resolves against. For x86-64 Linux that is:

curl -O https://releases.solidus.network/bin/v0.1.0/solidus-node-x86_64-unknown-linux-gnu
sha256sum solidus-node-x86_64-unknown-linux-gnu

The binary is 27,933,008 bytes, ELF x86-64, and its SHA256 (0012f106…8630e) matches the hash published in the signed manifest exactly. If your local hash doesn't match that value character for character, stop, don't run the binary, and don't round the mismatch off as "close enough." A half-matching hash is not partial confirmation; it's a reason to walk away and re-fetch from the source, not to proceed with caveats.

That's the whole chain: installer → signed manifest → binary hash, each link checkable from a terminal, with no account and no trust extended beyond the one release key. It is real, and it is exactly the kind of thing that should be walked rather than taken on faith. Run it yourself before you run the node itself: the point of publishing the exact byte counts and hash values above is so you have something concrete to compare against, not so you take this page's word for it.

What this does not verify

Signature and checksum verification confirm one thing: the binary you downloaded is the binary Solidus published. That is authenticity. It is not liveness.

This isn't a hedge; it's the actual state of the evidence. Don't present the verification chain above and a working sync as one proven fact: they're two separate questions, and only the first one has an answer right now.

For the full ledger on what's shipped versus what's roadmap across the rest of the product, see What's Actually Running in Solidus Node Today rather than re-litigating it here.

If you do run the binary, watch the JSON-RPC endpoint's reported block height against rpc.solidus.network's own current height, over time, rather than trusting a single successful start-up log line: a process that starts cleanly and a process that stays caught up to chain head are not the same observation, and the second one is the one nobody has recorded yet.

What would actually close this gap is specific: a fresh machine, a clean install following the three steps above, and a recorded comparison of local block height against the public RPC's height sustained over time, not a single snapshot. Until that test exists and is published, the honest position is silence on sync, not optimism.

What running the binary is not

Installing and running solidus-node is not the same claim as becoming a validator. Joining either requires staking plus DID registration, and no tradeable token exists to stake with.

This isn't a technicality. None of that changes by running the binary; it changes by staking and registering a DID, which is a separate step this page doesn't walk.

For what validator participation actually requires, see What Is a Blockchain Validator?.