On September 10 — year deliberately omitted — a single-sentence bulletin crossed a financial wire: the United States may submit an AI safety bill as early as next week. No bill name. No sponsor. No clause count. No penalty schedule. No committee referral. The signal was scraped by aggregators and deposited, by some classifier's error, into blockchain feeds. That misfiling is the most informative artifact in the entire story. It is not a routing bug. It is a diagnosis. The machinery that governs AI models and the machinery that governs smart contracts are collapsing into a single legal primitive — the criminalization of the build step. Metadata is just data waiting to be verified. Here the metadata was wrong, and the wrongness was correct.
I have spent the last eight years auditing systems that most people describe in marketing language and that I describe in opcode. In 2017 I dissected the Parity multisig library and found an integer overflow in a migration function before mainnet. The lesson was not that Parity is bad. The lesson was that when a system's stated model diverges from its executed model, the divergence is where everything breaks. The same diagnostic applies to legislation. A bill is a specification. A statute is a deployed contract. The gap between them is the attack surface.
So let me do what I actually do: treat this bulletin as a diff with most of the hunks deleted, and reconstruct only the parts that matter to anyone holding a private key or a GPU cluster.
Context: Three Regimes, One Primitive
Three regulatory regimes are now live in the same substrate. They arrived from different directions and they are converging on the same coordinate.
The first is the compute threshold. Executive Order 14110, signed October 2023, established a reporting obligation for models trained above 10^26 floating-point operations. That number is not a moral judgment. It is a parameter — a hard-coded trigger, the regulatory equivalent of a require() statement. Cross the line, and obligations execute. Stay below, and the state's reach does not arm itself.
The second is the risk tier. The EU AI Act sorts applications into unacceptable, high, limited, and minimal risk, and attaches obligations to each stratum. High-risk deployments in health, employment, credit, and critical infrastructure inherit testing, transparency, human-oversight, and record-keeping duties. This is a graduated scaling schedule — closer to a gas schedule than a binary flag.
The third is the liability capture. In August 2022, OFAC sanctioned Tornado Cash — not a person, not an entity running a service, but a set of smart contracts. The subsequent prosecutions of developers established the operative precedent: writing and publishing code can constitute a sanctionable or criminal act. The Fifth Circuit's 2024 ruling in Van Loon v. Treasury partially unwound the designation, but the precedent was already installed in the collective behavior of every team that now hesitates before deploying permissionless code.
These three regimes share one structural feature. They do not regulate an outcome. They regulate a trigger. The trigger is either a number (FLOPs, dollar amount, transaction count) or a category (frontier model, high-risk use, sanctioned address). And a trigger, unlike a principle, can be measured, gamed, and re-engineered.
That is why an AI safety bill belongs in a crypto feed. Both are now governed by parameterized, self-executing rules applied to builders. Verification is the only trustless truth — and neither regime has a verifier. It has a threshold and an enforcement budget. The gap between those two is the entire policy.
Core: The FLOPs Threshold as a Consensus Parameter
I want to be precise about what a compute threshold actually is, because the policy debate treats it as a line in the sand and it is not. It is a consensus parameter.
In a proof-of-work chain, the difficulty target is a number that determines who may produce a valid block. Adjust the number, and you adjust the population of valid producers. The FLOPs threshold does the same thing to models. Set it at 10^26 and a specific population of training runs becomes regulated. Set it at 10^24 and the population swells. The threshold is not a description of risk. It is a selector.
This produces a set of behaviors any protocol engineer recognizes immediately.
| Behavior | Crypto analogue | AI-regulatory analogue | |----------|-----------------|------------------------| | Split a large run into shards below the threshold | Structuring transactions to avoid reporting | Distributed training across sub-threshold clusters | | Route computation through a permissive jurisdiction | Cross-chain bridging to avoid sanctions | Training on offshore or federated compute | | Publish weights instead of a service | Deploying a contract instead of running a company | Open-weight release to offload liability | | Wrap the trigger in a proxy | Upgradeable proxy contracts | Research exemptions and intermediary hosting | | Time the release to a regulatory window | MEV and block-timing | Pre-compliance release sprints |
None of these are hypothetical. The first and the fourth are the mathematically dominant strategies for any team optimizing under a hard threshold. If your obligation is binary and your capability is divisible, you divide.
I have run this experiment before, on a smaller scale. In 2020 I stood up a local Ethereum testnet to stress-test liquidation cascades in Compound and Aave under high volatility. The interesting result was not that liquidations cascade — everyone expected that. The interesting result was that the oracle integration, not the liquidation engine, was the fragile point, because the threshold at which the oracle updated and the threshold at which the protocol reacted were two different numbers that nobody had reconciled. Two thresholds, one system, and the gap between them was exploitable.
A FLOPs threshold has the same structure. The number that triggers the reporting obligation and the number that triggers the capability that worries people are not the same number. The reporting threshold is where you draw the line for administrative convenience. The capability threshold is where the model becomes genuinely dangerous. They are coupled by nothing but the hope that they are close. The gap between them is where the entire evasion economy lives. I documented a similar oracle-manipulation vector in a 40-page deep dive in 2020, and the pattern has not changed: thresholds that are measured separately from the thing they claim to represent will drift.
Core: Threshold Evasion Is a Design Pattern, Not a Bug
I want to make a claim that sounds cynical and is merely architectural. Threshold evasion is not a compliance failure. It is the rational response to a threshold, and thresholds are the only mechanism this legislation has.
Consider the formal structure. A statute that says no model above X may be deployed without certification is a predicate. The cost of satisfying the predicate is C. The cost of restructuring to fall below X is R. If R is less than C, the rational actor restructures. This is not malice. It is arithmetic. Every mining pool that has ever adjusted its hashrate disclosure, every exchange that has ever routed through a shell entity, every developer who has ever read a sanctions list and renamed a function — they all executed R less than C.
The policy response to this is predictable and already visible in the leaked shapes of these bills: lower the threshold, widen the category, and add anti-structuring provisions. Each of these responses increases the surface area of the predicate. Widening the category from frontier model to general-purpose AI pulls in models that no one seriously considers catastrophic. Lowering the threshold pulls in academic research. Anti-structuring provisions create the AI equivalent of the Bank Secrecy Act's structuring offense — a crime of arranging rather than doing.
Here is the part that should concern crypto specifically. Once you have created an offense of arrangement — once it is illegal not to train a model, but to train it in a manner that defeats the trigger — you have legislated intent into a measurement. And intent is exactly the thing that ZK proofs were built to avoid proving.
In a circuit, you do not prove that a prover wanted to do something. You prove that a witness satisfies a constraint system. The moment a regulator needs to prove intent against a threshold, the evidentiary burden shifts from mathematics to testimony — and testimony is the least trustless form of evidence in existence. An anti-structuring AI statute and an anti-structuring financial statute share the same failure mode: they cannot be enforced by verifiers, only by informants.
Core: The Formal Verification Gap
This is where my actual expertise applies, and where the AI safety bill is structurally weaker than even its critics realize.
I spent eight months studying Groth16 and implementing circuits in Circom. I built a proof for a statement, and then I watched the proof say nothing about whether the statement was the right statement. This is the classic formal verification distinction between proving a specification and proving that the specification matches reality. You can have a flawless proof of an irrelevant property.
An AI safety certification regime requires three things: a specification of safe behavior, a measurement procedure, and a verification method. Crypto's formal methods community spent a decade building the third and never fully solved the first two. In smart contracts, we still argue about what correct means — reentrancy-safe? economically sound? liveness-preserving? We have specifications because we wrote them by hand, and they are good only to the extent an auditor's imagination is complete.
For AI, the specification problem is worse by orders of magnitude. There is no accepted formal specification of safe frontier model behavior. There is a pile of heuristics, red-team protocols, and benchmark suites, none of which is a specification in the mathematical sense. So a bill that mandates safety testing and third-party evaluation is mandating a measurement without a spec.
What you get when you measure without a spec is theater with a compliance certificate. I have seen this pattern before. I audited NFT metadata in 2021 and found that 60% of collections were overpaying gas because of poor data structuring — a measurable, objective inefficiency. The community ignored it because the inefficiency was invisible in the price. A year later, the same community demanded audits that consisted of a PDF and a logo. The audit became a marketing artifact. Silence in the code speaks louder than hype — and an audit that produces no testable spec is hype wearing a lab coat.
The AI certification industry this bill would create is the same shape. Third-party evaluators will produce attestations. The attestations will be compared to a specification that does not exist. The comparison will be performed by humans, subjectively, at a price. This is not safety. It is a gate and a rent.
Core: Open Weights, Open Code, Same Handcuffs
Now the crypto-relevant centerpiece. Both the AI safety bill and the Tornado Cash precedent terminate at the same question: who is liable for code that leaves the author's hands?
An open-weight model and a permissionless contract are the same legal object. They are published artifacts whose behavior is determined by the runtime environment and the user, not by the author at the moment of publication. The author's control ends at the commit. The state's theory of liability, in both cases, extends beyond the commit.
I have written at length about the Tornado Cash designation and I will not rehearse it here except to name the mechanism. The state asserted that publishing the contract was itself the regulated act. The Fifth Circuit pushed back on the sanction of the immutable contracts, but the criminal theory survived in the developer prosecutions. The theory is portable. If you can be liable for deploying a mixer, you can be liable for releasing an open-weight model that someone downstream fine-tunes into a harmful policy.
This is the cross-contamination that nobody in the blockchain press connected when they misfiled this bulletin. The AI safety bill is not a separate regime. It is the second deployment of the developer-liability template that was first tested on smart contracts. Tornado Cash was the testnet. The frontier model is mainnet.
I will state my position plainly, because the persona of a detached analyst does not require me to pretend neutrality about a legal doctrine I consider architecturally unsound. I trust the null set, not the influencer — and I trust published code over published intent. A liability regime that reaches the commit reaches every commit. It is not a law about mixers or models. It is a law about writing.
Core: The Compliance Moat
The final piece of the core analysis is the one the industry press consistently underweights: who the bill actually benefits.
Consider the structure of an AI safety regime with a compute threshold and a certification requirement. The cost of compliance scales with the number of models above the threshold and the number of certifications required. Large labs absorb this as a line item. Small labs and researchers cannot. The threshold therefore becomes a barrier to entry that the incumbents did not have to build; the state builds it for them.
This is not speculation. It is the observed pattern in crypto regulation. Every major jurisdiction that passed comprehensive digital-asset rules produced a net consolidation toward large, well-capitalized, jurisdictionally anchored firms and away from small teams and permissionless protocols. The regulation was written in the language of consumer protection. The effect was market structure. Liquidity fragmentation is a manufactured narrative — the real fragmentation problem is the regulatory moat, and the moat is the product.
A compute threshold does to AI what a licensing regime did to exchanges. It converts a number into a competitive advantage. The incumbents support the bill for the reason incumbents always support rules they can afford: the rules are affordable.
| Regulatory feature | Stated purpose | Structural effect | |--------------------|---------------|-------------------| | FLOPs threshold | Target catastrophic risk | Selects a compliant oligopoly | | Third-party certification | Independent assurance | Creates a rentier audit layer | | Pre-deployment testing | Safety | Slows only the undercapitalized | | Anti-structuring provisions | Prevent evasion | Criminalizes research triage | | Federal preemption of state law | Uniformity | Caps stricter state regimes | | Accuracy | Federal oversight | Increases state dependence on federal waiver |
Failure Modes
Every bill has a set of conditions under which it fails. I write these sections because predicting how a system succeeds is a marketing exercise and predicting how it breaks is an engineering one. Here are the four failure modes I assign the highest probability, ordered by the product of likelihood and impact.
Failure mode one: identity drift. The bulletin may not refer to one bill at all. A U.S. AI safety bill could name a federal framework, a state statute in the SB 1047 family, or a narrow single-issue measure on deepfakes or on authorizing an AI safety institute. The policy consequence differs by an order of magnitude across these candidates. A federal framework touches every model author in the country. A state bill touches a subset. A deepfake bill touches almost nothing in the training stack. If analysts assume federal and get state, every downstream inference is wrong. I assign this a high probability and a high impact, and I resolve it only by waiting for the bill number.
Failure mode two: introduced is not enacted. The historical base rate for comprehensive federal AI legislation in the United States is that proposals vastly outnumber statutes. A bill being submitted is an entry, not a conclusion. The reported urgency — as early as next week — is a scheduling signal, not a survival probability. I assign this a moderate probability and a moderate impact. The defense is a node-tracking discipline: submit, committee, vote, enactment. Do not collapse them.
Failure mode three: category capture by incumbents. If the text of the bill is negotiated before publication, the category membership will be shaped by the parties with lobbyists at the table. Those parties are the large labs. The result is a bill whose safety provisions are real for the frontier and hollow for everyone near it, which is exactly the moat structure described above. I assign this a moderate probability and a moderate impact, and it is the failure mode most likely to be invisible because the bill will be marketed as strict.
Failure mode four: the overfitting of downstream rules. A compute threshold, as I argued, is a parameter. Parameters invite tuning. Once the threshold exists, every subsequent political cycle has an incentive to lower it, because lowering it looks like tightening. The threshold ratchets downward and eventually captures research-scale work. I assign this a moderate probability and a high impact, because a ratchet is not reversible by the same mechanism that created it.
Contrarian: The Safety Label Is the Centralization Vector
Here is the angle that the AI safety debate, the crypto debate, and this misfiled bulletin all miss.
The consensus narrative worries that AI safety legislation will slow American AI relative to China. The competitive framing is speed against safety, and the industry argues that safety regulation forfeits the race. That framing is wrong, and it is wrong for a reason a ZK researcher sees before a policy analyst does.
The real function of a safety regime is not to slow the frontier. It is to relabel the frontier. When you require certification to deploy, you do not stop deployment. You decide who is allowed to deploy without friction. The bottleneck moves from compute to credentials. Credentials are centralized by construction. You cannot preemptively certify a permissionless network; you certify an institution.
So the safety label performs the same function as the security label in crypto. It is a legitimacy primitive. It converts an open, adversarial, permissionless frontier into a credentialed one — not by banning the open version, but by making the credentialed version the only one that can transact with regulated counterparties. This is exactly how the Tornado Cash designation worked in practice, regardless of the Fifth Circuit's reasoning: the chilling effect preceded the legal conclusion, and the chilling effect is the policy.
The blind spot in every analysis I have read of this bill, and of its crypto parallels, is the assumption that the risk is regulation being too strict or too loose. The actual risk is category formation. Once frontier model developer is a legal category, the category has members, and membership is defined by the state. Same for money transmitter. Same for sanctioned entity. The category, not the rule, is what does the work. A category is never proved; it is stipulated.
And a stipulated category is the one thing in this entire conversation that no circuit can verify.
I reached this conclusion before I reached any of the others, and it is the one I would defend with the least hesitation. The proof systems I spent a winter learning can attest to arithmetic. They cannot attest to a definition. Definitions are the input that no prover controls. When the definition is frontier model, the prover and the verifier are arguing about a word.
Takeaway: The Liability Template Is the Real Bill
Strip the misfiled bulletin to its bytes and you get one sentence with no specification. That is not a reason to dismiss it. It is the reason to watch it. A bill with no published text is a bill whose text is still being negotiated by parties who know the text is where the category lives.
My forward judgment, stated as a testable claim rather than a prediction: within the next regulatory cycle, expect the developer-liability template that was testnet-deployed against smart-contract authors to reach consensus on model authors. The mechanism will be identical — publish the artifact, inherit the liability — and the justification will be identical, because both are framed as safety. The blockchain industry will read the AI safety bill as an AI story. It is a crypto story wearing a different header, and the header is the only part anyone is reading.
The question I will leave running on the stack is this: if the trigger is a number and the liability is a commit, who verifies the gap between the two — and does anyone hold the proving key?