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 · 50 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	Benched for a while after too many missed slots. No stake burned.
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

Two routes to the same result. Start with the one-command installer; use the manual route if you want to understand every moving part or you are not on Debian/Ubuntu.

This installs the dependencies and Rust, builds the node, creates your key, initialises from genesis, installs a service that restarts on crash and on reboot, and starts it.

curl -sSf https://raw.githubusercontent.com/inazuma-network/inazuma-core/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-core/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         # height, sync state, missed-slot streak
inazuma validators     # active set, stake shares, next leader
inazuma slashing       # params, jail state, slash history
inazuma unstake --key <SECRET_HEX> --amount 1000
inazuma unjail  --key <SECRET_HEX>

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 & jailing

Enforcement activates at block 130,000, so all earlier history replays unchanged. 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	50 consecutive missed leader slots.	Jailed 10,000 blocks (~1 h). No burn on a first offence; repeats burn 0.1%.
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 on a first offence. For an honest operator the realistic worst case is a lost hour of rewards. 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
Jailed	50 missed slots in a row	Fix the node, wait out the jail height, then inazuma unjail
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?

No burn on a first downtime offence. You get benched and lose that period's rewards.

›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 & WebSocket reference Domain & RPC security Source on GitHub Get test INAZ