The hub has four user tiers, ordered by privilege. The top two are AncientHoldings staff; the bottom two are node operators (customers).
Ancient Admin
AncientHoldings staff. Full access + hub-policy authority.
- add / remove any node
- override per-node Ouronet accounts
- flip scoring shadow / live, schedule / clear flip date
- rotate the secrets-vault master key
- promote operators to Baron or Modern Admin
- open / close public self-signup
- manage the hub’s own on-chain operational keypair
Modern Admin
Trusted staff-adjacent collaborators. Hub-wide operational pages, own nodes only for drill-in.
- add / monitor own nodes
- take backups of own nodes
- hub-wide Nodes registry (read-only on foreign rows)
- Admins & Clients roster; revoke Modern
- Seeds + Stoicism leaderboard
Baron
Elite operator tier. Adds a hub-issued @ancientholdings.eu mailbox + Ouronet-scoped IPFS publishing on top of Operator.
- everything Operator can do
- hub-issued @ancientholdings.eu mailbox (activated)
- IPFS publishing for StoaChain ecosystem data
- priority seed access for new nodes
- listed on the public validator registry (once live)
Operator
Baseline tier. Self-service, owns their own nodes, no hub-wide operational pages.
- add / monitor own nodes
- take backups of own nodes
- fleet-wide Nodes registry (read-only on foreign rows)
- set profile Ouronet account, earn Stoicism
UI honesty
Every page labels itself with the caller’s role tag in the top-right badge. Links the caller can’t use are rendered grey rather than hidden — the hub is honest about what exists and what’s restricted.
How you become each tier
- Operator — public self-signup at /signup (when Ancient Admin has opened it). Your chosen email becomes the login; if it ends in
@ancientholdings.eu, the hub reserves the mailbox name for you (inactive) for future Baron promotion. - Baron — automatic via
ouronet-corein v0.8.x once qualifying criteria are met on chain; manual override available via an Ancient Admin on/admin/admins. See /admin/baron-upgrade. - Modern Admin — granted by an Ancient Admin via
/admin/admins. Revocable. - Ancient Admin — env-configured on the server (
ANCIENT_ADMIN_EMAILS). Not grantable via UI; limited to AncientHoldings staff.
Code-side note: the bottom tier is named client in the database and AdminRole union; externally every page uses the product name Operator. Baron is an overlay on top of operator (stored in the barons table, migration 031) — revoking Baron falls back to Operator without stranding any nodes.
Audit log visibility
As of v0.7.9b every tier can open /hub/audit-log, but what you see is scoped to your tier:
- Ancient / Modern Admin— every row across the hub. Filters include an actor-email substring search so they can zoom into a specific user’s trail.
- Baron / Operator— rows where either (a) you’re the actor, or (b) the event targets one of your owned nodes. System events (worker actions with no node attached) are hidden. Any filter that would broaden scope beyond this (e.g. querying a node you don’t own) is silently narrowed, not errored.
Every row carries a severity badge (info / warning / critical, with critical pulsing red), an actor-role chip, a source chip (api / worker / ui / cronoton / system), a node link when applicable, and a collapsible detail payload. Filter strip covers date range (24h / 7d / 30d / all-time), namespace + action kind, severity, result, and source. Changing any filter resets pagination.
Honest result semantics for async actions: any action that enqueues a background job (install netdata, run apt-upgrade, take a backup, obtain a cert, …) writes an audit row with result=queued at enqueue time, then a paired follow-up row with result=success or result=failurewhen the worker actually finishes the job. The UI folds the pair into a single grouped entry: the badge reflects the final outcome, with an inline “queued at X, completed at Y” line showing the latency. A lone queued row with no completion yet gets a pending chip until the worker catches up. This replaces the earlier (v0.7.9b) behaviour where every enqueue wrote result=success regardless of how the job ended, which was misleading for anything slow or fallible.
Export with Ed25519 hub signature, retention-driven archival, and the public transparency pulse ship in Phase C / D / G of the v0.7.9 audit rollout — see §12 Roadmap.