Alert on authority health
Service down, peer loss, finality lag, clock loss, missing authoring, disk pressure, session-key mismatch, and unexpected RPC exposure need actionable alerts.
Permissionless candidacy · competitive election
From running a node to running a validator.
This path ends at measurable operation: a qualified node, finalized staking intent, election, active-session membership, finalized authorship, credited rewards, and an honest cost ledger.
One authoritative test per state
Know exactly where you are.
A local flag or successful transaction is never evidence for a later state. Use one finalized chain head and the local node when custody must also be proved.
| State | Objective evidence | What it does not prove | Next action |
|---|---|---|---|
| Synchronized peer | Correct genesis, peers, isSyncing=false, advancing finalized head, stable peer ID after restart. | Keys, stake, candidacy, or election. | Generate the public enrollment package. |
| Candidate | Bonded ledger, matching session.nextKeys, and staking.validators intent at a finalized head. | An active validator slot. | Keep the node online and watch the election. |
| Queued | Account appears in the finalized queued session keys. | Current-session authority or authorship. | Wait for the stated session boundary. |
| Active | Account appears in finalized session.validators and authority views. | Healthy operation or reward credit. | Prove authorship, finality, and time quality. |
| Rewarded | Finalized reward event or credited staking balance attributable to the validator and era. | Positive net income. | Reconcile the reward receipt against costs. |
| Profitable | Realized revenue minus infrastructure, timing, labor, capital, taxes, fees, downtime, and losses is positive for the chosen period. | Future returns. | Recalculate continuously; no return is guaranteed. |
Which address goes where
Current testnet: chain ID 52370. Fund your own staking wallet's public 0x account. Use that same account for the node wallet's --account option.
pwROKO token and EVM lock/unlock interface: 0x0000000000000000000000000000000000000500 (18 decimals).
EVM staking interface: 0x0000000000000000000000000000000000000700.
Do not send a plain transfer to these precompiles. The local node wallet uses native pwRoko.lock, staking.bond, session.setKeys, and staking.validate; it does not ask for a contract address. The EVM staking interface alone cannot register session keys or declare validator intent.
Full address reference and network check · Node-wallet walkthrough: terminal, funding, plan, signing, and recovery
Node → candidate → authority → measured operator
The complete public journey.
Normal candidacy needs no incumbent-validator, operator, Tally, or Sudo approval.
-
01
Decide whether the economics can work
Price the host, storage growth, bandwidth, timing hardware or licence, monitoring, backup, incident response, labor, capital, taxes, and a loss reserve. Treat testnet tokens and unissued program terms as zero revenue.
Review finalized reward records -
02
Install as a non-authoring validator candidate
Use the guided installer. Match the configured-testnet genesis, pin a verified release, keep author and unsafe RPC on loopback, expose only reviewed P2P, synchronize completely, then prove finality and identity persistence after restart.
Open guided install -
03
Create, back up, and fund the local staking wallet
Follow the local-wallet guide to create a new account with the verified node binary, back up the encrypted wallet and keep its password separately, then fund the printed public account. It does not import an existing browser wallet. Keep the staking wallet separate from node session and P2P identities; the local node wallet stores it as an encrypted file. Encrypt node and session material, keep a tested recovery path, and never paste a seed, secret URI, keystore, node-key bytes, token, licence, or reusable signature into a browser, command line, support form, chat, or agent.
Create and fund the local wallet · Review custody options -
04
Create a short-lived public enrollment package locally
Match your exact node binary, source revision, architecture and runtime to the signed tooling compatibility metadata before generating keys. Historical runtime-286 qualifications do not qualify a newer release; do not downgrade merely to match version labels. First follow the signed install-and-verify instructions and verify the release installer against its signed checksum manifest. Then run
Copy the exact commandroko-validator-enrollagainst127.0.0.1:9944. It verifies genesis, runtime, clock, peers, finality, P2P reachability, non-authoring mode, and local custody of all seven public session identifiers. Before restarting a custom installation, preserve its PHC devices, flags and readiness checks using the existing-install preflight. To refresh an expired package, use guarded--reuse-session-keyswith the unchanged public tuple; do not rotate merely to refresh it. Inspect the public JSON before giving its path to the local wallet. -
05
Lock, bond, register, and declare intent
Use the local wallet’s read-only
Use local node walletplancommand before explicitly submitting withenroll --execute. Keep the encrypted wallet on the validator host; only the public session package belongs in--enrollment. Confirm chain ID52370, account, genesis, runtime, fees, and effects. Finalize the lock, bond,session.setKeys, andstaking.validatecalls separately. The current testnet walkthrough uses 50 ROKO plus fees; it is not a mainnet minimum or a profitability claim. -
06
Switch profiles without running two processes
Record rollback, stop the full-node service, prove the process and database lock are gone, load only this node's session keystore, and start the release-matched validator service. Preserve the base path, peer identity, session keys, time configuration, and protected RPC boundary.
Follow the activation gate -
07
Wait for election and verify actual operation
Selection is competitive and not guaranteed. Watch candidate, queued, and active states at one finalized head. Call the node operational only after active membership, finalized authorship, advancing finality, healthy peers, and non-null temporal evidence are all visible.
Inspect validators without a wallet -
08
Reconcile credited revenue, then calculate net income
Open the validator's Agora detail page for finalized payout events, fees, slashes, era claim state, and downloadable JSON or CSV evidence. Use credited rewards—not an advertised APY, block count, pending estimate, or token grant. Record the era, transaction or event, amount, valuation method, every cost, and any slash or downtime loss. Only this ledger can support a profitability claim.
Open finalized validator economics
Finalized rewards
Review credited rewards and public records.
Use finalized evidence to track your validator’s rewards, fees, and era claim state.
Stay eligible and available
Profitability is an operations discipline.
Plan host maintenance around finality
Before stopping a validator, verify that the remaining active authority weight meets the current finality threshold. Candidates do not provide active voting weight. Record the finalized head and independent reference, preserve chain data and identities, and stop the service gracefully before host shutdown.
After startup, wait for storage and clock readiness, peers, and full synchronization. Compare advancing finalized heights and matching hashes with an independent node, then require fresh finalized authorship from an active validator. A historical AUTHORED or readyToAuthor result is insufficient. Successful service restart does not prove cold-boot recovery.
Reconfirm active state
Check finalized active membership, authority views, recent authorship, and temporal evidence. A running process can silently cease to be an effective validator.
Reconcile economics
Record credited rewards, commission, fees, slash/offence events, token valuation basis, and costs. Retain exportable receipts for accounting and review.
Upgrade one authority at a time
Verify signatures and hashes, preserve identity and keys, record rollback, and require active membership, authorship, finality, and timing acceptance before the next rollout.
Overlap keys safely
Generate a fresh package. Keep old keys until replacement keys are active and have authored a finalized block; then retire the old material deliberately.
Exercise recovery
Restore encrypted backups on an isolated host, verify peer and public session identities, test alert routing and rollback, and update cost and capacity assumptions.
Symptoms → evidence → safe action
Recover the state you actually have.
| Symptom | Check first | Safe response |
|---|---|---|
| Package rejected | Expiry, exact genesis/runtime/metadata digests, P2P reachability, seven-key order, local keystore proof. | Fix the node evidence and generate a fresh package. Never edit key fields by hand. |
| Candidate, never queued | Finalized bond, intent, keys, election capacity, stake exposure, nomination preference. | Remain online, review competitiveness, and change only public staking preferences or stake. Do not claim activation. |
| Active, no authorship | Local keystore, key tuple, node profile, peers, clock, BABE/GRANDPA/Temporal views, logs. | Protect finality, use the documented rollback/recovery path, and avoid destructive key regeneration. |
| Finality or time degraded | Independent clock sources, root distance, direct authority peers, disk/CPU/network saturation. | Restore stable service; chill before extended maintenance when the finalized state and timing permit. |
| Exit requested | Finalized chill, removal from active session, bonding duration, unlocking chunks. | Stay online until no longer active, then unbond and withdraw only after the chain reports maturity. |
| Revenue below cost | Credited—not pending—rewards, election share, commission, uptime, costs, losses, valuation method. | Update the ledger and operational plan. Chill and exit safely if the risk-adjusted case no longer works. |
The next objective action
Start with a qualified peer—or inspect the current set.
Use the installer before touching stake. Use the local wallet for transactions, and Agora for finalized public evidence. Use the technical runbook for exact commands and custody boundaries.