Become a ROKO testnet validator

This is the beginner route from a synchronized node and local node wallet to a validator candidate. The local node wallet is the only path with successful validator deployment reported for ordinary users as of the October 23, 2026 operator correction. MetaMask/Talisman enrollment is unverified or known-failing. ROKO uses open staking enrollment: you do not need a ROKO operator to approve a normal candidacy transaction. Selection is still competitive and is not guaranteed.

Which address goes where

These values are for the current ROKO testnet, checked September 13, 2026: chain ID 52370 (0xcc92), 18 decimal places, genesis 0x0a2296f8f036f71437e8f6f2028ccbf0dc3dd6b3de9120fc15e43789c794e8bb. The live runtime reports mainnet spec 286; that internal name does not make this production mainnet. Verify the chain ID and genesis together.

What you are doing	Address or value to use	Where it belongs
Fund your validator or look up its balance	Your own staking wallet's full 0x account address	The sending wallet's recipient field, an explorer account lookup, or the node-wallet --account option
View or import the pwROKO token; use its EVM lock/unlock interface	0x0000000000000000000000000000000000000500	Token import or the supported pwROKO application; symbol pwROKO, decimals 18
Identify the EVM staking interface	0x0000000000000000000000000000000000000700	Supported staking application contract configuration; this is not your staking account
Lock and bond through the node wallet	No contract address	The tool selects native pwRoko.lock and staking.bond from chain metadata
Register session keys and declare validator intent	No contract address	Native session.setKeys and staking.validate, signed by your staking account
Register the public session tuple	The package's session.encodedKeys value	The session-key field; this long public value is not an account address
Tell peers how to reach your node	Your public P2P multiaddress ending in your peer ID	Enrollment's --public-address; this is not an RPC URL or wallet address

The two fixed addresses above are precompiles: interfaces implemented by the chain runtime. Use the whole address when copying it. Never send a plain ROKO transfer to a precompile to lock or bond. Those actions require a method call. Keep native ROKO in your own account for fees after locking.

Use the local node-wallet guide for the complete enrollment sequence. Agora remains useful for finalized public staking and validator inspection; its browser enrollment is unverified or known-failing. The EVM staking precompile does not expose session.setKeys or staking.validate; importing it into MetaMask cannot complete enrollment. Several staking selectors are runtime-specific, so a generic Solidity ABI is not a substitute for the supported application. The local wallet avoids this ABI issue by encoding native calls from metadata.

Rewards and exit are separate native staking actions, including staking.payoutStakers, staking.chill, staking.unbond, and staking.withdrawUnbonded; they do not require another recipient contract. The enrollment-only node-wallet command does not implement these maintenance actions. Follow the rewards and exit guidance below before changing a live validator. Unbonding stake and completing a pwROKO unlock are separate waits.

For eligible snapshot claims, use the claim application with the eligible account. A claim is not a transfer to either precompile, and a newly generated node wallet does not inherit another account's eligibility.

Check the network before signing

Run this read-only command in a terminal with curl installed. It does not need a wallet and does not send a transaction:

curl --fail --show-error --silent https://rpc.roko.network \
  -H 'Content-Type: application/json' \
  --data '[{"jsonrpc":"2.0","id":1,"method":"eth_chainId","params":[]},{"jsonrpc":"2.0","id":2,"method":"chain_getBlockHash","params":[0]}]'

Find "id":1 with "result":"0xcc92" and "id":2 with the full genesis above. The responses may appear in either order. Stop if either differs. Public HTTPS RPC is for this check; local node-wallet signing uses ws://127.0.0.1:9944 on the validator host.

Using the terminal in this guide

Open a terminal on your computer and connect to your validator using the SSH login supplied by your hosting provider. In ssh YOUR_USER@YOUR_SERVER, replace both capitalized labels with your actual Linux username and server hostname or IP address. Confirm the server's SSH fingerprint using your provider's console before accepting a first connection. Run node and wallet commands in that SSH session, on the validator. Open Agora and the explorer in your computer's browser.

Copy one command block at a time. Lines ending in \ are one command continued on the next line; copy the entire block. Do not type a leading $ prompt. A sudo prompt asks for your Linux login password; the wallet prompt asks for the wallet password you created. Neither displays characters as you type. If a command fails, read its message and resolve that step before continuing.

Start with the guided node installation, choosing validator-candidate. Wait for its readiness checks to pass before creating session keys or staking. The local node-wallet walkthrough then covers software checks, wallet creation, funding, reviewing a transaction plan, and confirming each finalized result.

What the words mean

State	What has happened
Synced node	The node follows the chain but does not author blocks.
Locked	Native ROKO was reserved 1:1 and the wallet received pwROKO.
Bonded	pwROKO was committed to staking.
Candidate	Session keys are registered and staking.validate is on-chain.
Queued	The staking election selected the candidate for a future session.
Active validator	The account is in session.validators and the node authors/finalizes.

The --validator flag changes the node's local role. It does not skip any on-chain step.

Before you start

You need:

• a dedicated Linux host and the guided validator-candidate installation;
• the local encrypted node wallet, created on the validator host with a verified node binary;
• 50 ROKO to lock and bond, plus liquid ROKO for fees;
• safe local access to the node RPC; and
• a recovery copy of wallet and session-key material that no agent or support person can read.

The live runtime currently reports an on-chain minValidatorBond of zero. That is an unset technical floor, not the recommended amount. ROKO's genesis and enrollment tooling use 50 pwROKO as the current testnet self-bond. Do not advertise zero-bond validation. The chain should be upgraded to encode the intended minimum before this becomes a mainnet economic rule.

1. Install and synchronize the node

Follow Guided node install, choose validator-candidate, and wait for the readiness report. Continue only when:

• genesis is 0x0a2296f8f036f71437e8f6f2028ccbf0dc3dd6b3de9120fc15e43789c794e8bb;
• system_health.isSyncing is false;
• the finalized head advances;
• the peer ID survives a restart; and
• system_nodeRoles still reports Full during bootstrap.

Keep RPC on loopback. Never run a full-node process and validator process against the same database at the same time.

Select the signed tool and node separately

Match the exact node binary, source revision, architecture and live runtime to the signed tooling compatibility metadata. Do not treat historical tests as qualification for a newer node.

Historical September 2026 qualification covered tooling 1.4.1, runtime 286 and a qualified Linux amd64 node build: source 086baf26c0e0db666526b8f649269facd1c37da7 (nightly-086baf26-20260913) or be8920f47d282da73297c17875791c4e3d444625 (v1.1.0). Keep the qualified current node; do not downgrade to make its release number match the tool. A node display such as 3.0.0-dev-086baf26c0e is a build identifier, not the enrollment-tool version. Compare binary digests against the signed release and qualification record.

Tooling 1.4.0 first corrected the guarded RPC probe and portable offline checksum; 1.4.1 adds guarded reuse of an existing tuple. The v1.1.0 and v1.3.0 historical offline sidecars contain absolute build paths. Download the fixed archive and sidecar together, run sha256sum --check --strict in that directory, and still authenticate the pinned signed manifest before installing.

Before restarting an existing installation, complete the existing-install preflight. Preserve the effective service, PHC device mappings/flags, clock/readiness checks, base path and peer/session identity. Generic Chrony defaults do not qualify a custom PHC image. The helper requires its supported policy-variable unit contract; a hardcoded Safe unit needs a reviewed adaptation preserving those settings. Do not rotate keys to refresh an expired package.

2. Set up the staking wallet

Follow the local node-wallet walkthrough on the validator host. Verify the required software and wallet source, create a new encrypted staking wallet with the verified node binary, back it up, and keep its password separately. Fund the public account printed by create; the wallet does not import an existing Talisman or MetaMask account. Do this before generating the short-lived public session package.

The local wallet performs the four native calls after you review the plan and explicitly authorize submission. After finalized candidate registration, return here for validator-mode, election and authorship verification.

MetaMask/Talisman enrollment is unverified or known-failing. Browser connection, balances and custom-network setup do not prove enrollment works. See wallet compatibility for that investigation; use the local node wallet for validator deployment. If the package expires, use the supported refresh procedure without changing its expiry or rotating its keys solely to retry.

Never paste a seed phrase or private key into a terminal, chat, form, or AI agent. It is safe to share the public wallet address and transaction hashes.

3. Obtain testnet ROKO

There are two different funding paths:

1. If the wallet address was included in the Ethereum holder snapshot, open claim.roko.network, check the address, connect the same wallet, and press the claim button. The app switches or adds ROKO Testnet and waits for a receipt.
2. Otherwise use faucet.roko.network for basic transaction funds. The standard faucet amount is not a validator bond. If the balance remains below 50 ROKO plus fees, use the support route in Public services and provide only the public address.

Check the address in the explorer before continuing.

4. Generate the public enrollment package

Install and verify the enrollment helper

Keep the synchronized node non-authoring. Download the current installer with the signed SHA256SUMS manifest and the published release signing key. Require the key fingerprint to be exactly 62297562B1C7053088F405DB0117DAAA677A5BF2, verify the manifest signature, then verify the installer against the signed manifest before running it.

BASE=https://downloads.roko.network/validator-tools/current
curl -fLO "$BASE/install-roko-validator-enroll.sh"
curl -fLO "$BASE/SHA256SUMS"
curl -fLO "$BASE/SHA256SUMS.asc"
curl -fLO "$BASE/roko-release-signing-key.asc"
gpg --import roko-release-signing-key.asc
gpg --fingerprint 62297562B1C7053088F405DB0117DAAA677A5BF2
gpg --verify SHA256SUMS.asc SHA256SUMS
sha256sum --check --strict --ignore-missing SHA256SUMS
bash ./install-roko-validator-enroll.sh
INSTALL_PATH="$(readlink -f "$(command -v roko-validator-enroll)")"
printf '%s\
' "$INSTALL_PATH"
"$INSTALL_PATH" --version

Do not run the installer if the fingerprint differs or either verification command fails. The printed path and version confirm the shell resolves the installed helper before you use it.

Use the guarded session-key workflow from the signed tool release. The normal Safe RPC policy intentionally rejects direct key generation. The supported helper briefly opens a local key-management window, restores Safe, and checks restoration. Read its isolation requirements before running it; do not expose or forward port 9944.

For --public-address, replace the example DNS name with your node's public DNS name and the peer-ID placeholder with this node's public peer ID from the readiness report. If using IPv4 rather than DNS, use the /ip4/ADDRESS/tcp/30333/p2p/PEER_ID form. These public node identifiers are different from your staking account. Keep the generated roko-validator-enrollment.json where the enrollment command can read it, and require the helper's Safe restoration check to pass. If you already generated keys, use the helper's --reuse-session-keys option with the unchanged public tuple and a new output filename. This verifies custody and refreshes the package without rotation, then restores exact Safe policy. A custody failure never triggers replacement keys.

The CLI requires the exact configured-testnet genesis, advancing finality, a fully synchronized node, peers, a synchronized host clock, non-authoring mode, loopback-only author RPC, a reachable advertised P2P address, and proof that the generated public session tuple exists in this node's local keystore. Its default package expires after 30 minutes.

The JSON is public but integrity-sensitive. It contains the public peer ID, advertised multiaddresses, binary/runtime/metadata digests, readiness facts, and seven public session identifiers. It must not contain a mnemonic, secret URI, private key, keystore, node-key bytes, wallet material, token, or OpenBao credential.

ROKO's current metadata requires the seven-key order GRANDPA, BABE, ImOnline, authority discovery, Mixnet, BEEFY, and Temporal, plus explicit legacy-empty proof bytes 0x. The CLI and Agora fail closed if this contract changes.

5. Review and enroll with the local node wallet

Follow the local-wallet walkthrough from the wallet checkout on the validator host. Keep the encrypted staking wallet separate from the public roko-validator-enrollment.json; never upload the wallet to Agora or send it to support.

1. Run bin/roko-validator-wallet plan with the encrypted --wallet path, the public --account printed at creation, and the fresh public --enrollment package path, exactly as documented in the walkthrough.
2. Review the account, chain ID 52370, genesis, runtime, stake amount, encoded next call and fees. The default walkthrough uses 50 ROKO plus fees; check the live minimum and use the same chosen stake in plan and execution.
3. Only after reviewing the plan, explicitly submit with bin/roko-validator-wallet enroll --execute and the same paths and account. Enter the wallet password only at the hidden local prompt.
4. Wait for each finalized receipt and save the public transaction/block hashes. The command rechecks finalized state before the next native lock, bond, session-key registration or validator-intent call.

No ROKO operator, incumbent validator, Tally form, or Sudo call approves normal candidacy. Finalized candidate registration does not establish election or finalized authorship. If interrupted, inspect pending activity and run plan before resuming; do not create a second wallet or blindly resubmit.

After the calls finalize, follow the local-wallet walkthrough's pre-activation handoff to verify finalized bond, intent, matching session keys, local custody and Safe RPC readiness. Use reviewed release qualification and require safeToEnableValidatorMode: true. A not-ready result does not permit skipping custody verification. These checks do not prove election or authorship.

6. Switch to the validator profile

After all required enrollment calls finalize:

1. record the working full-node service and rollback command;
2. stop it and prove the process/database lock is gone;
3. load only this node's session keystore;
4. start the release-matched service with --validator, loopback-only safe RPC, and the reviewed reserved-peer policy; and
5. keep the host clock synchronized and monitored.

Understand the two time-source checks

You do not need GPS/PPS hardware for testnet bootstrap. The guided Chrony profile uses public Internet NTP servers. chronyc sources -v should show one selected source (^*) and at least one other usable combined source (^+).

That is separate from temporal_getConsensusTime.peerCount. The temporal RPC counts mapped ROKO /roko/timesync/1 peers, not NTP servers. If it says zero:

1. verify chronyc -c tracking succeeds in the node's own environment;
2. when using an isolated service/container, verify chronyc exists there and chronyc -h /run/chrony/chronyd.sock -c tracking can read the explicitly mounted, read-only Chrony socket;
3. confirm the service flag names the same socket path; and
4. separately confirm connections to at least two current ROKO authorities whose time-protocol announcements map to their on-chain keys.

Do not install hardware merely to make peerCount increase. Hardware improves clock quality tiers; it does not replace ROKO temporal peer connectivity.

The current public bootnode is non-authoring. A node can therefore be fully synced through it while seeing zero mapped temporal authorities. Before authoring, the candidate must have a publicly reachable P2P multiaddress (or an approved outbound-dial arrangement) and direct ROKO P2P sessions with at least two active authorities. Never publish RPC, SSH, or Prometheus to solve this; only the libp2p port and peer ID belong in the public multiaddress.

If those authority multiaddresses are not present in the published network manifest, this is a network-topology blocker owned by ROKO operations—not a mistake the beginner can fix by changing Chrony. Operations must either publish at least two safe validator/sentry-authority P2P endpoints or configure two active authorities to persistently dial the candidate's advertised address.

7. Verify selection and activation

Registration does not guarantee an active slot. A candidate must win the runtime staking election and wait for the relevant era/session boundary.

Call the node active only when all of these are true:

• the account has validate intent in staking storage;
• its expected keys appear in session.nextKeys;
• it becomes queued and then appears in session.validators;
• BABE, GRANDPA, and Temporal authority views include it;
• finalized blocks continue to advance; and
• the node authors a finalized block with non-null time quality.

Use Agora validators to inspect the named finalized source, canonical account, candidate/waiting/queued/active state, bonds, session readiness, preferences, nominators, recent finalized authorship, and temporal-quality availability. The explorer is a helpful second display, but active on-chain session membership is the authority.

8. Reconcile rewards, payout state, and costs

Open the validator's Agora detail page to inspect finalized credited payouts, extrinsic-wide fees, slashes, and exact era claim state. The same evidence is downloadable as canonical JSON from /api/v1/validators/{account}/economics and accessible CSV from /api/v1/validators/{account}/economics.csv.

If an era has an unclaimed runtime page, Agora constructs only that exact permissionless payout call. The submitting wallet pays the network fee and the runtime sends rewards only to the configured payees. After finalization, Agora refreshes the runtime state and disables repeat submission when no unclaimed page remains.

A credited payout is not a profitability claim. Public chain records do not contain private infrastructure, timing, labor, capital, tax, downtime, or risk costs. Export the finalized evidence and reconcile every attributable cost and loss before describing historical net income. Never present testnet results as an APY, forecast, guarantee, or mainnet economics.

9. Rotate, maintain, or exit

For software maintenance or a host reboot, follow the September 10 maintenance checks and upgrade guide. Historical AUTHORED readiness does not prove current finality; require a fresh finalized authorship proof after restart when the node is elected. Keep the remaining elected authority weight online.

Agora supports preference updates, fresh-package key rotation, chill, unbond, unlocking-era review, and mature withdrawal. During rotation, keep old keys until the replacement is active and has authored a finalized block. During exit, keep an active node online after staking.chill until finalized session state proves it is no longer active. Then unbond, wait the runtime bonding duration, and use staking.withdrawUnbonded when the chunks mature.

Neither Agora nor the CLI automatically purges keys. Stop or delete material only after the corresponding safe finalized state is independently verified.

What an assisting agent should do

An agent may inspect public balances, transaction receipts, node health, and public session keys. It should explain one action at a time and name the state reached after each action. It must never ask for or handle a seed phrase, private key, keystore archive, wallet file, or reusable signature, and it must not report “validator active” from a successful bond or --validator alone.

For hardened topology, timing, maintenance, and recovery guidance, read Validator key custody.