Inazuma docs · Devnet

Run a validator

Rent a server, paste one command, bond 1,000 INAZ. This guide assumes no blockchain experience — every term is explained the first time it appears.

Time needed

~20 minutes

Minimum server

2 vCPU · 4 GB NVMe

Minimum stake

1,000 INAZ

Block time

400ms

What a validator actually is

Inazuma produces a block every 400ms. Someone has to build each of those blocks and everyone else has to agree it is valid. A validator is a small server that keeps a full copy of the chain, gets picked in turn to produce a block (more stake means picked more often), votes on the blocks others produce, and earns the fees and rewards for the blocks it makes.

To be picked you lock up — “bond” — 1,000 INAZ. Cheat, and part of that stake is burned. Go offline, and you are temporarily benched. That is the whole deal. There is no allowlist and no application: bond and you are in the rotation on the next block.

Term	Plain English
Stake / bond	INAZ you lock so the network can punish you if you misbehave.
Slot	Your turn to produce a block.
Missed slot	Your turn came and your node did not produce — offline or behind.
Jailed	Legacy state. Downtime jailing was retired at block 1,400,000 — only double-signing removes a key now.
Slashed	Stake burned for provable cheating (signing two blocks at one height).
Tombstoned	That key is banned forever. Only ever happens for double-signing.
Unbonding	The 300-block wait before withdrawn stake becomes spendable.
Genesis	The chain's block 0. Every node must use the identical file.

Step 1

Pick a server

You do not need a powerful machine — you need a consistent one on a fast disk. 400ms blocks mean a slow disk hurts far more than a slow CPU.

Setup	vCPU	RAM	Disk	Good for
Minimum	2	4 GB	50 GB NVMe	Works, but little headroom
Recommended	4	8 GB	100 GB NVMe	What we run in production
Heavy RPC / replica	8	16 GB	200 GB NVMe	If you also serve public traffic

Also required, whichever provider you use:

Ubuntu 22.04 or Debian 12, 64-bit, with root or sudo access
A static public IP and inbound TCP 9944 open
Unmetered or at least 2 TB/month bandwidth — gossip is constant
Local NVMe SSD. Not spinning disk, not network-attached storage

Avoid the cheapest burstable-CPU plans. They throttle at exactly the wrong moment and cause missed-slot streaks. One vCPU is fine for a read replica, never for a validator. If you run a backup, put it in a different data centre — two boxes in one rack fail together.

Any host works: a rented VPS, a dedicated box, your own rack, or a machine at home behind a port-forward. The node has no cloud dependencies at all. Expect roughly $10–25/month for a suitable VPS.

Step 2

Install the node

One command per device type — Linux, macOS, Windows or Docker — all ending at the same running node. The manual route is there if you want to see every moving part.

The production path: Ubuntu 22.04 / Debian 12 with a static IP. Installs the dependencies and Rust, builds the node, creates your key, initialises from genesis, installs a systemd service that restarts on crash and on reboot, and starts it.

curl -sSf https://raw.githubusercontent.com/inazuma-network/inazuma-validator/main/scripts/install-validator.sh | bash

Prefer to read the script before running it — you should:

curl -sSfO https://raw.githubusercontent.com/inazuma-network/inazuma-validator/main/scripts/install-validator.sh
less install-validator.sh
bash install-validator.sh

Options are environment variables:

INAZ_ROLE=replica bash install-validator.sh        # read-only node, no key, no stake
INAZ_PEERS=1.2.3.4:9944 bash install-validator.sh  # join via a different seed

The installer is safe to re-run — that is also how you upgrade. It never overwrites an existing key or data directory. When it finishes it prints your address; continue at step 3.

Back the key up offline the moment it exists. Lose it and you can neither sign blocks nor ever withdraw your stake — nobody can recover it for you. And never run one key on two machines: two nodes signing at the same height is indistinguishable from an attack and is tombstoned permanently.

Step 3

Bond your stake

Fund your address with at least 1,000 INAZ, confirm you are synced, then bond.

inazuma status                                  # must say in sync
inazuma stake --key <SECRET_HEX> --amount 1000
inazuma validators                              # you should be in the active set

You are now in the leader rotation. The leader keeps every fee in its block plus 20% commission on the block reward; the remaining 80% is split across the active set in proportion to stake and credited immediately — there is no claim transaction.

Step 4

Day-to-day operation

Watch exactly three things. Everything else is noise.

Missed-slot streak — should stay at 0–2
Lag versus the network tip — should stay under a couple of blocks
Free disk — top up long before it fills

inazuma status           # your node only: height, finalized, peers, mempool
inazuma status --compare # also query the public RPC for the network tip (opt-in)
inazuma validators       # active set, stake shares, next leader
inazuma slashing         # params, jail state, slash history
inazuma wallet           # saved address, balance, stake, rewards
inazuma unstake --key <SECRET_HEX> --amount 1000

status talks to your own node by default. Comparing against the network tip means contacting rpc.inazuma.network, which reveals your IP to whoever runs it, so it only happens when you ask for it with --compare.

Reading the logs

The node prints Ethereum-client style structured logs — the same shape geth and lighthouse operators already read, so grep, journald and log shippers work unchanged. One line per event, UTC timestamps, key=value fields.

INFO  [08-19|01:27:24.469] Starting Inazuma node                  chain=7777 datadir=/var/lib/inazuma validator=8cCbiPdq..Vw6u
INFO  [08-19|01:27:24.469] Started P2P networking                 self=b991d1a4..aa64 peers=2 transport=INSC1-required
INFO  [08-19|01:27:32.512] Syncing chain segment                  number=1,402,900 target=1,404,120 progress=99.91% peers=2
INFO  [08-19|01:27:40.104] Chain synchronisation finished          height=1,404,120 validators=3 netstake=140000 INAZ you=producing blocks
INFO  [08-19|01:27:40.507] Imported new chain segment             number=1,404,121 hash=9f2c81aa..a1c4 txs=3 peers=2 elapsed=6ms
INFO  [08-19|01:27:48.507] Chain head updated                     number=1,404,141 finalized=1,404,109 peers=2 stake=40000 INAZ role=validator
WARN  [08-19|01:28:02.507] Looking for peers                      peercount=0

Message	Meaning
Starting Inazuma node	Boot line: chain id, data directory, validator address
Loaded local state database	Local height, finality and state root on disk
Started P2P networking	Node key, peer count, INSC1 transport mode
Validator account ready	Your address, bonded stake, bonded or unbonded
Syncing chain segment	Sync progress, printed every 8s while catching up
Chain synchronisation finished	Caught up — live validator set and total stake
Imported new chain segment	A block with transactions was produced or applied
Sealed new block	Empty block; logged at most once every 10s to stay quiet
Chain head updated	Heartbeat at the tip: height, finality, peers, your role
Looking for peers	No peers — check --peers and the firewall on 9944

journalctl -u inazuma -f | grep -E "WARN|ERROR|Imported|synchronisation"

# animated Inazuma HUD instead of logs (banner, progress bar, QR dashboard link)
inazuma run --data /var/lib/inazuma --ui hud

Upgrading

cd ~/inazuma-core && git pull && cargo build --release
sudo install -m755 target/release/inazuma /usr/local/bin/inazuma
sudo systemctl restart inazuma

Consensus changes always ship behind an activation height, so upgrading early is safe and upgrading late is what breaks you. Watch releases.

Step 5

Hardening

Do this once your node is stable and synced.

Encrypted, pinned P2P

Every peer connection is an INSC1 session: ephemeral X25519 exchange, an Ed25519 signature over the handshake transcript, then ChaCha20-Poly1305 framing. Pin the node keys you accept so an attacker cannot surround you with fake peers.

inazuma run ... \
  --peers rpc.inazuma.network:9944 \
  --peer-ids <PEER_NODE_KEY_HEX>,<PEER_NODE_KEY_HEX> \
  --require-encrypted-p2p

curl -s localhost:9933 -d '{"jsonrpc":"2.0","id":1,"method":"inaz_netInfo"}'

Keep RPC bound to 127.0.0.1 unless you intend to serve the public. If you do, see the RPC reference for API keys, per-method cost weighting and stake-weighted rate limits.

Basic server hygiene

sudo apt install -y unattended-upgrades fail2ban
sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl restart ssh

Slashing & liveness

Enforcement activates at block 130,000, so all earlier history replays unchanged. Downtime jailing was retired at block 1,400,000 — like Ethereum, being offline only costs the rewards for the slots you missed, and your validator keeps its seat. Reporting is permissionless: anyone who submits valid proof keeps 10% of the burn as a bounty. Evidence stays valid for 100,000 blocks and unbonding takes 300 blocks, so stake cannot outrun a pending report.

Offence	How it is detected	Penalty
Equivocation (double-sign)	Two blocks or two precommits signed at the same height.	Burn max(5%, 3 × stake share) and permanent tombstone.
Downtime	Missed leader slots — offline, behind, or laptop asleep.	No jail and no burn since block 1,400,000. You only lose the rewards for the slots you missed.
Invalid block / bad state root	Peers reject the block; it never finalises.	No burn — the block is orphaned, the slot counts as missed.

Worked example

A validator holding 20% of total stake double-signs. 3 × 20% = 60%, which beats the 5% floor, so 60% of its stake is burned and the key is banned forever. A validator with 1% of stake loses the 5% floor instead. The bigger you are, the more an attack costs you — that is deliberate.

# report a double-sign you captured and collect the bounty
inazuma report --evidence ./evidence.json

Downtime never burns stake and never jails. For an honest operator the realistic worst case is the rewards for the minutes it was offline. The only way to lose real money is running one key on two machines — so don't.

Step +

Read replicas — no stake required

Reads and consensus are different jobs. A replica syncs every block but never produces one and never votes, so you can run as many behind a load balancer as your traffic needs without touching the validator set.

inazuma run --data /var/lib/inazuma-replica --genesis /etc/inazuma/genesis.json \
  --replica --peers rpc.inazuma.network:9944 \
  --rpc 0.0.0.0:9933 --ws 0.0.0.0:9955

# or, with the installer
INAZ_ROLE=replica bash install-validator.sh

Troubleshooting

What you see	Why	Fix
state root mismatch at a low height	Wrong genesis.json	Re-init with the network genesis into a clean data dir
No peers after 60 seconds	Port 9944 closed or wrong --peers	sudo ufw allow 9944/tcp, verify the seed address
Missed-slot streak keeps growing	Node behind, or disk too slow	Check lag with inazuma status; move to local NVMe
Missed slots and no rewards	Node offline or behind — no jailing since block 1,400,000	Bring the node back and let it sync; rewards resume automatically
nonce too low when sending	Stale pending nonce	Read pendingNonce from inaz_getAccount
Service dies on boot	EnvironmentFile missing or unreadable	chmod 600 the env file, then systemctl daemon-reload
cargo: command not found after reconnecting	Rust env not sourced	Run . "$HOME/.cargo/env" or re-login
Build killed on a 2 GB box	Out of memory while linking	Add 2 GB swap, or build elsewhere and copy the binary

Still stuck? Open a validator support issue on GitHub with the output of inazuma status and the last 50 lines of journalctl -u inazuma.

FAQ

›Do I need to know Rust?

No. You need to be able to rent a server and paste about eight commands.

›Can I run it at home?

Yes, if you can forward TCP 9944 and your connection is stable. A home outage costs you rewards, not stake.

›Can I run two validators?

Yes — two machines with two different keys. Never the same key on two machines.

›What happens if I lose my key?

The stake is unrecoverable. Back up the key file offline before you bond anything.

›Can I unstake whenever I want?

Yes. It becomes spendable after 300 blocks, roughly two minutes.

›Is my stake at risk if I'm just offline?

Short outages cost only the rewards for the slots you missed — no jail, no burn. From block 2,000,000, an absence past 50 slots in a row slowly decays the bond until you are back online.

›Do I need a domain or TLS?

Only if you serve public RPC. A validator needs neither.

›How much does it cost to run?

A suitable VPS is roughly $10–25 per month.

RPC reference Security Validator repo Get test INAZ Source on GitHub