Extremely Selective: The Export-Control Phrase That Breaks Decentralized Compute

Jensen Huang went on Lex Fridman's podcast and said export controls should be "extremely selective." Three reasons, in his framing: promote global partnerships, preserve economic strength and innovation, and avoid pushing competitors into self-sufficiency. I read the transcript twice. Not for the geopolitics. For the adjective. Selective is a fine word in a policy memo. It is a broken word in a protocol. Last quarter I spent three weeks auditing a DePIN compute network — tokenized GPU capacity, the kind of project that raised a nine-figure round and posted a manifesto about censorship-resistant inference. I was looking for one thing: how the protocol handled geo-fencing. It did not. It could not. The contract could mark a wallet. It could not mark a chip. Those are different objects, and the gap between them is where this entire debate actually lives. That gap is what Huang is really talking about, whether he knows it or not. And the bull market is not pricing it. Export controls operate on a physical object. The chip has an ECCN classification, a country of destination, an end-user. The Foreign Direct Product Rule extends reach to foreign-made goods that touch US technology. Enforcement is document-based: licenses, end-use statements, audits. The entire apparatus assumes you can interrogate a transaction at the point of sale and decide, in that moment, whether the buyer intends to train a recommendation model or a targeting model. You cannot. AI accelerators are the cleanest dual-use technology ever built. The same H100 that serves a chatbot weights serves a drone-swarm simulator. There is no register on the die that flips when the workload becomes military. Selectivity, then, is not a property of the chip. It is a property of the use, and use is observable only after the fact — through monitoring, telemetry, and inference about intent. Now drop that problem into crypto. Decentralized compute networks — Render, Akash, io.net, a dozen smaller forks — sell access to physical GPUs through token incentives. The pitch is that you can rent compute without a gatekeeper. The reality is that every one of these networks sits on top of hardware that is legally located somewhere, owned by someone, subject to some jurisdiction's export regime. The token is permissionless. The silicon is not. That collision is the actual story, and almost nobody covering Huang's quote is covering it. Here is the technical problem, stated plainly. To be "selective," an export-control regime needs to classify use at the moment of access. To classify use, it needs visibility into the workload. To get visibility into a decentralized compute network, it needs an attestation layer — a way to prove that a given GPU is physically where it claims to be, running what it claims to be running, for whom. That layer is the whole ballgame. Everything else is commentary. I went looking for that attestation layer in the protocol I audited. I found marketing. The network's docs claimed "hardware-verified location." The implementation was a signed JSON blob from the node operator. Self-reported. A node in a sanctioned jurisdiction could attest to any coordinates it liked, because the attestation key and the physical machine were controlled by the same party. I wrote a harness that spun up forty mock nodes, fed them fabricated geolocation, and watched the protocol accept every one. Twelve edge cases later — spoofed coordinates, relayed inference, a GPU physically in one country fronted by a coordinator in another — the "verified" claim was dead. Code is the only law that compiles without mercy, and this code compiled a lie. This is not a knock on one team. It is structural. Physical-layer attestation in a permissionless network is a trust problem dressed as a cryptography problem. You can sign a message. You cannot sign the fact that the silicon is in Singapore. A zero-knowledge proof can attest to a computation, but it cannot attest to the physical substrate running it without trusting the party that generated the proof — which returns you to the exact centralized oracle you were trying to escape. I ran into the same wall building an AI-oracle prototype two years ago. I wrapped model outputs in proofs and benchmarked latency against a conventional oracle network. The proofs verified. The overhead killed the use case for anything time-sensitive. Attestation is not free, and at the physical layer it is not even cheap. Every claim of "verified location" carries a hidden trust anchor. When you find it, you find the gatekeeper the network swore it had removed. So what does "extremely selective" actually require? It requires a trusted middle layer that sits between the chip and the buyer, inspects the workload, and issues a verdict. That is a gatekeeper. And a gatekeeper is precisely the thing decentralized compute claims to eliminate. The crypto narrative and the export-control regime are not compatible. One of them has to bend, and the physical layer does not bend. Huang's third reason — avoid competitors becoming self-sufficient — is the most interesting, because it is a crypto argument wearing a trade-policy suit. It is the logic of lock-in. Keep the counterparty dependent; do not force them to fork. In protocol terms: a chain that maintains dependency through network effects survives; a chain that pushes users past the switching cost gets forked into irrelevance. The math is the same. Lock-in beats blockade when the switching cost is high enough, and blockade accelerates the switch when it is not. That is not a diplomatic observation. It is a reflex from watching every "irreplaceable" protocol get replaced within two market cycles. Risk Reality Check. The tokenized-compute sector is priced as if hardware access is a commodity and demand is infinite. Neither assumption survives contact with the enforcement layer. Hardware access is the one input a state can actually choke, because it is physical and attributable. The token layer is frictionless; the layer beneath it is a supply chain with customs forms. When the two layers disagree, the physical layer wins every time. That is not a political opinion. It is an engineering constraint, and it is the one variable absent from every compute-network token model I have read this year. The restaking crowd should recognize the pattern. In 2025 I audited slashable-stake mechanisms and found the economic penalties insufficient to deter Sybil behavior in low-liquidity conditions. The same flaw recurs here: the security assumption — "the operator won't lie about location" — is asserted, never stress-tested. A signed blob is a promise. A promise is not a proof. Audit reports are hope, not guarantee, and attestation without a physical anchor is hope with a hash. The counter-intuitive part is not that export controls are hard to enforce. Everyone knows that. The counter-intuitive part is that "extremely selective" is the most dangerous phrase in the sentence — more dangerous than "total ban." A total ban is legible. It is a line. You can build around a line. A selective regime is a judgment call, and a judgment call requires someone to make it, which means someone holds discretionary power over which code runs and which hardware ships. Selectivity is permission. Permission is the opposite of permissionless. I watched this exact movie with Tornado Cash. The lesson there was not that sanctions are bad. The lesson was that when enforcement becomes selective — when the state decides which smart contracts are lawful based on inferred intent — the developer becomes the defendant. The code did not change. The interpretation did. A selective export regime sets the same template for compute: the network operator becomes liable for the workload it cannot see, and the only defense is surveillance of its own users. Writing code is not a crime, but selectively enforced code is a liability, and the line between them is drawn by whoever holds the discretion. That is why the censorship-resistant compute pitch is mostly marketing. The physical layer is inherently attributable. A GPU draws power at a known address. Decentralizing the token does not decentralize the substation. Anyone selling you sovereignty at the token layer while renting silicon at the physical layer is selling you a fork of an argument they have already lost. The liquidity-fragmentation playbook has a new costume, and it is compute. The signal to track is not Huang's opinion. It is attestation. If decentralized compute networks cannot produce hardware-level proof of location and workload — and right now they cannot — then selective enforcement will route around them, straight to the coordinator and the cloud provider. The protocols that survive the next regulatory cycle will be the ones that admit the physical layer is centralized and design the trust boundary honestly, instead of pretending a signed JSON blob is a proof. So the question worth asking is not whether export controls should be selective. It is this: when the first compute network gets served a selective-enforcement order it cannot technically comply with, does it fork the policy, or fork itself? Code is the only law that compiles without mercy. The rest is negotiation.