Documentation / Roadmap

Documentation · Pillar

Roadmap

vH.1.19phase: Chronos — The H.1.x benchmark/scoring rehaul arc

Living document. Every feature the hub is committed to build lives here, pinned to a numbered phase (v0.7.9 through v.G.13.0). Items move down the status lane as they ship — SHIPPED → IN FLIGHT → PLANNED → FUTURE → RESEARCH. Edit this page whenever a feature is designed, in-flight, or shipped.

Mission context

The hub is infrastructure support for StoaChain and its ecosystem. Every feature on this roadmap strengthens one of four pillars: resilience (more validators, IPFS replication, code mirrors so no single piece of infrastructure can take the network down), accessibility (one-stop hub for what operators + users need, no blockchain-expert prerequisite), education (Pact knowledge + reference tooling spread through the ecosystem), and rewards (Stoicism for operators who run nodes in ways that benefit the network — not for uptime alone). Subsequent waves add the customer portal + monetisation on top of this base, once the user base is grown enough to sustain it.

Status legend

ShippedIn flightPlannedFutureResearch

Phase codenames

Every phase carries a Greek / mythological codename — a memorable handle that the dev team and operators use day-to-day instead of reciting version numbers ("Hermes lands in v1.0", "Athena is in flight"). The names follow the project's Stoic / Ancient theme; each one is chosen to evoke the phase's purpose:

Apotheosisv4.0.xStoaChain protocol absorption (long horizon)
Agorav3.0.xWave 3 — Customer portal + monetisation
Aegisv2.2.xCertificate-Authority service (long horizon)
Nikev2.1.xSpeed-test infrastructure
Phalanxv2.0.xWave 2 — Ouronet Validator Network
Hephaestusv1.4.xModular runtime
Atlasv1.3.xIPFS everywhere — verifiable ledger
Mnemosynev1.2.xAutonomic backups + hub-as-package-repository
Zeusv1.1.xBaron power tools
Hermesv1.0.xHermes Engine — paid RPC fleet service
Icarusv.G.3.0Icarus
Athenav0.8.xOuronet Core integration
Genesis Patchesv.G.1.xGenesis post-launch fixes
Genesisv.G.1.0Genesis — public launch
CodenameVersionPhaseStateItems
Apotheosisv4.0.x🌐 StoaChain protocol absorption (long horizon)FUTURE2
Agorav3.0.x🏛 Wave 3 — Customer portal + monetisationFUTURE5
Aegisv2.2.x🔐 Certificate-Authority service (long horizon)FUTURE3
Nikev2.1.x📶 Speed-test infrastructureFUTURE3
Phalanxv2.0.x🛡 Wave 2 — Ouronet Validator NetworkFUTURE9
Hephaestusv1.4.x🧩 Modular runtimeFUTURE4
Atlasv1.3.x🗂 IPFS everywhere — verifiable ledgerFUTURE3
Mnemosynev1.2.x📦 Autonomic backups + hub-as-package-repositoryFUTURE4
Zeusv1.1.x◈ Baron power toolsPLANNED6
Hermesv1.0.x✦ Hermes Engine — paid RPC fleet servicePLANNED12
Icarusv.G.3.0◇ IcarusPLANNED0
Athenav0.8.x⛓ Ouronet Core integrationPLANNED10
Genesis Patchesv.G.1.x🔧 Genesis post-launch fixesFUTURE5
Genesisv.G.1.0🌅 Genesis — public launchIN FLIGHT6

Apotheosis·v4.0.x

StoaChain protocol absorption (long horizon)

FUTURE

Once the validator network is battle-tested and the scoring model is operator-verifiable, scoring logic migrates into the StoaChain protocol itself. The hub becomes one validator among many; the product shifts from "hub that runs scoring" to "hub that orchestrates a network that scores itself".

  • Operator-verifiable scoring

    Research

    Operators can independently verify their own Stoicism accrual by pulling their node’s daily IPFS snapshot + running the eligibility engine locally against their own state. Zero trust in the hub’s numbers; hub is just the orchestrator.

  • Protocol absorption

    Research

    Scoring logic enters the StoaChain protocol as a Pact module; validator-tier operators compute scoring independently; consensus absorbs what was previously a centralised function. End-state the architecture has been building toward from day one.

Agora·v3.0.x

Wave 3 — Customer portal + monetisation

FUTURE

Once the validator fleet is established and the user base is substantial, open the monetisation surface. Customer portal sits on top of the hub infrastructure: StoaChain custodian services, managed-node leases, tiered IPFS pinning service (Pinata-style but Ouronet-native), payment in STOA with Elite-Tier discounts.

  • Customer portal product

    Future

    Distinct deployment (portal.ancientholdings.eu). Shares auth (Ouronet + mail), Stoicism ledger, and billing events with the hub via a stable internal API. Hub keeps operator-facing surface; portal is buy-side.

  • Tiered IPFS pinning service

    Future

    The Baron IPFS service (v1.0.x) scales up to a paid tier: anyone can buy IPFS pin capacity for Ouronet-ecosystem data (NFT collections, dApp assets). Elite Tier = discount. Payment in STOA. Scope remains Ouronet-focused — not a general-purpose Pinata replacement.

  • Managed-node leasing

    Future

    Customers (non-operators) rent capacity on AncientHoldings-owned nodes. Hub side: new node role "managed-for-hire" with revenue-split metering. Billing in STOA via a cronoton; fiat option for institutional.

  • Custodian services

    Future

    Multi-sig wallet management, cold-storage scheduling, key-ceremony tooling. Institutional customers who want StoaChain exposure without running nodes.

  • Payment module

    Future

    Accept STOA for any hub service; Elite-Tier-based discounts applied automatically. Accounting lives on chain via a cronoton; the portal surfaces invoices + statements. Fiat off-ramp to be defined.

Aegis·v2.2.x

Certificate-Authority service (long horizon)

FUTURE

Once the validator fleet is established, AncientHoldings operates a Certificate Authority for StoaChain-ecosystem TLS certificates. Currently certbot + Let’s Encrypt; long-term we issue our own, completing the independence from external infrastructure for blockchain-related operations.

  • ACME endpoint compatible with Let’s-Encrypt clients

    Research

    Certbot drop-in: point at our ACME URL instead of acme-v02.api.letsencrypt.org. Operators don’t change their tooling; certs come from us.

  • Per-ecosystem issuance policy

    Research

    Domains on the StoaChain / Ouronet ecosystem get auto-approved via Ouronet-account signature. Third-party domains use a DNS-challenge similar to LE. Keeps issuance fast for the ecosystem without becoming a general-purpose CA.

  • Root-CA publication + trust story

    Research

    Root certificate distributed via the IPFS package repository; trusted by operators via their OS cert store. Pain of bootstrapping the trust is the real barrier — hence "long horizon".

Nike·v2.1.x

Speed-test infrastructure

FUTURE

Use the validator fleet’s geographic spread to run benchmark probes from known-good endpoints. Currently nodes benchmark network throughput against external test servers; at scale the hub operates its own measurement network and stops depending on any third party.

  • Validator-to-validator speed probes

    Planned

    Each validator runs periodic iperf-style probes against every other validator; results feed a latency + bandwidth matrix publicly visible on the explorer. Sub-second recent data points per link.

  • Integrated benchmark reference

    Planned

    Node benchmarks (currently part of ServerScore) stop using external reference servers and use the validator fleet as the measurement network. Removes an external dependency from the scoring path.

  • Public speed-test tool

    Future

    End-user-facing "test my connection to StoaChain" tool — pick your nearest validator, get latency + bandwidth. Demonstrates infrastructure capability + helps operators pick their own seed-donor candidate.

Phalanx·v2.0.x

Wave 2 — Ouronet Validator Network

FUTURE

Each validator is a single server carrying everything StoaChain needs to remain operational, hosted across continents. A stoa node + IPFS pins + the full set of ecosystem UIs (hosted as static sites) + docker packages + a code mirror. The more validators online, the stronger the network; any single validator can serve the full StoaChain user experience to anyone on earth.

  • Stoa-node role (already present in v0.7 fleet)

    Planned

    Validators are a superset of the current hub-managed Stoa nodes. Every capability the current nodes have (scoring, backup, sync) carries forward; the validator role layers additional services on top of the same box.

  • IPFS pin set — federated + resilient

    Planned

    Each validator pins a shard of the full StoaChain-ecosystem IPFS corpus (ledger snapshots, UI bundles, NFT collections, docker packages, code mirrors). Content replication targets N redundancy across continents; losing any single validator doesn’t lose any CID.

  • Ecosystem UI hosting (Hub / Ouronet / Explorer / Caduceus)

    Planned

    Every AncientHoldings-operated UI — AncientHub, OuronetUI, the block explorer, Caduceus bridge — is served as a static site from the validator’s IPFS pinset. Any validator can serve any UI; the UIs work even when a specific hub instance is down.

  • Docker package storage

    Planned

    Validators hold a mirror of the docker containers needed to operate the stack: chainweb-node, mailcow images, hub release bundles, any critical dependency. Removes external docker-registry availability as a SPOF.

  • Code mirror (self-hosted git + IPFS pinning)

    Planned

    Mirrors of the hub repo + OuronetUI + explorer + adjacent code lives on the validator fleet. Reduces reliance on GitHub + makes the source publicly retrievable even if the upstream host becomes hostile or unavailable.

  • Federated blockchain data API layer

    Research

    Research + implement a way for the validator fleet to serve blockchain read-requests in a federated manner — an Explorer UI or OuronetUI doesn’t hammer a single node (single point of failure). Request routes to the healthiest reachable validator based on caller geography + load. Makes explorer capability unkillable.

  • Validator onboarding + scoring

    Planned

    Validator-tier operators earn a Validator-Score on top of their Stoicism — rewarding the additional services (IPFS pin availability, UI uptime, data-API reliability). Flag-enforced: validators must actually serve what they claim, or the reward stops.

  • Geographic distribution targets

    Future

    Minimum validator count per region (EU, NA, APAC, LATAM, AF) before the network claims "resilient". Dashboard on the hub + public explorer surfaces current distribution.

  • Public Network Map (validator + Stoa-node visualisation)

    Planned

    Public 2D map of the fleet. Nodes show as dots at their approximate geographic positions; gossip between peers renders as animated laser-style lines between dots. Toggle between Stoa-node view and Validator-node view. Demonstrates network reach + resilience at a glance; doubles as a PR surface. An early version ships in v0.7.x with hardcoded demo positions; live geolocation data lands with the validator network.

Hephaestus·v1.4.x

Modular runtime

FUTURE

Turn the hub into a platform. Cronotons, backup destinations, IPFS integrations are already modular internally; this phase exposes the module boundary so third parties (or we) ship extensions without forking the hub.

  • Module interface spec

    Future

    Stable TypeScript interface for modules: cronoton rules, backup destinations, scoring bonuses, node templates. Each module is a directory with a manifest + entry points. Hub loads modules at boot from a configured directory.

  • Module marketplace (read-only)

    Research

    Published modules are CID-addressed IPFS objects. Ancient admin pulls a manifest, audits, installs with a version pin. Later: signed reputation + community submissions. Initial rollout is read-only + curated.

  • Plugin security boundary

    Research

    Modules run in a sandbox (vm2-style) with a capability-scoped API surface: a cronoton module can’t read arbitrary DB tables. Defence in depth for untrusted extension code.

  • Own IPFS-like protocol tied to StoaChain

    Research

    Research-grade: a content-addressable storage layer co-designed with StoaChain consensus so CIDs + attestations can be referenced directly from Pact. Would complement or eventually replace the IPFS dependency for ecosystem-critical data. Far-horizon research; today’s IPFS cluster is sufficient.

Atlas·v1.3.x

IPFS everywhere — verifiable ledger

FUTURE

IPFS moves from "a Baron perk" to the hub’s own data plane. Daily mints publish manifest CIDs; scoring snapshots get CIDs; operators can verify their Stoicism delta by pulling a CID and running a local check. Trust shrinks; verifiability grows.

  • Scoring-ledger daily snapshot to IPFS

    Planned

    Every daily mint publishes the full pre-mint ledger state as an IPFS object; the on-chain mint tx carries the CID as a memo. Anyone pulls the CID + verifies the mint deltas locally.

  • IPFS backup destination

    Planned

    Completes the v1.1 pluggable-destinations story. Encrypted archive + its CID recorded on-chain via a cronoton — the backup’s existence is publicly provable without exposing the body.

  • Public seed-archive distribution via IPFS

    Future

    Hub-current seeds publish to IPFS (encrypted); new-node installs pull from any public gateway with a hub-issued decrypt capability. Faster than the current hub-only download + resilient to a hub outage during install.

Mnemosyne·v1.2.x

Autonomic backups + hub-as-package-repository

FUTURE

The hub stores its own artefacts on decentralised storage + ships operator backups off-site. Makes the ecosystem less dependent on any single piece of centralised infrastructure: hub releases live on IPFS, operator backups live on S3-compatible destinations, both verifiable.

  • Hub as IPFS package repository

    Planned

    Every signed hub release (deploy bundle, doc snapshot, CHANGELOG pin, docker containers) is published to the AncientHoldings IPFS cluster with a CID manifest. Anyone can verify a running hub matches a published bundle. Sets up the reproducible-deploy story and removes GitHub as a single point of failure for hub distribution.

  • S3-compatible backup destinations

    Planned

    Pluggable destination for node backup archives: local disk (today), S3 (this feature), IPFS (v1.2). Ancient admin configures credentials once; per-node "where do backups go" setting lets operators choose destinations.

  • Autonomic backup policy engine

    Planned

    Rule-based: "every scoring-state change + every 24h + before every reseed take a backup; retain 7 daily / 4 weekly / 12 monthly". Operator-configurable defaults per-node. Removes the "did I remember to back up?" category from the operator’s job.

  • Destination-side encryption for S3

    Planned

    Archives already encrypted with the hub master key; this adds a secondary layer of destination-side encryption (SSE-C with a per-tenant key) so even a compromised bucket can’t expose backup bodies.

Zeus·v1.1.x

Baron power tools

PLANNED

The things that make Baron tier earn its weight. Full mailbox management, IPFS publishing for NFT collections + StoaChain-related data, and — the headline — self-service Cronoton so Barons configure their own scheduled on-chain txs (gas funded by their Ouronet account).

  • Full mailbox management

    Planned

    Baron-side UI on /admin/email: quota usage vs Elite-Tier allowance, alias add/remove via Mailcow API, autoresponder toggle, password reset. SOGo deep-link kept. Elite Tier determines quota ceiling + max aliases.

  • Baron Codex hosting (zero-knowledge)

    Planned

    Google-Drive-like Codex hosting on the hub for Barons who want their own Ouronet Codex kept on resilient infrastructure. Storage is zero-knowledge: the hub stores encrypted Codex blobs; the decryption key never leaves the Baron’s device. The hub cannot read Codex contents and does not sign transactions on the Baron’s behalf. Functionally: encrypted file storage scoped to one file type.

  • IPFS service — 7 Ouronet NFT data types

    Planned

    Baron uploads content for StoaChain-ecosystem use. Ouronet NFTs classify data across 7 types: Image, Sound, Video, Document, Archive, Model, Exotic. The hub pins the bytes on the AncientHoldings IPFS cluster with an Elite-Tier-sized allowance; the type taxonomy shows up in the Baron upload UI + metadata. Deliberately scoped to Ouronet-ecosystem data — not general-purpose IPFS hosting.

  • Baron Cronoton — self-service scheduled tx

    Planned

    Barons register their own cronotons: "every day at 02:00 UTC call my Pact module X.Y with my account + these args". Hub signs with the Baron’s key (held encrypted; multisig option for high-value cronotons). Gas paid by Baron, audit-logged, revocable any time.

  • Baron cronoton monitoring

    Planned

    Per-Baron monitoring scoped to the caller: same data as admin cronoton monitoring, but only their own rules. Daily digest email on failure / success.

  • Node-operator cronoton templates

    Planned

    Built-in templates for typical node operations: renew validator registration, update stake, publish uptime attestation, refresh self-custody proofs. Barons enable a template with a click instead of writing the cronoton from scratch.

Hermes·v1.0.x

Hermes Engine — paid RPC fleet service

PLANNED

Convert the AncientHoldings chainweb fleet into a paid public RPC service. Customers (dApps, wallets, indexers, block explorers) pay AH for API quota; requests route through an AH-managed edge layer to participating fleet nodes. Operators earn BONUS Stoicism proportional to the compute-units they serve — keeping all rewards in the same unit operators already understand. Funds AH development going forward and creates a third earning vector for operators (alongside base accrual + warmup-period bonus). Forward-compatible plumbing already exists from v0.7.10z30 (tunnelee-frpc-rewrite handler is reused with an "edge-pool mode" extension). See plans/v1.0-hermes-rpc-fleet.md for the full design.

  • The deal — the operator value exchange (foundational)

    Planned

    Hub-registered chainweb nodes participate in the Hermes RPC pool as the cost of free hub access. The hub provides setup, monitoring, scoring, certs, backups, alerts, fleet onboarding; operators provide compute. AH monetises the aggregate via Hermes; operators earn BONUS Stoicism per request served (in addition to the base scoring + warmup credits they already get). Operators who refuse to participate stay outside the hub — chainweb keeps running independently, but they lose hub features AND Stoicism eligibility. Documented up-front in onboarding so operators understand the deal before signing up.

  • Edge layer (the Hermes service itself)

    Planned

    Public-facing TLS endpoint at hermes.ancientholdings.eu. New top-level service in apps/hermes-edge/ (Node + Fastify or similar). Responsibilities: TLS termination, API-key auth, per-key rate limiting, LRU/Redis caching of hot reads, weighted backend routing (by ServerScore + RTT), request metering, audit log, billing aggregation. Single dedicated AH VPS for v1.0 phase 1; multi-region (US + EU + APAC anycast/geo-DNS) for phase 4.

  • Compute-unit weighting per call type

    Planned

    Industry-standard CU model (Alchemy / Infura / QuickNode pattern). Light reads ~1 CU (info, cut), full block fetch ~5 CU, computational queries ~20 CU (pact local), transaction submission ~100 CU (pact send), mining work distribution ~50 CU. Heavier calls cost the customer more AND credit the serving operator more Stoicism — incentive structure pays operators for actual work delivered, not just request count.

  • Per-node bonus Stoicism accrual (the smart bit)

    Planned

    Daily aggregator: total CU served per node × bonus multiplier → Stoicism credit on the operator’s Ouronet account. Higher ServerScore + uptime + better latency → more requests routed → more bonus. Operators competing on quality, not just availability. All earnings stay denominated in Stoicism (no separate cash/STOA payout track) — keeps the economic story coherent: operate well, earn Stoicism. The mint converts Stoicism to STOA at the daily mint window, same flow as base accrual.

  • Mandatory pool participation gate (Stoicism eligibility)

    Planned

    lib/validator-eligibility.ts gains an rpc_pool gate: hub-registered nodes must have node.rpc_pool_member === true to earn Stoicism. One-click "Join RPC pool" button on every node detail (per-topology: Tunnelees extend tunnelee-frpc-rewrite with edge-pool mode; standalone gets SSH-tunnel-from-edge with zero node config change). Migration banner with deadline countdown for nodes that haven’t opted in.

  • Mandatory Docker supervision gate (Stoicism eligibility)

    Planned

    lib/validator-eligibility.ts gains a supervision gate: node.supervision_kind === 'docker' required for accrual. Screen + systemd installs (StoaNodeOne/Two originally, AncientMiner) lose eligibility unless migrated. Existing stoachain-convert-supervision + stoachain-data-migrate handlers do the heavy lifting; needs a one-click wizard UI + red banner. Required because Hermes needs predictable backend node state to make reliability guarantees to paying customers.

  • API key issuance + quota tier system

    Planned

    Hub /hub/api-keys page (operator-only initially, public signup in phase 4). Free / Bronze / Silver / Gold tiers with monthly CU quota + per-second rate limit per tier. Generate / rotate / revoke keys; per-key usage dashboard. New api_keys + api_calls tables.

  • LRU cache for hot reads (massive fleet load reduction)

    Planned

    Redis-backed cache at the edge, per-endpoint TTL (info: 5s, cut: 2s, account state: 10s, mempool: no cache, transaction submission: never cached). ~80% of RPC traffic is cacheable; one cache hit = zero load on the fleet. Critical for the economics — without caching, the fleet load scales linearly with customer count.

  • Per-topology backend access

    Planned

    Tunnelees: extend the v0.7.10z30 tunnelee-frpc-rewrite handler with "edge-pool mode" — re-adds a service-port frpc proxy with mTLS + IP allowlist (only AH edge VPS can connect). Standalone / Tunneler / self-container parent: edge VPS opens an SSH tunnel via the existing AH-managed SSH key, port-forwards to localhost:18481 (zero node config change for phase 1). Phase 2+ optimisation: chainweb --service-host=0.0.0.0 + iptables allowlist for direct edge-IP connect (faster, requires container restart).

  • Operator dashboard for RPC bonus Stoicism

    Planned

    On every node detail page, alongside the existing Stoicism dashboard: "Today: X requests served, Y CU, Z bonus Stoicism earned." 7d / 30d aggregates. Per-endpoint breakdown so operators see which call types their node is serving heavily. Combined with the existing Stoicism dashboard so the operator sees their full earning picture in one place.

  • Public customer signup + billing (phase 4 sub-feature)

    Future

    Public marketing page describing the AH RPC service. Customer signup (email → API key with quota tier). Stripe (or similar) for fiat → STOA conversion at the hub treasury; direct STOA payment for ecosystem-native customers. Per-tier pricing. Only ships once phases 1-3 (edge layer + caching + Stoicism accrual loop) are battle-tested with operator-only API keys.

  • Multi-region edge layer (phase 5 sub-feature)

    Future

    Second + third edge VPS in different regions (US + EU + APAC). Anycast IPs or geo-DNS for proximity routing. Customer requests land at the nearest edge; backend selection still picks the best-fit fleet node based on ServerScore + RTT. Removes the single-edge SPOF and improves global latency.

Icarus·v.G.3.0

Icarus

PLANNED

Iris: see patch log.

    Athena·v0.8.x

    Ouronet Core integration

    PLANNED

    The hub becomes a first-class Ouronet citizen. Reads StoaChain directly, cryptographically verifies Ouronet account ownership, submits its own transactions, and turns on the real reward distribution engine (Acquisition Pool payouts, Delegation IDs, Validator Operator slots). Precondition: DALOS_Crypto Go Schnorr hardening landed + @stoachain/dalos-crypto TS port reaching its Schnorr module + @stoachain/ouronet-core bumped to consume dalos-crypto and re-export Schnorr helpers. Hub-side v0.8 work does NOT begin until that cluster-wide chain is ready; otherwise the hub would stub primitives the wider cluster already owns.

    • Precondition: DALOS Go Schnorr hardening + TS port reaches Schnorr module

      Planned

      The 7 Schnorr hardening items from the v1.0.0 audit (length-prefix Fiat-Shamir transcript, RFC-6979 deterministic nonces adapted for Blake3, domain-separation tag "DALOS-gen1/SchnorrHash/v1", on-curve R validation, 0<s<Q range check, explicit typed errors, constant-time Montgomery-ladder scalar mult) land in the Go reference FIRST. Schnorr is exempt from the Genesis freeze because no on-chain DALOS sigs exist yet. The TypeScript port then validates byte-for-byte against hardened-Go test vectors — single source of truth, no Go/TS drift. Bonus: RFC-6979 nonces make the 20 Schnorr test vectors deterministic, lifting the corpus to 105/105 reproducible (from 85/105).

    • Precondition: @stoachain/ouronet-core consumes @stoachain/dalos-crypto

      Planned

      The shared TypeScript library (already live at v1.2.2 on npmjs.org, consumed today by OuronetUI) bumps to consume the new @stoachain/dalos-crypto and re-exports signSchnorr + verifySchnorr plus the Ouronet account-reader helpers the hub needs (ouronet.get-account public-key read, guard-analysis, StoaChain node-pool client). First-time hub dependency on ouronet-core lands with this feature — see OuronetUI’s ANCIENTHOLDER_HUB_HANDOFF.md for the handoff spec.

    • Ouronet RPC client (rides on ouronet-core’s node-pool helper)

      Planned

      Hub-side HTTP client for StoaChain /chainweb/0.0/<ver>/chain/<c>/pact/local + /send. Retry + per-chain endpoint rotation. Initial implementation sources from Ancient-Admin-owned nodes; long horizon: also consumes the Ouronet Validator fleet’s RPC pool (see Wave 2). Used by every v0.8.x+ feature that touches the chain.

    • Hub ↔ Ouronet account linkage via DALOS-Schnorr signed challenge

      Planned

      Every hub client’s profile-level Ouronet account must be cryptographically proven, not self-declared. Flow: hub emits a challenge string (Hub ID + User ID + account + nonce + expiry) → user clicks "Sign in OuronetUI" deep-link → OuronetUI unlocks Codex and signs via @stoachain/dalos-crypto.signSchnorr → signature (not the secret) returns to hub → hub reads account’s public key from chain and verifies via verifySchnorr against hardened DALOS. Private key NEVER leaves the browser. Stamps clients.ouronet_account_linked_at + ouronet_link_method='schnorr-sig'. Required for Delegator Entities AND Participants; unverified linkage → no Acquisition Pool payout. Replaces the today-stubbed verified_at.

      cluster-roles →

    • Delegation ID mechanics + Validator Operator slots

      Planned

      Two operational roles riding on the linked Ouronet account. Validator Operator: runs ≥1 validator server; hub tracks uptime + benchmark + mandatory-flag compliance and emits a daily eligibility TX per validator to the Acquisition Pool. Delegator Entity: stakes own NFTs (≥10k Quintessence minimum to create a Delegation ID, 1:1 with the Ouronet account), optionally accepts delegations. Quintessence thresholds: 20k per validator slot, integer-truncated (55k → 2 slots, 61k → 3 slots). Running more validators than your Quintessence unlocks buys nothing; limit is Quintessence-gated. Participants below 20k delegate into an existing Delegation ID; hub aggregates.

      validator-mechanics →

    • Pact-read: Baron qualification check

      Planned

      Periodic job reads each Operator’s Ouronet account against a Baron-qualification Pact module. Matches → grantBaron auto-fires. No-match with an active overlay → revokeBaron. No Ancient-Admin in the approval path; the chain decides. Uses the on-chain-verified account linkage from above — no linkage, no qualification check.

    • Scoring flip: shadow → live

      Planned

      Once the Pact module publishes the on-chain Stoicism token + register schema, the ancient-admin toggle on /hub/stoicism/settings switches mode. Shadow balances zero-out; Pending survives warmup; daily register-update TXes start emitting on-chain at 06:00 UTC.

    • Register aggregation mint

      Planned

      Daily-mint job computes per-account deltas, shards by chain that owns the account’s register, emits one batched update-registers tx per chain. Plain Pact math, no ZK, no Merkle dance. At StoaChain’s 2M max gas, a full 500k-account sweep fits in ~5 minutes across the 10 chains.

      scaling §500k →

    • Acquisition Pool reward distribution

      Planned

      The per-day reward formula lives here. Total Quintessence in the pool / 20k = potential validator slot count. Reward pool / slot count = per-slot reward. Each Delegator Entity captures slots proportional to its own Quintessence (truncated to integer). Worked example: 1M Quintessence in pool, 1000-token reward injection → 50 slots → 20 tokens/slot → a 55k Delegator running 6 validators still only captures 2 slots = 40 tokens, rate 0.000727 tokens/Quintessence; a 61k Delegator running 3 validators captures 3 slots = 60 tokens at 0.000984 tokens/Quintessence (better rate for crossing the 60k threshold).

      validator-mechanics →

    • Hub-hosted Explorer — ancient-owned nodes only

      Research

      The hub grows its own explorer database by streaming block data from one Ancient-Admin-owned node. Ancient-admin surface renders the same explorer UI + APIs as the public third-party explorer, but sourced from a DB the hub controls. Reads are bounded to Ancient-Admin-owned nodes; an operator’s own nodes stay in the per-node chainweb/jobs surfaces. Lets the hub decouple from third-party explorers long-term; long horizon: expose the Explorer as one of the Wave 2 validator-fleet services.

    Genesis Patches·v.G.1.x

    Genesis post-launch fixes

    FUTURE

    Forward-line fixes inside the Genesis launch (v.G.1.x). Bug fixes, polish items deferred from Papyrus, and the chapter-content rewrite for the about/hub stubs that landed at scaffold quality. Patches inside this line append to the Genesis release-page patch log via the extractor; the spine stays authoritative.

    • Extractor pipeline cleanup

      Planned

      Re-point readVersionProse + readChangelog at CHANGELOG.legacy.md (lib/version.ts no longer carries the 279 prose markers; CHANGELOG.md is now the phase-grouped output, not the per-version source). Fixes F-FINAL-001 + F-FINAL-002 from the launch audit.

    • Releases pillar — visual nesting under Genesis

      Planned

      The Releases pillar index (/docs/releases) currently shows 7 equal cards. Restructure to surface Genesis as the umbrella card with the 6 sub-phases visually nested beneath it, matching the page-level framing.

    • Hand-polish older Genesis sub-phases

      Future

      Cassandra and Prometheus were polished as part of Papyrus; Hydra, Pythagoras, Medusa already had launch chrome. Future v.G.1.x patches deepen narrative detail (operator notes, audit-grade qualification on Hydra) without changing the spine schema.

    • Mailbox password-change endpoint

      Future

      The Mail chapter at /docs/hub/mail documents the password-change flow as design intent; the actual API surface (/api/mail/password) lands here and rotates the password in Mailcow + re-encrypts the scrypt fallback in the secrets vault.

    • Roadmap deep-link slugs

      Planned

      Three outbound roadmap-anchor refs in pages/docs/hub/stoicism, pages/docs/hub/backups, and pages/network-map currently target legacy section IDs (#phase-v0.7.x, #phase-v1.1.x, #phase-v2.0.x). Re-target to the new G-coded anchors so deep-links land on the right card.

    Genesis·v.G.1.0

    Genesis — public launch

    IN FLIGHT

    Genesis is the era. v.G.1.0 is the launch milestone — the moment ancientholdings.eu becomes the public face of the Ancient Holdings hub. Six shipped sub-phases compose the era: Cassandra (audit foundation), Prometheus (Tunnelee/Tunneler), Pythagoras (decimal precision), Hydra (unified wizards), Medusa (segregated containers), and Papyrus (the docs + spine rehaul that turns the hub into a public-launch product). Each sub-phase has its own release page; this card surfaces them as a drop-down so the era story is visible at a glance.

    • Cassandra (v.G.0.1) — audit-system foundation

      Shipped

      Pluggable storage backends, retention windows, monthly archival, public transparency pulse, hash-chain export with Ed25519 hub signature. v0.7.9 series.

      release page →

    • Prometheus (v.G.0.2) — Tunnelee / Tunneler dual-role

      Shipped

      Every operator who can’t run a public node gets one anyway. Hierarchical fleet, install-wizard rehaul, server-wide DNS hostnames, Stoicism fee setup, cached fleet-wide network-tip. v0.7.10 series — 70+ patches.

      release page →

    • Pythagoras (v.G.0.3) — Stoicism numerical contract

      Shipped

      Arbitrary-precision decimal arithmetic across the Vault. Replay-events test proves byte-identical balances under replay. Drive-divisor invariant under property-based testing. 90 tests across unit/property/integration/reproducibility/drift/performance.

      audit →

    • Hydra (v.G.0.4) — unified install / convert / migrate wizards

      Shipped

      One wizard for every install path. Segregation by default. l-chain ready-for-multitenancy. Mode-aware StoaChain tab with capacity-gated install buttons; conversion preserves cluster-id + mining pubkey + warmup state. v0.7.12l series.

      release page →

    • Medusa (v.G.0.5) — slice-aware ServerScore

      Shipped

      N independently-scored chainweb containers per host — each its own nodes row, its own ServerScore, its own slice CPU/RAM/drive. Drive divisor honesty (per-slice, not host-wide). Cgroups-isolated bands. Compose spec hash for install reproducibility. 104 m-series patches.

      audit →

    • Papyrus (v.G.0.6) — documentation + spine rehaul

      Shipped

      Genesis-era versioning, five-pillar docs tree, typed Genesis spine, per-codename release pages, ReleasePageShell component, 24 HTTP 308 redirects, CHANGELOG rebuilt from spine, lib/version.ts trimmed from 10,186 to 20 lines. The narrative restructure that makes Genesis public-launch ready.

      release page →