Validators

Most node programs pay for registration. Sunima pays for work. A validator earns a slot in the genesis set by running a node in the testnet for five months, defending against real attack simulations, and passing randomised hardware challenges. The hardware capital expenditure plus continuous uptime is a natural Sybil barrier — it cannot be faked at scale.

Sunima validators run encrypted compute and the PRION security model in parallel. Hardware capacity is calibrated against measured Stage 5 (Cosmos-SDK + CometBFT + Halo2-KZG privacy + matryoshka runtime) workloads during the testnet phase — not estimated from a desk. The goal is a permissionless network where the scoring system rewards real, sustained operation rather than pre-set spec sheets.

Validators do not need a GPU. Block proposal and signing (ed25519) is pure CPU work, and the fee split pays a validator the same stake-weighted share whatever hardware sits in the box. Encrypted computation runs on separate confidential-compute workers, organised as an N-of-M attestation pool and independent of the consensus validator set. Those workers are protocol-operated and are not paid from the gas-fee split — accelerator hardware earns no fee income on this network, so do not buy a card expecting one.

Why these specs. Anything below 16 cores / 32 GB / 1 TB struggles under sustained encrypted-transaction load and falls behind on block production, triggering downtime slashing. Anything above the recommended tier is wasteful for the current load profile. The reference VPS class is calibrated to be expensive enough to deter farm-scale Sybil attacks (a 100-node Sybil farm costs €4,500+/mo) yet affordable for a serious individual operator.

All dates are estimates. The testnet launch date is conditional on Stage 5 completion. Stage 5 is the pre-mainnet codebase — we do not open the validator program on earlier stages because early-stage conditions do not transfer to mainnet.

Sunima distinguishes between operators who earn the genesis slot through testnet work and operators who buy in with stake after mainnet launch. Both paths produce a fully-functional validator. The difference is how the network treats them in their first months on mainnet.

The scoring formula is public. The weights are calibrated during the testnet period and finalised before the genesis snapshot. The point-to-SUNA conversion rate is determined by the protocol council before mainnet launch — this preserves flexibility to adjust weights if a particular metric is being gamed.

The validator emissions pool is 17% of total supply — 17,000,000 SUNA of the 100,000,000 fixed supply — distributed linearly over 7 years from mainnet launch. Distribution is proportional to ongoing performance, not split equally across all validators. A validator that performs well in year 3 earns more than one coasting on their genesis selection.

After Year 7 emissions end, every gas fee paid on the Sunima sovereign chain is split three ways. Operators do not earn from token-emission inflation — they earn from real network revenue plus PRION bug-bounty payouts. Misbehaviour is punished via graduated slashing with a small mercy fraction returned to the offender (a Sunima-unique mechanic).

Fee distribution per gas fee — with bootstrap burn ramp

Every operator class also earns a 2x staking APY multiplier on bonded SUNA versus passive stakers (subject to DAO-vote slide toward 1.2x once active-operator count reaches a documented threshold). Disabling the node forfeits the multiplier. Verified PRION pattern matches earn SUNA bounty payouts from the 3% Bug Bounty Pool (separate from the fee pool, replenished from protocol fees).

Bear-market dynamic adjustment — multi-signal trigger. The trigger fires when any one of four signals registers (a single-signal trigger is gameable through wash-trading): trailing 60-day volume falls below the DAO-set bootstrap floor; unique-sender-address trendline drops more than 40% below the rolling 90-day median; volume swings more than 5x within 30 days; or average validator monthly income falls below the documented hosting-cost floor for two consecutive months. When any signal fires, burn share automatically reduces by 20 percentage points and the difference is redirected to the treasury. The treasury then has DAO authority — with 48-hour timelock — to apply those redirected funds as an operator-runway subsidy. Mechanism reverses automatically when all four signals clear. This is a protocol-level constant, not discretionary management.

Profitability shape

The protocol commits to shares of fee revenue, not absolute payouts. Per-operator income scales with actual network volume in any given month rather than against a fixed dollar floor that the protocol cannot guarantee. Per-validator floor numbers are calibrated empirically from Stage 3–4 testnet telemetry and published with the testnet open announcement. The full profitability shape — validators at maturity, validators in early mainnet, broad coverage, and the treasury's bear-market role — is in whitepaper §11.5.6.

Slashing — three tiers

Mercy percent — a Sunima-unique mechanic

2–5% of slashed stake returned to the offender even in severe and medium tiers. This is a deliberate fork from the Ethereum and Cosmos defaults. Reasoning:

• The validator does not zero-out completely → keeps a stake-based incentive not to commit a second offense.
• Reduces the "unfair, nothing left to lose" perception that drives operators to abandon the network entirely after one mistake.
• Differentiates from the binary-burn pattern of Ethereum / Cosmos — Sunima is punitive but not cruel.

The 20% whistleblower share on severe-tier slashing is sized to attract serious community monitoring of validator behaviour. Catching a cheater earns a stake-proportional reward — the larger the violation, the larger the bounty.

Genesis 100 — accountability window (first 6 months post-TGE)

Validators who entered through Path A (the 5-month testnet probation, with the 5,000 SUNA airdropped into a locked self-delegation) operate under doubled slashing rates for the first 6 months after the token generation event. The trigger conditions and the slashed-stake distribution are the same as the three-tier table above — the slashed amount itself is multiplied by two.

• Severe tier (double-sign, malicious court-order vote, unlawful disclosure) → 2× slashed stake instead of 1×.
• Medium tier (persistent downtime, repeated missed blocks) → 2× slashed stake instead of 1×.
• Minor tier (rare missed blocks, brief instability) → 2× slashed stake instead of 1×.
• Mercy fraction and whistleblower share percentages are unchanged — they apply to the doubled base.

After the 6-month window expires, the validator transitions to the standard slashing schedule and is treated identically to a Path B (paid-in) validator. The window is bounded — it is not a permanent classification.

Why doubled, why bounded. The Path A slot was given as a reward for unpaid testnet work — operators received the entry without writing a 25,000 SUNA cheque. Doubled slashing for the bootstrap window prices in the asymmetry: a Genesis 100 validator who misbehaves in the first months of mainnet causes outsized reputational damage to the protocol launch and is penalised accordingly. The window expires because the cumulative on-chain track record from those 6 months is itself the validator's track record going forward — the surveillance is no longer needed once the data is public.

Uptime requirement — 80% minimum signed

Sunima sets a strict uptime floor. Validators must sign at least 80% of the most recent 20,000 blocks (the signed_blocks_window). At the chain's nominal 6-second block time that window is roughly 33 hours: a validator offline for more than 6.6 hours inside any 33-hour rolling window triggers an automatic jail.

This is significantly stricter than mainstream Cosmos chains (Cosmos Hub, Juno, Sei use a 5% floor — i.e. a validator can miss 95% of blocks and still avoid jail). Sunima's 80% floor is intentional and security-first: validators are paid for work, not for the privilege of holding a slot. An operator who cannot maintain 80% uptime is not a validator — they are a slot squatter, and the protocol does not subsidise that.

Dynamic downtime slashing — escalation for repeat jails

Vanilla Cosmos applies a flat slash (e.g., 1%) every time a validator is jailed for downtime. Sunima uses a three-tier dynamic schedule tracked over a 60-day rolling window:

Old jails roll off the counter once 60 days pass. A validator with a single jail four months ago starts the next cycle from a clean slate. The escalation curve protects responsible operators from one-off accidents while removing chronic underperformers quickly.

Slash distribution. The 1st-jail 0.05% slash distributes under the minor tier (5% to other validators). The 2nd-jail 20% slash distributes under the medium tier (50% returned at reactivation · 30% to other validators · 15% treasury · 5% mercy). The 3rd-jail 80% slash distributes under the severe tier (70% burn · 20% whistleblower · 8% treasury · 2% mercy) since it is paired with tombstone.

Scheduled maintenance windows — planned downtime without penalty

Operators occasionally need to take a node offline for legitimate reasons: kernel upgrades, hardware swaps, ISP migration. Sunima provides an on-chain mechanism to declare planned downtime so missed blocks inside the announced window do not count toward the jail counter:

• An operator submits a maintenance request on-chain via requestMaintenanceWindow(start_block, duration) at least 24 to 48 hours before the planned start. No retroactive requests.
• Maximum 1 maintenance request per 30 days per validator. Operators who need more frequent windows are running unreliable infrastructure and do not belong in the active set.
• Maximum window length: 6 hours. Anything longer is a hardware migration, not maintenance — those go through validator rotation, not maintenance exemptions.
• During the announced window: missed blocks are not counted toward the jail counter. Block rewards are still missed (the validator is not signing — that is unavoidable), but no slashing or jail occurs.
• Outside the announced window: normal slashing rules apply. A maintenance request is a pre-coordinated, time-boxed exemption — not a free pass.

Why we do this. Honest two-way contract. Operators get predictable maintenance flexibility; the network gets advance notice and can route consensus around the planned absence. Without this mechanism, every kernel upgrade is a coin-flip on whether the operator gets jailed during it. With it, the operator schedules, signals, and the network adapts.

Manual unjail with health check

When the downtime_jail_duration elapses, a jailed validator is not automatically released back into the active set. The operator must explicitly submit a MsgUnjail transaction to declare they are ready to return. Before the unjail is accepted, the chain runs a brief health check against the operator's node:

• Latest block height observed on the operator's RPC endpoint is within ±2 blocks of the network head
• Validator's consensus key is reachable and signs test payloads correctly
• Operator's reported hardware fingerprint still matches their pre-jail snapshot — no surprise migration to a different machine during jail

If any check fails, the unjail transaction is rejected. The operator fixes the issue and tries again. This prevents the cascade where a jail expires, the validator re-enters with a still-broken node, immediately misses blocks, and gets re-jailed in a fresh 60-day window — accumulating slashes the dynamic schedule was never designed for.

Why manual. Most Cosmos chains use auto-unjail because their security model is operator-friendly above all. Sunima's military framing prefers explicit return: the operator confirms "I am back, the issue is fixed" with a transaction signed by their key. Auto-release plus a still-broken node is a recipe for cascade jails that the protocol then has to absorb. Manual is a one-line ceremony that closes that failure mode.

Tombstone — permanent removal with governance escape hatch

Tombstone is permanent removal from the validator set, triggered by any of:

• Double-signing at consensus level (signing two competing blocks at the same height) — the canonical Cosmos tombstone trigger
• Third jail in 60 days per the dynamic downtime schedule above
• Severe-tier offense (malicious court-order vote, unlawful disclosure) per the three-tier severity table

A tombstoned validator cannot return through the standard unjail flow — their consensus key is permanently retired. The same operator can, in theory, set up a new validator with a fresh consensus key, but they lose any Genesis 100 status they held and re-enter through the permissionless path: a 25,000 SUNA self-delegation and a 6-month queue.

For exceptional cases — for example, an operator can demonstrate that a double-sign was the result of a misconfigured backup signing the same block, not a malicious actor — Sunima provides a governance-revertible escape hatch. A 4-of-5 multisig governance proposal can untombstone a validator. The untombstoned validator returns to the active set on a 1-month probation: any further offense during that month results in immediate re-tombstone with no second escape.

Path A on-chain terms acceptance

Genesis 100 validators (Path A) operate under doubled slashing during their first 6 months post-TGE. To make that enforceable without traditional legal contracts (which would require collecting validator real-world identity, breaking pseudonymity), Sunima uses an on-chain Terms-of-Service acceptance mechanism:

• The Genesis 100 terms document will be published at sunima.uk/legal/genesis-terms and the document hash anchored on-chain at program launch
• Before staking the 5,000 SUNA airdrop, a Genesis 100 validator must call OperatorTermsRegistry.acceptTerms(termsHash) from their validator wallet
• The on-chain registry stores (validator_address → accepted_terms_hash, accepted_at_timestamp) permanently
• The supplement slashing module reads from the registry: if a slashed validator has accepted Path A terms and is within their 6-month window, the doubled-rate supplement applies automatically — no governance vote required
• The terms cannot be retroactively changed. The hash is immutable; any future amendment requires a separate acceptance transaction from the validator

This preserves pseudonymity (no email collection, no KYC, no real-name binding) while creating cryptographic proof of acceptance the supplement module can rely on without any off-chain coordination. The wallet signature is the consent.