VCC Threat Model (v0.1)

This is the standalone threat model the charter commits to publishing openly. The architecture is intended to be revised against this document and against adversarial test results, never weakened without quorum.

The VCC's single product is verifiable common knowledge. Every threat below is framed by what it does to that good: a threat matters insofar as it lets a party appear compliant while defecting, or lets a faction capture the machinery that produces the common knowledge.

T1, Off-the-books compute (the coverage hole)

Threat. Hardware-enabled and attestation-based approaches govern only the equipped frontier. A motivated actor can acquire or repurpose unequipped compute that emits no attestation at all. The hole widens over time: as algorithmic efficiency improves, the FLOP threshold for a dangerous run falls, so more and more compute becomes capable of a relevant run, eroding coverage.

Why it bites. Attestation can only speak to what is instrumented. Silence is not proof of compliance unless silence is itself made suspicious.

Mitigation. Pair on-platform attestation with independent signals so that un-attested large-scale compute is itself anomalous and visible:

chip supply-chain / registry data (where did the accelerators go?);
datacenter power and footprint analytics (what is drawing the load?).

The design goal is coverage over a party's entire equipped fleet and a world in which the absence of a heartbeat is itself the alarm.

T2, Spoofing & the brokenness of existing schemes

Threat. Verification primitives can be forged. Proof-of-Learning, as published, is more broken than commonly assumed: an adversary can forge cheaper training transcripts that nonetheless pass verification. Any scheme adopted naively becomes a rubber stamp.

Why it bites. A verifier that can be spoofed produces false common knowledge, worse than none, because it manufactures misplaced confidence.

Mitigation (strategic consequence). Before the VCC endorses any verification primitive, that primitive must survive an open, reproducible adversarial test suite, a "Pwn2Own / MITRE ATT&CK of compute verification." The red-team harness lives in adversary/ and is a credibility flywheel: in security, only what survives public attack is trusted. We build the adversary alongside the verifier, released under coordinated disclosure (charter §6.5), because an open cookbook for spoofing verification is exactly what a defector wants.

T3, Neutrality capture

Threat. A single state or lab gains effective control over hosting, funding, or rule-updates, and quietly bends the regime toward its interest, or defangs it.

Why it bites. If any one party controls the rule-set, every other party is right to distrust the output, and adoption dies. Capture destroys the common knowledge at its source.

Mitigation.

Adversarial board (§6.2): seats span mutually-distrusting constituencies, multiple labs, multiple governments across blocs, academic cryptographers, civil society. The point is not harmony; it is that no faction can capture the rule-set.
The ratchet (§6.3): tightening transparency/verification is easier to pass; weakening either requires a supermajority of mutually-distrusting parties.
Diversified funding (§6.4): no majority dependence on any single lab or state, funding concentration is capture by another name.
Multi-jurisdictional / neutral seat (§6.1): reduces single-state leverage.

T4, The legitimacy trap

Threat. A "coordinated slowdown" that merely lets the least cautious actor catch up makes everyone less safe. Framed wrong, the platform reads as a call for unilateral disarmament, which no one will sign.

Why it bites. This is a political/structural failure, not a technical one, and it can kill adoption even if every cryptographic guarantee holds.

Mitigation.

The platform must be valuable even if a slowdown never triggers (hence the peacetime-first strategy, charter §5): provenance, export-control compliance, IP-preserving audit are independently useful.
It must never be framed as unilateral disarmament. Its job is to create the option for a credible, mutual, verifiable pause, not to advocate that any single party stop alone.
The reciprocal reveal escrow (§4.6) makes any pause symmetric and simultaneous: no party reveals or stops first.

Cross-cutting design rules these threats impose

Negative claims are the hard part. Verification must prove "I did not run above N FLOPs," not just "here is the run I did." That requires compute accounting with double-counting prevention and fleet-level coverage.
Open verifier, private inputs. Verification logic ships open and auditable; verification inputs stay private (TEEs, ZK where tractable).
Silence must be expensive. Independent signals make un-attested compute anomalous, so coverage gaps cannot be exploited quietly.
Adopt nothing that hasn't survived the adversary. No primitive enters the verifier until it has been attacked in the open.

v0.1, tracking the charter. Revised against adversarial test results; never weakened without quorum.