privacy · proofs · compute
v1.5 · checksummed

§25. Operator & Investor Checklist

v1.3
Cite this section

Copy/paste (plain text):

Jason St George. "§25. Operator & Investor Checklist" in Next Generation Stores of Value: Privacy, Proofs, Compute. Version v1.3. /v/1.3/read/part-v/25-operator-investor-checklist/

§25. Operator & Investor Checklist

The last piece of Layer 6 is a practical checklist: how builders, operators, and allocators decide whether this stack (or any competing system) actually qualifies as a next‑gen store of value in the triad frame.

Think of it as a set of questions you can ask with numbers behind them.

25.1 Triad supply: Privacy, Proofs, Compute

For each leg of the triad:

  • Privacy.

    • Are there live, non‑custodial privacy corridors with measurable anonymity sets?
    • Are shielded pools growing in depth and churn?
    • Are lawful‑privacy patterns (viewing keys + receipts) actually used, or just aspirational?
  • Proofs.

    • Is there a robust supply of proofs for canonical workloads?
    • Are VerifyPrice SLOs met consistently (p95 times/costs)?
    • Is proof production diversified across hardware profiles, geographies, and operators?
  • Compute.

    • Are meaningful amounts of useful compute (MatMul, inference, etc.) actually being proven?
    • Is there a liquid market for Work Credits or equivalent instruments?
    • Are triad workloads tied to real‑world demand (AI, compliance, analytics), or mostly synthetic?

If any leg is tokenized but not actually supplied and used, the monetary story is thin.

Value Capture & Anti-Bypass

The most important questions for evaluating whether the SoV thesis holds:

  • Can users buy equivalent Privacy, Proofs, or Compute service without the native asset?
  • Are fees actually paid in the asset, or do most operators accept and immediately off-ramp alternatives?
  • Are burns and collateral lockups material relative to total supply?
  • Is there a visible bypass channel (hyperscaler-hosted provers, stablecoin-denominated services) that captures most of the demand without flowing through the asset?
  • Does governance have the power to redirect value away from holders (e.g., by eliminating burns, inflating supply, or changing fee routing)?
  • Is the Wrapper Dominance Ratio (§6.4) rising while native fee share, private settlement, and collateral lockups stagnate?
  • Is price being cited as evidence of monetary adoption in place of native fee, burn, collateral, and settlement series (§6, Market-Price Non-Equivalence)?

If the answer to any of these is ‘yes,’ the system may be useful infrastructure but the SoV thesis is weakened or falsified.

Institutional Holdability

  • Is custody support available from regulated custodians?
  • Is the legal classification clear enough for treasury or fund mandates?
  • Is the asset auditable enough for institutional reporting requirements?
  • Is liquidity deep enough for institutional-scale positions?
  • Is there a valuation policy that allocators can apply (fee-flow models, comparable frameworks)?

Holdability is a virtue with a bill attached (§4.5, Tension 3). Every question above should therefore be paired with its market-realization counterweight:

  • Does wrapper growth seed native usage, or substitute for it? Is the Wrapper–Native Growth Gap (§23.1.1) persistently positive?
  • What share of supply sits under custodial control (CCR), and how concentrated is that custody?
  • Is delta-adjusted synthetic exposure (SER) large relative to liquid free float?
  • Do daily-reset leveraged products exist on the asset, and what is their net mechanical gain κ\kappa and Wrapper Recycling Ratio?
  • Is exposure concentrated in a small number of dealers or counterparties, and has the hedge-instrument mix shifted from physical to swaps to options?
  • Is demand governed by a small number of common rebalancing policies (Policy Concentration Ratio)?

25.2 Stack health: Layers 0–6

Layer 0 (Verifiable Machines).

  • Are there documented hardware profiles, lot sampling, and attestation strategies?
  • Is there meaningful open hardware participation, or only a single closed‑vendor stack?
  • Are there visible incident reports for hardware issues?
  • Are Facility Capacity Receipts available and independently verifiable (§14.5.1)? Is Physical VerifyPrice within bounds (§19.7.4)?

Layer 1 (Reachability).

  • Does VerifyReach show resilient connectivity across multiple ASNs and countries?
  • Are there alternative transports (satellite, mesh, pluggable transports), or just standard ports and IPs?

Layer 2 (Distribution & Execution).

  • Are clients and runtimes distributed via multiple channels (repos, torrents, side‑loads), or only via one app store?
  • Are binaries reproducible and signed?

Layer 3 (Identity & Claims).

  • Are pseudonymous credentials and selective‑disclosure proofs actually integrated, or is everything tied to real‑name KYC at the edge?
  • Can actors prove rights without doxxing themselves?
  • Is non-custodial usage share and dossier-minimization score visible (§3)?

Layer 4 (Truth & Work).

  • Are canonical workloads and proof systems clearly documented?
  • Is VerifyPrice monitored and within target SLOs?
  • Is proof production decentralized?

Layer 5 (Value & Settlement).

  • Are non‑custodial corridors and shielded pools live, healthy, and diversified?
  • Is refund safety enforced and tested?

Layer 6 (Governance & Telemetry).

  • Are there public dashboards for VerifyPrice, VerifyReach, VerifySettle, decentralization, and hardware profiles?
  • Are governance processes documented with clear control surfaces?
  • Are there recent, honest incident reports?

Market Realization Plane (around the stack, not in it).

  • Is VerifyFlow published at all (§23.1.1)?
  • Are wrapper inventory, creations/redemptions, flow elasticity, concentration, and the Wrapper–Native Growth Gap visible?
  • Is the market-realization stress harness (§23.5) run and reported?
  • Remember that this plane sits around the stack: its failure does not break the protocol, but its opacity breaks price interpretation.

If one layer is fundamentally weak, the whole triad is living on borrowed time.

25.3 Telemetry honesty: Verify* signals

Telemetry itself can be gamed. Checklist for telemetry honesty:

  • Open data.

    • Are raw metrics or sampling methods public, or only summarized charts?
    • Can independent teams reproduce Verify* metrics?
  • Client diversity.

    • Are metrics gathered by multiple clients and operators, or by one privileged actor?
  • Incentive alignment.

    • Is there any incentive to under‑report problems (e.g., governance rewards for “no incidents”)?
    • Are whistleblower or bug‑bounty‑style incentives in place to surface bad news?
  • History and continuity.

    • Are there historical series for Verify* metrics, or only recent snapshots?
    • Do metrics continue through crises, or do dashboards conveniently go dark?

A system with no telemetry is untrustworthy. A system with one vendor’s telemetry is fragile. A system with multi‑source, reproducible telemetry has a shot at being money.

25.4 Red flags and failure patterns

Finally, some patterns that should trigger skepticism:

  • Closed hardware monoculture.

    • One TEE, one vendor, no sampling, no open profiles → Layer‑0 cliff.
  • Opaque bridges.

    • “Magic multisig” bridges with no proofs, unclear jurisdiction, and no incident history → not settlement rails, just custodial risk.
  • Foundation fiat.

    • Major parameter or policy changes via blog post, with no on‑chain trace, no telemetry, and no incident report → governance capture.
  • Zombie corridors.

    • Privacy rails that haven’t moved meaningful volume in months but still appear in marketing.
    • Anonymity sets that are effectively dead.
  • Proof theater.

    • Lots of “ZK” branding but no public VerifyPrice metrics, no canonical workloads, no commodity verifiers.
  • Governance theater.

    • Token votes with single‑digit participation deciding fundamental parameters; no constraints; no SLOs.
  • Price as proof.

    • Marketing that cites market capitalization, wrapper AUM, product launches, or trailing returns as evidence that the monetary thesis is working, while native fee, burn, collateral, and settlement series are absent or flat → financialization narrated as adoption (§6, Market-Price Non-Equivalence).

Any one of these is survivable in the short run; taken together, they say:

“This is not a triad‑backed money system; it is a platform dressed as one.”


Part V closes the governance loop:

  • It treats SLOs and dashboards as the constitution.
  • It makes Verify telemetry* the lifeblood of neutrality and repression‑resilience.
  • It frames law and politics as constraints to be engineered around, not as deities to be appeased.
  • It gives builders and allocators a practical checklist for deciding whether a system’s “store of value” claim is mathematically grounded or just well‑typeset.

With Layer 6 in place, the stack has all three angles:

  • Money (triad as SoV),
  • Stack (Layers 0–6), and
  • Telemetry (Verify* keeping it honest).

Part VI can now focus on dynamics (adoption curves, risk, and implementation sketches): how this thing actually gets built, traded, attacked, and, if it works, quietly becomes part of what the world calls “money.”


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