Onboarding — zero to earning node

Register at /signup. Two equally valid paths:

• Your own email (Gmail, Proton, anything): you get a verification link — click it within 24 hours, then sign in. If you are later promoted to Baron, you pick your hub username at upgrade time — it gets attached to this same account, and from then on either identifier logs you in.
• A bare username (just type cucubau): it becomes cucubau@ancientholdings.eu automatically — the account is active instantly and the mailbox name is reserved for you, locked until Baron upgrade activates it as a real mailbox. You log in with the bare username too.

The full identity model (external email / hub username / both) is in Signing in.

Hub Stoicism only becomes on-chain Stoicism when the scheduled minter pays it out — and it pays out only to a verified Ouronet account. Do this first so that the moment your node starts earning, the destination is already in place and every mint lands correctly.

• Have an Ouronet account ready.If you don’t have one yet, create it in OuronetUI first — that’s the account (and key) your earnings are paid into.
• Set your Prime Ouronet account on My Profile. Every node you own earns into this account by default. (Per-node overrides can route an individual node to a different, Secondary account — each account verifies separately.)
• Click Verify and sign the challenge.You sign a one-time challenge in OuronetUI with that account’s own key, proving you control it. From then on every mint credits your account — publicly auditable in the mint-transparency view and ranked on the Stoics leaderboard.

Verification is independent of your hardware — there is no reason to leave it for later, and an unverified account is the most common reason “my node earns but I never received anything.” Mechanics in full: The Stoic System.

Any of these works: a rented VPS, a bare-metal server, or a spare machine at home. The baseline is Ubuntu 24.04 (Noble) with SSH access — run it directly on the metal. Exact OS, kernel and minimum hardware are in System requirements. Earnings scale with hardware quality (Step 10), so a better machine is yield, not vanity — and the data directory must be SSD/NVMe (an HDD never keeps up; full warning in Step 9).

Before anything else, find out which kind of public IP the machine has — this single fact decides your entire DNS setup (Step 4). There are three cases:

• 1. Fixed (static) public IP — most VPSes, bare-metal, and business lines; the IP never changes.
• 2. Rotating (dynamic) public IP — typical home fibre/cable: you DO have a public IP, but it changes on reconnect.
• 3. CGNAT / shared rotating IP — mobile connections and many home ISPs: the public IP is shared with other customers, so nobody can reach your machine from outside at all.

How to tell which you have: run curl ifconfig.meon the machine and compare it to the IP shown by any “what is my IP” site in a browser on the same network, and check your router/provider status page:

• Both match and your provider guarantees a static address → type 1.
• Both match but the address changes after a router reboot → type 2 (assume type 2 for any home line unless the contract says static).
• They differ, or the router shows an upstream address like 100.64.x.x / 10.x / 192.168.x → type 3 (CGNAT).

Every server needs a DNS name. This is not optional, and it is the step most newcomers skip and then get stuck on. Here is why, in plain terms.

What a DNS name is. A DNS hostname (like node1.example.com) is a human-readable label that “resolves” to an IP address — it’s the internet’s phone book. When you point a name at your server’s IP, that name becomes the server’s stable identity: other nodes dial it, certificates are issued against it, and the hub manages it by name even if the underlying IP later changes.

Why a node can’t run on a bare IP. A StoaChain node serves peers over TLS, and a TLS certificate is issued against a name— Let’s Encrypt (and every public CA) issues certificates for DNS hostnames, never for raw IP addresses. No name → no real certificate → the node falls back to a self-signed cert and will not peer with mainnet. So the server must have a DNS identity before chainweb can be installed.

Name vs. IP, and the recommended way. The recommended way to give the hub your server is by its DNS hostname, not its bare IP. Logging the server in by raw IP is acceptable only if you know the IP is genuinely fixed (type 1) — and even then you still have to set a DNS identity for the certificate (Step 7). For types 2 and 3 a bare IP is never an option. So: get a hostname now.

Where to get the hostname — pick the row that matches your machine:

• Provider-supplied generic hostname (easiest if you have one). Many providers hand every server a generic DNS name that already points at it. IONOS bare-metal boxes, for example, come with something like 70b25a9.online-server.cloud. That is a perfectly valid server hostname — just use it as-is. Check your provider’s control panel for a “reverse DNS” / “hostname” / “FQDN” field. Works for type 1(it tracks the server’s fixed IP).
  ⚠ Known issue — shared provider domains and certificates. Some providers put every customer’s generic hostname under one shared registered domain — e.g. netcup / supersrv hosts are …​.supersrv.de, and IONOS uses …​.online-server.cloud. Let’s Encrypt limits certificates to 50 per registered domain per week, and on a shared provider domain that quota is consumed by allof the provider’s customers — so it is often already exhausted. If your install aborts at the certificate step with too many certificates already issued for "supersrv.de" (or similar), that is why. chainweb cannot run on a self-signed cert (peers reject it), so the install stops there. Fix: use your own domain (next bullet) or DuckDNS — each is its own separate certificate quota. Point an A record at the same server IP and re-run the install with that hostname instead.
• Your own domain. If you own a domain, add an A record (e.g. node1.yourdomain.com) pointing at the server’s public IP. Cleanest and fully yours. Works for type 1 (and type 2 only if you run your own dynamic-DNS updater against it).
• DuckDNS (free dynamic DNS). Create a free account at duckdns.org, claim a subdomain (e.g. yourname.duckdns.org) and copy your token. A small updater on the server keeps the record pointed at your current IP automatically. This is the answer for type 2 (rotating IP), and a fine free option for type 1 too if you have no domain. The install wizard can wire the DuckDNS subdomain + token (the update timer and the certificate) for you.
  Why DuckDNS is the only option for most home machines (and the only one that needs no port 80). When you give the wizard a DuckDNS token, the certificate is obtained with the DNS-01 challenge: Let’s Encrypt is proven by a temporary TXT record on your DuckDNS name — nothing inbound is needed, so port 80 can stay closed. Every other option (your own domain pointed straight at the box, a provider hostname) uses the HTTP-01 challenge, which requires Let’s Encrypt to reach port 80 of that machine from the internet.
  
  That distinction is decisive when you have several computers behind one home IP (a typical household — e.g. 3 machines on one router). Port 80 is a single door on that one public IP: a router can forward it to exactly one machine at a time, so HTTP-01 can certify at most oneof them — you’d have to keep re-pointing the port-forward between boxes for each renewal, which is unworkable. DNS-01 has no such limit: each machine gets its own DuckDNS name + token and certifies itself independently, all behind the same IP, with no port-forwarding at all. For home nodes, use DuckDNS.
• CGNAT (type 3) — DNS alone cannot help. When the public IP is shared, no name and no port-forward can make your machine reachable from outside. You need a public front: either enlist behind an existing Tunneler (a server that already has a public IP and fronts others), or get a cheap VPS (≈1 €/mo) with a fixed IP and run your own tunnel. The VPS gets the DNS hostname; your machine (the Tunnelee) rides the tunnel. Full walkthrough: VPS tunnel setup.

Every server in the hub carries one of four categories — additive tiers, each adding capability on top of the previous. When you onboard, the category picker shows all four, but only one is yours to pick today:

• ◯ Stoa Node — pick this. The base tier and the only category an operator self-selects: a full StoaChain node + optional Miner + Cronoton + tools. If you are here to earn Stoicism, this is you.
• ⬡ Ouronet Validator — coming soon. Shown but disabled for everyone for now (adds Websites + Storage / package hosting, Validator ID later). It will open up in a future release. See Validator mechanics.
• ▣ IPFS Storage — admin only. Adds IPFS (kubo daemon): pinning + content addressing. Assigned by the Ancient Admin, not self-selected.
• ⬢ Master — admin only. Top tier; adds Mailcow + full Cronoton management. Infrastructure-grade servers, set by the Ancient Admin.

So in practice: choose Stoa Node and continue. If you later want IPFS Storage or Master, ask the Ancient Admin to assign it. (Categories are separate from the cluster roles — Miner / Ouronet Validator / Hub — explained in Cluster roles.)

In AncientHub → Nodes→ “Add node”, you give the hub SSH access (host, user, key). The one decision that matters here:

• Enter the server’s DNS hostname as the host (from Step 4) — this is the recommended way. The server is then tracked by its stable name, which survives an IP change.
• A bare IP is acceptable only for a genuinely fixed IP (type 1)— and even then you must still register the DNS identity in the next step before installing chainweb. For rotating or CGNAT machines, always use the hostname (or the Tunneler’s).

The wizard runs a layered preflight — TCP reachability → SSH banner → authentication → hardware probe — and shows each stage pass/fail live, so a typo or a closed port is caught before anything installs. From this point on the hub manages the machine over SSH; you never have to shell in yourself for routine operations.

Details: Nodes.

Having a hostname that resolves to your IP (Step 4) is half of it; the hub also has to know that name. On the node page there is a Server DNS hostname section — add your hostname there and mark it primary. This is the name the chainweb install uses to request the certificate and the one the install wizard preselects.

• If you added the server by hostname in Step 6, it’s effectively already set — just confirm the primary entry is correct.
• If you added it by bare IP, you must register the hostname here now. A server with no registered DNS hostname will install chainweb with a self-signed certificate and won’t peer with mainnet — this is mandatory, not cosmetic.

The hostname must be a real DNS name (letters, digits, dots, hyphens) — e.g. node1.yourdomain.com, yourname.duckdns.org, or a provider generic like 70b25a9.online-server.cloud. An email-style string with an @is rejected — that’s an address, not a hostname. Any container or Tunnelee inheriting from this server uses this entry as its default, so getting it right once carries downstream.

A node needs specific ports reachable from the internet. The canonical single-node defaults:

• 1789 — chainweb P2P (peers connect here; MUST be publicly reachable).
• 1848 — chainweb service/API port.
• 22— SSH (for the hub’s management connection).
• 1917 — miner stratum, only if you run a miner (Step 13).

Multi-container hosts take the next slot per container — P2P 17891, 17892, …, service 18481, 18482, …, miners 19171 + slot — allocated automatically and shown on the node page.

How: open the node page’s Firewall tab and let the hub apply the UFW baseline; it shows every rule and flags drift between what’s configured and what’s actually live. Full reference: Cerberus firewall control. The stricter alternative — forwarding only the exact ports upstream and leaving the host open — also works if you prefer to manage the edge yourself; it’s just more bookkeeping.

Running several servers behind ONE public IP (a home lab, or a Tunneler fronting Tunnelees)? Assign them to a location in the hub — the location’s port allocator hands each one a non-colliding slice, so you forward one coherent block instead of juggling individual ports.

With the server added, its DNS identity set, and ports open, run the install wizard from the node page. It does the heavy lifting: Docker, the StoaChain container, DNS/certificate wiring (certbot against your hostname), and — crucially — bootstrap from the hub’s seed snapshot, so your node starts from a recent copy of the chain instead of syncing from genesis. That turns days of initial sync into the time it takes to transfer a few GB.

What the wizard asks you (everything else is automatic):

• The drive — which disk holds the chain data. Pick an SSD/NVMe one (see the box below). The picker lists your eligible drives; the largest is preselected.
• The DNS hostname — preselected from Step 7; the certificate is issued against it.
• Initial committed storage— how many GB you pledge to the chain. You can change this later, and you’ll turn on automatic management in Step 11.

It then streams its progress live — reachability, key install, prepare, seed restore — and finishes with a node that is starting to sync.

Prime vs multiple containers — a question of how big your machine is. StoaChain is a braided multi-chain network (a Chainweb): one chainweb container runs a full node that tracks every chain at once— that single container IS a complete Stoa node and earns one ServerScore. “Multichainweb” does NOT mean one container per chain; it means running several independent full-node containers on the same physical host, each its own node with its own drive, DNS hostname + certificate, ports, and ServerScore.

• Prime container — small VPS / single drive. The whole server backs ONE chainweb container. The right (and simplest) choice for a typical VPS or any single-disk box. Start here unless you have a genuinely large, multi-drive server.
• Multiple (segregated) containers — bigger / multi-drive servers. One container per drive, each with its own port pair, hostname + certificate, and ServerScore. More containers = more earning slots from the same box — but each is a full node and needs real resources: its own SSD drive, roughly ~3 vCPU and ~6–8 GB RAM per container, plus a port slot. Don’t over-pack — starved containers fall off the tip and earn nothing. The Medusa panel enforces the host’s real capacity and tells you when it’s reached; the hub wires per-container nginx/DNS automatically.

You can convert between Prime and multi-container later from the node page — Vigilance and earnings state survive a conversion.

Know your flags. Every chainweb container runs with a defined flag set(its startup arguments — ports, cluster identity, mining coordination, and more), editable on the node page’s Flags tab (applying restarts only that container; a no-op change is zero-downtime). Two things matter:

• Certain flags are MANDATORY to earn Stoicism.The hub reads the container’s live arguments on every scoring tick against the Ancient-admin-maintained mandatory-flag list — a missing or wrong mandatory flag is a flag violation and the node earns nothing until it’s fixed (the node page names the offending flag). Current list: The Stoic System.
• Don’t hand-edit flags on the server.Change them through the Flags tab so the hub’s stored definition and the running container never drift apart.

Before a container earns anything it must be benchmarked: CPU (chainweb-correlated crypto workloads), disk, network and RAM are measured and stamped into a ServerScore. Stoicism accrues proportionally to that score — and a node with a stale or missing benchmark shows RED and earns nothing until re-benchmarked (when the benchmark version moves, the hub tells you). One click on the node page runs the whole pipeline; multi-container hosts have “re-benchmark cluster”. Deep dive: Benchmarking.

You don’t make the first commitment here — that already happened in the install wizard (Step 9), where you pledged an initial number of GB. That pledge is what the benchmark captured. This step is about changing it: on the node page, in the Provisioning commitment panel, you can raise or lower the pledge manually, or flip on autonomic commitment to let the hub manage it for you. Three things to understand:

• The minimum grows with the blockchain — it is recomputed continuously from the live chain size (+headroom, rounded up). Falling below it halts earning until resolved.
• Commitment is the one UNCAPPED score dimension: committing more than the minimum raises your ServerScore logarithmically — extra pledged space is rewarded without a ceiling, unlike CPU/disk/net/RAM which cap at their weights.
• Turn on autonomic commitment. In the same Provisioning commitment panel on the node page, flip on autonomic commitment for the drive and the hub adjusts the pledge for you on every worker tick — growing it while space allows, shrinking before a breach. Set it once and stop thinking about it. This is the recommended end state for every operator.

A fresh container must prove itself first. During this window it is in Vigilance — it must hold 24 cumulative hours at the chain tip(within a few blocks of the fleet’s peak) before it graduates. The counter is strict uptime-only — offline time never counts, but it doesn’t reset you either; it just pauses. (In the earnings view this is the orange Vigilance tile.)

Once Vigilance clears it matures into Stoicism (gold) — and the same rule is now your income rule: the node earns Stoicism only while it tracks the tip and passes the eligibility gates (benchmarked gold, storage committed, mandatory runtime flags, not in breach). Your accrued Stoicism becomes Minted Stoicism once the daily on-chain mint fires — paid into the verified Ouronet account you set in Step 2. Everything about accrual, gates and the ledger: The Stoic System.

Your synced node also powers the seed system: the hub periodically picks a healthy at-tip node as a seed donor, snapshots its chain database, and that snapshot becomes the bootstrap every NEW node starts from (Step 9). Donating a seed earns the donor a Stoicism bonus — staying synced literally feeds the next operator’s fast start. See Backups & seeds.

Any chainweb container can have a paired mining client (the Medusa panel’s Miner tab): the hub installs a chainweb-mining-client container next to your node, pointed at its service port, with a stratum port for ASICs (1917 on a Prime, 19171 + slot on multi-container hosts). Requirements: the chainweb flags enable-mining-coordination + mining-public-key (set on the Flags tab), then one click installs and the hub keeps the miner reconciled to spec.

Heads-up: a hub mining pool is coming — once it ships, solo miner containers won’t be necessary to participate. Running your own remains supported.