SOVR

Technical Whitepaper — v7.0 · September 2026

This version corrects how supply is described; the protocol model is unchanged. See Appendix C.4.

At a Glance

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 v7.0 of the chain:

• Single-token, closed-loop supply. SOVR is the sole unit of account. Every token sits in exactly one of four states (Latent, Locked, Vesting, Claimed). The Burn-and-Recycle Protocol is non-terminal: a “burn” is a Claimed → Latent transition, not a fifth state — the bytes never leave the supply machine. 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 distribution. All 1 B SOVR exists on-chain from genesis — the closed-loop invariant requires it. 95 M is allocated to reserve wallets held in multisignature custody under issuer control; 905 M remains held undistributed in the protocol reserve: 670 M protocol emissions, 150 M Bootstrap Rewards, 75 M Exchange Allocation, and 10 M Node Revenue Match. Issuance, spending, and recycling change observed balances; nothing changes the 1 B cap.
• Usage-priced, not gas-priced. Every service market — storage, gateway, bandwidth, GPU inference, vector databases, generic compute jobs — settles off-chain via domain-separated signed vouchers, on-chain in bounded batches. Gas pays for consensus inclusion, not for the underlying work, and the minimum gas price is a governance-set network constant (x/globalfee) rather than a per-validator setting. 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 / Treasury Allocation / 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. The node-license system is capped at 10,000 total. Of that total, 1,000 licenses are reserved as a Company Reserve Allocation: genesis seeds the T10 tranche as a Strategic Reserve (TRANCHE_KIND_STRATEGIC_RESERVE) rather than pre-minting NFTs, and each license is minted only when it is issued, via MsgIssueT10License/MintReserved (tracked by t10_issued_count) — the company holds reserved capacity, not pre-minted licenses. The remaining 9,000 are sold across the T01–T09 ladder. T01 is a $3,000 fixed-price Reserved Access tranche available to approved participants under published eligibility rules; T02 is a $3,000 fixed-price Public Launch tranche; T01 and T02 are priced identically — T01 is reserved-access, not discounted; T03–T09 use 72-hour linear Dutch decay. The 1,000 Company Reserve licenses are distributed off-auction by a Sovren multi-signature wallet via MsgIssueT10License and are not additive to the 10,000 cap. A node license is a long-term infrastructure participation right, not a passive income instrument.

What follows is what the chain is today. Track A and Track B launch defaults are pinned (§5.1, §5.2); the oracle ships dormant with the Bootstrap Reference Price as fallback (§11); there is no separate validator/security floor at launch (§5). The remaining open mechanic — Node Revenue Match program rules — is explicitly flagged in §10.

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), x/compute (deterministic compute jobs — transcode, classify). 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.
• A bridge to an EVM-compatible chain (initial targets: Ethereum mainnet and Base) plus 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

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

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. This is externally verifiable: the x/mint query endpoints return Not Implemented on the live chain, because the module is not wired in.

SOVR is the sole unit of account; there is no separate utility token. The Exchange Allocation is 75 M (§3.2): a dormant, currently unissued reserve for trading venues, centralized or decentralized, covering venue set-asides and the costs of securing listings.

2.0 Activation and Live State

Capability and activation are separate. A component is implemented and shipped in the chain binary; whether it is live is an operational state set by governance, not a property of the code. Components ship dormant and fail-closed — inert until a governance action arms them — and several described in this document are in that state at publication. Off-chain workers and sidecars attach to interfaces the chain already exposes and are enrolled the same way. Because activation is an operational event rather than a protocol change, this document describes the design and does not track activation state; the live state of any module, parameter or job type is public and queryable at any block height from the endpoints in §3.4.

2.1 The Network Fee Floor (x/globalfee)

Gas pays for consensus inclusion, not for the underlying infrastructure work (the work is settled through service vouchers, §6, §13). The price of that gas — the minimum a transaction must pay per unit — is a network constant set by governance rather than a setting each validator configures locally. x/globalfee holds that floor as consensus-level parameters and enforces it in the ante chain.

The module holds no funds and no per-account state — only a single parameter block:

Enforcement is a FeeDecorator placed immediately before the SDK’s DeductFeeDecorator in the ante chain. It validates only — it rejects a transaction whose fee is below ceil(gas_limit × minimum_gas_price) for each floor denom, unless every message is on the bypass allowlist and total gas is within the cap. Because the SDK’s deduct step still applies each node’s local floor in CheckTx, the effective floor on any node is max(global, local): the network floor can only raise the bar, never lower it. The launch default of 0.001 usovr/gas matches the public-node default that preceded the module, so no operator’s fees change when the floor turns on.

The floor is changed only through MsgUpdateParams under the standard governance authority; there is no admin override. x/globalfee was introduced as a store-adding, consensus-breaking upgrade (v0.6.0-globalfee) — the first SOVR upgrade to add a module store post-launch — whose handler seeds DefaultParams() explicitly so the activated floor is unambiguous and logged. It does not interact with x/settlement: the fee floor gates what a transaction must pay to be included, after which gas/tx fees are deducted and distributed through the SDK’s standard fee path (DeductFeeDecorator and the fee-collector) — not through x/settlement. x/settlement is invoked only by service modules to split settled service amounts (and the bridge/service fees explicitly routed to it), and is never on the gas-fee path.

3. Token Model

Defined terms. In this document, the Company means the entity that builds and operates the chain and receives the company share of service settlement (§6). The Issuance Company means the entity that holds the token reserves and conducts distribution, and that controls the reserve wallets identified in §3.4. Legal entity identification is provided in the disclosure package and in venue applications rather than here.

SOVR is a single-token system. 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 Four States

Why all SOVR exists from genesis. The closed-loop invariant requires it. x/supply.Move transitions tokens between states; it never creates them, and x/mint is disabled. Emission is therefore a state transition, not an issuance event — which is what makes the 1 B cap an invariant rather than a promise.

Latent SOVR is held in the x/supply module account:

sovr17vxlu88mdhndrjtzm4c5y3m8ung662etfef9qp

A module account is derived deterministically from the module name and has no private key. No party can sign a transaction moving those tokens — not the Issuance Company, not the Company, not a compromised signer, not a validator majority. They move only along the protocol’s own emission paths, each gated on verified infrastructure work and bounded by its named sub-bucket (§3.2). The balance is publicly queryable at any time.

A “burn” is a Claimed → Latent transition, not a state — burned tokens return to the Latent reserve and become future-emission capacity. There is no Burned pool to query, no terminal-destruction path for SOVR.

x/supply.Move(ctx, from, to, amount) is the underlying primitive. Every economic transition routes through it, so the invariant is enforced once and everywhere. Production callers use the bucket-aware emission helpers (IssueFromBucketToLocked, IssueFromBucketToAccount) which atomically draw from a named latent sub-bucket (§3.2), transfer the bank coins, and run Move. The return-to-latent helpers (BurnClaimedToLatent, ReturnClaimedToLatent, ReturnVestingToLatent, ForfeitToLatent) move tokens back to Latent and credit the recycled capacity to protocol_emissions. The vesting helpers (StartVest, FinishVest, LockClaimed, FinishVestToAccount) handle the Locked → Vesting → Claimed lifecycle without touching latent.

3.2 Allocation Baseline

The 1 B SOVR cap is partitioned across six allocation categories. Two are held as Claimed reserves in multisignature wallets controlled by the Issuance Company; four remain Latent in the protocol reserve.

95,000,000 SOVR is allocated to reserve wallets and 905,000,000 SOVR remains Latent. Listing on any specific venue is not guaranteed.

Ecosystem & Operations. Up to 25,000,000 SOVR of the Liquidity Pool Reserve is available for the costs of establishing and maintaining market presence: marketing, advisory and consulting engagements, market-making retainers and inventory, listing costs, and the operating costs of the Issuance Company. This is a disclosed sub-use of an existing allocation, not an additional allocation — it does not change the six-category partition, the 75 M Liquidity Pool Reserve, or the 1 B cap.

Allocation is not a holding. The figures in this section are allocation ceilings — the maximum that may ever be assigned to each category. They are not statements of current wallet balances. Tokens move into a reserve wallet only through the release path for that category, and Latent, Locked and Vesting balances change continuously as emissions run. Current balances are queryable at any block height from the published endpoints in §3.4, which is the authoritative source for what is actually held rather than what is allocated.

Each genesis validator may receive or self-delegate an operational amount of SOVR from the genesis-released supply solely to satisfy validator creation and launch requirements. This allocation is not a validator reward pool, does not increase max supply, and is accounted for within the genesis-released supply.

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

The four latent sub-buckets sum to 905,000,000 SOVR. The exchange_allocation earmark remains Latent and unissued.

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.

3.4 Supply Disclosure

The four protocol states are internal accounting. Three figures are what venues, aggregators and holders consume. They map as follows.

Circulating supply is computed, not asserted:

Circulating = Total Supply
            − Locked
            − Vesting
            − Σ(balances and delegations of the published excluded addresses)

Excluded addresses. Each is publicly queryable; anyone may recompute the figure independently.

Additional issuer-controlled operating wallets are maintained alongside the supply endpoints; the authoritative current list is served with the supply query so the computed figure always reflects every excluded address.

Treatment rules.

• Tokens deployed into a public liquidity position count as circulating from deployment — they stand at a published ask any party may take.
• Tokens transferred to a venue, or made available to a third-party market maker, count as circulating from transfer.
• Tokens held by the Issuance Company or its affiliates are uncirculated until sold or transferred to a third party.
• Locked and Vesting SOVR is non-transferable by protocol rule and is never counted as circulating.
• The IBC transfer escrow account is not excluded: tokens held there circulate as vouchers on the destination chain.

Latent, Locked and Vesting balances change continuously as emissions run; the excluded-address method returns a current figure at any height.

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

Operator entry is gated by an NFT-backed node license. The 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. T01 is a fixed-price Reserved Access tranche available to approved participants under published eligibility rules. Governance installs the T01 buyer set with MsgSetT01Allowlist — a generic governance-set allowlist — and only those addresses can clear T01 bids. T01 buyers pay in SOVR via the same oracle quote everyone else uses. T01 participation does not create passive reward rights and does not alter the activation, module participation, attestation, lockup, or work-contingent reward requirements applicable to all node licenses. 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–T09 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.

Company Reserve Allocation: Of the 10,000 total node licenses, 1,000 are reserved for company-controlled allocation. Genesis seeds the T10 tranche as TRANCHE_KIND_STRATEGIC_RESERVE (pre-cleared) rather than pre-minting 1,000 NFTs into a wallet: no T10 license NFT exists until it is distributed. Each is minted on issuance by MsgIssueT10License, which calls MintReserved to materialise an inactive NFT to the recipient (clearing price 0, activation bond 0) and increments the governance-visible t10_issued_count — so the company holds reserved capacity, not pre-minted licenses. They are not offered via public auction and are not additive to the 10,000 cap; both the reserve draw-down and the public auction mint against the shared 10,000-license hard cap. They may be used for strategic, operational, hosted-node, validator-support, ecosystem-development, partner-support, testing, or internal infrastructure purposes, and may be distributed at any time, including during active public tranches T02–T09. Company-reserved licenses do not create passive reward rights: each must satisfy the same activation, module participation, attestation, lockup, and work-contingent reward rules as other node licenses before it can earn. All such licenses are subject to a 12-month transfer lockup from date of distribution and a 180-day vesting condition upon staking. Distribution does not increase total supply beyond 10,000 licenses fleet-wide.

T01 pre-order fulfilment: T01 is sold both on-chain (MsgPlaceBid against the allowlist) and via an off-chain pre-order process whose purchases are fulfilled on-chain by MsgAssignT01License. A pre-order buyer pays through the portal off-chain; the dedicated T01 pre-order multisig (t01_preorder_multisig_address) then mints the purchased licenses to the buyer at clearing price 0 (the payment already happened off-chain). Pre-order grants draw down the same 1,000-node T01 inventory as on-chain T01 bids — a grant that exhausts T01 marks it CLEARED and auto-advances the ladder exactly as a final paid bid would — and they are exempt from the 200-NFT per-wallet cap, since a pre-order customer may have committed to a larger block off-chain. This multisig is deliberately separate from the T10 Strategic Reserve multisig (t10_multisig_address, which authorises MsgIssueT10License): T01 pre-order fulfilment and Company-Reserve distribution are distinct signing authorities, each with its own governance-visible issued-count counter (t01_preorder_issued_count, t10_issued_count) that the keeper re-stamps from chain state so a parameter update cannot reset it. If either multisig address is unset, its issuance path is disabled.

Two primary-market constraints apply:

• 200-NFT per-wallet cap on the public auction (T01–T09), 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. T10 is exempt: distribution flows through MsgIssueT10License rather than PlaceBid, and strategic partners may receive arbitrarily many T10 licenses by design.
• 12-month transfer lockup on minted licenses (every tranche, including T10), enforced by x/nodelicense.MsgTransferLicense against the PurchasedAt height stamped at mint time. Self-transfers bypass.

Sequential gating applies on the public ladder: T(N+1) cannot open until T(N) is cleared, for N in T01–T08. Only the current open tranche accepts bids. T10 is outside the gating ladder; it is pre-cleared at genesis and distributed independently. 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

Primary-market license purchases happen off-chain in the validator portal. The buyer pays in USD (or whatever payment rail the portal supports); the portal then drives the on-chain mint as the settlement leg. The on-chain x/auction.PlaceBid path is not the user-facing checkout — it is the deterministic settlement of a cleared bid.

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–T09 by Dutch decay against OpenedAt) and quoted in usovr through x/oracle. Two issuance paths never enter PlaceBid: T10 strategic-reserve licenses are minted by MsgIssueT10License, and off-chain T01 pre-orders are fulfilled by MsgAssignT01License — both at clearing price 0, since their settlement happened outside the on-chain bid path.
• 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, x/compute), 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

A flat-price model has no mechanism to discover a clearing price — every license sells at the same number whether demand is 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 issues SOVR through the bucket-aware x/supply.IssueFromBucketToLocked helper (Track A from bootstrap_rewards, Track B from protocol_emissions, Bootstrap Match from node_revenue_match), which atomically draws from the named latent sub-bucket and enforces the 1 B closed-loop cap on every transition. x/track_a, x/bootstrap, and x/exchange_allocation are accountants — they own per-program counters but never call bank MintCoins directly. The mint authority is concentrated in x/distro and x/settlement (issuance); cross-chain flows escrow rather than mint native SOVR — x/warp locks native SOVR as collateral and mints only the wrapped synthetic on the remote chain — so no other module can manufacture native SOVR.

Operator emissions land in the Locked state. 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 180-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 held in the protocol reserve account and not in any issuer-controlled wallet. Tokens from this reserve are released 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, attestation, and eligibility. Attestation can be earned through either (a) module participation — registering against an infrastructure module (x/storage, x/gateway, x/bandwidth, x/inference, x/vectordb, x/compute) and producing in-process module receipts on verified work, or (b) the attestor-allowlisted re-entry path (§8.3) — measured Cloud Work Units (CWU) per license (RECEIPT_TYPE_CWU, §8.4), the designated earning signal that supersedes the earlier Cloud Proof of Work (CPoW) liveness/light-client heartbeats. All paths feed the same 30-day rolling attestation score; CWU is bounded by the existing per-license rate limit, and CPoW receipts pass through a per-license per-credit-epoch cap before contributing (§6.2, §8.3, §8.4).
• 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):

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

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

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 the settlement design: 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 / Treasury Allocation / 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.

CPoW receipts (§8.3) feed the same 30-day rolling attestation score but are subject to a per-license per-credit-epoch cap before contributing to the score. The cap defaults to one credited receipt per license per epoch with last-write-wins inside the epoch — multiple slim agents bound to the same license sum to one credited contribution, not many. This is the Sybil deterrent for the CPoW path; service-module receipts (SubmitModuleReceipt) remain uncapped because the in-process verification already carries the proof-of-work weight of the attested service action. Multi-host high-availability across redundant slim agents is therefore a hosting-plane concern (primary election, leader-lease, etc.), not a chain-pipeline concern.

CWU receipts (§8.4) feed the same 30-day rolling score but are bounded by a different control: the existing per-license rate limit (MinReceiptIntervalSeconds), which throttles how often any one license may be credited, plus the per-term scoreCWU caps that bound how much a single measurement can be worth. The CPoW per-credit-epoch cap and the CWU per-license rate limit are distinct mechanisms guarding the two receipt types on the same attested-batch rail.

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/evmbridge — the outbound bridge fee (MsgBridgeOut) routes its 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/evmbridge 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 current design holds the claim flow on a 180-day linear vest and adds a small but important 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 absorb a roughly six-month idle stretch, 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 handles forfeiture directly. A ForfeitPool + DrainForfeitPool re-emission path also ships alongside it. Both converge to the same end state — forfeited value flows back to active operators — on different curves.

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 a 180-day idle window, a claim is a deliberate pause: the operator forgoes roughly half a year of earning to liquidate previously-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. Service modules emit receipts in-process on verified work (the earning path); operators submit signed receipts directly only for node/validator telemetry. The keeper validates, dedups, stores in a rolling 30-day 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 call SubmitModuleReceipt(ctx, operator, receiptType, metrics, ts, sourceID) directly without an end-user signature — trust is established by the call being in-process (the stored signature is the literal "module"), not by a params allowlist. This is the earning path for real service work: x/storage on a verified proof, and x/gateway / x/bandwidth / x/inference / x/vectordb / x/compute on client-signed voucher redemption. x/identity and x/policy do not use it — they neither attest nor earn.

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.

8.3 Attested Receipts and Cloud Proof of Work

Beyond the two paths above (in-process module receipts; direct operator-signed receipts for node/validator telemetry), the chain accepts a third receipt class: attestor-signed batches, submitted via MsgSubmitAttestedReceipts by a governance-allowlisted attestor address. This is the on-ramp for receipts whose origin is neither an in-process service module nor a direct end-user signature — specifically, Cloud Proof of Work (RECEIPT_TYPE_CLOUD_POW = 10).

The trust model is explicit: the chain credit pipeline trusts the attestor allowlist (Params.enabled_attestors). An attestor is added by governance and is constrained to a set of AllowedReceiptTypes — a managed-hosting attestor allowed to submit CPoW cannot also submit storage-deal receipts. Atomicity is preserved at the batch level: any per-row rejection rejects the entire batch.

Cloud Proof of Work (CPoW) is the receipt type a slim agent emits per credit epoch. A slim agent (full specification at specs/002-slim-node-128mb/) is a sub-128 MB, pure-Go, non-replaying agent that:

• signs every report with a per-agent delegated subkey rooted in a customer-held master key (see §17 for the new domains sovr:cpow-report:v1 and sovr:delegation:v1);
• emits either Tier-1 liveness heartbeats (cross-checked against multiple public RPCs) or Tier-2 light-client-verified attestations of chain state;
• submits no transactions itself — its reports are batched and submitted by an allowlisted attestor.

The slim agent is not a chain-replaying node: it does not import app/, does not link wasmd, and does not maintain IAVL state. The product premise is a low-cost node a license holder can run, or have hosted on their behalf, without the full sovrd footprint. CPoW receipts feed the standard 30-day rolling attestation score (§8 intro) and Track A / Track B fan-out (§5, §6) — but are subject to the per-license per-credit-epoch cap described in §6.2 before contributing.

The CPoW path adds two new trust assumptions relative to the existing module-receipt and direct-operator-signed paths: (i) the chain credit pipeline trusts the attestor allowlist for any receipt routed through MsgSubmitAttestedReceipts, and (ii) a Tier-2 slim agent trusts the chain’s validator set (standard light-client trade-off). Both are explicit, neither is hidden, and both are restated in the §19 security model.

8.4 Cloud Work Units (CWU): the per-license measured earning signal

CPoW (§8.3) proves a license is alive; it does not measure how much work the license actually performed. SOVR’s earning signal evolves from liveness to measurement with Cloud Work Units (CWU) — RECEIPT_TYPE_CWU = 12, a new attestor-signed receipt type carried on the same MsgSubmitAttestedReceipts batch rail described in §8.3.

A Cloud Work Unit expresses the cloud-equivalent value of the real computing work a node performs across four resource terms — compute, memory, storage, and egress — as bounded work-unit quantities. The chain only ever ingests work units; it never accepts, encodes, or requires absolute dollar figures or raw inventory counts (a strict decode rejects any unknown field, so a row carrying a price or inventory figure fails the whole batch). The CWUMetrics payload is exactly those four work-unit terms; the enclosing attested row carries the window-end timestamp, the source identifier (the per-(operator, source_id) dedup key), and the operator address being credited. The reward attaches to that operator’s held node license through the existing license-held-attestation eligibility filter, not to a license identifier embedded in the metrics.

A governance-allowlisted CWU attestor — initially the company-operated portal, which already computes per-node metrics — submits batches of per-license CWU rows, scoped to the CWU receipt type by the same per-attestor AllowedReceiptTypes allowlist that constrains a CPoW attestor. The chain scores each row with scoreCWU: for each term, clamp the work-unit value to its governance-set per-term cap, apply the governance-set per-term weight (cwu_score_weights — four basis-point weights, defaulting to a neutral 1.0×), sum the four terms, and clamp the result non-negative. The score folds into the same 30-day rolling attestation score that Track A and Track B already consume (§5, §8 intro), bounded by the existing per-license rate limit (MinReceiptIntervalSeconds, default 60 s) so no license can inflate its share by over-reporting within a window. No new distribution path is created; CWU is simply the receipt type that determines per-license earning weight, distributed pro-rata through the existing Track A / Track B fan-out and subject to every existing eligibility filter (active license, non-idle node, non-validator account, license-held attestation).

CWU is designed to supersede CPoW liveness heartbeats as the earning signal while reusing the entire attestation→distribution rail unchanged. The change is deliberately contained — a new receipt type, a new scorer (scoreCWU, the analogue of scoreCloudPoW), and new governance parameters (cwu_score_weights and the four per-term caps). A cwu_min_attestors parameter is also provisioned, but it is currently validation-pinned to 1 (single-attestor passthrough): each CWU row is credited immediately from one attestor, and the multi-attestor agreement gate (FR-016) is not yet wired into the credit path. The field exists now only to avoid a second params migration when that buffer lands. Everything downstream is untouched: the rolling score, Track A’s 4-tier cadence, Track B’s burn-parity valve, and the 50/25/25 settlement split all read CWU-derived weight exactly as they read CPoW-derived weight today. The CPoW receipt type (§8.3) is retained for the transition; its retirement is a separate, scheduled follow-up.

Activation posture. The CWU scoring parameters ship dormant: no CWU attestor is allowlisted at upgrade time, so CPoW remains the live earning signal until governance allowlists the portal as a CWU attestor and confirms the weights, per-term caps, and per-license rate limit are armed to non-trivial values. The inflation path is closed before any reward track is pointed at CWU score. This is the standard posture across the protocol — see §2 Activation and Live State.

Privacy posture — a deliberate, accepted tradeoff. Per-license CWU work units on public chain state weaken the aggregate-only fleet-scale privacy of the companion network-wide CWU index: because each license’s four terms are individually visible, an informed observer can estimate fleet scale from public per-license figures. This is accepted because per-license distribution is impossible without per-license data reaching consensus — a single network index cannot attribute reward to any one node. Admitting only bounded work units (never dollars or inventory) minimizes the leakage. The weakening is a governance/whitepaper-level acceptance, surfaced here rather than hidden.

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 undistributed capacity in the protocol reserve inside the 1 B cap; tokens transition 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 and producing attested work in the relevant rolling window. Attested work means either (a) in-process module receipts from registration against an infrastructure module, or (b) CPoW receipts from a slim agent emitting liveness / light-client verification via the attestor-allowlisted re-entry path (§8.3). A node with no attestation in the relevant rolling window — under either path — does not draw Track A. This protects the reserve against passive ownership: a license that buys in and never hosts (and never runs a slim agent on its own behalf) 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 match ratio, cadence, tapering, eligibility, and sunset rules are pending policy and technical validation; what is fixed is the reserve size and the constraint that this is not company revenue and is released only under program rules.

The reserve is held undistributed in the protocol reserve 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. 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/evmbridge 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 six markets — storage, gateway, bandwidth, inference, vectordb, compute — 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.

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):

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. Host-signed benchmarks provide non-repudiation; the MsgDisputeBenchmark path adds client-observed truthfulness and activates with 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:

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

13.6 Compute (x/compute)

x/compute is the marketplace for deterministic compute jobs over stored objects — work that takes a stored input, applies a transformation, and writes the result to an output storage deal. It uses the same registration, settlement, and attestation shape as the other markets, but its unit of work is a job rather than a streamed session, and a host advertises capability per job type rather than per model.

Two job types ship at launch:

The job-type set is consensus state (a proto enum), so adding a type is a chain upgrade, not a permissionless message. JOB_TYPE_IMAGE_TRANSFORM (deterministic image ops — resize, crop, thumbnail, format-convert, watermark) is implemented and enrolled by a chain upgrade that extends the proto enum; CreateJob rejects any unknown enum value until then. The framework is generic — every validation site keys off the job-type registry with no per-type branching — and a strong host for one job type is not assumed strong for another, so the HostsByJobType and BenchmarksByJobType indexes price and rank hosts apart by type.

Hybrid metering. Unlike the per-byte or per-token markets, a compute job is billed on two axes at once. A host publishes, per job type, a rate_per_output_unit_usovr (the work axis — seconds of transcoded media, items classified; this rate must be positive, so no host can advertise free work to inflate attestation) and a rate_per_uptime_block_usovr (the availability axis — price per block the job slot is held reserved; may be zero). A redeemed voucher carries cumulative output_units and uptime_blocks, and the cost is:

paid_usovr = output_units × rate_per_output_unit + uptime_blocks × rate_per_uptime_block

computed with saturating arithmetic so an overflow cannot wrap to a small value. Short-lived jobs typically price the output axis only and set the uptime rate to zero.

Lifecycle. A host registers with MsgRegisterComputeHost (active license + stake + endpoint + per-job-type rate schedule); registration carries no advertised-throughput field and only checks stake >= MinHostStake (a flat 100 SOVR floor). Capacity-scaled collateral is enforced later, at benchmark submission: SubmitBenchmark requires stake >= RequiredStakeUsovr(output_units_per_sec), which scales the floor by a coefficient that defaults to zero — so until a host benchmarks (and unless governance raises the coefficient), every host is bonded only at the flat MinHostStake floor. A client opens a job with MsgCreateComputeJob, backed by an x/payments channel for payment and an x/storage input deal for the source object; the job pins the host’s rates at creation. The host produces output and records the result deal(s) with MsgAttachJobOutput, then redeems a client-signed voucher with MsgRedeemComputeVoucher. MsgCloseComputeJob finalizes. Hosts also publish signed capability measurements with MsgSubmitBenchmark (output-units/sec and p50 latency at a declared height); MsgDisputeBenchmark is reserved for phase 3 and returns ErrBenchmarkDisputeNotEnabled until the compute sidecar pins the client-observation domain.

Settlement and attestation. Voucher redemption routes the settled amount through x/payments.SettleServiceFromChannel into x/settlement.Split, so the 50/25/25 economics apply uniformly — and the redeem path is bound so a colluding client and host cannot redeem to mint attestation weight and then close with a zero settlement to refund the deposit. What RedeemCompute enforces is client-authorized paid voucher redemption: it verifies the client's signature over the exact voucher facts and settles real SOVR, then emits a best-effort in-process attestation receipt (RECEIPT_TYPE_COMPUTE) the same way the other markets do. It does not itself verify that the transformation output is correct — output-correctness verification belongs to the dispute path (MsgDisputeBenchmark and sovr:compute-observation:v1), which arms under the standard activation posture (§2). The word “verified” therefore applies to the client authorization and the settled payment.

The compute worker (sovr-transcode) and the sovr:compute-observation:v1 dispute domain are off-chain components that attach to the interfaces the chain already exposes. The chain-side market — registration, job dispatch, hybrid voucher redemption, benchmarks, and live slash plumbing — is complete. Worker activation follows the standard posture in §2.

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.). The chain holds skin-in-the-game rather than collecting a flat tax up front.

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 an EVM-compatible chain (x/evmbridge) and IBC

SOVR is bridgeable to an EVM-compatible chain (initial target: Base) as an ERC-20 through a Hyperlane-based design with zero custom Solidity. Native SOVR is escrowed as collateral on the SOVR side and a stock, audited HypERC20 synthetic (“wrapped SOVR”) is minted on the EVM side; the return leg burns the synthetic and releases the native collateral. This replaces an earlier custom lock-and-mint bridge (a deleted x/bridge module plus bespoke Solidity and a relayer daemon), removing every hand-rolled contract and signer from the trust surface.

Framework, compiled in — not forked. The upstream hyperlane-cosmos modules x/core (the mailbox, hooks, and Interchain-Security-Module router) and x/warp (the token router) are compiled directly into sovrd with no fork. x/warp holds the escrowed SOVR collateral and mints/burns only synthetic-type tokens on the remote domain; it never issues native SOVR outside the escrow accounting.

x/evmbridge — the Sovren policy layer. A thin custom module wraps the generic framework with Sovren’s economic and safety policy: per-domain routes; per-transfer minimum and maximum bounds; fixed-window (hourly and daily) volume limits and a total-outstanding cap; and pause scopes — global, route-outbound, and route-releases — exercisable fast-path by a governance-configured emergency authority. Every outbound transfer runs policy checks → fee → warp remote-transfer of the net → journal + window + liability atomically, so no partial lock is ever left behind. An ante decorator (RejectDirectWarpTransferDecorator) forces canonical-token transfers through the module’s MsgBridgeOut, making the policy layer consensus-enforced rather than advisory. The module registers a policy ISM (type 240) in the Hyperlane ISM router for the release path, with a core-store routing-ISM shadow so the stock relayer builds standard multisig metadata for it.

Decimal model: SOVR is 6-decimal on-chain (usovr) and the wrapped SOVR synthetic is deployed 6-decimal as well, so the scale factor is 1:1 — there is no 10^12 conversion and no sub-unit rounding surface (the legacy 18-decimal ERC-20 is gone).

Verification and agents. Cross-domain messages are authenticated by a Hyperlane multisig ISM: an independent verifier set signs checkpoints of each origin chain’s mailbox, and the destination requires a k-of-n quorum before a message is processed — one compromised verifier cannot move funds. On the EVM side the router’s ISM is a staticAggregation(messageIdMultisigIsm, pausableIsm), pairing the quorum with a pausable circuit breaker, and no owner-mint path ever holds the SOVR symbol on an official route. The validator and relayer are the official Hyperlane Rust agents (pinned images), not custom software.

Solvency invariant and reconciliation. The design is fully collateralized: escrowed native SOVR always equals the outstanding wrapped supply (adjusted for in-flight transfers), and both figures are publicly queryable so anyone can verify the peg at any time. An off-chain reconciler cross-checks the on-chain escrow / collateral / journal-liability triple against the remote synthetic’s total supply; on any unexplained variance above zero it alerts, automatically suspends new bridge initiation via the emergency pause, and surfaces the condition publicly within a fixed cadence window, holding until a documented, zero-variance resolution.

Settlement integration: the outbound fee routes through x/settlement.Split, applying the same 50/25/25 economics (burn-to-latent / operators / company) to cross-chain transfers that every other settled SOVR flow uses — a portion of each bridge operation is burned back to latent rather than retained as bridge revenue.

The whole chain-side design ships in one coordinated upgrade (working name v0.26.0-evm-bridge) dormant and fail-closed: no Hyperlane instances exist, no routes are enrolled, and nothing moves until a governance activation sequence creates each instance (the gov authority owns every one), enrolls the routes, and finally enables outbound flow at conservative launch limits.

x/evmbridge 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 the Hyperlane bridge validator checkpoints (ECDSA, verified by the EVM-side multisig ISM); ed25519 for CometBFT consensus keys. No post-quantum signature scheme is active today, and no migration is scheduled.

What has shipped is crypto-agility. A 2026 audit corrected misleading comments in x/attestation that implied signatures must be secp256k1 — they must match the account's registered pubkey, whatever type it is — and added coverage exercising the full payment-channel lifecycle with a 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.

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. The Latent reserve is held in a module account with no private key, so no signer, and no majority of signers, can move it outside the protocol’s own emission paths (§3.1).

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.

Sybil resistance for CPoW. The slim-agent CPoW path (§8.3) adds a second Sybil layer specific to off-chain attested work: a per-license per-credit-epoch output cap applied at receipt admission, before the 30-day attestation score updates. Multiple slim agents bound to the same license — whether legitimate HA redundancy or adversarial Sybil — contribute to at most one credited receipt per license per epoch, with last-write-wins inside the epoch. Multi-host primary election is therefore a hosting-plane concern (leader-lease, external coordinator, etc.), not a chain-pipeline concern. The chain credit pipeline also trusts the attestor allowlist (Params.enabled_attestors) for any receipt routed through MsgSubmitAttestedReceipts: a compromised allowlisted attestor key is a defined threat that must be mitigated by the attestor operator’s custody discipline and a fast governance path to remove the entry from the allowlist.

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. Cross-domain messages are authenticated by a Hyperlane multisig ISM: an independent verifier set signs each origin mailbox’s checkpoints and the destination requires a k-of-n quorum, so no single verifier can authorize a mint or release. The EVM router pairs that quorum with a pausable circuit breaker (staticAggregation(messageIdMultisigIsm, pausableIsm)), and the x/evmbridge policy layer adds per-transfer bounds, fixed-window volume limits, an outstanding cap, and global/route-outbound/route-releases pause scopes. The design is fully collateral-backed — escrowed native SOVR always equals the outstanding wrapped supply (adjusted for in-flight), publicly queryable — and an off-chain reconciler auto-suspends new initiation on any variance. Bridge fees route through x/settlement.Split so a successful 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/exchange_allocation reserve cap (reserve_cap_usovr) — accounting bound on the dormant 75 M reserve; no allowlist, rate, or exchange-window params exist. The reserve’s permitted uses are venue-required token set-asides, listing costs, and market-maker inventory associated with securing and maintaining listings (§3.2); release requires a governed action. No mechanism may raise the 1 B SOVR cap, and the Exchange Allocation may not be redirected to general operating expenses without an express tokenomics amendment
• 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
• x/attestation CPoW path: enabled_attestors allowlist (with per-attestor AllowedReceiptTypes scope), credit_epoch_seconds (default 3600), per-license per-epoch CPoW credit cap (default 1, last-write-wins is fixed for v1), light_client_trust_period (default 2/3 × unbonding). All four are governance-tunable without an agent-side software upgrade (§8.3, §17). The attestor allowlist is the chain’s trust root for the CPoW path; removing a compromised entry is a governance action that takes effect at the next block.
• Standard Cosmos params (consensus, bank, staking, etc.)

Voting is bonded-stake-weighted, using the Cosmos SDK default tally, with quorum = 0.334 of bonded stake. Stake is the Sybil-resistant denominator that consensus already trusts, and it is the tally in force today.

The intended direction is an attestation-weighted tally: a custom GovTallyFn 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 the operator's rolling attestation score, capped at 2 % of fleet-wide total (GovernanceCapBps = 200, a non-mutable protocol constant, so no single megafleet operator can dominate). The x/attestation governance-weight primitives are retained in the codebase as the path to it.

Trade-offs of the stake tally, stated plainly: passive token holders vote, so the “governance authority follows contribution” property is not yet in force, and there is no per-identity cap on stake weight. Both are addressed by moving to a capped attestation-weighted (or hybrid stake/attestation) tally through a subsequent upgrade. Validator-set composition and the live bonded distribution are public and queryable at any height from the endpoints in §3.4.

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. 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 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 rewards sustained network participation rather than redemption timing.

The chain ships with twenty-four 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, compute — 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

Appendix C — Version History

v6.0 keeps the v5.0 economic model intact and brings the document up to the current state of the chain. The substantive changes since v5.0 are additive: a new generic compute job marketplace (x/compute) joins the infrastructure markets; a new governance-set network fee floor (x/globalfee) makes the minimum gas price a consensus-level, gov-tunable parameter rather than a per-validator config; the node-license primary market gains an off-chain T01 pre-order fulfilment path (MsgAssignT01License) under a dedicated multisig, distinct from the T10 Strategic Reserve multisig; and the dual-token OPT carve-outs are fully gone (the former x/opt_exchange is now the dormant x/exchange_allocation). The first-party module count rises from 21 to 24 (x/compute, x/globalfee, x/txquery). No reward-track, supply, settlement-split, or lockup mechanics change in v6.0. One attestation-layer change does land: the per-license Cloud Work Unit (CWU) earning signal (RECEIPT_TYPE_CWU, §8.4), which supersedes Cloud Proof of Work liveness heartbeats as the signal that determines per-license reward weight while leaving every downstream reward-track, settlement, and supply mechanic untouched. See Appendix C.1 for the line-by-line v5.0 → v6.0 differences.

v5.0 was a wholesale rewrite of the protocol’s economic model and remains the basis of this document. The dual-token economy of v4.0 is gone — IOPT was removed in April 2026 and the chain is a single-token system in SOVR — and the emission model was replaced wholesale. Operator rewards are work-contingent across two tracks (Track A Bootstrap Rewards, Track B Usage Rewards) with no debt, repayment, or guaranteed-return framing. Node licensing moved from a flat IOPT mint to a Dutch-auction primary market with a fixed-price reserved-access seed. Service settlement no longer credits the serving operator directly; every settled SOVR is split 50/25/25 (Burn-and-Recycle to latent / fleet-wide operator pool / company) and the operator slice is distributed pro-rata at the daily flush. v5.0 supersedes v4.0 in its entirety — see Appendix C.2 for those differences. Numbering continues the v-series so readers coming from v4.0/v5.0 can track the progression.

C.1 Differences from v5.0 (v6.0 baseline)

v6.0 (June 2026) brings the whitepaper to the current state of the chain on master. The economic model is unchanged — supply machine, two-track rewards, 50/25/25 settlement, lock-claim with node idle, and the auction ladder all carry over from v5.0 verbatim. The differences are additive surface and accuracy fixes:

• New compute market (x/compute). A generic deterministic-compute job marketplace joins the infrastructure markets (§13.6). It ships with two active job types — JOB_TYPE_TRANSCODE and JOB_TYPE_CLASSIFY — billed on a hybrid output_units + uptime_blocks voucher (sovr:compute-voucher:v1), with per-job-type rate schedules, host-signed benchmarks (sovr:compute-benchmark:v1), and settlement through x/settlement.Split like every other market. JOB_TYPE_IMAGE_TRANSFORM is implemented and enrolls by chain upgrade. The compute worker is an off-chain component under the standard activation posture (§2).
• Network fee floor (x/globalfee). The minimum gas price is now a governance-set consensus parameter rather than a per-validator config (§2.1), default 0.001 usovr/gas, with an IBC-relay bypass allowlist and a bypass gas cap. It holds no funds and no per-account state, enforces in the ante chain (max(global, local)), and was introduced by the store-adding v0.6.0-globalfee upgrade — the first post-launch upgrade to add a module store.
• T01 pre-order fulfilment. The node-license primary market gains an off-chain pre-order path fulfilled on-chain by MsgAssignT01License under a dedicated t01_preorder_multisig_address, distinct from the T10 Strategic Reserve multisig (§4.1). Pre-order grants draw down the shared 1,000-node T01 inventory at clearing price 0 and are exempt from the 200-NFT per-wallet cap.
• First-party module count 21 → 24. Adds x/compute, x/globalfee, and x/txquery (a stateless merged sender-or-recipient transaction-query aggregator over CometBFT tx_search, with no state and no messages).
• OPT carve-outs fully removed. The former x/opt_exchange is the dormant x/exchange_allocation; no OPT-burn settlement path is active, and the auction settlement-kind enum reserves no live BurnReceipt variant.
• EVM bridge redesigned on Hyperlane (§16). The custom lock-and-mint x/bridge (and its Solidity + relayer daemon) is deleted; the bridge is now the x/evmbridge policy layer over upstream Hyperlane x/core/x/warp with a stock HypERC20 synthetic on Base (zero custom Solidity), shipping dormant/fail-closed in the v0.26.0-evm-bridge upgrade (bundled on mainnet as v0.26.0-combined, which also folds in x/wasmguard). Only the Base EVM deploy and the on-chain governance activation sequence remain before the bridge is enabled.
• Per-license CWU earning signal (RECEIPT_TYPE_CWU, §8.4). Attested-receipt earning evolves from CPoW liveness to measured Cloud Work Units — per-license compute/memory/storage/egress work units, scored by scoreCWU (per-term governance weights + per-term caps, non-negative clamp), bounded by the existing per-license rate limit, folded into the same 30-day rolling attestation score, and distributed through the existing Track A / Track B fan-out. No new module, message, or distribution path; a new receipt type and scorer on the existing attestor-allowlisted batch rail. The scoring parameters shipped dormant under the v0.11.0-cwu-earning upgrade (x/attestation ConsensusVersion 6 → 7 via Migrate6to7); CPoW remains the live earning signal until governance allowlists a CWU attestor. CPoW (§8.3) is retained for the transition; its retirement is a scheduled follow-up. Per-license work units on public state are a deliberate, accepted weakening of the companion CWU index’s fleet-scale privacy (§8.4).

C.2 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 became the initial Exchange Allocation in the v5.0 genesis allocation; v0.24.0 later adds 25 M to that latent earmark.
• 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 four-state invariant — latent + locked + vesting + claimed == 1B for all time — and “burns” are not destructions but Claimed → Latent transitions. Tokens never leave the loop; they cycle through it.
• Redline genesis allocation. v4.0 had no formal genesis-allocation table; the v5.0 six-bucket genesis model (730 M Latent / 150 M Bootstrap Rewards / 50 M Exchange Allocation / 50 M Liquidity Pool / 10 M Service Liquidity / 10 M Node Revenue Match) was the canonical genesis partition before the v0.24.0 post-genesis reallocation.
• 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 keeps the 180-day linear vest but removes the instant-claim portion entirely, makes the originating node idle during its own vest window, and routes emergency-claim forfeits straight back to Latent (instead of through a year-long re-emission pool).
• Dutch-auction primary market with reserved-access seed and a company reserve. v4.0 priced node licenses at a flat fee in IOPT. v5.0 mints licenses exclusively from x/auction. The 10,000-license cap splits into a 1,000-license Company Reserve Allocation (reserved as a Strategic Reserve and minted on issuance via MsgIssueT10License, not pre-minted) plus a 9,000-license sale ladder (T01–T09). T01 is a $3,000 fixed-price Reserved Access tranche available to approved participants under published eligibility rules; T02 is a $3,000 fixed-price Public Launch tranche (T01 and T02 priced identically — T01 is reserved-access, not discounted); T03–T09 are 72-hour linear Dutch decay. The 1,000 Company Reserve licenses are distributed by a Sovren multi-signature wallet via MsgIssueT10License rather than auctioned, and are not additive to the 10,000 cap. 200-NFT per-wallet cap on the public auction (T01–T09); 12-month transfer lockup on every minted license.
• 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. A custom GovTallyFn 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. The boundary between protocol-level governance (parameters, reward weights) and corporate authority (operations, treasury management, partnerships) is formalized. The live tally is bonded-stake-weighted; see §20.
• 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/exchange_allocation, 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 / exchange_allocation / 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.
• Cloud Proof of Work (post-v5.0 v0.5.x). A third attestation path lands on top of the v5.0 attestation model: RECEIPT_TYPE_CLOUD_POW = 10 and the attestor-allowlisted MsgSubmitAttestedReceipts re-entry path (Params.enabled_attestors[] with per-attestor AllowedReceiptTypes scope). v4.0 had no equivalent — there was no off-chain attested-receipt category at all. CPoW receipts go through the chain credit pipeline subject to a per-license per-credit-epoch cap (default 1, last-write-wins) and a credit-epoch governance parameter (credit_epoch_seconds, default 3600). The receipts are emitted by a new sub-128 MB pure-Go slim agent (cmd/slim-agent) operating under a master-key / per-agent-subkey delegation primitive. See §8.3, §17, and the full specification at specs/002-slim-node-128mb/.

C.3 v0.24.0 allocation update

The v0.24.0-reserve-reallocation software upgrade applies the approved reserve-allocation deltas after genesis. It is not a new genesis and does not issue outside the closed-loop 1 B cap. The upgrade draws 60 M SOVR from the latent protocol_emissions sub-bucket:

• 25 M moves to the Liquidity Pool Reserve, changing that allocation from 50 M to 75 M and the total to 7.5% of the hard cap.
• 10 M moves to the Service/OTC Liquidity Reserve, changing that allocation from 10 M to 20 M.
• 25 M moves to the latent Exchange Allocation earmark, changing its reserve cap from 50 M to 75 M and its share of the hard cap from 5% to 7.5%. Those tokens remain unissued.

The allocation baseline is 670 M for protocol_emissions, 150 M for bootstrap_rewards, 75 M for exchange_allocation, and 10 M for node_revenue_match, totalling 905 M; the reserve-wallet allocation is 95 M. Unchanged: the 1 B hard cap, the 150 M Bootstrap Rewards Reserve, the 10 M Node Revenue Match Reserve, the 50/25/25 settlement split, reward-track mechanics, and lockup rules.

C.4 v7.0 supply-disclosure correction

v7.0 corrects how the document describes supply. It changes no protocol mechanic.

• Latent is not “unminted.” Earlier versions described Latent SOVR as “not issued” and the non-genesis allocations as “unminted.” All 1 B SOVR exists on-chain from genesis — the closed-loop invariant latent + locked + vesting + claimed == 1B requires it, x/supply.Move transitions rather than creates, and x/mint is disabled. The corrected language describes Latent as held undistributed in the protocol reserve account (§3.1).
• New §3.4 Supply Disclosure. Maps the four protocol states onto Maximum, Total, Uncirculated and Circulating supply; states the circulating-supply formula; publishes the excluded reserve addresses; and fixes the treatment of liquidity positions, venue transfers, market-maker inventory, locked and vesting balances, and the IBC transfer escrow.
• Protocol reserve address published. The x/supply module account holding Latent SOVR is named in §3.1 and Appendix B. It is a module account with no private key.
• Reserve descriptions widened to match use. The Exchange Allocation covers trading venues whether centralized or decentralized, and its permitted uses are venue set-asides, listing costs, and market-maker inventory associated with securing listings; the prior “solely,” “untouched,” and “no issuance path” framings are replaced with a current-status statement and a governed-release condition (§3.2, §20). The Liquidity Pool and Service/OTC descriptions are stated in terms of issuer control.
• Ecosystem & Operations sub-allocation disclosed. Up to 25 M of the Liquidity Pool Reserve is available for marketing, advisory and consulting engagements, market-making retainers and inventory, listing costs, and Issuance Company operating costs. A disclosed sub-use of an existing allocation, not an additional allocation (§3.2).
• Entity terms defined. “The Company” and “the Issuance Company” are defined at the head of §3.

This whitepaper describes the protocol design as of the publication date. Implementation details remain subject to audit, governance approval, legal review, and final mainnet configuration. Public network metadata, chain parameters and integration tooling are published at github.com/sovrn-tech; live chain state is authoritative and queryable from the endpoints in §3.4. Where this document and live chain behavior diverge, the discrepancy should be reported as a documentation issue.