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:

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

This document represents the current best understanding of how the SOVR ecosystem is expected to evolve over time. It reflects a forward-looking model based on available data, design principles, and intended incentives, but it is not immutable. As the system is deployed and real-world conditions emerge, modifications and refinements may be required to ensure long-term stability and alignment with core objectives. Wherever practical, these changes will be implemented through governance mechanisms that involve the community. At the same time, during the early and transitional phases of the ecosystem, certain adjustments may be made unilaterally to address immediate needs, correct structural issues, or preserve system integrity, with the expectation that control progressively decentralizes as the network matures and stabilizes.

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:

1. A stable, low-fee settlement rail for per-request payments between clients and operators, denominated in SOVR.
2. 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.
3. An Attestation layer that turns signed proof of delivered work into operator reward weight, replacing the synthetic-work fiction of traditional PoW.
4. 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
5. 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.
6. A multi-module SDK in Go, TypeScript, and PHP so non-chain systems integrate with the same voucher domains the chain validates.
7. 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.

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.

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.

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.

Each genesis validator may receive or self-delegate an operational amount of SOVR from the upfront-minted genesis supply solely to satisfy validator creation and launch requirements. The recommended launch configuration is 10,000 SOVR self-delegated per genesis validator, with a minimum self-delegation threshold of 1,000 SOVR unless adjusted in the final genesis configuration. This allocation is not a validator reward pool, does not increase max supply, and is accounted for within the 60,000,000 SOVR upfront-minted genesis supply.

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:

Drains happen through bucket-aware emission helpers (IssueFromBucketToLocked, IssueFromBucketToAccount) so each program consumes only its own earmark, Track A cannot silently dip into protocolemissions, the bootstrap match cannot dip into bootstraprewards, etc. The x/supply invariant sum(subbuckets) ≤ latentpool 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/supplyLatentSubBuckets.

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

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.

T10 Strategic Partner Reserve: 1,000 licenses are pre-minted at genesis to a multi-signature wallet controlled by Sovren. These licenses are not offered via public auction. They may be distributed to strategic partners at any time, including during active public tranches T02-T09. All T10 licenses are subject to a 12-month transfer lockup from date of distribution and 180-day vesting upon staking. Distribution does not increase total supply beyond 10,000.

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:

1. The buyer’s allowlist / per-wallet-cap status is checked.
2. The price is computed (T01 / T02 fixed; T03-T10 by Dutch decay against OpenedAt) and quoted in usovr through x/oracle.
3. The clearing price is settled and an activation bond may be escrowed (default 0 bps; governance-tunable).
4. x/nodelicense.MintFromAuction(buyer, metadata, trancheID, clearingPriceUsovr) mints an inactive license stamped with the tranche ID and clearing price.
5. 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 LICENSESTATUSINACTIVE. 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/tracka, 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/distroBeginBlock for Track A and Track B; x/settlementDistributeRewards for the Bootstrap Match payout) issues SOVR through x/supply.IssueToLocked, which enforces the 1 B closed-loop cap on every transition. x/tracka, 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 protocolemissions latent sub-bucket via IssueToLocked); the §6 settlement 25 % slice lands in the settlementrewards 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):

TrackBtoday = 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 Subject to change based on company requirements.

6.2 Pro-Rata Distribution

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

1. Reads each operator’s rolling 30-day attestation score from x/attestation.
2. Allocates shares pro-rata; dust below per-operator allocation stays in the pool for the next distribution.
3. Records each share in OperatorLocked[operator] += share (settlement-layer claim ledger).
4. 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/paymentsOpenServiceChannel 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

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, inthe 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(noderevenuematch, ...) 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.

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[[1]](http://#msocom1) ;
• 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/oracleParams 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 servicemodule 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 servicemodule 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:

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:

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 (ratepergib_usovr)

Host registration, locked at session creation

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

peerid is == sessionid 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):

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:

1. Register against the permissionless on-chain model registry (sequence-assigned model_id, name unique on first registration);
2. Publish a per-model rate schedule (input-per-1K usovr, output-per-1K usovr);
3. 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):

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

• vectorblocks accumulates vectorsstored × blocks_elapsed, storage-over-time
• queries, cumulative ANN query count

paidusovr = vectorblocks × rateperblock + (queries × rateper1k) / 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 = 50000000). 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: (sovrid, verifier, kind) with verifiedat / 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[[2]](http://#msocom2) . 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.

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/cryptoagilitytest.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 (signedblockswindow, minsignedperwindow, downtimejail_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.

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

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-blockchain 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.

Appendix B: Key Parameters at Mainnet Default