SOVR

A Sovereign Layer 1 for Decentralized Infrastructure Markets

Technical Whitepaper — v6.0

June 22, 2026

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 v6.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 minting. Of the 1 B cap, only 60 M is minted upfront at genesis (50 M Liquidity Pool Reserve + 10 M Service Liquidity Reserve, both held in company-controlled multisig wallets). Every other allocation — including the 730 M Latent / Protocol Emission Reserve, the 150 M Bootstrap Rewards Reserve, the 50 M Exchange Allocation, and the 10 M Node Revenue Match Reserve — remains unminted until protocol mechanics, approved reserve policy, or program rules trigger issuance or allocation.
• 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.
• Work-contingent rewards across two tracks. Operators earn through Track A Bootstrap Rewards (early-network operator support, funded by the 150 M Bootstrap Rewards Reserve) and Track B Usage Rewards (ongoing usage-linked emissions, gated by a burn-parity capacity rule). Both tracks require activation, module participation, attested work, and eligibility — neither is a debt instrument, yield product, repayment obligation, or guaranteed return.
• Pro-rata fleet-wide operator settlement. Service-channel redeems no longer credit the serving operator. Every settled SOVR is split 50/25/25: 50% Burn-and-Recycle to Latent, 25% into a fleet-wide active-operator pool, 25% to the hard-coded company sub-split (40/40/10/10 across Infrastructure / Ecosystem / DAO Treasury / Staking Pool). The operator pool drains pro-rata by attestation score at the daily flush.
• 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 already minted and held as a Company Reserve Allocation; the remaining 9,000 are sold across the T01–T09 ladder. T01 is a $3,000 fixed-price Reserved Access tranche; T02 is a $3,000 fixed-price Public Launch tranche; T03–T09 use 72-hour linear Dutch decay. A node license is a long-term infrastructure participation right, not a passive income instrument.

What follows is what the chain is today. 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: 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). Each is a module sharing one settlement primitive 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.
• 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.

2.1 The Network Fee Floor (x/globalfee)

Gas pays for consensus inclusion, not for the underlying infrastructure work. 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:

The floor is changed only through MsgUpdateParams under the standard governance authority; there is no admin override. 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.

3. Token Model

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

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.

3.2 Genesis Allocation

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

The two upfront-minted buckets (60 M total) sit in Claimed at genesis. Everything else (940 M) sits in Latent and migrates into Locked or Claimed only when the protocol's emission rules fire.

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 is not company revenue and is not shared with the company. It is reserved as future operator reward fuel, released only through protocol-defined emissions tied to verified infrastructure work.

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

4. Node Licensing and the Primary Market

Operator entry is gated by an NFT-backed node license. 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, and only those addresses can clear T01 bids. T01 participation does not create passive reward rights and does not alter the activation, attestation, lockup, or work-contingent reward requirements applicable to all node licenses.

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. These licenses are already minted and held in a Sovren-controlled multi-signature wallet. They are not offered via public auction and are not additive to the 10,000 cap. They may be used for strategic, operational, hosted-node, validator-support, ecosystem-development, partner-support, testing, or internal infrastructure purposes. 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 and a 180-day vesting condition upon staking.

T01 pre-order fulfilment: T01 is sold both on-chain and via an off-chain pre-order process fulfilled on-chain by MsgAssignT01License. A pre-order buyer pays through the portal off-chain; the dedicated T01 pre-order multisig then mints the purchased licenses to the buyer. Pre-order grants draw down the same 1,000-node T01 inventory as on-chain T01 bids. This multisig is deliberately separate from the T10 Strategic Reserve multisig: T01 pre-order fulfilment and Company-Reserve distribution are distinct signing authorities, each with its own governance-visible issued-count counter.

Two primary-market constraints apply:

• 200-NFT per-wallet cap on the public auction (T01–T09), enforced at the address level. T10 is exempt: strategic partners may receive arbitrarily many T10 licenses by design.
• 12-month transfer lockup on minted licenses (every tranche, including T10). Self-transfers bypass.

If a Dutch tranche reaches its floor and supply does not naturally exhaust within the 72-hour window, the price stays at floor and the tranche remains OPEN. Governance unblocks the ladder via MsgForceCloseTranche. This is the chain’s defined post-auction handling process for unsold supply; the unsold-node disposition 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.

Earning is gated separately. A minted license starts as inactive. The buyer must wait the activation delay, call MsgActivateLicense, register against an infrastructure module, 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.

4.3 Why a Dutch Auction

The earlier flat-price model under v4.0 had no mechanism to discover a clearing price — every license sold at the same number whether demand was 10× supply or 0.1×. Dutch decay lets the market price each tranche over a 72-hour window. The 200-wallet cap and 12-month transfer lockup keep the primary market distinct from a secondary-trading vehicle.

5. Operator Reward Architecture

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

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.

5.1 Track A: Bootstrap Rewards

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

• Track A is not a loan, debt instrument, repayment obligation, yield product, or guaranteed return.
• Track A rewards require activation, attestation, and eligibility. Attestation can be earned through (a) module participation — registering against an infrastructure module and producing in-process module receipts on verified work, or (b) Cloud Proof of Work (CPoW) — running a slim agent that emits liveness or light-client-verification receipts. 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 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.

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 — not to Track A or Track B emissions.

Launch defaults (governance-tunable):

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

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.

The hard-coded 25% company sub-split (40/40/10/10) 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, allocates shares pro-rata, and records each share in the settlement-layer claim ledger. If the pool balance or the active attestation weight is zero, the call is a no-op.

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 may emergency-claim mid-window. The emergency path releases the vested slice to Claimed and forfeits the unvested remainder back to Latent. There is no haircut to a third party: forfeited tokens fund future emission generally, in the same way the burn slice does.

Vesting is distinct from the withdrawal cooling-off period. VestingDurationSeconds (180 days) governs the claim flow on operator rewards. UnbondingDurationSeconds (45 days) governs withdrawal of a time-locked deposit position from x/lockup — a different state machine. The two never collapse onto the same timer.

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; 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, receipt type discriminator, metrics payload, timestamp and source-ID for dedup, and a signature over the domain-separated preimage (sovr:receipt:v1). Domain separation matters: every voucher / receipt / attestation kind uses a distinct domain tag, so a signature from one context cannot be replayed under another.

8.1 Receipt Fraud Challenges

MsgChallengeReceipt lets any participant flag a specific receipt as fraudulent: the challenger posts a dispute bond, references the receipt by id, and supplies evidence. An upheld fraud finding additionally slashes the receipt-issuing operator at SlashFractionFraudulent (default 5%). Receipt fraud is no longer “the host’s word,” it’s contestable.

8.2 Governance-Weight Primitive

GovernanceWeight(operator) returns the operator’s attestation 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.

8.3 Attested Receipts and Cloud Proof of Work

Beyond in-process module receipts and direct operator-signed receipts, 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 Cloud Proof of Work (RECEIPTTYPECLOUD_POW = 10).

Cloud Proof of Work (CPoW) is the receipt type a slim agent emits per credit epoch. A slim agent is a sub-128 MB, pure-Go, non-replaying agent that signs every report with a per-agent delegated subkey, emits either Tier-1 liveness heartbeats or Tier-2 light-client-verified attestations of chain state, and submits no transactions itself — its reports are batched and submitted by an allowlisted attestor.

The slim agent is not a chain-replaying node. 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 and Track A / Track B fan-out, subject to the per-license per-credit-epoch cap before contributing.

9. Track A Reserve Mechanics (x/tracka)

9.1 Reserve Ceiling

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

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. A node with no attestation in the relevant rolling window does not draw Track A. This protects the reserve against passive ownership.

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.

9.4 Compliance Framing

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

10. Node Revenue Match Reserve (x/bootstrap)

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

The reserve is unminted at genesis and migrates into the Locked state via the bucket-aware IssueFromBucketToLocked(noderevenuematch, ...) path only when match conditions fire; matched payouts vest exactly the way other operator rewards do. The pool halts on exhaustion: 10 M is what’s available, with no top-up mechanism.

Detailed cadence, tapering, eligibility, and sunset rules are defined under program governance prior to activation. 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 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.

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.

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.

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.

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; double-spending is impossible because the channel’s redeemed balance advances monotonically with every successful redemption.

13. Infrastructure Markets

The six markets — storage, gateway, bandwidth, inference, vectordb, compute — share one settlement primitive (x/payments channels redeemed through x/settlement.Split), one slash primitive, and one host-registration shape (license-gated via x/nodelicense.HasActiveLicense).

13.1 Storage (x/storage)

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.

13.2 Gateway (x/gateway)

x/gateway handles the entire class of metered delivery with per-request counters, parameterized by meter mode: BYTES (VPN, CDN, DNS-over-HTTPS, WebSocket relay) and REQUESTS (HTTP 402, per-API-call pricing). A stake-backed dispute primitive lives in the module, capped at MaxDisputeSlashBps (default 5%).

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.

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. There is deliberately no GPU tier enum on chain — hardware ages out of any fixed ladder within a release cycle. Hosts register against the permissionless on-chain model registry, publish per-model rate schedules, and submit host-signed benchmarks. Clients rank hosts off chain by whatever benchmark dimensions they care about.

13.5 Vector Database (x/vectordb)

x/vectordb is the index + ANN query service that pairs with x/inference for RAG workloads. The chain owns Collection records as first-class entities. Billing uses a single voucher with two meters: vector_blocks (storage-over-time) and queries (cumulative ANN query count), because write-heavy and read-heavy workloads have decoupled cost profiles.

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.

Two job types ship at launch:

Hybrid metering: a compute job is billed on two axes at once — a rate per output unit (the work axis) and a rate per uptime block (the availability axis, may be zero). Short-lived jobs typically price the output axis only.

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. x/identity provides that record — one per sovr_id, distinct from any wallet address.

Registration takes a refundable deposit (default 50 SOVR) rather than a one-time fee. The deposit is held in escrow for the lifetime of the identity, refunded on retirement, and slashable on misbehavior.

The critical property is key rotation without hijack: MsgRotateIdentityKey requires the outer transaction to be signed by the owner and carries an inner signature produced by the current identity pubkey. The chain rejects any rotation where the inner signature does not verify.

15. Policy (x/policy)

x/policy holds per-provider configuration on chain so it can be queried and cached by any edge middleware. The two reference use cases are HTTP 402 micropayments and reverse bot management (throttling unpaid traffic while prioritizing paying requesters).

Provider registration takes a refundable deposit (default 100 SOVR). 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.

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

SOVR is bridgeable to an EVM-compatible chain (initial targets: Ethereum mainnet and Base) as an ERC-20 via a lock-and-mint design. The chain ID of the EVM counterparty is a governance-tunable parameter, so the bridge module is not hard-tied to any single network.

• Decimal conversion: SOVR is 6-decimal on-chain (usovr), 18-decimal on the EVM side. The bridge applies a 10¹12 scale factor in both directions.
• Relayer quorum: Multiple relayers sign each direction’s confirmation message; the contracts enforce a configurable quorum threshold so a single compromised relayer cannot drain the bridge.
• Settlement integration: Bridge fees route through x/settlement.Split, applying the 50/25/25 economics to cross-chain transfers — a portion of every bridge operation is burned back to latent rather than retained as bridge revenue.

The multi-relayer quorum code has landed; only deployment and signer-set activation remain before the bridge is enabled.

x/bridge is complementary to IBC. SOVR ships IBC-Go v10 enabled, with transfer and Interchain Accounts modules wired in. Use IBC for Cosmos-native flows; 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; drift between them is a hard-forking bug.

17.1 Crypto-Agility, Not PQC

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

What has shipped is crypto-agility: every verification path accepts non-standard sizes through the Cosmos SDK’s cryptotypes.PubKey interface. 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.

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

19. Security Model

• Consensus integrity. CometBFT BFT tolerates up to 1/3 Byzantine voting power. Double-sign is slashable; extended downtime triggers jail. 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.
• 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.
• Sybil resistance for CPoW. A per-license per-credit-epoch output cap is applied at receipt admission. Multiple slim agents bound to the same license contribute to at most one credited receipt per license per epoch.
• Signature replay resistance. Every signed payload the chain validates is prefixed with a domain tag. Cross-domain replay is structurally impossible because the preimages differ by the domain prefix.
• 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.
• Bridge safety. Quorum-based relayer confirmations on both sides; no single relayer can authorize a mint or unlock. Bridge fees route through x/settlement.Split so a successful bridge raid does not retain proceeds — half of the take burns back to latent.
• Dispute bonds. Metered-delivery disputes require a posted bond in SOVR (100 SOVR per side at default), slashed on loss, capped at MaxDisputeSlashBps. Every service module’s dispute path calls into the same shared x/disputebonds primitive — the chain has one bond + slash mechanism, not five.

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.

Voting is attestation-weighted by default, not stake-weighted. The custom GovTallyFn replaces the SDK’s token-weighted tally with one that (a) requires every voter to hold at least one active staking delegation as a bonded-SOVR participation gate, and (b) weights each ballot by the operator’s rolling attestation score capped at 2% of fleet-wide total. A practical consequence: passive token holders with no infrastructure work do not vote.

21. Roadmap

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 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, one bond primitive, 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

Appendix B — Key Parameters at Mainnet Default

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