SOVR

At a Glance

Chain

Cosmos SDK v0.53 · CometBFT BFT consensus · IBC-Go v10 · CosmWasm

Token

SOVR (usovr, 6 decimals) — sole unit of account: staking, governance, gas, service payments, operator rewards

Hard cap

1,000,000,000 SOVR — protocol-enforced closed-loop cap

Initial minted supply

60,000,000 SOVR (Liquidity Pool Reserve + Service Liquidity Reserve); all other allocations remain unminted at genesis

Supply model

Latent / Locked / Vesting / Claimed / Burned-to-latent; burn is non-terminal and returns tokens to latent

Reward model

Track A Bootstrap Rewards + Track B Usage Rewards. Both work-contingent. No debt, repayment, or guaranteed-return framing

Settlement

Atomic 50/25/25 split on settled SOVR: Burn-and-Recycle to latent / fleet-wide active-operator pool / company allocation. Company sub-splits 40/40/10/10 (Infrastructure / Ecosystem / DAO Treasury / Staking Pool)

Block time

~13.5 s target (testnet)

Markets

Storage · Gateway · Bandwidth · Inference · Vector DB — each with its own module

Node licenses

10,000 NFT-backed licenses across 10 sequential tranches × 1,000. T01 Reserved Access (fixed $3,000); T02 Public Launch (fixed $3,000); T03–T10 Dutch (72 h linear decay). 200-NFT per-wallet primary cap; 12-month transfer lockup

OPT

Future 50 M SOVR OPT Exchange Reserve remains unminted until the protocol-level OPT-to-SOVR exchange opens; T01 access available to approved OPT holders under published rules

Identity

x/identity with dual-signature key rotation · x/policy for HTTP 402 + reverse bot management

Cross-chain

Lock-and-mint bridge to Arbitrum One with multi-relayer quorum · IBC to every Cosmos chain

Modules

21 first-party chain modules including x/bridge

Governance

Attestation-weighted by default with bonded-SOVR participation gate; per-operator weight capped at 2 % of fleet attestation as a non-mutable protocol constant

Executive Summary

Decentralized infrastructure has been promised for a decade. Storage without S3, compute without AWS, CDNs without Cloudflare, VPNs without centralized exit providers. Every project announcing one has run into the same three problems: measuring the work honestly, paying for it at the granularity it actually happens, and keeping operators from cheating on either side. “Proof of work” was a synthetic metric that only solved the last of those for one kind of work; the rest got hand-waved.

SOVR is built to solve the three problems together. It is a sovereign Cosmos SDK Layer 1 whose first-class citizens are operators — the people and businesses running real infrastructure — and whose first-class product is settled work, proven and paid for at the request level. The chain does not try to host every application; it is the settlement layer those applications and their underlying infrastructure can trust.

Six design decisions define v5.0 of the chain:

Single-token, closed-loop supply. SOVR is the sole unit of account. Every token sits in exactly one of five states (Latent, Locked, Vesting, Claimed, Burned-to-latent). The Burn-and-Recycle Protocol is non-terminal: a “burn” returns tokens to Latent, where they remain eligible to fund future emission. The 1 B SOVR cap is a closed-loop invariant — the chain cannot manufacture a token outside that envelope and never destroys one outside it either.

Minimized upfront minting. Of the 1 B cap, only 60 M is minted upfront at genesis (50 M Liquidity Pool Reserve + 10 M Service Liquidity Reserve, both held in company-controlled multisig wallets). Every other allocation — including the 730 M Latent / Protocol Emission Reserve, the 150 M Bootstrap Rewards Reserve, the 50 M OPT Exchange Reserve, and the 10 M Node Revenue Match Reserve — remains unminted until protocol mechanics or program rules trigger issuance.

Usage-priced, not gas-priced. Every service market — storage, gateway, bandwidth, GPU inference, vector databases — settles off-chain via domain-separated signed vouchers, on-chain in bounded batches. Gas pays for consensus inclusion, not for the underlying work. A node that stores a gigabyte for a month or forwards a terabyte of VPN traffic is paid for that work, not for synthetic hash cycles.

Work-contingent rewards across two tracks. Operators earn through Track A Bootstrap Rewards (early-network operator support, funded by the 150 M Bootstrap Rewards Reserve) and Track B Usage Rewards (ongoing usage-linked emissions, gated by a burn-parity capacity rule). Both tracks require activation, module participation, attested work, and eligibility — neither is a debt instrument, yield product, repayment obligation, or guaranteed return.

Pro-rata fleet-wide operator settlement. Service-channel redeems no longer credit the serving operator. Every settled SOVR is split 50/25/25: 50 % Burn-and-Recycle to Latent, 25 % into a fleet-wide active-operator pool, 25 % to the hard-coded company sub-split (40/40/10/10 across Infrastructure / Ecosystem / DAO Treasury / Staking Pool). The operator pool drains pro-rata by attestation score at the daily flush — operators are paid for being part of the fleet that’s working, not for being the host that happened to redeem this voucher.

Node licensing as a primary-market sale. Operator entry is gated by an NFT minted exclusively from x/auction. Ten sequential tranches × 1,000 nodes = 10,000 fleet cap. T01 is a $3,000 fixed-price Reserved Access tranche available to approved OPT holders under published rules; T02 is a $3,000 fixed-price Public Launch tranche; T03–T10 use 72-hour linear Dutch decay. A node license is a long-term infrastructure participation right, not a passive income instrument.

What follows is what the chain is today. Sections describing launch-sensitive mechanics — oracle activation, T01 OPT settlement, Node Revenue Match cadence, bridge hardening, and DAO Treasury maturation — are explicitly marked.

1. Positioning

Cloud infrastructure is centralized for two structural reasons: the economics of running at scale favor a handful of hyperscalers, and the metering + billing machinery those hyperscalers built is extraordinarily hard to replicate. Decentralized alternatives exist for the first problem — lots of operators with commodity hardware — but they keep failing on the second. You cannot have an honest provider market without an honest, cheap, automated way to measure and settle work.

SOVR is built to be that settlement layer. The chain provides:

• A stable, low-fee settlement rail for per-request payments between clients and operators, denominated in SOVR.
• Native infrastructure markets with matching shape: x/storage (hot + cold tiers), x/gateway (metered delivery with stake-backed disputes), x/bandwidth (WireGuard), x/inference (GPU), x/vectordb (ANN search). Each is a module, and all share one settlement primitive (x/payments channels redeemed through x/settlement.Split) and one slash primitive.
• An Attestation layer that turns signed proof of delivered work into operator reward weight, replacing the synthetic-work fiction of traditional PoW.
• A closed-loop supply machine (x/supply) and a work-contingent reward engine (x/distro, x/track_a, x/bootstrap) that together enforce the 1 B cap, fund the operator network through verified work rather than passive ownership, and tie issuance to attested service delivery.
• Identity and Policy primitives that any service participant can use to publish portable reputation, accept signed claims, and express pricing + tier rules as chain-queryable data. Edge middleware, subscription services, SaaS APIs, and application backends consume them identically; the chain records facts, the edge decides what to do with them.
• A multi-module SDK in Go, TypeScript, and PHP so non-chain systems integrate with the same voucher domains the chain validates.
• An Ethereum/Arbitrum bridge and IBC so SOVR is not an island.

Operators compete on price, reliability, and measured delivery. Clients buy what they use. The chain takes a thin cut on settlement, not a fat cut on every hop.

2. Architecture Overview

Layer

Component

Consensus

CometBFT (Tendermint) BFT; tolerates up to 1/3 Byzantine voting power

Chain framework

Cosmos SDK v0.53

Cross-chain

IBC-Go v10 (Cosmos ecosystem), custom lock-and-mint bridge

Smart contracts

CosmWasm enabled (optional per-module opt-in)

Deterministic address

Bech32 (sovr1... for accounts, sovrvaloper1... for validators)

Gas denomination

usovr (1 SOVR = 1,000,000 usovr)

Binary

sovrd (single binary — node + CLI client)

SOVR ships twenty-one first-party modules in addition to the standard Cosmos modules. Each is a separate Go package under x/:

Module

Purpose

x/supply

Five-state supply machine with §2.5 latent sub-bucket metadata; sole oracle for the 1 B-SOVR closed-loop invariant

x/distro

Daily/epoch reward scheduler; orchestrates Track A and Track B distributions

x/track_a

Bootstrap Rewards Reserve treasurer; 4-tier daily-pool cadence; 150 M lifetime cap

x/bootstrap

Node Revenue Match Reserve (10 M, 2.5× match concept); cold-start matching

x/opt_exchange

OPT Exchange Reserve treasurer (50 M); allowlist + SOVR-sale exchange surface

x/lockup

30-day linear vest on operator claim; originating node idles during its own vest

x/attestation

Rolling weighted score over signed work receipts; receipt-fraud challenge primitive; governance-weight primitive

x/oracle

USD/SOVR median aggregator with variance circuit breaker; dormant at launch (Bootstrap Reference Price applies)

x/settlement

Atomic 50/25/25 split on every settled SOVR; single-step burn invariant; daily pro-rata operator distribution

x/auction

10 sequential tranches × 1,000 NFTs; T01 / T02 fixed-price; T03–T10 Dutch decay

x/disputebonds

Shared escrow + non-terminal forfeit-to-latent settlement primitive consumed by every service module’s dispute path

x/nodelicense

NFT-backed operator licenses; 12-month transfer lockup; minted only from x/auction

x/bridge

SOVR ↔ Arbitrum lock-and-mint with multi-relayer quorum

x/payments

Payment channels, voucher redemption, session tracking (service-agnostic)

x/storage

Decentralized storage: hosts, deals (hot + cold tiers), challenges, proofs, slashing

x/gateway

Metered delivery (bytes or requests), stake-backed dispute arbitration

x/bandwidth

WireGuard VPN / mesh marketplace; chain-as-coordination-server

x/inference

GPU inference + embedding marketplace; per-model rate schedules; benchmark attestations

x/vectordb

Vector index + ANN query market; dual storage-and-query meter on one voucher

x/identity

Portable identity records, verification claims, reputation, revocation

x/policy

Per-provider configuration: pricing, tier rules, subscriptions, revocations

Standard Cosmos modules are wired in the usual way, with one deliberate exclusion: x/mint is disabled. All SOVR issuance is governed by x/distro, x/track_a, and x/bootstrap under the closed-loop supply invariant. Running x/mint would double-mint.

The deleted x/iopt module (and the dual-token model that motivated it) is gone. The 50 M SOVR that v4.0 had reserved for IOPT conversion is reframed as the OPT Exchange Reserve (§3.2): an unminted reserve that mints only when the future protocol-level OPT-to-SOVR exchange opens.

3. Token Model

SOVR is a single-token system. Under v5.0 there is no separate utility token: SOVR is the sole unit of account for staking, governance, validator gas, service payments, and operator rewards.

Token

Denom

Decimals

Role

SOVR

usovr

6

Staking, governance, gas, service payments, operator rewards, bridgeable to Arbitrum

Total supply is capped at 1,000,000,000 SOVR as a closed-loop invariant: latent + locked + vesting + claimed == 1B for all time, enforced centrally by x/supply on every transition.

3.1 The Five States

State

Definition

Latent

Not issued. Fuel for future emissions. Replenished by burns and forfeits.

Locked

Operator-earned, awaiting claim initiation. Not transferable.

Vesting

Claim initiated. 30-day linear release. Originating node idle during the window.

Claimed

Fully liquid. Transferable and spendable on services.

Burned

Not a distinct state — “burn” returns Claimed tokens to Latent.

x/supply.Move(ctx, from, to, amount) is the underlying primitive. Every economic transition in the chain routes through it, so the invariant is enforced once and everywhere. Typed helpers wrap common transitions (EmitToLocked, LockClaimed, StartVest, FinishVest, ForfeitToLatent, BurnClaimedToLatent, IssueFromLatent).

3.2 Genesis Allocation

The 1 B SOVR cap is partitioned across six allocation categories. Two are minted upfront into specific recipient wallets at genesis; four are protocol reserves held in latent and minted only when their issuance conditions are met.

Allocation

Amount

Minting

Purpose

Latent / Protocol Emission Reserve

730 M

Not minted upfront

Long-term protocol fuel: operator reward capacity, future Track B usage emissions, all work-based issuance

Bootstrap Rewards Reserve

150 M

Not minted upfront

Track A: work-contingent emissions to active, attesting node operators. Hard cap on category lifetime issuance

OPT Exchange Reserve

50 M

Not minted upfront; minted only at exchange

Reserved for a future protocol-level OPT-to-SOVR exchange under published rules. Tracked on-chain as a distinct latent sub-bucket (opt_exchange) so future emissions cannot accidentally consume the capacity earmarked for the OPT exchange

Liquidity Pool Reserve

50 M

Minted upfront

Initial market liquidity, held in a company-controlled multisignature wallet. Supports market-level liquidity (exchange, AMM, market-making depth)

Service Liquidity Reserve

10 M

Minted upfront

OTC service liquidity for customers and enterprises when open-market supply is insufficient. Multisignature wallet

Node Revenue Match Reserve

10 M

Not minted upfront; minted under program rules

Cold-start matching reserve for verified node-directed revenue. 2.5× match concept; cadence, tapering, eligibility, sunset rules pending policy validation

The two upfront-minted buckets (60 M total) sit in Claimed at genesis. Everything else (940 M) sits in Latent and migrates into Locked or Claimed only when the protocol’s emission rules fire. Locked and Vesting are zero at genesis; they grow as work-contingent rewards accrue and operators initiate claims.

The 940 M Latent pool is partitioned into four named sub-buckets carried by x/supply as protocol-aware metadata, each fed by exactly one program path:

• Sub-bucket
• Amount
• Sole consumer
• protocol_emissions
• 730 M
• Track B Usage Rewards (§5.2) and any future work-based protocol emissions; also receives credits from burn-and-recycle and emergency-claim forfeits
• bootstrap_rewards
• 150 M
• Track A Bootstrap Rewards (§5.1) — the only earmark Track A consumes
• opt_exchange
• 50 M
• The future OPT-to-SOVR exchange (§4.1, dormant at launch)
• node_revenue_match
• 10 M
• The Node Revenue Match Reserve cold-start program (§10)

Drains happen through bucket-aware emission helpers (IssueFromBucketToLocked, IssueFromBucketToAccount) so each program consumes only its own earmark — Track A cannot silently dip into protocol_emissions, the bootstrap match cannot dip into bootstrap_rewards, etc. The x/supply invariant sum(sub_buckets) ≤ latent_pool is checked on every transition. Burn-and-recycle (Claimed → Latent) and emergency-claim forfeit (Vesting → Latent) credit the recycled capacity to protocol_emissions — burns become general protocol fuel rather than refilling specific program reserves. All balances are queryable via x/supply LatentSubBuckets.

3.3 Burn-and-Recycle Protocol

SOVR uses a Burn-and-Recycle Protocol rather than a terminal burn model. When SOVR is paid into the network for services, the burned portion is removed from circulating supply and returned to Latent. At that moment it no longer exists as active circulating supply and becomes future emission capacity inside the fixed cap.

The 50 % Burn-and-Recycle slice of every settled SOVR (§6) is not company revenue and is not shared with the company. It is reserved as future operator reward fuel, released only through protocol-defined emissions tied to verified infrastructure work.

The right framing for the supply effect is float-constrictive rather than deflationary. Burns reduce the immediately circulating supply but do not destroy tokens, so the long-run picture is recycling rather than permanent contraction.

4. Node Licensing and the Primary Market (x/auction, x/nodelicense)

Operator entry is gated by an NFT-backed node license. Under v5.0 the legacy flat-price MsgPurchaseLicense path is disabled (LicensePrice defaults to zero). Mints originate exclusively from x/auction.MintFromAuction, which means a node enters the network through the primary-market Dutch auction.

4.1 The Tranche Ladder

• Tranche
• ID
• Mechanism
• Opening / Floor
• Buyer gate
• T01
• 1
• Reserved Access (fixed)
• $3,000
• T01Allowlist (gov-set)
• T02
• 2
• Public Launch (fixed)
• $3,000
• none
• T03
• 3
• Dutch decay
• $6,000 → $3,500
• none
• T04
• 4
• Dutch decay
• $7,500 → $4,000
• none
• T05
• 5
• Dutch decay
• $9,000 → $4,500
• none
• T06
• 6
• Dutch decay
• $11,000 → $5,000
• none
• T07
• 7
• Dutch decay
• $13,000 → $5,500
• none
• T08
• 8
• Dutch decay
• $15,000 → $6,000
• none
• T09
• 9
• Dutch decay
• $17,500 → $6,500
• none
• T10
• 10
• Dutch decay
• $20,000 → $7,000
• none

T01 and T02 are priced identically: T01 is reserved-access, not discounted. Governance installs the T01 buyer set with MsgSetT01Allowlist, sourced from an off-chain OPT-holder snapshot on a separate chain (T01 participation does not merge the OPT and SOVR ecosystems or create common ownership). Approved OPT holders may purchase T01 nodes using OPT under published rules; the applicable OPT reference price may be fixed using a 7-day market reference snapshot taken before the program opens. Final settlement mechanics — including whether OPT is burned, escrowed, retained, or otherwise processed; which authority controls the disposition path; and the disclosure language presented to T01 buyers — must be pinned before public release. This whitepaper acknowledges the open status and does not commit to a specific path; the chain side is state-shape compatible (the TrancheSettlementKind enum reserves a BurnReceipt variant for the on-chain OPT-burn proof should that become the final treatment). T01 buyers may also pay in SOVR via the same oracle quote everyone else uses. The 1,000 T01 nodes are reserved at the protocol-allocation level; license issuance occurs at settlement.

T02 is the public launch tranche, also at the $3,000 fixed price, with no allowlist gate. T03–T10 use 72-hour linear Dutch decay between their opening and floor prices; after the window elapses the price stays at floor. A tranche does not clear merely because time elapsed — it clears when supply is exhausted.

Two primary-market constraints apply across the entire ladder:

200-NFT per-wallet cap across the full primary market, enforced by PerWalletCap in PlaceBid. This cap is enforced at the address level; it is not presented as a guaranteed beneficial-owner concentration cap. A single beneficial owner operating multiple signing addresses can accumulate beyond 200 NFTs in aggregate; the chain does not deduplicate by off-chain identity.

12-month transfer lockup on minted licenses, enforced by x/nodelicense.MsgTransferLicense against the PurchasedAt height stamped at mint time. Self-transfers bypass.

Sequential gating applies across the whole ladder: T(N+1) cannot open until T(N) is cleared. Only the current open tranche accepts bids. The TrancheSettlementKind enum is modeled so a future BurnReceipt variant for on-chain OPT-burn proof can drop in without state reshape.

If a Dutch tranche reaches its $X floor and supply does not naturally exhaust within the 72-hour window, the price stays at floor and the tranche remains OPEN — the chain does not auto-clear on time alone. Governance unblocks the ladder via MsgForceCloseTranche, which marks the stalled tranche CLEARED (recording the residual unsold count for off-chain audit) and auto-advances to the next PENDING tranche. This is the chain’s defined post-auction handling process for unsold supply; the unsold-node disposition (re-tranche, retire, distribute) is a governed decision rather than an automatic protocol behavior.

4.2 What Minting Entails

A T(N) bid that clears triggers a single atomic flow inside x/auction.PlaceBid:

• The buyer’s allowlist / per-wallet-cap status is checked.
• The price is computed (T01 / T02 fixed; T03–T10 by Dutch decay against OpenedAt) and quoted in usovr through x/oracle.
• The clearing price is settled and an activation bond may be escrowed (default 0 bps; governance-tunable).
• x/nodelicense.MintFromAuction(buyer, metadata, trancheID, clearingPriceUsovr) mints an inactive license stamped with the tranche ID and clearing price.
• x/track_a records the new license as eligible for Track A Bootstrap Rewards under the active reward parameters (§9).

Earning is gated separately. A minted license starts as LICENSE_STATUS_INACTIVE. The buyer must wait the activation delay, call MsgActivateLicense, register against an infrastructure module (x/storage, x/gateway, x/bandwidth, x/inference, x/vectordb), and produce attested work. Track A and Track B reward distribution depend on rolling attestation score and active-license status. Merely owning a license does not earn anything; an inactive license, or an active license with no attested work, accrues no rewards.

4.3 Why a Dutch Auction

The earlier flat-price model under v4.0 had no mechanism to discover a clearing price — every license sold at the same number whether demand was 10× supply or 0.1×. Dutch decay lets the market price each tranche over a 72-hour window. The opening / floor pairs are governance-tunable, but the chain enforces the math: a tranche cannot be cleared at a price the market would not accept, and a tranche cannot reopen retroactively if the market overshoots. The 200-wallet cap and 12-month transfer lockup keep the primary market distinct from a secondary-trading vehicle.

5. Operator Reward Architecture (x/distro, x/track_a)

SOVR uses two reward tracks. Both are work-contingent. Neither creates passive yield, debt, repayment, principal, payback, or a guaranteed return. Operators earn through Track A Bootstrap Rewards (early-network operator support, sourced from a fixed reserve) and Track B Usage Rewards (ongoing usage-linked emissions, gated by a burn-parity capacity rule).

Reward scheduling lives in x/distro. Track A reserve accounting lives in x/track_a, which holds the lifetime drawdown counter against the 150 M Bootstrap Rewards Reserve and selects the day’s pool size from a 4-tier ladder keyed to fleet attestation. Both modules return payout amounts; the calling path (x/distro BeginBlock for Track A and Track B; x/settlement DistributeRewards for the Bootstrap Match payout) issues SOVR through x/supply.IssueToLocked, which enforces the 1 B closed-loop cap on every transition. x/track_a, x/bootstrap, and x/opt_exchange are accountants — they own latent sub-bucket draws and per-program counters but never call bank MintCoins directly. The mint authority is concentrated in x/distro (and x/bridge for cross-chain mint/burn).

Operator emissions land in the Locked state via x/supply.IssueToLocked. The daily flush credits operator-scoped ledgers (OperatorLocked in x/settlement, PendingRewards in x/distro) without touching x/lockup. x/lockup is uninvolved until the operator initiates a claim, at which point the claimed slice transitions Locked → Vesting (§7) and a 30-day linear-vest position is created in x/lockup. The operator must take the explicit claim action before any token starts to release; an inactive ledger position does not auto-vest.

There is no chain-level “validator floor” emission separate from Track A and Track B. Consensus participants earn through standard Cosmos staking rewards plus their share of operator-pool drains; the chain does not issue a daily fixed amount independent of service activity.

5.1 Track A: Bootstrap Rewards

Track A is the network’s early operator bootstrap mechanism. It is funded by the 150,000,000 SOVR Bootstrap Rewards Reserve, which is not minted upfront and is not held in a company wallet. Tokens from this reserve are minted only when active node operators perform verified infrastructure work and satisfy applicable reward conditions.

• Track A is not a loan, debt instrument, repayment obligation, yield product, or guaranteed return.
• Track A rewards require activation, module participation, attestation, and eligibility.
• A node with no verified work in the relevant rolling window receives no Track A rewards.

Launch defaults (governance-tunable post-launch within the immutable reserve ceiling):

Parameter

Default

Daily-pool tier 0 (<25 % attesting)

50,000 SOVR/day

Daily-pool tier 1 (≥25 % attesting)

120,000 SOVR/day

Daily-pool tier 2 (≥50 % attesting)

190,000 SOVR/day

Daily-pool tier 3 (≥75 % attesting)

260,000 SOVR/day

Attesting-share window

7-day rolling

Per-node cap

10 × cohort average

Distribution

Pro-rata by 30-day attestation score

Lifetime ceiling

150,000,000 SOVR (immutable upper bound)

There is no taper schedule; Track A halts hard at reserve exhaustion. The 150 M ceiling is a fixed protocol cap — governance may lower it (early sunset of the program) but cannot raise it. The other parameters above (tier amounts, breakpoints, cohort cap, windows) remain governance-adjustable so the network can respond to observed fleet behavior in the bootstrap window.

Depletion sensitivity. At the highest tier the Track A daily pool is 260,000 SOVR (≈ 95 M / year), which would consume the 150 M reserve in roughly 19 months of sustained ≥75 % attesting. Lower-tier paths extend the runway substantially: at 25 % attesting the runway is ≈ 8 years, at 50 % ≈ 3.4 years. The launch defaults are sized for a Bootstrap window that overlaps Track B’s 36-month phase ramp, but the actual depletion curve depends on observed fleet behavior. Scenario modeling against the launch fleet attestation profile, with sensitivity on early-vs-late attestation ramp and on the Track B burn-parity activation timing, is part of the pre-mainnet validation track and is documented in docs/modeling/ once published; until then the tiers are conservatively defined and governance retains the lever to lower them if the observed depletion runs faster than the Track B ramp.

The reserve closes when exhausted. Track A as a category ends when the 150 M ceiling has been emitted in full.

5.2 Track B: Usage Rewards

Track B is the network’s ongoing usage-based operator reward mechanism. It is sized against attested service demand and is gated by a burn-parity capacity rule: Track B emission scales with how much SOVR the network has recently returned to Latent through service-payment burns, so a chain with no service activity emits no Track B.

The rule has two consequences. First, Track B emissions are anchored to verifiable network use rather than calendar time. Second, the closed-loop supply machine and the reward engine are coupled: every service payment that burns to Latent expands Track B’s near-term capacity envelope, every Track B issuance contracts it.

Track B routes 100 % of issuance into the fleet-wide operator pool. It is not subdivided across ecosystem, staking, or company allocations. The hard-coded company allocation applies only to the 25 % company share of service payments (§6) — not to Track A or Track B emissions.

The Track B operator pool is distinct from the §6 settlement 25 % operator pool. Track B issuance lands in the distro module’s PendingRewards ledger (sourced from the protocol_emissions latent sub-bucket via IssueToLocked); the §6 settlement 25 % slice lands in the settlement_rewards module account’s OperatorLocked ledger (sourced from current service payments). The two ledgers use separate module accounts under separate distribution paths — both pro-rata by attestation, neither cross-funds the other. Conceptually: Track B pays operators for future issuance funded by recycled latent capacity; settlement 25 % pays operators for current service work that just settled.

Launch defaults (governance-tunable):

Track_B_today = min(phase_cap × TrackBDailyCapUsovr, k × AttestedWorkValue) × BurnParityFactor

Parameter

Default

k

1 bps (100 usovr per attestation unit)

TrackBDailyCapUsovr

50,000 SOVR/day

Bootstrap phase

Months 1–12, phase_cap = 2×

Scaling phase

Months 13–36, phase_cap = 5×

Mature phase

Month 37+, phase_cap = 5× (inherits)

Burn-parity threshold

60 % (trailing burns ÷ trailing emissions)

Burn-parity trailing window

30 days

BurnParityFactor

Linear 0 → 1.0 as ratio approaches threshold

The phase multiplier scales the cap term, not AttestedWorkValue. During Bootstrap the daily cap is 2× TrackBDailyCapUsovr (= 100,000 SOVR/day with the launch default); during Scaling and Mature it is 5× (= 250,000 SOVR/day). The BurnParityFactor then multiplies whichever side of the min(...) constraint binds, so a chain with no burns emits no Track B regardless of phase.

6. Settlement (x/settlement)

x/settlement is the routing layer between service-payment redeems and the supply machine. Every settled SOVR — every voucher redeemed through x/payments, every bridge fee, every direct service-module settlement — flows through keeper.Split(ctx, coin), which fans out atomically to three destinations.

6.1 The 50/25/25 Split

Share

Destination

50 %

Burn to latent — bank.BurnCoins followed by x/supply.BurnClaimedToLatent. Returns the coin to Latent.

25 %

Operator reward pool — credited to the settlement_rewards module account, drained pro-rata by attestation score at the daily flush (§6.2).

25 %

Company allocation — sub-split 40/40/10/10 into infra / ecosystem / DAO / staking destinations.

Dust from integer division at the top level rolls into the company slice; dust from the company sub-split rolls into staking. Every usovr is accounted for. Defaults: BurnBps = 5000, OperatorBps = 2500, CompanyBps = 2500; company sub-split 4000/4000/1000/1000.

A critical property of v5.0: the 25 % operator slice is not credited to the operator who served the redeemed voucher. It enters a fleet-wide pool. An operator that served the voucher and an operator that did not are paid from the same pool, weighted by their rolling attestation score. This decouples reward from voucher-redemption timing — a host that runs reliably for a quarter and redeems vouchers in one big batch, and a host that runs reliably for a quarter and redeems steadily, earn the same reward weight for the same delivered work.

The hard-coded 25 % company sub-split (40/40/10/10 across Infrastructure / Ecosystem / DAO Treasury / Staking Pool) applies only to the company share of service payments. It does not apply to Track A Bootstrap Rewards or Track B Usage Rewards.

6.2 Pro-Rata Distribution

DistributeRewards(ctx) drains the settlement_rewards pool at the daily flush:

Reads each operator’s rolling 30-day attestation score from x/attestation.

Allocates shares pro-rata; dust below per-operator allocation stays in the pool for the next distribution.

Records each share in OperatorLocked[operator] += share (settlement-layer claim ledger).

Calls x/supply.LockClaimed(share) so the 5-state total stays consistent.

If the pool balance or the active attestation weight is zero, the call is a no-op. The accumulator across distributions means an operator can claim from OperatorLocked against many days of accumulated settlement, in a single claim-initiation event.

6.3 What Calls Split

• x/payments — service-channel finalize routes each SettledToB coin through Split rather than direct-paying the host. Channels carrying a non-empty service_module field opt in to settlement routing; generic peer-to-peer channels still direct-refund.
• x/bridge — LockAndMint and RedeemAndUnlock route the fee slice through Split for partial-burn behavior on cross-chain transfers.
• Future — direct service-module voucher redeems may call Split directly if the current payment-channel gating is relaxed.

Service channels are usovr-only at launch. x/payments OpenServiceChannel rejects any non-usovr accepted-denom up front (ErrUnsupportedServiceDenom), and finalizeChannel hard-errors if a service channel somehow holds a non-usovr SettledToB slice. Generic peer-to-peer channels (no service_module field) continue to direct-refund regardless of denom — they never touch settlement. x/bridge fees are usovr-only as well. The launch posture is intentional: service activity must route through SOVR economics. Once x/oracle is feeder-populated and governance enables non-usovr conversion, the service-channel denom restriction can be relaxed; until then, only usovr is settle-routable through x/settlement.Split and the 50/25/25 economics apply uniformly to every settled service payment.

7. Lock-Claim and Node Idle (x/lockup)

Operator rewards do not unlock immediately. The v5.0 design replaces v4.0’s 180-day curve with a 30-day linear vest and a small but important new property: a node idles during its own claim window.

7.1 Vesting Mechanics

Parameter

Default

Meaning

VestingDurationSeconds

180 days

Linear-drip window from claim initiation to fully Claimed

InitialClaimableBps

0

No instant-claim portion (v4.0 had 5 %; v5.0 removed it)

Forfeit on emergency claim

unvested slice

Returns to Latent (closed-loop conservation)

When an operator initiates a claim against their OperatorLocked ledger, the claimed slice transitions Locked → Vesting and begins to release linearly over 180 days. During the active vest window, the originating node idles: it does not earn new Track A or Track B rewards, and it does not contribute to the fleet-wide attestation weight. An operator running a single node faces a real choice — wait for accumulated rewards and take a productive month off, or run continuously and claim at lower volume.

An operator may emergency-claim mid-window. The emergency path releases the vested slice to Claimed and forfeits the unvested remainder back to Latent through x/supply.ForfeitToLatent. There is no haircut to a third party: forfeited tokens fund future emission generally, in the same way the burn slice does.

The keeper helper x/supply.ForfeitToLatent exists; a transitional ForfeitPool + DrainForfeitPool re-emission path also still ships from v4.0. The accounting converges to the same end state — forfeited value flows back to active operators — just on a slower curve until the legacy path retires.

Vesting is distinct from the withdrawal cooling-off period. VestingDurationSeconds (180 days) governs the claim flow on operator rewards: Locked → Vesting → Claimed. UnbondingDurationSeconds (45 days) governs withdrawal of a time-locked deposit position from x/lockup — a different state machine that returns previously-locked principal after a mandatory cool-down. The two never collapse onto the same timer: vesting is on the reward side, unbonding is on the position-withdrawal side. A long vest does not imply a long unbond, and vice versa.

7.2 Why Node Idle

The idle-during-vest property is a deterrence against churn-and-claim attacks. Without it, an operator could run hard for a month, claim, run hard for the next month, claim again, and never face the opportunity cost of the lock. With it, a claim is a deliberate pause: the operator forgoes the next month’s earning to liquidate the previous month’s accumulated reward. This is not a punishment — it is a price for liquidity that aligns operator behavior with sustained network participation.

8. Attestation (x/attestation)

Attestation is the bridge between off-chain work and on-chain reward. Operators (or modules acting on their behalf) submit signed receipts describing metered work; the keeper validates, dedups, stores in a rolling window, and exposes a score per operator that drives the operator-pool fan-out.

A receipt carries:

• Operator address (and license reference, by extension)
• Receipt type discriminator (storage delivery, gateway session, etc.)
• Metrics payload (service-specific bytes, canonicalized)
• Timestamp, source-ID for dedup
• Signature over the domain-separated preimage (sovr:receipt:v1)

The keeper validates the signature against the operator’s current pubkey — through cryptotypes.PubKey, so the verification path is algorithm-agnostic (§17.1). It dedups by (operator, source_id) and writes to the operator’s score window. The 30-day rolling score is what x/settlement.DistributeRewards reads at the daily flush.

Modules can call SubmitModuleReceipt(ctx, operator, receiptType, metrics, ts, sourceID) directly without an end-user signature — the calling module’s name in Params.TrustedModuleSources is the trust authority. x/storage and x/gateway use this path to attest delivery without requiring the host to co-sign.

8.1 Receipt Fraud Challenges

A signed receipt that does not reflect real delivered work is a fraud claim against the chain’s reward pool. MsgChallengeReceipt lets any participant flag a specific receipt as fraudulent: the challenger posts a dispute bond through x/disputebonds, references the receipt by id, and supplies evidence. Resolution slashes the loser’s bond per the §19 dispute model, and an upheld fraud finding additionally slashes the receipt-issuing operator at SlashFractionFraudulent (default 5 %). This closes the loop between operator-signed receipts and the chain’s other dispute primitives — receipt fraud is no longer “the host’s word,” it’s contestable.

8.2 Governance-Weight Primitive

Attestation also exposes a governance-weight primitive: GovernanceWeight(operator) returns the operator’s score capped at 2 % of fleet-wide total. This is a protocol constant (GovernanceCapBps = 200), not gov-mutable. The cap exists so a single megafleet operator cannot dominate governance even if they accumulate disproportionate attestation. The SDK x/gov weight-override hook is the follow-up integration; the primitive itself is ready.

Domain separation matters: every voucher / receipt / attestation kind the chain knows about uses a distinct domain tag (§17), so a signature from one context cannot be replayed under another.

9. Track A Reserve Mechanics (x/track_a)

Track A is described at high level in §5.1. This section covers the reserve-side mechanics that give the category its closed-loop discipline. Reserve accounting and per-day pool selection live in x/track_a; daily orchestration lives in x/distro.

9.1 Reserve Ceiling

Track A is bounded by the 150,000,000 SOVR Bootstrap Rewards Reserve. The reserve is held as unminted capacity inside the 1 B cap; tokens migrate from Latent into Locked at the moment Track A pays out, never before. When the reserve has been emitted in full, Track A as a category closes — no further Track A issuance occurs regardless of fleet size, attesting %, or service demand.

This makes Track A a bootstrap mechanism in the literal sense: it is sized to subsidize early-network operators while service demand and Track B’s usage-linked emission ramp up, then steps out of the way.

9.2 Eligibility and Inactivity

A node qualifies for Track A only when it is active, registered against an infrastructure module, and producing attested work. A node with no attestation in the relevant rolling window does not draw Track A. This protects the reserve against passive ownership: a license that buys in and never hosts does not consume the reserve.

9.3 Cohort Sizing

The Track A daily pool is not a fixed daily amount. It is sized against the fleet’s recent verified-work attestation profile, so a network where most licenses are working draws more from the reserve than a network where most licenses are idle. Per-cohort distribution applies a per-node cap to bound variance — a single concentrated operator cannot consume a disproportionate slice of any one day’s pool.

The exact cohort-sizing schedule, per-node cap multiplier, and rolling-window length are protocol parameters tuned through governance and described in x/track_a module documentation. They are not pinned in this whitepaper because they may be adjusted as the network observes real fleet behavior in the bootstrap window.

9.4 Compliance Framing

Track A is not a loan, debt instrument, repayment obligation, yield product, or guaranteed return. The reserve is a fixed capacity of SOVR earmarked for work-contingent issuance to early operators. No SOVR is owed to any holder; issuance occurs only on verified work; the reserve cannot be drawn by any party other than active+attesting operators through protocol mechanics.

10. Node Revenue Match Reserve (x/bootstrap)

Independent of Track A and Track B, a separate Node Revenue Match Reserve holds 10,000,000 SOVR as a cold-start matching mechanism that may supplement verified node-directed revenue while service demand forms. The confirmed match concept is 2.5×. Detailed cadence, tapering, eligibility, and sunset rules are pending policy and technical validation; what is fixed is the reserve size, the match multiple, and the constraint that this is not company revenue and is minted only under program rules.

The reserve is unminted at genesis and migrates into the Locked state via the bucket-aware IssueFromBucketToLocked(node_revenue_match, ...) path only when match conditions fire; the matched amount is then credited to the operator’s settlement-layer locked ledger and follows the standard lock-claim discipline (§7) — node-revenue match payouts vest exactly the way other operator rewards do, rather than landing as immediately-spendable Claimed. The pool halts on exhaustion: 10 M is what’s available, with no top-up mechanism, and the bucket-aware draw guarantees the program cannot silently consume protocol_emissions capacity intended for Track B.

The remaining program-rule items are pending policy and technical validation prior to public release: the eligible-revenue definition (which on-chain or attested signal counts as “node-directed revenue”), the match cadence (per-block, daily flush, per-attested-receipt), the per-node and global per-epoch cap, any taper schedule across the program window, the sunset trigger (calendar date vs. exhaustion vs. governance vote), exhaustion behavior (program halt vs. tapered final payouts), the disposition of any unused reserve after sunset, and whether all match payouts uniformly follow the lock-claim flow or include a fast-path for some category. The launch defaults will be pinned in a follow-up before the program is enabled; until then the keeper is wired but the activation switch is off.

11. Oracle and Bootstrap Reference Price (x/oracle)

x/oracle provides USD/SOVR conversion for service-payment denoms that aren’t usovr and for the auction’s USD-equivalent pricing. The keeper ships fully implemented (median aggregator, variance circuit breaker, governance-gated feeder allowlist) but dormant at genesis: the feeder allowlist is empty. DAO governance installs feeders post-launch as market data and oracle infrastructure mature.

11.1 Bootstrap Reference Price

At genesis, SOVR may not have sufficient external market data to support a reliable external market price. During this early period, the protocol uses an internally approved Bootstrap Reference Price for limited protocol-accounting purposes — chiefly auction USD-equivalent quoting and any other launch mechanic that requires a USD anchor.

The Bootstrap Reference Price is an internal reference. It is:

not published in this whitepaper or in public marketing material;

not a guaranteed market price, redemption price, floor price, or representation of future value;

not a SOVR/USD exchange rate the protocol commits to maintaining;

a temporary protocol-accounting input intended to be retired as external market and feeder infrastructure matures.

When market data, liquidity, and oracle infrastructure mature, protocol pricing inputs transition toward external market references through the standard feeder onboarding path.

The Bootstrap Reference Price is held in x/oracle Params as BootstrapPriceUsdMicros (default 100_000 micros = $0.10 / SOVR). Updates are gated by MsgUpdateParams under the standard chain governance authority, with the proposal-vote-emit audit trail Cosmos x/gov provides natively — there is no separate admin override path. The keeper auto-prefers feeder medians once at least MinFeeders posts have arrived; until then it falls back to the reference price for callers (auction USD-equivalent quotes, future cross-denom service settlement). Governance retires the reference price by setting BootstrapPriceUsdMicros to zero (validation permits this) once feeders are stable.

11.2 Active Mode

Once feeders are installed, the keeper computes a median across live feeders and trips a circuit breaker if cross-feeder variance exceeds the configured threshold. A tripped breaker degrades downstream callers to the last-consensus anchor price rather than halting service.

Non-usovr service payments cannot be converted while the oracle is dormant. The launch posture closes the gap directly: x/payments rejects non-usovr service channels up front, and x/bridge fees are usovr-only — so the 50/25/25 settlement split applies uniformly to every settled service payment. Once feeders are installed and governance enables conversion, the service-channel denom restriction can be relaxed; until then non-usovr service activity is not supported as a launch-time bypass.

12. Payment Channels (x/payments)

x/payments implements the settlement rail every metered service shares. The hot path is off-chain voucher signing; the on-chain cost is one OpenChannel, zero or more FundChannel top-ups, and one CloseChannel. Voucher redemption is a single tx per redemption.

Channels carry a service_module field set at open time. A non-empty value (e.g. "x/storage", "x/gateway") opts the channel into settlement routing: the host’s SettledToB slice on finalize flows through x/settlement.Split rather than a direct host-paying transfer. Generic peer-to-peer channels with an empty service_module direct-refund as before.

Vouchers are domain-separated by use case:

sovr:retrieval-voucher:v1 — storage retrieval sessions

sovr:storage-voucher:v1 — storage deal commitments

sovr:gateway-bytes-voucher:v1 — byte-metered gateway sessions (CDN, VPN)

sovr:gateway-request-voucher:v1 — request-metered gateway sessions (HTTP 402)

sovr:gateway-evidence:v1 — counter-observation evidence in disputes

sovr:bandwidth-voucher:v1 — WireGuard byte sessions

sovr:inference-voucher:v1 / sovr:embedding-voucher:v1 — GPU sessions

sovr:vectordb-voucher:v1 — vectordb storage + query sessions

Channel state is authoritative on-chain. Vouchers carry strictly monotonic nonces; a host that presents an out-of-order voucher is rejected. Double-spending is impossible because the channel’s redeemed balance advances monotonically with every successful redemption.

13. Infrastructure Markets

Storage was the oldest of SOVR’s infrastructure markets and the pattern every market that followed was modeled on. The five markets — storage, gateway, bandwidth, inference, vectordb — share one settlement primitive (x/payments channels redeemed through x/settlement.Split), one slash primitive (stake × bps, BurnCoins, jail below MinHostStake, forfeit re-emission to latent), and one host-registration shape (license-gated via x/nodelicense.HasActiveLicense).

13.1 Storage (x/storage)

The question x/storage answers: how does a client pay random strangers to hold their bytes and prove they still have them? The answer is a triangle of commitments — a deal on chain, escrowed payment in a payment channel, and periodic challenges the host must answer with a cryptographic proof. Fail a proof, lose stake. Fulfill it, drain escrow.

Two deal tiers:

• Tier
• Availability
• Retrieval latency
• Challenge cadence
• Best for
• Hot
• 24/7
• ms–s
• Short window
• Application state, hot datasets
• Cold
• Periodic
• minutes
• Long window
• Archives, backups, cold video data

Deal tier is fixed at creation; switching tiers requires terminating the deal and creating a new one. Pricing parameters per tier are separate TierParams records in module state, adjustable by governance.

Lifecycle: host registers (MsgRegisterHost, license + stake + endpoint + supported tiers), client creates a deal (MsgCreateStorageDeal, escrows upfront), keeper deterministically allocates shards across registered hosts, chain emits PoR-style challenges on cadence, hosts submit proofs within a deadline window. Successful proofs release escrow; missed proofs trigger slashing. Retrievals open a session under the deal, stream bytes via the signed-voucher protocol, and the host redeems the final voucher on close. Escrow drain and deal state are atomic — a failed submit leaves the cumulative-paid counter untouched.

13.2 Gateway (x/gateway)

x/gateway is one module that handles the entire class of metered delivery with per-request counters, parameterized by meter mode:

Meter mode

Unit

Domain

Example services

BYTES

bytes

sovr:gateway-bytes-voucher:v1

VPN, CDN, DNS-over-HTTPS, WebSocket relay

REQUESTS

requests

sovr:gateway-request-voucher:v1

HTTP 402, per-API-call pricing

Both modes share the same session + channel + voucher lifecycle; only the unit conversion and settlement payload differ. Sessions lock a price rate at open time so the payload shape stays fixed (sessionID, channelID, nonce, paidUsovr as 4 × uint64 big-endian, cross-language testable).

A stake-backed dispute primitive lives in the module: either party posts a dispute bond in SOVR, posts a counter-observation receipt under sovr:gateway-evidence:v1, and the keeper computes the signed delta between claims against a tunable tolerance band. Within tolerance, the dispute closes in the host’s favor (capped at MaxDisputeSlashBps, default 5 %). Outside tolerance, the lying side is slashed up to that cap. Slashed stake is re-emitted through the same forfeit path as operator rewards.

13.3 Bandwidth (x/bandwidth)

x/bandwidth is the dedicated WireGuard module. The framing is chain-as-coordination-server: every public key needed to bring up a tunnel lives on chain, so there is no off-chain key exchange and a host never accepts traffic from a peer whose identity is not chain-verified.

Field (chain-recorded)

Source

Host WireGuard endpoint

MsgRegisterBandwidthHost (host:port or [IPv6]:port)

Host WireGuard pubkey

MsgRegisterBandwidthHost (44-char base64, 32 bytes)

Client WireGuard pubkey

MsgCreateBandwidthSession

Per-GiB rate (rate_per_gib_usovr)

Host registration, locked at session creation

Billing uses a 4 × uint64 voucher (session_id, peer_id, bytes_consumed, paid_usovr, 32 B) under sovr:bandwidth-voucher:v1. Both sides independently verify bytes_consumed from their own WireGuard transfer_rx / transfer_tx counters — counters converge by design, so the voucher is a direct reconciliation, not an approximation. Replay protection is strict monotonicity on bytes_consumed. Pricing is (bytes × rate_per_gib) >> 30 with overflow-safe hi/lo split arithmetic; cross-language signers must match the floor-division semantics exactly.

peer_id is == session_id in v1; the separate field exists so future multi-peer-per-session extensions (proposal 005 edge CDN, proposal 007 mixnet) compose on top without a voucher-format change.

13.4 Inference + Embedding (x/inference)

x/inference is the marketplace for any GPU-hosted model workload. Two voucher shapes share one module because LLM inference and embedding generation share operator decisions and hardware profile (GPU memory + compute):

• Mode
• Voucher
• Fields
• INFERENCE
• sovr:inference-voucher:v1 (40 B)
• (session_id, model_id, input_tokens, output_tokens, paid_usovr)
• EMBEDDING
• sovr:embedding-voucher:v1 (32 B)
• (session_id, model_id, input_tokens, paid_usovr)

There is deliberately no GPU tier enum on chain. Hardware ages out of any fixed ladder within a release cycle, and unified-memory designs (Apple Silicon, AMD MI, Groq, TPUs) collapse the “memory vs compute” axes a tier tries to express. Hosts instead:

• Register against the permissionless on-chain model registry (sequence-assigned model_id, name unique on first registration);
• Publish a per-model rate schedule (input-per-1K usovr, output-per-1K usovr);
• Submit host-signed benchmarks (sovr:inference-benchmark:v1, 48 B) recording measured tokens-per-second, p50 latency, precision, and batch size at a declared block height.

Clients rank hosts off chain by whatever benchmark dimensions they care about — throughput vs latency, precision vs cost. The chain stores the signed measurement; it deliberately does not impose a ranking function. Phase-2 benchmarks are host-signed only (non-repudiation without truthfulness); the MsgDisputeBenchmark handler body lands with the sidecar PR that pins the client-observation domain.

13.5 Vector Database (x/vectordb)

x/vectordb is the index + ANN query service that pairs with x/inference for RAG workloads. Different hardware profile — vectordb wants CPU + RAM + SSD, not GPU — so hosts are typically distinct operators. The chain owns Collection records as first-class entities (clients don’t just rent black-box namespaces on a host):

Field

Locked at

Notes

owner

creation

Client address; only owner opens sessions against the collection

host

creation

The host serving this collection’s index

name

creation

Free-form; (owner, host, name) unique over ACTIVE collections

dimension

creation

Bounded by MaxVectorDimension (16 384)

metric

creation

Cosine / dot product / Euclidean

Billing is a single voucher (sovr:vectordb-voucher:v1, 40 B) with two meters:

vector_blocks accumulates vectors_stored × blocks_elapsed — storage-over-time

queries — cumulative ANN query count

paid_usovr = vector_blocks × rate_per_block + (queries × rate_per_1k) / 1000

Two meters because write-heavy and read-heavy workloads have decoupled cost profiles. Rates lock at session creation; a host rate change applies only to sessions opened afterwards. Closing a collection frees the (owner, host, name) triple for re-use; closed collections are retained for history.

14. Identity (x/identity)

Operators, services, and their clients often need a portable record of reputation and claims that is not bound to a specific wallet. A storage host signing retrieval vouchers today and a GPU operator publishing benchmarks next quarter may both rotate their wallet keys without losing the verifications they accumulated; a subscribing client may want a verification from one identity provider to unlock tier-1 access at ten different domain operators without re-onboarding each time. x/identity provides that record — one per sovr_id, distinct from any wallet address.

Registration takes a refundable deposit rather than a one-time fee. Default is 50 SOVR (DefaultRegistrationDepositUsovr = 50_000_000). The deposit is held in escrow for the lifetime of the identity, refunded on retirement, and slashable on misbehavior (chain-wide revocation, fraud finding, etc.). This replaces v4.0’s burn-or-treasury fee model: the chain holds skin-in-the-game rather than collecting a flat tax up front.

Record

Purpose

Identity

sovr_id (auto-assigned), current pubkey, owner address, display name, capabilities

Verification

Third-party claim: (sovr_id, verifier, kind) with verified_at / revoked_at heights

Reputation

Per-identity signal log with FIFO eviction; consumers compute their own scores

Revocation

Chain-wide ban record issued by a governance-allowlisted revoker

The critical property is key rotation without hijack. A compromised owner wallet cannot silently rotate an identity to attacker-controlled keys: MsgRotateIdentityKey requires the outer transaction to be signed by the owner and carries an inner signature produced by the current identity pubkey over the sovr:identity-rotate:v1 preimage (big-endian sovr_id concatenated with the new pubkey bytes). The chain rejects any rotation where the inner signature doesn’t verify.

Verifiers must be on the governance-maintained allowlist at the time of the claim and at the time of an IsVerifiedBy query. Governance can therefore de-authorize a verifier retroactively, invalidating all their prior claims from the downstream consumer’s perspective without touching the claim rows themselves.

Revocation is chain-wide and distinct from per-provider blocking (which lives in x/policy). A chain-wide revocation is reserved for terminally compromised identities; provider-scoped blocking handles the far more common case of “this identity misbehaved on my service.”

15. Policy (x/policy)

Any operator — a storage host exposing a retrieval API, a CDN edge, a SaaS company running its own infrastructure — eventually needs to tier pricing, throttle abusive traffic, and enforce payment. x/policy holds that per-provider configuration on chain so it can be queried and cached by any edge middleware. The two reference use cases baked into the module are HTTP 402 micropayments and reverse bot management (throttling unpaid traffic while prioritizing paying requesters — whether those requesters are human subscribers, enterprise integrations, or automated clients).

Like x/identity, provider registration takes a refundable deposit (default 100 SOVR). The deposit is slashable on policy abuse and refunded on retirement.

One ProviderPolicy per domain, owned by an admin address:

• PricingRules — default price (usovr per request) plus per-path-prefix overrides, plus decimal-string tier multipliers.
• TierRules — ordered list of TierCriterion matchers; first match wins; falls back to DefaultTier.
• TierMatcher — discriminated union: always / has-payment-proof / has-active-verification-from / fingerprint-class / reputation-at-least.
• RateLimits — per-tier token-bucket config.
• TrustedIdentityProducts — the subset of x/identity verifiers this provider honors.
• Subscriptions — per-sovr_id access passes with optional expiry.
• Revocations — per-provider denylist, keyed by sovr_id or raw pubkey.

Edge middleware caches policies (5 min TTL by default), evaluates criteria locally against each incoming request, and only makes chain calls to refresh cache or check revocations. There is no per-request on-chain query on the hot path.

The inversion. Reverse bot management inverts the traditional posture. Instead of “block bots, serve humans,” any requester presenting payment proof gets premium tier access while unpaid traffic hits the free tier with rate limits. x/policy expresses this as data: a provider’s TierRules can trivially put has-payment-proof first and fingerprint-class=browser second, sending paying clients — whatever their client stack — ahead of anonymous browsers. The policy module makes no assumptions about why a requester is paying; the tier rules just measure whether they are.

Each ProviderPolicy carries an optional contract_address field. The v1 chain stores and echoes this field but does not dispatch to it. Edge middleware that opts into contract-driven evaluation can query that contract for richer pricing logic (surge pricing, custom rule engines) — a future extension that does not require a chain upgrade to adopt.

16. Bridge to EVM compatible chain (x/bridge) and IBC

SOVR is bridgeable to an EVM-compatible chain (initial targets: Ethereum mainnet and Base) as an ERC-20 via a lock-and-mint design. On the SOVR side, x/bridge holds locked SOVR in a module account; on the EVM side, a set of relayers signs mint / burn messages against a deployed SOVR ERC-20 contract. The chain ID of the EVM counterparty is a governance-tunable parameter (EthereumChainId), so the bridge module is not hard-tied to any single network.

Decimal conversion: SOVR is 6-decimal on-chain (usovr), 18-decimal on the EVM side. The bridge applies a 10^12 scale factor in both directions; sub-10^12 wei amounts are rejected to prevent slow-drain rounding attacks.

Relayer quorum: multiple relayers sign each direction's confirmation message; the contracts enforce a configurable quorum threshold so a single compromised relayer cannot drain the bridge. The relayer daemon (bridge/relayerd/) defaults to SIGNER_MODE=validator and refuses to start without explicit configuration.

v5.0 settlement integration: bridge fees route through x/settlement.Split, applying the 50/25/25 economics to cross-chain transfers — a portion of every bridge operation is burned back to latent rather than retained as bridge revenue.

Mainnet hardening for the bridge is tracked in x/bridge/TODO.md; the current testnet configuration uses a lower quorum than mainnet will. Multi-relayer quorum hardening is the highest-priority mainnet blocker.

x/bridge is complementary to IBC. SOVR ships IBC-Go v10 enabled, with transfer and Interchain Accounts modules wired in. Any IBC-compliant Cosmos chain can open channels to SOVR; outbound channels to Cosmos Hub, Osmosis, Noble, and Celestia are the expected first connections. Use IBC for Cosmos-native flows (stablecoins from Noble, LPs on Osmosis); use the bridge for EVM-world flows.

17. Signing Domains

Every cryptographic operation the chain validates uses a domain-separated preimage. The canonical domain strings are frozen in both the chain module (authoritative source) and the sovr-sdk/signing package that non-Go consumers compile against; drift between them is a hard-forking bug.

• Domain
• Binds
• Consumer
• sovr:retrieval-voucher:v1
• (session_id, channel_id, nonce, paid_usovr)
• x/storage retrieval
• sovr:storage-voucher:v1
• (deal_id, storage_bytes, duration_blocks, quoted_price_usovr)
• x/storage deal commitment
• sovr:receipt:v1
• (metrics, unix_timestamp)
• x/attestation
• sovr:gateway-bytes-voucher:v1
• (session_id, channel_id, nonce, paid_usovr)
• x/gateway byte sessions
• sovr:gateway-request-voucher:v1
• (session_id, channel_id, request_nonce, paid_usovr)
• x/gateway request sessions
• sovr:gateway-evidence:v1
• (session_id, role, observed_units, observed_at_block)
• x/gateway disputes
• sovr:identity-rotate:v1
• (sovr_id, new_pubkey)
• x/identity key rotation
• sovr:bandwidth-voucher:v1
• (session_id, peer_id, bytes_consumed, paid_usovr)
• x/bandwidth WG sessions
• sovr:inference-voucher:v1
• (session_id, model_id, input_tokens, output_tokens, paid_usovr)
• x/inference INFERENCE sessions
• sovr:embedding-voucher:v1
• (session_id, model_id, input_tokens, paid_usovr)
• x/inference EMBEDDING sessions
• sovr:inference-benchmark:v1
• (model_id, tokens_per_sec, p50_latency_ms, fp_precision, batch, measured_at)
• x/inference benchmark attestations
• sovr:vectordb-voucher:v1
• (session_id, collection_id, vector_blocks, queries, paid_usovr)
• x/vectordb sessions

All payloads are big-endian for integer fields, no length prefix for variable-length bytes. Cross-language conformance vectors are committed in sovr-sdk/vectors/ and a conformance script exercises the Go, TypeScript, and PHP implementations against the same JSON fixtures.

17.1 Crypto-Agility, Not PQC

SOVR uses classical signatures everywhere signatures appear: secp256k1 for account addresses, voucher signing, identity-rotation, and bridge relayer confirmations; ed25519 for CometBFT consensus keys. No post-quantum signature scheme is active today, and no migration is scheduled.

What has shipped is crypto-agility. The April 2026 audit (PR #86) rewrote misleading comments in x/attestation/keeper/receipt.go that claimed signatures must be secp256k1 — they must match the account’s registered pubkey, whatever type it is — and added x/payments/keeper/crypto_agility_test.go exercising the full payment-channel lifecycle with a mock 128-byte signature and a 48-byte “PQC-style” pubkey. Every verification path accepts non-standard sizes through the Cosmos SDK’s cryptotypes.PubKey interface.

The narrow claim this lets us make: when a PQC signature scheme is ready to ship, adding it is a chain upgrade that registers the new key type with the SDK, not a redesign of verification logic. The claim it does not let us make: that we have a production PQC scheme today. Library maturity, upstream Cosmos SDK / CometBFT consensus-layer work, and governance sequencing are all ahead of us.

Operators signing commitments that must remain unforgeable in the 2035+ regime should not rely on secp256k1 alone today. For the current threat environment, classical signatures are sufficient.

18. SDK (sovr-sdk)

Consumer code talks to SOVR through the sovr-sdk repo — a multi-module workspace with independent version tags per submodule.

Submodule

Purpose

signing

secp256k1 + ed25519 primitives, domain-separated preimage helpers, cross-language

txclient

Lightweight Cosmos tx builder + broadcaster

channels

Payment-channel + session state machine, voucher signing

identity

Type mirrors + rotate helpers + ChainQueryClient interface for x/identity

policy

Type mirrors + reference tier/pricing evaluator + cache client + fingerprint classifier for x/policy

Go is the canonical implementation. TypeScript and PHP bindings exist for every domain that a non-Go consumer already needs (all signing domains; identity + policy helpers used by edge middleware and frontends). New capabilities follow the same multi-language-when-needed pattern.

19. Security Model

Consensus integrity. CometBFT BFT tolerates up to 1/3 Byzantine voting power. Double-sign is slashable; extended downtime triggers jail (signed_blocks_window, min_signed_per_window, downtime_jail_duration in consensus params). Standard Cosmos 21-day unbonding prevents long-range equivocation.

Closed-loop supply integrity. The 1 B-SOVR cap is a state invariant, not a print-time check. Every transition routes through x/supply.Move, which refuses any operation that would break latent + locked + vesting + claimed == 1B. There is no path through the chain — emission, settlement, burn, slash, or forfeit — that mints a token outside the loop.

Economic security. Lock-claim with node idle and emergency-claim forfeit-to-latent couples operator behavior to long-run participation: quick exits are economically costly, and the cost funds future emission. Sybil licenses earn nothing from idle nodes because reward weight is attestation-score driven, not stake- or count-driven.

Signature replay resistance. Every signed payload the chain validates is prefixed with a domain tag. Cross-domain replay (e.g., presenting a storage retrieval voucher as a gateway request voucher) is structurally impossible because the preimages differ by the domain prefix even when the payload bytes are identical. Covered by canary tests on every binding.

Identity hijack resistance. The sovr:identity-rotate:v1 preimage binds the signature to both sovr_id and the new pubkey. A signature captured for rotating identity A to key X cannot be replayed to rotate identity B, nor to rotate A to an attacker-chosen key Y.

Bridge safety. Quorum-based relayer confirmations on both sides; no single relayer can authorize a mint or unlock. Mainnet-readiness tracking in x/bridge/TODO.md. Bridge fees route through x/settlement.Split so a successful bridge raid does not retain proceeds — half of the take burns back to latent.

Dispute bonds. Metered-delivery disputes require a posted bond in SOVR, slashed on loss, capped at MaxDisputeSlashBps so a bad-faith claimant cannot ruin a legitimate counterparty. The bond escrow + settlement mechanics live in the shared x/disputebonds module: 100 SOVR per side at default, with a 50 / 50 split on a forfeited bond between the winner and the latent pool (ForfeitToLatentBps = 5000). Every service module’s dispute path (x/gateway, x/bandwidth, x/inference, x/vectordb, x/storage) and the x/attestation fraud-challenge path call into the same primitive — the chain has one bond + slash mechanism, not five.

ForfeitToLatentBps is governance-tunable, in contrast to the immutable 50/25/25 settlement split. Future tightening — e.g. raising the latent share to reduce litigant incentive, or lowering it to align with restitution-style outcomes — is a parameter change, not a chain upgrade.

20. Governance

Governance distinguishes protocol-level authority from company-level authority. Node ownership and SOVR token ownership grant participation in protocol parameters where expressly permitted; they do not imply corporate governance rights.

Area

Authority

Boundary

Token max supply

Protocol fixed cap

No mechanism may increase the 1 B cap.

Settlement split

Hard-coded 50/25/25 + 40/40/10/10

Protocol-immutable; x/settlement Validate() rejects any deviation. Only target addresses are governance-tunable.

Track A reserve ceiling

Hard-capped at 150 M SOVR

Governance may lower the reserve (early sunset) but cannot raise it; x/track_a Validate() rejects values above the protocol cap.

Governance attestation cap

Hard-coded at 2 % of fleet

Protocol constant GovernanceCapBps = 200, not gov-mutable.

Module parameters

Protocol governance

Standard Cosmos x/gov proposal/vote cycle, subject to module-level Validate() guards.

Reward weights

Protocol governance

Must remain within reserve and emission constraints.

Company allocation

Hard-coded 40/40/10/10 split

Protocol enforces the routing; deployment mandates remain with the company.

DAO Treasury

Standard x/gov-controlled module account at launch

Receives the 10 % company sub-split. Pre-DAO-maturity controls: deployments are subject to the standard x/gov proposal / vote / voting-period cycle; no separate timelock, emergency veto, or compliance override layer exists at launch. Phase 5 work pins the additional wrapper authority — a deployment timelock, an emergency-veto seat (compliance / legal / security), and a multisig keyset for routine operational draws — before the DAO Treasury becomes large enough to require them. The launch posture is intentionally conservative: until the DAO matures and the wrapper authority lands, the DAO Treasury is not expected to fund discretionary operational spend. Funding for emergency response and legal/compliance work routes through the standard company allocation paths during the pre-DAO-maturity window.

Corporate operations

Company

No protocol governance control over hiring, roadmap, partnerships, treasury management, or corporate decisions.

Standard Cosmos x/gov mechanics — text, parameter change, software upgrade, and community-pool-spend proposals — drive protocol-parameter governance. The surface includes:

x/distro reward-track parameters, schedule cadence (no validator-floor at launch; floor emission is dormant by default)

x/track_a daily-pool tier amounts, tier breakpoints, per-node cohort cap, eligibility thresholds. Reserve sizing may only be lowered, not raised, above the 150 M protocol cap (enforced by Validate()). Lowering the reserve is a sunset action, not an instantaneous parameter flip: a sunset proposal is subject to the standard x/gov proposal/vote/timelock cycle, and operator-facing notice should accompany any reduction so active-attesting nodes can plan against the program’s revised end state. The chain does not unilaterally reduce earned but unclaimed Track A — only future emission capacity — so already-locked operator balances are unaffected.

x/bootstrap Node Revenue Match parameters (cadence, eligibility, sunset)

x/opt_exchange allowlist, exchange rate, exchange-window timing

x/lockup vesting duration, claim mechanics, forfeit handling

x/settlement target addresses only — the 50/25/25 burn/operator/company split and 40/40/10/10 company sub-split are protocol-immutable and any MsgUpdateParams attempting to change them is rejected at Validate()

x/auction per-tranche price ladder, per-wallet cap, Dutch duration, activation-bond bps, T01 allowlist, MsgForceCloseTranche for stalled tranches

x/oracle feeder set, TWAP window, variance threshold, min feeders, Bootstrap Reference Price

x/nodelicense activation delay, transfer lockup, max licenses

x/gateway / x/bandwidth / x/inference / x/vectordb / x/storage per-market parameters (min stake, slash fractions, dispute tolerance, etc.)

x/identity verifier allowlist, revoker allowlist, registration deposit

x/policy module caps, registration deposit

x/disputebonds bond per side, forfeit-to-latent fraction

Standard Cosmos params (consensus, bank, staking, etc.)

Voting is attestation-weighted by default, not stake-weighted. The custom GovTallyFn in app/gov_tally.go replaces the SDK’s token-weighted tally with one that (a) requires every voter to hold at least one active staking delegation as a bonded-SOVR participation gate, and (b) weights each ballot by x/attestation.GovernanceWeight(voter), which returns the operator’s rolling attestation score capped at 2 % of fleet-wide total. The 2 % cap is a protocol constant (GovernanceCapBps = 200), not gov-mutable, so a single megafleet operator cannot dominate governance even if they accumulate disproportionate attestation.

A practical consequence: passive token holders with no infrastructure work do not vote. The chain treats governance authority as a function of contributing to the network being governed, gated by a bonded-SOVR proof-of-skin-in-the-game. Token-weighted tally is the legacy SDK behavior and is overridden at app wiring time; non-attesting bonded holders see their ballots silently dropped from the tally.

Unbonding delegations retain participation eligibility during the unbonding window; no quadratic / conviction variants in v1.

21. Roadmap

• Phase
• Scope
• Status
• 1 — Foundation
• Chain binary + foundational modules. Consensus, storage market, payment channels, cross-chain bridge, license-gated operator entry.
• Shipped
• 2 — Infrastructure Markets
• x/gateway, x/bandwidth, x/inference, x/vectordb + agent-side primitives x/identity and x/policy. Every market uses the same settlement + slash + reserved-dispute shape. Multi-language SDK (sovr-sdk) v1.0 consolidating signing, txclient, channels, identity, policy.
• Shipped
• 3 — Tokenomics Rework
• IOPT removal, single-token model, five-state supply machine, Track A / Track B reward architecture, Burn-and-Recycle Protocol, settlement pool with 50/25/25 split and pro-rata operator distribution, Dutch-auction node licensing with reserved-access seed, 30-day lock-claim with node idle, attestation fraud-challenge primitive, shared dispute-bond module, governance-weight cap.
• Shipped
• 4 — Sidecars + Enforcement
• Per-market daemons: sovr-bandwidth (WireGuard peer lifecycle), sovr-inference (model-server proxy + token counting), sovr-vectordb (LanceDB / Qdrant wrapper), sovr-rpc (future). Each pins its client-observation signing domain so the reserved phase-3 dispute handlers (ErrDisputeNotEnabled today) get wired to the live slash plumbing. Reference nginx/openresty middleware consuming the x/policy tier evaluator. Oracle feeder onboarding.
• Converging
• 5 — Mainnet
• Bridge multi-relayer quorum hardening and key-rotation runbook. Release-bundle tooling (make release-bundle, CI checksums, K8s configmap replaced from placeholders). Sentry-topology rehearsal on a hardening testnet. Remediation runbooks for validator jailing, sync stall, key rotation. Voting periods tightened, testnet-only parameters stripped from production paths.
• Pre-launch
• 6 — Expansion
• Service proposals not built in phase 2: 003 compute hosting, 005 edge CDN (extends x/bandwidth), 007 mixnet, 009 RPC market. Contract-driven policy evaluation via the reserved x/policy.contract_address dispatch path. Subscription UX in wallets. Attestation dashboards in the operator portal. DAO Treasury timelock + emergency-veto + multisig hardening.
• Planned

Every entry in phase 4 has a ready-to-consume chain API today. The chain did not wait for sidecars; it pinned the settlement shapes, reserved the dispute messages, and ships live slash plumbing tested against a bench harness. Phase 4 is the sidecars taking up the interface the chain already exposes, not a mutual design negotiation that could slip the chain.

22. Conclusion

SOVR is a pragmatic design. It does not pretend that every useful thing should be a gas-paid on-chain call, and it does not pretend that off-chain work can be rewarded without cryptographic proof. Infrastructure is chain-native in the sense that matters — provider registration, challenge / attestation verification, settlement, and slashing all live in protocol — while usage itself happens off-chain and is settled in bounded on-chain batches via domain-separated signed vouchers.

The token model under v5.0 is uniformly pragmatic. SOVR does the work of both store-of-value and utility token because the closed-loop supply machine and the work-contingent reward tracks keep monetary discipline without needing a second token to absorb micropayment churn. Every settled coin has 50 % return to Latent under the Burn-and-Recycle Protocol — float-constrictive but not deflationary. Operator rewards are earned through verified work across two tracks (Track A Bootstrap Rewards, Track B Usage Rewards), with no debt, no repayment, and no guaranteed return. The fleet-wide 25 % operator pool replaces the older “host who served the voucher gets paid” accounting with one that rewards sustained network participation rather than redemption timing.

The chain ships with twenty-one first-party modules including the cross-chain bridge, a multi-language SDK, IBC interoperability, and a reward architecture that ties issuance to verifiable infrastructure work. The infrastructure markets — storage, gateway, bandwidth, inference, vectordb — share one settlement primitive (x/payments channels redeemed through x/settlement.Split), one bond primitive (x/disputebonds), and one slash primitive. Everything in this document maps to code; every signing domain has a canary test; every module has unit, property, atomicity, and adversarial tests across its Go implementation.

The hard part of a public network launch is not inventing new cryptography. It is honestly describing the economic primitive the chain is meant to serve, then making sure the code matches the description. This whitepaper is intended as the reference for that match.

Appendix A — Module Quick Reference

Cosmos SDK error codes are namespaced by module name, not globally, so the numeric codes below are module-local. Full tables live in x/<module>/types/errors.go.

Module

Key proto

Key messages

x/supply

sovr.supply.v1

MsgUpdateParams

x/distro

sovr.distro.v1

MsgUpdateParams

x/lockup

sovr.lockup.v1

MsgUpdateParams, MsgCreateVestingPosition, MsgClaimVested

x/attestation

sovr.attestation.v1

MsgUpdateParams, MsgSubmitReceipt, MsgChallengeReceipt

x/oracle

sovr.oracle.v1

MsgUpdateParams, MsgAddFeeder, MsgPostPrice

x/settlement

sovr.settlement.v1

MsgUpdateParams

x/track_a

sovr.track_a.v1

MsgUpdateParams

x/auction

sovr.auction.v1

MsgUpdateParams, MsgSetT01Allowlist, MsgOpenTranche, MsgForceCloseTranche, MsgPlaceBid

x/bootstrap

sovr.bootstrap.v1

MsgUpdateParams

x/opt_exchange

sovr.opt_exchange.v1

MsgUpdateParams

x/disputebonds

sovr.disputebonds.v1

MsgUpdateParams

x/nodelicense

sovr.nodelicense.v1

MsgPurchaseLicense (legacy, disabled), MsgActivateLicense, MsgTransferLicense, MsgDeactivateLicense

x/bridge

sovr.bridge.v1

MsgLockSovr, MsgConfirmLock, MsgConfirmUnlock, MsgWithdrawBridgeFees

x/payments

sovr.payments.v1

MsgOpenChannel, MsgFundChannel, MsgRedeemVoucher, MsgCloseChannel

x/storage

sovr.storage.v1

MsgRegisterHost, MsgCreateStorageDeal, MsgSubmitStorageProof, MsgTerminateDeal

x/gateway

sovr.gateway.v1

MsgRegisterGatewayHost, MsgOpenSession, MsgRedeemVoucher, MsgOpenDispute, MsgSubmitEvidence, MsgResolveDispute

x/bandwidth

sovr.bandwidth.v1

MsgRegisterBandwidthHost, MsgCreateBandwidthSession, MsgRedeemBandwidthVoucher, MsgDisputeBandwidthSession

x/inference

sovr.inference.v1

MsgRegisterModel, MsgRegisterInferenceHost, MsgCreateInferenceSession, MsgRedeemInferenceVoucher, MsgRedeemEmbeddingVoucher, MsgSubmitBenchmark, MsgDisputeBenchmark

x/vectordb

sovr.vectordb.v1

MsgRegisterVectordbHost, MsgCreateCollection, MsgCreateVectordbSession, MsgRedeemVectordbVoucher, MsgDisputeVectordbSession

x/identity

sovr.identity.v1

MsgRegisterIdentity, MsgRotateIdentityKey, MsgUpsertVerification, MsgAttestReputation, MsgRevoke

x/policy

sovr.policy.v1

MsgRegisterProvider, MsgUpdateProviderPolicy, MsgRevokeRequester, MsgGrantSubscription

Appendix B — Key Parameters at Mainnet Default

Parameter

Module

Default

Note

Block time (target)

consensus

~13.5 s

Targeted block cadence on testnet

Hard cap

x/supply

1,000,000,000 SOVR

Closed-loop invariant; latent + locked + vesting + claimed always equals cap

Initial minted supply

genesis

60,000,000 SOVR

50 M Liquidity Pool Reserve + 10 M Service Liquidity Reserve (multisig)

Settlement split

x/settlement

50 / 25 / 25

Burn-and-Recycle to Latent / fleet-wide operator pool / company

Company sub-split

x/settlement

40 / 40 / 10 / 10

Infrastructure / Ecosystem / DAO Treasury / Staking Pool

Vesting duration

x/lockup

30 days

Linear drip from claim initiation to fully Claimed

Initial-claimable fraction

x/lockup

0 %

v5.0 has no instant-claim portion

Bootstrap Rewards Reserve

x/track_a

150,000,000 SOVR

Track A category lifetime ceiling; not minted upfront; immutable upper bound

Track A daily-pool tier amounts

x/track_a

50k / 120k / 190k / 260k SOVR

Tier 0 / 1 / 2 / 3 daily pool sizes

Track A daily-pool tier breakpoints

x/track_a

25 % / 50 % / 75 %

Fleet-attestation thresholds selecting the day’s pool size

Track A attesting-share window

x/track_a

7 days

Rolling window for tier selection

Track A per-node cap multiplier

x/track_a

10×

Per-node cap = multiplier × cohort average

Track A attestation score window

x/attestation

30 days

Rolling weighted score driving pro-rata distribution

Track B k

x/distro

1 bps

Track B formula coefficient against AttestedWorkValue

Track B daily cap (TrackBDailyCapUsovr)

x/distro

50,000 SOVR/day

Baseline cap multiplied by phase multiplier

Track B Bootstrap phase

x/distro

Months 1–12, 2× cap

Phase 1 emission window

Track B Scaling phase

x/distro

Months 13–36, 5× cap

Phase 2 emission window

Track B Mature phase

x/distro

Month 37+, 5× cap

Inherits Scaling cap

Burn-parity threshold

x/distro

60 %

Trailing burns ÷ trailing emissions to reach BurnParityFactor = 1.0

Burn-parity trailing window

x/distro

30 days

Used by BurnParityFactor calculation

OPT Exchange Reserve

x/opt_exchange

50,000,000 SOVR

Reserved for future protocol-level OPT-to-SOVR exchange; not minted upfront

Node Revenue Match Reserve

x/bootstrap

10,000,000 SOVR

Cold-start matching reserve; 2.5× concept; details TBD; not minted upfront

Auction tranche count

x/auction

10

T01–T10

Nodes per tranche

x/auction

1,000

10,000 fleet cap

Per-wallet primary cap

x/auction

200

Across the full primary market

Dutch decay duration

x/auction

72 hours

Linear opening-to-floor (T03–T10)

License transfer lockup

x/nodelicense

~12 months (~2.34 M blocks)

Anchored to PurchasedAt; self-transfers bypass

Identity registration deposit

x/identity

50 SOVR

Refundable on retire; slashable on misbehavior

Policy registration deposit

x/policy

100 SOVR

Refundable on retire; slashable on policy abuse

Dispute bond per side

x/disputebonds

100 SOVR

Pulled from each disputant on MsgOpenDispute

Forfeit-to-latent on resolved dispute

x/disputebonds

50 %

Loser bond split: half to winner, half back to Latent (governance-tunable)

Attestation fraud slash fraction

x/attestation

5 %

Applied on upheld MsgChallengeReceipt

Governance attestation cap

x/attestation

2 %

Protocol constant GovernanceCapBps = 200, not gov-mutable

Bootstrap Reference Price

x/oracle

$0.10 / SOVR

BootstrapPriceUsdMicros = 100_000; used until oracle feeders post

Min feeders for live oracle

x/oracle

3

Below this the Bootstrap Reference Price is the canonical USD/SOVR quote

TWAP window

x/oracle

900 s

Median aggregation window once feeders are live

Variance circuit-breaker threshold

x/oracle

500 bps

Cross-feeder spread tripping the circuit breaker

Service-channel denom

x/payments

usovr only at launch

Non-usovr service channels rejected at open + finalize

Unbonding period

x/staking

21 days

Standard Cosmos

Double-sign slash

x/slashing

5 %

Standard Cosmos

Voting period (testnet)

x/gov

5 minutes

Will be tightened on mainnet

SOVR denom

x/bank

usovr

6 decimals (1 SOVR = 1,000,000 usovr)

Address prefix

bech32

sovr

sovr1... accounts, sovrvaloper1... validators

Appendix C — Differences from v4.0

The v4.0 draft (April 2026) describes the chain as it stood before the v5.0 economic-model rewrite. The differences are economic, not just cosmetic; they cut across emission, settlement, the token model, and licensing.

• Single token, not dual. v4.0 ran a SOVR + IOPT economy with IOPT as the utility / micropayment denom. x/iopt is deleted in v5.0; SOVR is the sole unit of account. The 50 M SOVR that v4.0 had reserved for IOPT conversion is now reframed as the OPT Exchange Reserve under the v5.0 genesis allocation.
• Closed-loop supply. v4.0 talked about a 1 B hard cap that monotonically approached but never exceeded the ceiling. v5.0’s cap is enforced as a five-state invariant — latent + locked + vesting + claimed == 1B for all time — and “burns” are not destructions but transitions back to Latent. Tokens never leave the loop; they cycle through it.
• Redline genesis allocation. v4.0 had no formal genesis-allocation table; v5.0’s six-bucket model (730 M Latent / 150 M Bootstrap Rewards / 50 M OPT Exchange / 50 M Liquidity Pool / 10 M Service Liquidity / 10 M Node Revenue Match) is the canonical partition.
• Work-contingent two-track reward architecture. v4.0 emitted via continuous gradient decay against the cap with a 1-day epoch and a per-block 5-way split. v5.0 emits through two work-contingent tracks: Track A Bootstrap Rewards (sourced from the 150 M Bootstrap Rewards Reserve) and Track B Usage Rewards (gated by a burn-parity capacity rule). Neither track is a debt instrument or guaranteed return.
• Burn-and-Recycle Protocol. v4.0’s burn was framed as deflationary destruction. v5.0’s Burn-and-Recycle is non-terminal: burns return tokens to Latent rather than destroying them, so the supply effect is float-constrictive rather than deflationary. The 50 % burn slice on settled SOVR is not company revenue; it is future operator reward fuel.
• No validator-floor emission. v4.0 specified a guaranteed-issuance Floor as a parameter. v5.0 has no chain-level validator-floor emission; consensus participants earn through standard Cosmos staking rewards and their share of operator-pool drains. Earned-through-work is the only emission rule.
• Fleet-wide operator pool. v4.0 paid the host that served a redeemed voucher directly. v5.0 splits every settled SOVR 50/25/25 (Burn-and-Recycle / fleet-wide operator pool / company) and the operator slice drains pro-rata by attestation score.
• Lock-claim with node idle. v4.0 had 180-day vesting with a 5 % instant-claim portion and a forfeit pool that drip-re-emitted over a year. v5.0 has 30-day linear vesting, no instant claim, the originating node idles during its own vest window, and emergency-claim forfeits the unvested slice straight back to Latent.
• Dutch-auction primary market with reserved-access seed. v4.0 priced node licenses at a flat fee in IOPT. v5.0 mints licenses exclusively from x/auction across 10 sequential tranches × 1,000 NFTs. T01 is a $3,000 fixed-price Reserved Access tranche available to approved OPT holders under published rules; T02 is a $3,000 fixed-price Public Launch tranche; T03–T10 are 72-hour linear Dutch decay. 200-NFT per-wallet cap and 12-month transfer lockup apply across the ladder.
• Settlement-routed bridge fees. v4.0’s bridge collected fees as bridge revenue. v5.0 routes bridge fees through x/settlement.Split, applying the 50/25/25 economics to cross-chain transfers.
• Receipt fraud challenges and shared dispute bonds. v4.0 had no fraud-challenge primitive on attested receipts. v5.0 ships MsgChallengeReceipt with a 5 % fraudulent-receipt slash and a shared x/disputebonds module (100 SOVR per side, 50 / 50 forfeit-to-latent) that every service module’s dispute path consumes.
• Refundable deposits replace one-time fees. v4.0’s x/identity and x/policy charged registration fees that burned or routed to treasury. v5.0 takes refundable, slashable deposits instead — 50 SOVR (x/identity) and 100 SOVR (x/policy) — held in escrow for the lifetime of the registration.
• Attestation-weighted governance. v4.0 inherited the SDK default token-weighted tally. v5.0 ships a custom GovTallyFn that weights every ballot by x/attestation.GovernanceWeight(voter) (the operator’s rolling attestation score, capped at 2 % of fleet total as a non-mutable protocol constant), and gates participation on at least one active staking delegation. Token-weighted tally is overridden at app wiring time. v5.0 also formalizes the boundary between protocol-level governance (parameters, reward weights) and corporate authority (operations, treasury management, partnerships). Did not exist in v4.0.
• Rolling attestation window. v4.0-era chain code used a short rolling window; v5.0 uses a longer rolling window (specified by protocol parameters), making the operator-pool fan-out responsive to sustained delivery rather than instantaneous bursts.
• Bootstrap Reference Price replaces the v4.0 “fixed-table fallback” framing. x/oracle ships fully implemented but dormant at genesis; auction USD-equivalent quotes use an internal Bootstrap Reference Price during the early period, retiring as feeders and external market data mature. The Bootstrap Reference Price is not published, not a guaranteed market price, and not a redemption price.
• Compliance-safe terminology. v4.0’s text used “loan,” “payback,” “principal,” and “repayment” terms in the operator-reward section. v5.0 deprecates that language entirely. Track A is a work-contingent reward category, not a credit instrument. Any per-node lifetime ceiling on Track A issuance lives in protocol parameters; it is not framed as a guaranteed return or a return obligation, and any specific multiplier remains an internal protocol-parameter detail subject to legal review.
• New modules: x/supply, x/oracle, x/settlement, x/track_a, x/auction, x/bootstrap, x/opt_exchange, x/disputebonds. The v4.0 module count was 13; v5.0’s is 21 (x/iopt removed; eight new). x/storage, x/gateway, x/bandwidth, x/inference, x/vectordb, x/identity, x/policy keep their shapes; their voucher denoms are now in usovr rather than uiopt and their settlement paths route through x/settlement.Split. The latent pool carries §2.5 sub-bucket metadata (protocol_emissions / bootstrap_rewards / opt_exchange / node_revenue_match) that earmarks each program’s capacity. The sub-buckets are load-bearing: every Latent → X transition is bucket-aware via IssueFromBucketToLocked / IssueFromBucketToAccount, and the chain enforces sum(buckets) ≤ latent on every Move so a program cannot silently consume capacity earmarked for another.

This whitepaper describes the intended protocol design as of the publication date. Implementation details remain subject to audit, governance approval, legal review, and final mainnet configuration.