Governance and Agora

ROKO governance is available on the configured testnet at two deliberate entry points:

• governance.roko.network is the

wallet-free, read-only evidence view. Use it when you only want to inspect.

• agora.roko.network is the participant

experience. It can connect an injected browser wallet for supported actions, but it never receives a recovery phrase or private key.

Both sites identify the network as chain ID `52370` (`0xcc92`) with genesis `0x0a2296f8f036f71437e8f6f2028ccbf0dc3dd6b3de9120fc15e43789c794e8bb`. Runtime spec 286 activated at finalized block `839462` on 2026-08-28.

The fastest safe path

1. Open the read-only proposal list without a wallet. 2. Select a proposal and review its lifecycle, exact call or runtime payload, disclosure metadata, source-code reference, signed conversation ledger, provenance, voters, vote direction, and committed stake. Missing or unverified evidence is shown as unavailable rather than guessed. 3. Resolve a public account through its verified `.roko` name when one exists. The canonical address remains visible and authoritative. 4. Check public governance status. Require the expected genesis, runtime spec 286 or later, matching finalized and indexed heights, `fresh: true`, and `executionAuthorized: false`. 5. Only when you intend to act, open Agora, connect your own wallet, confirm the network and account, review the exact call and fees, and sign that one action in the wallet.

An empty proposal list is a valid chain state, not a loading failure. The configured-testnet projection began from a verified empty governance boundary and follows finalized state from there.

What is public now

• finalized-first proposal, referendum, participant, validator, vote, stake,

disclosure, deliberation, and provenance views;

• stable detail URLs that can be bookmarked or shared;
• machine-readable, bounded governance and validator APIs;
• wallet-free inspection through `governance.roko.network`;
• browser-wallet participation surfaces in Agora, including staking,

nomination, and permissionless validator candidacy; and

• explicit unavailable, stale, gap, and integrity-failure states.

The public support API is deliberately read-only and has no signer, transaction constructor, Sudo authority, unsafe RPC, or chain-mutation credential. `executionAuthorized: false` describes that service boundary; it does not make a user-signed wallet transaction read-only.

Current availability boundary

Public publication-support routes for proposal disclosure, conversation/IPFS, and the finite participant faucet remain unavailable until `roko/roko_network` issue #261 is delivered. The UI must fail closed when one of those support services is unavailable. Do not interpret a local-UAT example or rendered form as proof that its corresponding public service is active.

Validator self-enrollment uses direct, separately reviewed wallet calls and a short-lived public enrollment package generated on the operator's node. Follow Prepare a validator for the exact journey and evidence required at each state.

Accessibility, reliability, and recovery

• You can inspect public governance without a wallet, account, or extension.
• Use the page headings, landmarks, skip link, and ordinary links with a

keyboard or screen reader. Status, errors, and unavailable evidence must be conveyed in text and never by color alone.

• Canonical addresses, transaction hashes, block numbers, proposal identifiers,

content digests, and source links remain selectable and copyable.

• Refresh from the canonical URL after a transient failure. A proposal detail

URL should remain stable; return to the proposal list if an identifier does not exist.

• If the status API reports a gap, stale projection, wrong genesis/runtime, or

unequal indexed/finalized boundary, pause participation and use the read-only explorer or RPC to verify finalized chain state.

• Never enter a seed phrase, private key, keystore, reusable signature, or

OpenBao credential into a site, support request, chat, or AI agent.

Human review before a consequential action

Deterministic checks cover network identity, payload and digest equality, metadata shape, signatures, balances, lifecycle state, finalized receipts, projection freshness, and accessibility automation. A person should still decide whether the proposal's intent, tradeoffs, risks, real-world references, source changes, social consequences, and requested authority are acceptable. The wallet confirmation is the final authorization for that exact transaction.