11. Cluster roles — Miner · Ouronet Validator · Hub · Docs

The StoaChain cluster has three distinct roles. They’re related but play different parts, and the confusion between them costs prospective operators real money (wrong hardware, wrong expectations). This chapter draws the line once.

In one sentence each

Hub: the user-facing control plane; one exists today at ancientholdings.eu/hub; will be served across the validator fleet as decentralised website infrastructure.
Ouronet Validator: a barebone machine that stores + serves Ouronet infrastructure (UI, Explorer, Hub, IPFS assets) across the network, AND provides a public RPC pool to chain consumers.
Miner: a plain chainweb node running mining software; earns STOA from block rewards. Not part of Ouronet infrastructure; VPS-friendly.

1. Hub — the user-facing control plane

Primary role: the UI through which users control their nodes. Signup / login, node enrolment, fleet dashboard, per-node operations (benchmark / backup / install / restart / cert rotation), Stoicism surface, Baron / Operator self-service tools — everything under /hub/*. When a customer buys hardware to run a StoaChain node, the Hub is what they open in a browser.

Secondary role: initiator of automated on-chain transactions. The Hub holds a Codex (one Codex per Hub; see /hub/codex for the Ancient-admin surface) containing seed words for every operation the Hub executes on users’ behalf:

Daily 06:00 UTC mint — takes floor(Current)from each operator’s accumulated Stoicism and pushes an on-chain mint TX per-chain into the Acquisition Pool.
Future Cronotons — recurring user-defined on-chain actions (Baron-tier feature landing in v1.0.x). Each user’s Cronoton keys sit in the Hub’s Codex in a Baron-write-only lane.
Hub’s own operational keypair — for fee-bearing reads + writes to the chain (e.g. Ouronet account lookups during onboarding).

How many Hubs exist today? One. At ancientholdings.eu. Running on a single VPS owned by the AncientHoldings GmbH operator, same box that serves this documentation.

Where Hub is going. The medium-term direction is for the Hub itself to be served across the validator fleet as decentralised website infrastructure. Users always reach aHub; if the origin server drops, the validators serve the same UI from cached state. That’s why validators aren’t just accounting peers — they need to be web-serving, storage-carrying boxes. More on that in §2.

What the Hub is NOT: not a blockchain node itself (it talks to chainweb over HTTP), not a wallet (it manages no keys for users — users manage Ouronet keys in OuronetUI), not a validator. See §0 Legal scope for the authoritative framing.

2. Ouronet Validator — the decentralised infrastructure backbone

The Validator is the role most people misunderstand first. The name suggests "accounting peer that verifies transactions" — which is wrong. StoaChain doesn’t have traditional delegated validators in the Ethereum / Cosmos sense; consensus is pure PoW at the chainweb layer. The StoaChain Validator name is about a different function:

Primary role: decentralised backbone for ALL Ouronet infrastructure. Each validator hosts (and serves from its barebone storage + bandwidth):

The Ouronet UI — the wallet and interaction app at wallet.ouronetwork.io and eventually its mirrors.
The Ouronet Explorer — on-chain data browsing.
The Hub website itself— i.e. the thing you’re reading right now — distributed across physically diverse validators, so no single origin server can take it down.
Package distribution for the StoaChain software stack (chainweb-node releases, install scripts, etc.).
IPFS-stored assets referenced by any of the above — images, static data, backups of community content.

Think of a validator as a regional edge server for all of Ouronet. This is why validators need real barebone hardware — actual disk, predictable IOPS, customisable storage. They’re storing real content, not just a chainweb ledger.

Secondary role: public RPC endpoint.Each validator also runs a StoaChain node. Collectively, the validator fleet becomes a large-scale blockchain-query pool any dApp or user can consume. The Hub is the first consumer of that pool (daily mint TX, user Ouronet account lookups), but anyone can hit the same endpoints — it’s public infrastructure.

Tertiary / at-scale role: TX execution offload. When Cronoton traffic crosses ~10 000 users (speculation: late 2027+), the Hub will offload TX EXECUTION to validators via @stoachain/ouronet-core. Codex + seed material stays exclusively on the Hub; validators are execution horsepower for already-signed TX, never trustees of secrets. See §11 Scaling for the tier-gated rollout.

What validators are NOT

Not accounting / state holders. The chain state lives in chainweb; validators hold amirrorof it for RPC purposes but don’t mutate it.
Not signing authorities. Validators never sign anything on a user’s behalf. All signing happens in user-controlled keysets (OuronetUI) or in the Hub’s Codex for Hub-initiated TX.
Not codex holders. Validators never receive seed words, never receive long-term secrets. The only Hub-side secrets they see are ephemeral execution tokens for signed-TX submission.
No zero-knowledge involved. The “Validator” name in StoaChain context does not imply ZK proofs / SNARKs / whatever. Storage + execution + RPC muscle, period.

Why barebone, not VPS (for validators)

Validators are disk-heavy by role: they serve Ouronet UI assets, hold IPFS copies, keep a full chainweb data directory, and need predictable IOPS under concurrent load. A low-spec VPS with 25-100 GB of storage runs out mid-year. A high-spec VPS works but costs more than a good home barebone at equivalent spec, with no real upside.

The §16.6 requirements still apply — validators need public IPv4 reachability. The §18 tunnel pattern is an escape hatch for CGNAT’d operators, but it adds one more failure domain (the VPS) and a small latency tax. A validator on a proper public IP, no tunnel, is the happy path.

The future Validator registration page will apply the gates in lib/validator-eligibility.ts: barebone accepted directly; VPS accepted only above 2× CPU-baseline + 500 GB committed; unknown rejected. See source for the policy matrix.

3. Miner — plain chainweb + mining software

A Miner is a plain chainweb-node running chainweb-mining-client, competing for STOA block rewards via proof-of-work. Not part of Ouronet infrastructure; purely chain-level work.

Earns two streams:

STOA block rewards— PoW payouts from the chainweb protocol itself (issued on successful blocks). Paid directly to the miner’s chainweb mining address, not routed through the Hub.
Stoicism— uptime / chain-tracking points, same as any other managed node. Hub-aware miners (enrolled in the Hub) earn this; standalone miners don’t.

Hardware requirements are less strict than validators because miners don’t serve content — they just compute and broadcast. A decent VPS can mine profitably against the current difficulty. See §16 System requirements for the baseline.

Can one physical box be multiple roles?

Yes, in specific combinations:

Miner + Validator on the same barebone box: fine. One chainweb-node process can do both — mining runs as a sidecar, the node serves as a validator endpoint too. Most natural setup for an operator who wants both revenue streams.
Hub + anything: no. The Hub needs its own dedicated host for operational reasons (HA, maintenance windows, Codex isolation). Running the Hub alongside a miner on the same box mixes failure domains in a way nobody wants.
Multiple miners on one box: possible via the §18 multi-node VPS tunnel pattern — but watch the hardware budget. Each miner process eats real CPU + RAM + disk.