Become a ROKO testnet validator

This is the beginner route from an ordinary wallet and synchronized node to a validator candidate. 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.

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;
• a compatible Substrate-signing browser extension exposing the intended Ethereum-format 0x... account that will own the stake;
• 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.

2. Set up the staking wallet

Complete wallet signing compatibility and setup before generating the short-lived enrollment package. Ordinary MetaMask/EVM mode cannot sign Agora staking or session-key calls, even with the right balance. Talisman is the documented setup path with reported enrollment success: verify it exposes your intended Ethereum-format account, add ROKO as a custom Substrate network using wss://rpc.roko.network, and verify the full genesis and current metadata in Agora. A watch-only or newly created account is not a substitute for the intended signer.

If the package expires during setup, use the supported refresh/reissue procedure without editing the expiry or tuple; do not assume new keys are needed.

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

Keep the synchronized node non-authoring. Install the release-matched roko-validator-enroll command from roko-edge-tools, then run:

roko-validator-enroll \
  --rpc http://127.0.0.1:9944 \
  --binary /usr/local/bin/roko-node \
  --public-address /dns4/validator.example/tcp/30333/p2p/YOUR_PEER_ID \
  --confirm-new-keys \
  --output roko-validator-enrollment.json

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. Import in Agora, lock, bond, and declare intent

Open Agora validator self-join:

1. import roko-validator-enrollment.json and require Package verified;
2. connect the staking wallet and confirm chain ID 52370, the canonical account, exact genesis, runtime, fees, and consequences;
3. review and finalize pwRoko.lock(50 ROKO);
4. review and finalize staking.bond(50 ROKO, Staked);
5. review and finalize session.setKeys(public_tuple, 0x); and
6. select commission and nomination preference, then review and finalize staking.validate(...).

Each is a separate wallet action. The encoded tuple comes only from the verified package and is not editable. Agora records the public digest as consumed after session registration; generate a fresh package for rotation. No ROKO operator, incumbent validator, Tally form, or Sudo call approves normal candidacy.

If the connected account has zero balance and the finite configured-testnet faucet is available, Agora can grant exactly 1,000,000 ROKO after a wallet possession challenge. The signature is not a vote or transaction. Do not rely on the faucet for mainnet or as a statement of validator economics.

After the calls finalize, verify the node/wallet handoff locally:

roko-validator-enroll \
  --rpc http://127.0.0.1:9944 \
  --check-account 0xYOUR_STAKING_ACCOUNT \
  --expected-session-keys 0xPUBLIC_ENCODED_KEYS

Exit status 0 proves finalized bond, intent, matching next-session keys, and local custody. It does not prove election, active membership, or authorship.

6. Switch to the validator profile

After the two 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.