Documentation / 12. Validator mechanics

Chapter 12

Validator mechanics

Validator Operators vs Delegator Entities, Quintessence thresholds (10k / 20k), slot math, reward formula with worked examples, Hub-acting-as-Delegator flow.

This chapter covers how validators get paid. See §19 Cluster roles first for what a validator actually is(storage + RPC + Ouronet infrastructure backbone). This one is about the economics: who earns from the Validator reward pool, how much, and based on what.

Status: reward pool + Quintessence accounting is NOT yet live on-chain. The protocol layer (@stoachain/ouronet-core) that computes payouts is in development; see roadmap §12. This chapter documents the finalised design so operators can plan hardware + NFT acquisition ahead of launch.

Two halves of the reward mechanism

Validator rewards have two operational halves, both of which must be present for a flow to exist:

Server side

Validator Operator

Runs one or more validator servers on real hardware. The Hub tracks operational eligibility — uptime, benchmark freshness, mandatory-flag compliance — and pushes a daily on-chain TX per online validator into the Acquisition Pool. Validator Operators don’t need to hold Quintessence themselves; they can just be the hands running hardware for a Delegator Entity.

Stake side

Delegator Entity

Stakes Ouronet NFTs (produces Quintessence) and/or accepts delegations from other NFT holders. Creates a Delegation ID, becomes the on-chain party that captures validator slots in proportion to stake. A Delegator Entity doesn’t need to run hardware themselves; they can hire Validator Operators (or the Hub) to do that.

In the simplest case, one person is BOTH a Validator Operator and a Delegator Entity — they stake their own NFTs, they run their own validator. In larger or more specialised setups the roles separate: a hobbyist stakes 10k Quintessence and delegates running the validator to the Hub; a professional operator runs 50 validators funded by a pool of Delegators who don’t want to touch hardware.

Quintessence — the stake unit

Quintessence is the stake unit produced when an Ouronet NFT is staked. Different NFT classes produce different amounts of Quintessence per stake (final ratios locked with the mainnet genesis). For this chapter, assume a 1:1 mapping for the math.

Thresholds

Quintessence heldRoleCapability
< 10 000ParticipantCan stake into someone else’s Delegation ID (their Quintessence aggregates with the Delegator Entity’s own). Cannot create a Delegation ID themselves. Still earns rewards proportional to their Quintessence share.
≥ 10 000Delegator EntityCan create a Delegation ID (1:1 owned by the Ouronet account that created it). Becomes the pool owner — other Participants can delegate into the same ID.
per 20 000+1 validator slotEvery 20k Quintessence in a Delegator Entity unlocks one validator slot. Integer-truncated: 20k = 1 slot, 40k = 2 slots, 55k = 2 slots (you stay at 2 until you cross 60k), 60k = 3 slots, etc.

You can run MOREvalidator servers than slots your Quintessence unlocks. Running three validators with only 40k Quintessence (= 2 slots) gets you the same reward as running two validators with the same Quintessence — the third server’s capacity is wasted. Captured slots are Quintessence-gated, not server-count-gated.

Reward formula

Per epoch (daily, at 06:00 UTC mint time):

potential_slots  = total_Quintessence_in_Hub / 20 000
reward_per_slot  = injected_reward_pool / potential_slots
your_slots       = floor(your_Quintessence / 20 000)
your_reward      = reward_per_slot × your_slots

Distributed proportionally by Quintessence held. A Delegator Entity with 40k (2 slots) earns 2 × reward_per_slot. A Participant with 10k delegated to that Entity earns their proportional share of that 40k — specifically (10 / 40) × (2 × reward_per_slot)= half a slot’s reward.

Worked examples

Both assume a total of 1 000 000 Quintessence in the Hub and an injected reward pool of 1000 tokens this epoch. So potential_slots = 1 000 000 / 20 000 = 50 and reward_per_slot = 1000 / 50 = 20 tokens.

Example A — 55k Quintessence, 6 validators running

your_slots        = floor(55 000 / 20 000) = 2
your_reward       = 20 tokens × 2 = 40 tokens
per-Quintessence  = 40 / 55 000 = 0.000727 tokens/Quintessence

Running 6 validators with only 55k captured 2 slots. The extra 4 server capacities sat idle. Moving Quintessence would do more than adding servers here.

Example B — 61k Quintessence, 3 validators running (same epoch)

your_slots        = floor(61 000 / 20 000) = 3
your_reward       = 20 tokens × 3 = 60 tokens
per-Quintessence  = 60 / 61 000 = 0.000984 tokens/Quintessence

Crossing the 60k threshold bumped captured slots from 2 to 3 and gave a better per-Quintessence rate (0.000984 vs 0.000727). This is why the 20k granularity matters — the next integer multiple is always a rate bump for the Entity that crosses it.

Fractional delegation — Participants

Holders below the 10k Quintessence threshold (Participants) can’t create their own Delegation ID but can stake INTO someone else’s. Mechanically:

  1. The Participant stakes their NFT(s) through the Ouronet UI, selecting a target Delegation ID (owned by a real Delegator Entity — another user or the Hub itself acting as a pool).
  2. Their Quintessence aggregates with the Entity’s on the same Delegation ID. If the Entity had 45k and the Participant adds 8k, the Delegation ID now holds 53k — still 2 slots, but closer to the next bump.
  3. The reward for those 53k aggregated is captured by the Delegation ID. Distribution back to the Participant happens proportionally to each contributor’s Quintessence share, minus any operational slice the Entity claims (typical for the Hub-acting-as-pool case: 2-10% for running the validators + coordination work).

The protocol math is the SAME whether 50k is one monolithic staker or 5×10k Participants pooled under one Entity. No special-case code — just aggregated Quintessence feeding the slot formula, with downstream distribution handled at the Delegation ID level.

The Hub acting as Delegator Entity

AncientHoldings’s Hub can act as a Delegator Entity for holders who don’t want to run hardware themselves. Flow:

  1. Holder stakes their NFT(s), delegates Quintessence to the Hub’s Delegation ID.
  2. Hub aggregates all delegated Quintessence into its Delegation ID, claims corresponding slot count in the reward epoch.
  3. Hub runs enough validators on Ancient Holdings infrastructure to cover the slots (barebone servers in various regions).
  4. Epoch reward is received by the Delegation ID. Hub distributes proportionally back to delegators, retaining an operational slice that covers hardware + bandwidth + admin.

This is the turnkey validator-as-a-service path for users who want exposure to the reward stream without operating servers. Same mechanics as any other delegation; just the Entity happens to be AncientHoldings.

Hub’s orchestration role

The Hub handles the operational side of validator reward flow:

  • Daily eligibility push — for each validator enrolled in the Hub, the Hub checks uptime + benchmark freshness + mandatory-flag compliance + storage health, and emits an on-chain TX marking the validator as “eligible for this epoch” into the Acquisition Pool contract.
  • Delegator bookkeeping — tracks which Ouronet accounts are linked to which Hub clients (signed-challenge linkage via DALOS-Schnorr; see roadmap §12). Prevents a user from claiming rewards on a Delegation ID they don’t own.
  • Reward distribution (for Hub-acting-as-Entity): routes epoch payouts back to each delegator’s Ouronet account proportionally to their Quintessence share.
  • Surfaces Delegator controls for users who want to self-manage (switch validators between their own Delegation IDs, add Quintessence mid-epoch, withdraw stake, etc.).