Solidus Validator Guide

A guide to the Solidus validator model — what the solidus-node binary actually supports today, and what is still design intent.

Current Status — read this first

The production testnet (rpc.solidus.network) runs as a single Solidus-operated process today. It starts as solidus-node dev-testnet --testnet-dir ... --rpc-port 9944 — one process simulating the whole validator committee over an in-process channel transport, not a set of independently-run machines reachable over the public internet. The multi-node P2P path (solidus-node run --consensus) and the non-validating full-node path (solidus-node run --full-node) both exist in the codebase and are what a public validator rollout would use, but there is no externally-joinable validator flow deployed today.

Several mechanics this guide used to describe as available are not implemented yet. Each section below is marked. In short:

Why Run a Validator?

Validators are the infrastructure operators of the Solidus network. Blocks, transactions, DID/credential operations, and (once wired up) identity verification throughput all depend on the validator committee staying online.

Fee-sharing. Validators collectively receive 70% of transaction fees, settled at the end of every block. Today that 70% is split equally across all active validators — a validator staking 1,000,000 SLDS currently earns the same per-block share as one staking the 10,000 SLDS minimum. There is no stake-weighted or uptime-weighted reward formula in the running code.

Structurally necessary. Decentralized identity requires decentralized infrastructure. Every validator that joins increases resilience, geographic coverage, and censorship resistance — once the network supports external validators joining (see Current Status above).

Governance. The only on-chain “governance” implemented today gates an unrelated compute-subnet allow-list (ComputeAdmit/ComputeRemove), and treats any active validator identically regardless of stake. A general validator-facing governance system (proposals, votes, slashing appeals) does not exist yet.

Validator Stake & Hardware Profiles

The protocol enforces exactly one minimum stake on-chain: 10,000 SLDS (MIN_STAKE in solidus-txns). There is no separate, protocol-enforced stake minimum for a “Subnet” or “Core” class, and stake size above the minimum does not currently change your reward share or your consensus weight.

node.solidus.network’s own hardware guide (node.solidus.network/docs/hardware) groups recommended hardware into three self-selected profiles — Light, Subnet, Core — as sizing guidance, not as an on-chain rule:

All profiles run the identical solidus-node binary — there is no separate light client, and nothing in the software itself distinguishes one profile from another.

Hardware Requirements

These figures track the canonical, always-current spec at node.solidus.network/docs/hardware — treat that page as the source of truth for current numbers; the table below is a snapshot.

Reference instances (see node.solidus.network/docs/hardware for the live list): Light — Hetzner CX22 ($5.40/mo, 2 vCPU · 4 GB); Subnet — Hetzner CCX23 ($32/mo, 4 dCPU · 16 GB); Core — Hetzner CCX43 or an equivalent dedicated NVMe instance in the $120–400/mo range.

Uptime — 🟡 no protocol enforcement today

There is currently no uptime-tracking code anywhere in solidus-node or the chain state — no automatic reward penalty and no automatic removal from the committee for downtime. Keep your node online as a matter of good operation, not because the protocol measures or penalizes it yet.

Software Setup

Step 1: Install Solidus Node

# Download the Solidus node binary
curl -sSL https://releases.solidus.network/install.sh | bash
 
# Verify the installation
solidus-node --version

The installer fetches a signed manifest from releases.solidus.network/stable/latest.json, verifies its Ed25519 signature against a release key compiled into the script, downloads the binary for your OS/arch, checks its SHA-256 against the (signed) manifest, and aborts without installing anything if any check fails.

For manual installation, the manifest lists a raw per-arch executable for each supported target (x86_64-unknown-linux-gnu, aarch64-unknown-linux-gnu) — there is no .tar.gz archive:

# Read the current version + binary URLs from the signed manifest
curl -s https://releases.solidus.network/stable/latest.json
 
# Download the binary for your architecture (URL comes from the manifest above)
wget https://releases.solidus.network/bin/v0.1.0/solidus-node-x86_64-unknown-linux-gnu
 
chmod +x solidus-node-x86_64-unknown-linux-gnu
sudo mv solidus-node-x86_64-unknown-linux-gnu /usr/local/bin/solidus-node

Step 2: The real solidus-node CLI

solidus-node (built from protocol/apps/consensus/crates/solidus-node) has six subcommands — this is the complete list, verified against main.rs:

solidus-node genesis -n <validators> -o <dir> --chain-id <id>   # generate a devnet's genesis.json + validator-N/ dirs + keys
solidus-node run --config <config.toml> [--consensus] [--full-node]  # run as a validator (or, with --full-node, a non-validating full node)
solidus-node dev-testnet --testnet-dir <dir> --rpc-port <port> --rpc-host <host>  # run an entire N-validator devnet in ONE process (this is what the live testnet runs)
solidus-node peer-id --key <node.key>       # print the libp2p PeerId derived from a node.key file
solidus-node canon-dump --config <config.toml>  # dump the canonical ledger index (node must be stopped)
solidus-node sign-transfer --key <key> --to <address> --amount <n> --nonce <n>  # build + sign a Transfer tx, printed as JSON

Running solidus-node with no subcommand falls back to the legacy single-node mode (equivalent to run --config config.toml). There is no keygen, start, or validator subcommand — those do not exist in this binary.

solidus-node genesis -n 4 -o ./testnet writes genesis.json, treasury.key, faucet.key, and one validator-N/ directory per validator, each containing node.key (Ed25519, hex), bls.key (BLS12-381, hex), and a generated config.toml.

Back up your key files immediately. Losing node.key or bls.key means losing your validator identity and access to staked SLDS. Store backups encrypted and offline.

Step 3: The real config format

Multi-node configs use a [node] table, zero or more [[peers]] entries, and a top-level bootstrap_peers array (which must appear before the [node] header — TOML parses a bare key after a table header into that table):

bootstrap_peers = []   # optional Kademlia bootstrap multiaddrs, e.g. "/ip4/1.2.3.4/tcp/30300/p2p/<peerid>"
 
[node]
chain_id     = "solidus-testnet-1"
listen_port  = 30300                # P2P (libp2p) port
data_dir     = "./data"
genesis      = "../genesis.json"
ed25519_key  = "node.key"
bls_key      = "bls.key"
rpc_port     = 9944
rpc_listen   = "127.0.0.1"          # "0.0.0.0" only behind a reverse proxy — RPC has no built-in auth
node_index   = 0                    # this validator's index in the committee
full_node    = false                # true = never propose/vote, just sync + serve RPC
 
[[peers]]
index    = 1
peer_id  = "12D3Koo..."             # libp2p PeerId, from `solidus-node peer-id --key validator-1/node.key`
address  = "/ip4/127.0.0.1/tcp/30301"

There is no tier, [consensus] subnets, [storage], [api], or [metrics] table — those keys do not exist in the real NodeConfig/MultiNodeConfig structs.

Step 4: Start the Node

cat > /etc/systemd/system/solidus-node.service << 'EOF'
[Unit]
Description=Solidus Network Node
After=network.target
Wants=network.target
 
[Service]
Type=simple
User=solidus
Group=solidus
ExecStart=/usr/local/bin/solidus-node run --config /etc/solidus/config.toml --consensus
Restart=always
RestartSec=10
LimitNOFILE=65536
StandardOutput=journal
StandardError=journal
 
[Install]
WantedBy=multi-user.target
EOF
 
systemctl daemon-reload
systemctl enable solidus-node
systemctl start solidus-node
 
# Check status
systemctl status solidus-node
journalctl -u solidus-node -f

Step 5: Verify Sync

The RPC server is JSON-RPC 2.0 over HTTP POST only (via jsonrpsee) — there is no REST GET /status route. Check node health with solidus_nodeInfo and solidus_chainInfo:

curl -s -X POST http://127.0.0.1:9944 \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"solidus_nodeInfo","params":[]}'
# {"jsonrpc":"2.0","id":1,"result":{"version":"0.1.0","uptime_seconds":1264674,"rss_bytes":203296768}}
 
curl -s -X POST http://127.0.0.1:9944 \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"solidus_blockNumber","params":[]}'

Compare your solidus_blockNumber result against the public rpc.solidus.network’s to confirm you’re caught up.

Staking and Registration

solidus-txns defines an on-chain Stake/Unstake transaction type, and solidus-state’s executor enforces the 10,000 SLDS minimum and the 21-day unbonding period on it. No CLI or SDK command builds one yet — solidus-node’s only transaction-signing subcommand is sign-transfer (Transfer only), and the TypeScript SDK does not expose a staking helper. Standing up a new external validator against a network that supports it — once the externally-joinable path described in Current Status ships — will need that tooling built first. There is no 24-hour “activation delay” or similar pending state anywhere in the code today: a validator’s active flag is set the moment a Stake transaction executes.

Unstaking

Unstaking is a direct on-chain Unstake transaction, not a request through a governance dashboard (no such dashboard exists). Submitting one moves your stake into a 21-day unbonding period (UNBONDING_PERIOD_MS), during which it earns no rewards; after 21 days the executor allows it to return to your spendable balance.

Monitoring

What’s real today

• solidus_nodeInfo — process version, uptime in seconds, resident memory (rss_bytes).
• solidus_chainInfo — chain ID, native token metadata, genesis hash, latest block height, node version.
• solidus_blockNumber / solidus_getLatestBlock / solidus_canonHead — sync progress.
• solidus_getValidators / solidus_getValidatorStake — committee membership and stake.
• Logs — tracing-based structured logs; journalctl -u solidus-node -f.

🟡 Roadmap — not in the deployed binary

There is no Prometheus /metrics endpoint, and no named metrics (solidus_uptime_seconds, solidus_peer_count, etc.) anywhere in protocol/apps/consensus/crates/solidus-node. Wire up log-based or RPC-polling alerting until this ships.

Slashing

What’s real today

solidus-consensus and solidus-hotstuff2 both implement equivocation detection: a validator that signs two conflicting votes (or, in HotStuff-2, two conflicting proposals) in the same round/view is caught, and the two signed messages are packaged into self-contained, independently-verifiable evidence (checked against the accused validator’s own committee key).

🟡 Roadmap — not wired up yet

Catching an equivocation does not currently reduce the offending validator’s stake. The solidus-hotstuff2 slashing module’s own comment is explicit about this: solidus-txns has no Slash transaction payload today, so turning verified evidence into an actual stake reduction is a founder decision (a new native payload, or a governance action) that has not been made yet. There is also no uptime-based slashing or removal — no uptime tracking exists at all (see Hardware Requirements above). Treat any specific slashing percentage or recovery process as undecided until this ships.

Never run two instances of solidus-node with the same key regardless — that is exactly the equivocation pattern the detector above is built to catch.

Upgrading Your Node

# Check the current version + binary URLs
curl -s https://releases.solidus.network/stable/latest.json
 
# Stop the node gracefully
systemctl stop solidus-node
 
# Replace the binary (see Step 1 above for the download/verify steps)
sudo mv solidus-node-x86_64-unknown-linux-gnu /usr/local/bin/solidus-node
 
# Start the node
systemctl start solidus-node
solidus-node --version

Major protocol upgrades will require validators to upgrade within a window once mainnet governance exists; there is no such enforcement mechanism today.

Economics

How fees are actually distributed today

Per block, solidus-state’s executor settles all fees collected in that block:

• 20% to the protocol treasury.
• 70% split equally across every address in the active validator set — not weighted by stake size, uptime, or any reputation score.
• The remainder (~10%) is not paid out (implicitly burned; the live chain keeps no counter for it).

There is no 7-day “epoch” reward cycle in the code — fees settle every block. The reputation field on a validator record exists (observed as 1000 for a validator that staked via a Stake transaction, 0 for genesis-seeded validators on the live chain today) but no code path adjusts it — there is no reputation-scoring system to describe yet.

Concrete SLDS reward figures are not published while the network is on testnet — testnet SLDS has no monetary value, and the equal-split mechanism above means profitability depends on how many other validators are active, not on your stake size. Treat any specific $/month reward estimate as speculative until mainnet.

FAQ

Q: Can I run multiple validators? The Stake transaction has no identity-linking requirement in the code today — “one human, one validator” is a design intent (see Solidus’s “Proof of Identity” eligibility concept), not something enforced on-chain yet.

Q: Can I unstake my SLDS? Yes, via an Unstake transaction (see Staking and Registration above). There is a 21-day unbonding period during which your SLDS is locked and earns no rewards. After 21 days it returns to your spendable balance.

Q: What happens to my stake if I’m slashed? Not applicable yet — see Slashing above. Detection and evidence exist; the stake-reduction step does not.

Q: Do I need a static IP address? The node has no built-in requirement for one. A static IP and public port generally improve peer connectivity once you’re running the multi-node --consensus or --full-node path with real P2P peers.

Q: Can I run a validator from my home? Yes for a Light profile on a stable connection. Subnet and Core profiles are better suited to dedicated hardware or a data center given the bandwidth and uptime those hardware guidance tiers assume.

Q: What is the minimum KYC level to become a validator? None is enforced in code today. Requiring identity verification to validate is part of Solidus’s long-term “Proof of Identity” design intent, not something the staking transaction or consensus engine checks currently.

Q: When does mainnet launch? See the Solidus Roadmap (docs/roadmap.md).

Support

• Source + issues: github.com/solidusnetwork/protocol  — the public mirror of the node/consensus code this guide describes; GitHub Issues are open there.
• Validator Dashboard: not yet live (validators.solidus.network is not in the current surface inventory).
• Documentation: this guide and node.solidus.network/docs/hardware.
• Emergency: [email protected] (for slashing or critical issues only).

Solidus does not currently run a Discord or other real-time chat — check the GitHub repo above or the docs site for updates rather than a chat community link.