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 browser EVM wallet whose public `0x...` address 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

Follow Wallets, holder claim, and faucet. The wallet can add ROKO automatically when either public app asks it to switch networks. Verify chain ID `52370` (`0xcc92`) before signing.

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. Lock 50 ROKO; verify bonding separately

Open stake.roko.network:

1. Select Connect wallet and approve ROKO Testnet. 2. In Lock ROKO, enter `50` and confirm Lock ROKO in the wallet. 3. Wait until the receipt says confirmed and the pwROKO balance shows 50.

Stop there. The live mainnet-configured runtime currently exposes pwROKO at `0x0000…0500` but does not register the staking precompile at `0x0000…0700`. An EVM transaction to `0x…0700` can have receipt status `success` because it called an empty address while creating no staking bond. The public portal therefore does not offer Bond.

Use the release-matched native enrollment client only after it verifies the on-chain runtime supports the requested call. After any bond attempt, query native staking storage. A transaction receipt or explorer input is not proof; the account must have a staking ledger with the expected active 50-pwROKO amount.

Locking is reversible through an on-chain cooldown. A real bond has separate staking unbond/withdraw rules. Keep extra native ROKO liquid for fees.

5. Create and register session keys

ROKO requires seven session-key types: GRANDPA, BABE, ImOnline, authority discovery, Mixnet, BEEFY, and Temporal. Generate them inside the validator's local keystore. If `author_rotateKeys` is used, expose unsafe author RPC only on loopback for that operation, then return to safe RPC immediately.

The public staking page currently performs wallet lock and bond only. It does not submit `session.setKeys` or `staking.validate`. Use the versioned enrollment client shipped with the matching ROKO node release, or a reviewed Substrate wallet that supports the staking account. Do not use the obsolete `scripts/register-validator.mjs`: it embeds a development-era sudo funding flow, generates and prints a mnemonic, and is not the public v2 workflow.

Before signing, the client must show:

• the expected genesis hash;
• the same staking `0x...` account that owns the 50-pwROKO bond;
• all seven public session keys from this node; and
• the calls `session.setKeys(keys, 0x)` followed by

`staking.validate({ commission, blocked: false })`.

This missing browser enrollment step is a product limitation, not a governance approval requirement. Until the versioned public enrollment client is published, stop here and use the support route for the exact release-matched client. Never send support the private keys.

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. The configured validator count is currently four, so another candidate must win a 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.

The explorer is a helpful display, but active on-chain session membership is the authority.

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.