Send a prompt to any major AI API and ask which machine processed it, in which building, in which country. You will not get an answer. Not because it is secret, but because the question does not fit the architecture. Your request went to a region, the region is a continent-sized abstraction, and inside it your tokens went wherever capacity was.
For most people that is fine. For a hospital, a law firm, a bank, or anyone whose regulator asks where personal data is processed, "eu-west" is not an answer to a question about jurisdiction.
A decentralized network is the only shape that could answer it properly, because every request lands on one identifiable machine rather than into a pool. So we went and looked at what ours can actually prove. This is the honest version, including the parts we cannot do yet.
What we know, and how we know it
Every node reports its location, which lands in the database alongside its hardware. Across 129 non-demo nodes with location data, the fleet sits in 32 countries:
| nodes | countries | |
|---|---|---|
| In the EU | 33 | 9 |
| Outside the EU | 96 | 23 |
Every inference request records which node served it. That link is not inferred or sampled — it is written on the row, because the scheduler had to pick a machine and the machine had to answer. Six months later we can still say which physical computer produced a given response.
That is already more than a centralised API can tell you. It is not yet proof of anything.
Why IP geolocation is evidence, not proof
Node location comes from geolocating the machine's public IP. That is the standard method, and it is honest about roughly where a connection emerges. It is not a statement about where a computer physically is.
A provider behind a VPN reports the VPN's country. A provider on a business connection whose IP block is registered to a head office in another country reports the head office. Neither is lying; the method simply measures something adjacent to the question.
So a node that says Germany is probably in Germany. For a marketing page that is enough. For a compliance answer it is not, and we would rather say so than let a customer discover it during an audit.
Anyone selling you "EU-only inference" on a decentralized network today is, unless they say otherwise, selling you IP geolocation. It is worth asking them which.
What would make it provable
The gap between evidence and proof is not unbridgeable. It is a stack, and each layer costs something:
Latency triangulation. Physics is harder to fake than a header. A machine claiming Frankfurt that answers Frankfurt in 90 ms and Singapore in 12 ms is not in Frankfurt. Round-trip times from several known points bound where a machine can be, and the bound tightens with more vantage points. It cannot place a node in a city, but it can rule out a continent — which is exactly the granularity a jurisdiction question needs.
Provider identity. A tunnel is anonymous; a company is not. A provider who has completed business verification and signed terms naming a jurisdiction is making a legal statement about their hardware, with consequences. That is a different kind of claim than a packet header, and for a regulator it is the kind that counts.
Hardware attestation. The strongest layer and the least available. A GPU that can sign a statement about its own state, in a confidential-computing mode, would let a machine prove what it is running as well as where. This exists on H100-class hardware and does not exist on the consumer cards most of our network is built from.
We have none of these three today. We have the routing record and the geolocation, and we know the difference between them.
The part we can already do
What is real today is narrower and still useful: because every request is bound to an identifiable machine, a customer can constrain which machines are eligible.
The scheduler already supports pinning a model to a named set of nodes — we use it to keep large models on cards that fit them. The same mechanism can pin a workload to a set of nodes chosen for where they are, which turns "somewhere in our fleet" into "these nine machines, and here is the list."
That is a meaningful thing to be able to say. It is also honest about its own weakness: the list is only as good as the evidence behind each entry, and today that evidence is geolocation plus whatever we know about the provider.
The number that matters for anyone considering this: five EU nodes were online at the time of writing, out of 33 registered. Constraining a workload to a jurisdiction on a network this size means accepting a much smaller pool, with the queueing and availability that implies. Anyone who tells you otherwise has not counted.
Why we think this is the interesting question
The AI infrastructure market is converging on a small number of very large providers, and the pitch is uniformly about capability and price. Jurisdiction is treated as a checkbox satisfied by a region name.
Meanwhile the regulation is going the other way. GDPR Article 28 has always cared where processing happens; NIS2 and the AI Act increasingly ask organisations to know their supply chain rather than trust it. "We use a major provider" is becoming a weaker answer every year, and the answer that replaces it has to be specific.
Specificity is the one thing a decentralized network has structurally. Not because it is more virtuous, but because a request that lands on one identifiable machine leaves a record that a request into a capacity pool cannot.
We are not there. We can tell you which machine ran your prompt, we can constrain which machines are allowed to, and we can tell you honestly that our location data is evidence rather than proof. The three layers that would close that gap are known, costed, and not built.
Writing that down is the point. A company that tells you what it cannot yet prove is easier to check than one that tells you it already can.
If verifiable processing location is something your organisation needs rather than prefers, we would like to talk — both about what it would take and about what it is worth. That conversation is more useful to us than another guess.
