privacy · proofs · compute
v2.0 · checksummed

2. Threat Model: What Must Survive

v2.0
Cite this section

Copy/paste (plain text):

Jason St George. "2. Threat Model: What Must Survive" in AfterFiat: The Load-Bearing Thesis. Version v2.0. /v/2.0/brief/read/threat-model-what-must-survive/

Threat Model: What Must Survive

The protected object is not a token balance in isolation. It is the complete Create/Compute \rightarrow Prove \rightarrow Settle \rightarrow Verify loop and the physical and institutional substrate beneath it. Four properties must survive:

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

  2. Confidentiality of flows. Privacy must survive ordinary use; optional disclosure cannot mean a master key or universal transaction graph.

  3. Availability and neutrality. Users and providers require open admission, reachable routes, non-seizable settlement, and practical exit.

  4. Verification economics. Checking a claim must remain cheap in absolute terms and cheap relative to producing it. Otherwise public verification degrades into a trusted-verifier priesthood.

Adversary classes

The rational sovereign under stress uses the levers it controls: negative real rates, capital controls, custody rules, identity mandates, hardware standards, app stores, telecoms, clouds, and interconnection queues. The likely form is often not prohibition but administrative repression: formally optional rails become practically mandatory through defaults, compliance rules, tax treatment, benefits, procurement, platform terms, and institutional mandates.

Platforms and strategic patrons can centralize provenance, decide which proofs count, privilege national champions, and convert private compute into protected quasi-public infrastructure. This enclosure by rescue may be more dangerous than overt attack because the closed competitor can be well funded, technically excellent, energy-privileged, and genuinely useful.

Economic and compositional adversaries include prover cartels, router capture, liquidity games, dealer hedging, wrapper redemptions, leverage, and common operating rules. No participant need be malicious. Locally rational behavior can still produce correlated sales, recursive leverage, procyclicality, concentration, and prices that reveal little about native use.

Hardware, supply-chain, and physical adversaries exploit biased randomness, closed attestation roots, firmware control, export restrictions, curtailment, discriminatory tariffs, cooling constraints, transformer queues, network cuts, or load priority. A state that finds verification awkward to ban can decline to energize proving or make unprivileged verifier hardware unobtainable.

Cryptanalytic, governance, and vaporware risks remain ordinary but fatal: proof-system breaks, captured update keys, unverifiable benchmarks, silent parameter changes, and performance claims without reproducible data.

The competent closed-stack competitor

The real competitor is not necessarily a failing state. It is a competent closed sovereign stack integrating energy, industry, compute, identity, payments, and duration warehousing. Such a system may win on cost, latency, uptime, and construction speed. AfterFiat’s claim is not capability superiority. It is that non-custodial settlement, private-by-default disclosure, portable identity, independently checkable receipts, and practical exit are distinct properties. A closed stack withholds them because that withholding is what makes it closed.

The scoreboard must therefore include agency and exit. Two systems can show identical throughput and uptime while giving opposite answers to the question: can the participant leave with keys, assets, proofs, and usable service?

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