§4. Threat Model: Adversaries, Assets, and Assumptions

Jason St George. "§4. Threat Model: Adversaries, Assets, and Assumptions" in Next Generation Stores of Value: Privacy, Proofs, Compute. Version v1.4. /v/1.4/read/part-i/4-threat-model/

§4. Threat model: adversaries, assets, and assumptions

Why a threat model? This thesis argues that Privacy, Proofs, and Compute can function as monetary primitives when verification is cheap and public. A threat model makes that claim falsifiable. It defines what we must protect, who is trying to break it, where the trust boundaries lie, and which metrics decide if the system remains credible under pressure. It sits between first principles and implementation so that every later design choice can be traced to an explicit adversary and invariant.

Every architecture is, implicitly, a bet about who will attack it and how. Up to this point we have argued from first principles: what a store of value must survive, and why Privacy, Proofs, and Compute can be engineered to meet those conditions. The next step is to be explicit about the pressure this stack will live under.

The backdrop is already in view. Macroeconomic arithmetic makes financial repression attractive: debt stocks in the hundreds of percent of GDP, negative real rates by policy, capital controls and captive balance sheets as standard tools rather than emergency measures.

At the same time, the web’s trust default has flipped from “trusted unless flagged” to “untrusted unless proven” as deepfakes and coordinated moderation make memory itself a soft target. The combination is simple and brutal: states are incentivized to squeeze balance sheets and communications; platforms are incentivized to mediate reality; hardware and networks are increasingly treated as levers of policy, not neutral infrastructure. Against that field, a “next‑gen store of value” is not being asked to survive price volatility; it is being asked to survive a world that optimizes for control.

4.1 Scope and assets

The scope is the full Create/Compute → Prove → Settle → Verify loop and its hardware base layer. At minimum, we need to protect four things:

1. Integrity of receipts & state. Proofs, provenance, settlement artifacts, and consensus state must not be silently corrupted.

2. Confidentiality of flows. Private settlement with optional disclosure, not privacy that evaporates at the first audit request.

3. Availability & neutrality. Open admission for provers and users, anti‑capture, and non‑seizable settlement paths.

4. Verifiability economics. Verification must remain cheap in absolute and relative terms; otherwise “anyone can verify” collapses into “someone we have to trust.”

These map directly to the SoV properties enumerated in §3. The assets at risk are not just balances on ledgers. They are the whole loop and the matter it runs on.

• At the bottom lie machines: chips, RNGs, secure elements, TEEs, capture devices, modems, routers, and the power infrastructure that feeds them.
• Up one level sit the proofs and receipts that describe what those machines did: provenance attestations, computation proofs, settlement artifacts, audit trails.
• Above that are the flows of value and obligation that ride on those receipts: private payrolls, cross‑chain settlements, inference contracts, collateral arrangements.
• Threaded through everything are the communications substrate that carries claims and proofs, the software distribution channels that keep clients coherent, and the identity and key material that bind actions to actors without doxxing them.

All of these must remain sufficiently intact that savings, truth, and compute can continue to clear when old guarantees fail.

4.2 Adversary classes (capabilities & goals)

We care about several classes of adversaries:

• State‑level repressors. Impose negative real yields, capital controls, and hardware mandates; gate on‑/off‑ramps; require closed attestation; seek to turn banks, clouds, app stores, and IXPs into enforcement arms.

• Platform cartels. Strip or obscure provenance; collude on labels; prefer vendor‑mediated “trust” and walled‑garden verification.

• Economic attackers. Miner/prover cartels, router capture, MEV/censorship, liquidity games on swap corridors, front‑running and soft‑forking that tilt rules in their favor.

• Hardware/supply‑chain adversaries. Trojans, biased RNGs, covert debug paths that turn “proof” into theater; opaque TEEs whose attestation keys terminate in unaccountable HSM farms.

• Energy & physical‑interdiction adversaries. Curtail, ration, or price‑discriminate against verification workloads; deny interconnection; withhold long‑lead grid equipment; prioritize state or industrial load over third‑party proving (§4.6).

• Cryptanalytic / PQ attackers. Proof forging or signature breaks; long‑horizon post‑quantum risk.

• UX / vaporware risk. Spec‑drift and unverifiable performance claims that corrode credibility, even if the cryptography is sound.

• Compositional / mechanical adversaries. No hostile intent at all: locally rational agents whose incompatible operating rules combine into concentration, procyclicality, and false price signals.

Of these, the primary adversary in this frame is not a cartoon hacker but the rational sovereign under stress. A state that must service promises larger than its productive base will reach, as history shows, for the levers it actually controls: interest‑rate caps, yield‑curve control, capital controls, regulated custody, and mandatory “secure” hardware and identity schemes. It will be tempted to turn banks, clouds, app stores, hardware vendors, and IXPs into enforcement arms: require real‑name registration at the edge; throttle or shut down networks in the name of stability; mandate TEEs whose attestation keys terminate in state‑controlled HSMs; define “safety” as surveillance.

In parallel, platforms facing regulatory and reputational risk will centralize moderation and provenance: which media is shown, which credentials count, which proofs are recognized. The danger is not that any one actor becomes an obvious villain, but that their combined incentives re‑create a soft but totalizing chokepoint architecture.

Beneath that sovereign‑platform axis are economic adversaries: miners, provers, routers, and liquidity providers who prefer rent to work. They will collude if they can, capture matching engines and orderflow, quietly prioritize their own routes, soft‑fork the rules in their favor, or simply withdraw service when it suits them.

If verification becomes expensive or gated, a priesthood of “trusted verifiers” will emerge, and with it all the familiar pathologies of rent extraction and arbitrary censorship.

And below them, like bedrock or landmines, are hardware and supply‑chain adversaries: fabs and vendors (sometimes complicit, sometimes merely compromised) who can bias randomness, slip trojans into IP blocks, leave “debug modes” wired to secrets, or ship opaque enclaves that amount to remote‑controlled kill switches. If the machine can corrupt inputs, leak witnesses, bias randomness, falsify energy receipts, or centralize useful-work markets, the economic claims built on those machines become unreliable—even if the underlying proof system remains mathematically sound.

Administrative Repression

The most probable control regime is not always a ban. It is administrative convergence. Banks, platforms, app stores, identity vendors, cloud providers, telecoms, stablecoin issuers, custodians, and regulators converge around safety, convenience, compliance, and fraud prevention. Each measure is defensible in isolation; together they turn optional rails into de facto mandatory rails.

Definition: Administrative Repression. The conversion of formally optional financial, identity, compute, and settlement rails into practically mandatory rails through custody defaults, compliance rules, app-store control, tax treatment, institutional mandates, benefit systems, and platform terms of service.

The stack must therefore defend against soft capture as much as hard censorship. The key question is not only “Can the protocol still run if banned?” but “What share of real usage remains non-custodial, private, verifiable, and protocol-native when compliant alternatives are easier?” This is the same substitution risk introduced in §2.1.1 (Treasury Market as Control Panel) and formalized as the Wrapper Dominance Ratio in §11.

Compositional and Mechanical Adversaries

Administrative repression still assumes intent, however diffuse. There is a further class of threat that requires no intent at all.

Not every threat to monetary integrity is an attacker. Some emerge from locally rational agents operating through incompatible rules. Product sponsors maximize fee revenue. Investors chase themes or rebalance portfolios. Authorized participants arbitrage discounts to net asset value. Dealers hedge swaps and options. Passive funds follow mandates. Trend systems follow prices. Each actor can behave rationally within its own boundary while the combined machine produces concentration, procyclicality, discontinuity, and false price signals.

Definition: Compositional Adversary. A failure mode in which no participant behaves maliciously or even irrationally, but the interaction of their operating rules produces emergent mechanical dependence, correlated behavior, recursive leverage, procyclical amplification, and prices that no longer carry information about the underlying system.

The threat here is not a villain; it is the sum of locally rational walls. A repression-resilient monetary architecture must therefore measure not only hostile actions, but emergent mechanical dependence, correlated operating rules, recursive leverage, and the failure of stabilizing flows. This is the adversary class that the Market Realization Plane (§6.5) exists to make visible, and that VerifyFlow (§23) instruments.

With this addition the threat model now spans three distinct kinds of failure: hostile capture (state and platform coercion), institutional co-option (administrative repression and wrapper substitution), and endogenous mechanical fragility (compositional adversaries). A design that defends against only the first is defending against the least likely.

4.3 Threats by loop stage (and the intended mitigation)

We can slice the threat surface by stage in the Create/Compute → Prove → Settle → Verify loop:

• Create/Compute.

  • Threats: poisoned models, mislabeled workloads, biased hardware profiles, hidden accelerators.
  • Mitigation: canonical workload registries, hardware profiles bound to receipts, open benchmarking, attested hardware provenance.

• Prove.

  • Threats: junk proofs, prover cartels, selective service, “house‑only” pricing.
  • Mitigation: multi‑ZK adapters, neutral routers with fairness tests, SLA escrows & slashing; publishing entry‑latency, top‑N share, and geography/ASN distributions.

• Settle.

  • Threats: corridor censorship, refund failure, deanonymization, bridge compromise.
  • Mitigation: adaptor‑signature swap kits, lawful‑privacy corridors (viewing keys + auditable receipts), bridge‑safety templates, mandatory refund‑safety, public VerifySettle metrics.

• Verify.

  • Threats: verification‑cost creep; opaque clients; “trust our node” monocultures.
  • Mitigation: laptop‑grade verifiers, reference harnesses, verify predicates embedded in SDKs, public p50/p95 telemetry via the VerifyPrice observatory.

• Telemetry & Governance.

  • Threats: silent centralization, KPI gaming, governance capture.
  • Mitigation: open dashboards for VerifyPrice, VerifyReach, VerifySettle; decentralization metrics (house share, geo/ASN spread, time‑to‑first‑proof); incident reports; hard rules about what must be public before changes ship.

• Layer 0.

  • Threats: “trust the vendor” cliff, mandatory closed TEEs, unmeasured side‑channels.
  • Mitigation: open RTL or microarchitectures where possible, lot sampling and imaging where not, SNARK‑wrapped attestations, and explicit side‑channel budgets.

Another view is by plane rather than loop stage:

• Communications plane. DPI, SNI filtering, BGP manipulation, and blunt‑force shutdowns all aim to make the network unreachable when it matters most.
• Hardware plane. Closed designs and supply‑chain opacity threaten to turn cryptography into ritual.
• Proof & accountability plane. Prover cartels, biased routers, unverifiable performance claims can turn receipts into marketing.
• Settlement plane. Bridges, custodians, and on‑/off‑ramps can be throttled or deputized until “bearer” assets behave like permissioned IOUs.
• Work plane. Useful‑work mining and verified inference can silently degrade into “whoever owns the strangest accelerator and tightest regulatory capture wins.”

Each plane can be attacked directly, and each can be used as leverage on the others.

Taken together, these attackers are all trying to break the same design North Star: pay the machine only for work anyone can verify cheaply, and give humans privacy by default with auditability by consent. Everything else in this thesis is just scaffolding around that rule. Wherever the loop can be subverted (by making work useless, verification expensive, or privacy and settlement gateable), you get repression rather than neutrality.

4.4 Mapping the authoritarian playbook → countermeasures

We can sketch several canonical “playbook moves” and the corresponding counter‑moves. The table below maps real‑world censorship and surveillance tactics to the stack’s countermeasures:

Beyond these network‑level moves, the financial and institutional playbook includes yield-curve control, capital controls, mandatory “secure” hardware mandates, platform-mediated reality attacks, and proof priesthoods. For each of these macro attacks, the stack provides specific countermeasures that are detailed throughout the document and formalized as testable stress harnesses in §23.4.

The high-level pattern:

• Yield‑curve control + captive balance sheets → triad assets with no fixed coupons, Work Credits priced by market demand for Privacy/Proofs/Compute rather than by decree.

• Capital controls + KYC choke points → non‑custodial privacy corridors (BTC↔ZEC/XMR) that remain viable without centralized exchanges; VerifySettle metrics that make corridor health public.

• Mandatory “secure” hardware + identity schemes → Layer‑0 verifiable machines with open or sampled designs; hardware‑profile receipts; identity schemes at Layer 3 that separate accountability from doxxing.

• Platform‑mediated reality + provenance stripping → PIDL‑encoded receipts for media and computation; PaL to compile provenance claims into portable proofs that survive platform stripping.

• Proof priesthoods + closed verifiers → laptop‑grade reference verifiers; multi‑backend proof systems; VerifyPrice observatories that publish verifier costs and failure rates.

The thesis responds by treating neutrality, privacy, and verifiability as service‑level objectives, not vibes.

Layer 0 is framed as verifiable machines because it is precisely here that a stressed sovereign will try to install repression tooling “below” the protocol, through mandatory TEEs, certified HSMs, and national‑security carve‑outs. The triad is framed as monetary base because repression will attack duration instruments and custodial rails first. VerifyPrice is introduced not as an aesthetic metric but as the economic hinge that keeps verification cheap enough that anyone, not just a priesthood, can check the receipts.

The Create/Compute → Prove → Settle → Verify loop is unpacked because each stage is a natural chokepoint that must be deliberately de‑choked:

• Open workloads and hardware profiles at Create.
• Multi‑ZK, open‑router proof markets at Prove.
• Non‑custodial privacy rails with refund‑safe swaps at Settle.
• Laptop‑grade verifiers and public dashboards at Verify.

Telemetry is elevated to its own layer because without public numbers (on verification cost, decentralization, corridor health, and swap success), claims of neutrality and censorship‑resistance are indistinguishable from marketing. “No dashboards, no trust” is not a slogan; it is the governance rule that keeps the system from quietly sliding back into gatekeeping.

At the same time, the threat model forces us to acknowledge assumptions. We assume:

• At least one family of open, sampled hardware profiles exists per canonical workload.
• Commodity cryptography remains unbroken or can be upgraded in time.
• Somewhere in the network there remain paths (over fiber, radio, satellite, or sneakernet) through which claims and receipts can flow.
• There is enough dispersed energy and hardware for independent verifiers to run.

We are clear about non‑goals. The stack does not certify metaphysical “truth” of media, only provenance and process. It does not promise perfect openness in fabs or chips on day one, only measurable progress and falsifiable claims. It does not abolish volatility or political risk; it channels them through verifiable economics rather than opaque decrees.

In that sense this threat model is simply the negative image of the North Star. “Pay the machine only for work anyone can verify cheaply” is not a poetic line; it is the design rule that each adversary will try to break in their own way. The rest of the document can be read as the counter‑move: verifiable machines to keep the silicon honest; Privacy, Proofs, and Compute wired into a loop that cannot easily be captured; VerifyPrice and settlement telemetry to keep verification and neutrality public; communications, identity, energy, and distribution layers treated as first‑class infrastructure rather than afterthoughts. Only when all of these hold together (under repression, not just in peacetime) do Privacy, Proofs, and Compute deserve to be called monetary primitives rather than a beautifully typeset wish.

4.5 Explicit tensions and boundary conditions

Two tensions within this thesis deserve explicit acknowledgment. Ignoring them would make the framework less credible; addressing them honestly strengthens it.

Tension 1: Privacy by default vs. coercion at the social layer

The concern: Lawful privacy proposes “optional disclosure via viewing keys.” But if disclosure becomes mandatory at chokepoints (exchanges, employers, landlords, visa applications), “optional” becomes fiction. The technical guarantee of privacy could be circumvented by social or legal coercion.

What the system can and cannot guarantee:

How the stack reduces coercion surface:

1. Data minimization: By default, nothing is revealed. Coercion must extract keys, not merely subpoena records that already exist.
2. Decentralized verification: No single auditor or platform must see all flows. Selective disclosure can be scoped narrowly.
3. Multi-jurisdiction design: Corridors, mirrors, and provers are distributed so no single legal regime can compel universal disclosure.
4. Exit optionality: Even under local coercion, users retain technical ability to move assets to less-coerced jurisdictions—if corridors remain open.

Honest acknowledgment: Lawful privacy is a technical property, not a social guarantee. It cannot prevent a sufficiently powerful adversary from coercing individuals. What it does is (a) raise the cost of mass surveillance (each disclosure requires individual coercion), (b) preserve optionality for those in less-coerced environments, and (c) make the coercion visible through telemetry rather than hidden in platform logs.

Tension 2: Verified compute vs. hyperscaler dominance

The concern: Compute is dominated by a handful of hyperscalers (AWS, Azure, GCP) and chip vendors (NVIDIA, AMD). If verified compute becomes valuable, won’t these incumbents simply dominate issuance and markets, making “decentralized” PoUW a fiction?

What the system offers vs. hyperscalers:

Why decentralized verified compute wins in specific scenarios:

1. Repression scenarios: When a hyperscaler is compelled to ban certain workloads or customers, decentralized alternatives remain available. The value proposition is not “cheaper” but “still available.”

2. Proof-heavy applications: For workloads where verifiability is the product (compliance proofs, provenance, audit trails), the receipt is the value—not raw FLOP cost. Hyperscalers don’t currently sell receipts; they sell capacity.

3. Certain procurement regimes: Governments, NGOs, and enterprises with sovereignty constraints may prefer compute that doesn’t route through foreign hyperscalers or vendor-controlled enclaves.

4. Composability with privacy: Hyperscaler inference is logged. Verified inference over privacy rails is not. For sensitive workloads (medical, financial, personal), the privacy premium justifies higher cost.

Honest acknowledgment: Decentralized verified compute will not beat hyperscalers on raw cost. It competes on verifiability, permissionlessness, and censorship-resistance. In a benign environment, hyperscalers win on price. In a repressive or high-stakes environment, verified compute wins on trust properties. The thesis bets that demand for these trust properties is structural and growing.

Telemetry response: If hyperscaler concentration in verified compute markets exceeds thresholds (e.g., >50% of VerifyPrice-tracked capacity from 3 vendors), this is flagged in dashboards. The decentralization metrics in §22–23 make this drift visible, not hidden.

AI Homestead vs. AI Enclosure

The hyperscaler tension above is a cost-and-verifiability question. Underneath it sits a sharper political one. AI is the first new frontier since the closing of the physical frontier, but it can be homesteaded or enclosed. In the homestead path, models, tools, proofs, and compute markets distribute cognitive leverage outward. Individuals, small firms, local institutions, agents, and open-source networks gain new capacity to act. In the enclosure path, cognition is rented from a handful of walled gardens. Users receive outputs but not sovereignty; access is mediated by terms of service, identity, payment rails, jurisdiction, and platform risk.

The triad is the monetary and technical response to enclosure. Privacy preserves the right to transact and coordinate without becoming fully legible. Proofs preserve the ability to verify claims without trusting platform labels. Verified compute preserves access to machine intelligence with receipts rather than vendor promises.

Definition: Homestead Ratio. The share of verified compute, proof generation, and AI-service capacity supplied by open-admission, non-hyperscaler, geographically diverse, independently verifiable operators.

An Enclosure Risk Flag triggers when more than a threshold share of VerifyPrice-tracked capacity comes from a small number of hyperscalers, closed TEEs, or single-jurisdiction facilities — the same telemetry response introduced above, read through a civic rather than purely economic lens.

The goal is not simply to make AI outputs auditable. It is to keep the AI frontier from becoming a tollbooth on human agency — the same demand this thesis names agency preservation in §2.4 and §3.

Tension 3: Institutional holdability vs. native monetary function

The third tension is the one most likely to be mistaken for good news.

Regulated wrappers may accelerate access, liquidity, legal clarity, and institutional holdability. They can also produce holders without users. A spot ETF may hold the underlying asset while shielding its investors from self-custody, private settlement, native fees, proof procurement, and verified-compute consumption. A treasury company may amplify exposure through debt and equity issuance without increasing protocol-native demand proportionally. A daily-reset leveraged wrapper may amplify price further while introducing path dependence and forced rebalancing that has nothing to do with the protocol at all.

Institutional wrappers are not automatically hostile, and the reflex that every ETF is an adversary is as lazy as the reflex that every ETF is adoption. The real question is empirical: does wrapper growth seed native use, or permanently substitute for it? Public telemetry must therefore distinguish accessibility from monetary adoption. §25 states the holdability requirements; §23 states the measurements that keep them honest.

These tensions are not defeaters of the thesis; they are boundary conditions. The stack does not promise to solve all social and political problems. It promises:

1. Technical guarantees that are real within their scope.
2. Telemetry that makes boundary violations visible.
3. Economic and architectural design that expands the scope of those guarantees over time.

If these boundary conditions tighten—if coercion becomes universal or hyperscalers capture all verified compute—the thesis weakens. But the design goal is to push against those boundaries, not to pretend they don’t exist.

4.6 Energy & Physical Interdiction

The playbook above is financial, informational, and legal. It has a physical companion that is easy to omit because it looks like infrastructure policy rather than monetary policy.

Every threat class enumerated so far assumes the machines are running. The adversary corrupts inputs, gates verification, captures governance, strips provenance, or mandates attestation. In each case there is still a facility drawing power, and the contest is over what that facility is permitted to do. A more elementary move is available: decide what the facility is permitted to draw.

A state that finds it awkward to ban verification can simply decline to energize it.

The instruments. Energy interdiction is unusually attractive to a rational sovereign under stress because it is administratively cheap, legally unremarkable, and rarely legible as repression:

• Curtailment and rationing. Interruptible‑load classifications applied selectively; verification and proving workloads designated non‑essential during scarcity.
• Interconnection denial and queue position. Not a prohibition, merely a multi‑year wait, applied unevenly.
• Tariff discrimination. Punitive rate classes for compute‑intensive load, justified on grid‑stability or environmental grounds.
• Long‑lead equipment scarcity. Transformers, switchgear, and turbines allocated by policy rather than by price. Nothing is banned; the queue simply never advances.
• Load prioritization. Sovereign or national‑champion AI build‑outs and industrial demand given precedence over third‑party proving for the same electrons.
• Water and cooling constraints. Permitting used to reach the same result as an energy denial.

Note that none of these requires hostility toward cryptography, and most survive judicial review comfortably. This is what makes the class distinct from administrative repression (§4.2): there is no order to comply with, and therefore nothing to resist.

Why this belongs in the threat model. Two reasons, one narrow and one structural.

The narrow reason is that §4.1 already names “the power infrastructure that feeds them” among the assets to protect, and then never returns to it. The asset is declared and left undefended.

The structural reason is more serious. The thesis makes verification affordability a constitutional target and treats its breach as fatal. Those targets are correctly described as exogenous to token price. They are not exogenous to the conditions under which power and reference hardware can be obtained, and those conditions are partly set by states. An adversary who can move the physical cost of verification can therefore trigger the thesis’s own primary failure condition without touching the mathematics, the governance, or the market.

That is a qualitatively different attack from the rest of this chapter. Every other adversary here must break something we are watching. This one adjusts a parameter we had classified as an environmental constant.

Distinguishing two exposures. The precise causal path differs between the two halves of the loop, and conflating them produces overclaims in both directions:

• Verification runs on reference hardware at the edge in small amounts. Its exposure is not bulk power but obtainability of unprivileged reference hardware, plus edge power and connectivity cost relative to local income.
• Proving and verified compute consume bulk power. Their exposure is energy price, firmness, curtailment risk, and competition from industrial and state load.

Bulk electricity prices do not directly break “anyone can verify,” because verification is not a bulk‑power activity. Export controls and platform lockdown do. §14 develops this distinction, and sovereign optionality (§14) gives it a metric.

Response posture. The stack’s answer is the same one it gives everywhere else: make the exposure measurable, then let it bind against issuance.

• Facility Capacity Receipts (§14.5.1) already record curtailment exposure, fuel mix, backup duration, and jurisdictional power risk.
• Sovereign optionality (O_s, §14) aggregates those fields into one exposure that can be published and challenged.
• Risk haircuts (§27) price fragility into Work Credit issuance rather than discovering it during a disruption.
• A dedicated red line (RL13, §27) retires the thesis if verification affordability becomes a sovereign policy variable rather than a market outcome.

What the stack cannot do is engineer its way out of physics. If a jurisdiction decides that third‑party proving will not be energized, the correct response is dispersion and honest reporting, not a claim that cryptography makes the grid irrelevant.

Tip: hover a heading to reveal its permalink symbol for copying.