UK data residency and sovereignty for chain infrastructure
UK data residency is usually treated as answered once someone names a region in a cloud console. That is the easy part of the question and it is not really the point. The harder, more useful question is who can be compelled to hand over the data or the infrastructure, and whether that can actually be checked.
For chain infrastructure specifically, this matters more than for a typical workload, because the assets at stake are keys, not just data. A validator signing key, an oracle node's operator credentials, or a staking cluster's threshold shares are the kind of thing worth having a specific, answerable story about: which building this is physically in, which jurisdiction governs that building, and who else, under what law, could compel access to it.
Why "hosted in the UK" is not the same as UK sovereignty
A hyperscaler's UK region answers the region question. It does not answer the other two. The company operating that region is typically headquartered elsewhere, incorporated and answerable under a different set of laws, and able to change the specific facility, ownership structure, or terms behind that region without much say from the tenant. The tenant knows where the workload runs today. They usually cannot say with certainty who else can reach it, or what would change that.
That gap does not disqualify cloud for most workloads. It matters specifically when the thing being hosted is a signing key or an operator credential, where the point is that only named, known parties should ever be able to touch it.
The same distinction shows up in cloud-native architecture more broadly, separate from chain infrastructure specifically: a control plane and a data plane are not the same thing, and where each one sits, and who operates it, can diverge even when a console shows one tidy region label. A workload's data might be pinned to a UK region while the control plane, or the vendor relationship standing behind it, sits somewhere else entirely. Chain infrastructure inherits that same split, with higher stakes attached to it. The equivalent of the control plane is whoever holds or can influence the signing key, not simply where a validator client happens to be running today.
What an actual answer looks like
A defensible sovereignty answer for chain infrastructure has three parts, and all three need to hold at once.
Where it physically sits. LinkPool runs infrastructure on owned, dedicated hardware across three availability zones in Manchester. That is a fixed, physical answer, not a region selector in a console.
Who you are actually contracting with. The infrastructure is owned and operated by LINKPOOL UK LIMITED, Companies House number 14448543, incorporated in October 2022, and infrastructure contracts sit with that UK entity. Knowing the domicile of the entity a contract sits with, not just the region label on an invoice, is the second half of the sovereignty question, and it is worth asking of any provider, not only LinkPool.
Whether it can be demonstrated, not just asserted. Access to the infrastructure itself is locked down at the API level: an immutable operating system with no interactive login and no ad-hoc configuration changes, so the audit trail is the deployment history in Git rather than a log of who happened to log in that week. That is something a provider can document and show on request, instead of something a customer has to take on trust from a compliance certificate alone.
Where this differs from a rules-compliance checklist
Sovereignty is not the same question as regulatory compliance, though the two get treated as interchangeable. MiCA, for instance, asks CASPs to document business continuity plans and ICT risk management. We covered that ground in our piece on MiCA infrastructure requirements. That is a rules question: which documented controls does a regulator want in place. Sovereignty is a separate, prior question: who physically controls the infrastructure and under whose law, independent of whichever rulebook currently applies. An operator can satisfy every item on a compliance checklist and still be one ownership change away from a different jurisdiction governing its infrastructure. The physical and legal facts are what a checklist is trying to approximate, not a substitute for them.
Why this is becoming a live question, not a hypothetical one
Institutional allocators moving from delegated staking to running their own validator infrastructure are already asking jurisdiction questions as a matter of course, because that shift is precisely a move toward wanting first-party answers instead of a provider's assurances. We covered that shift in why institutions are running their own validators. The same first-party instinct applies to the infrastructure location question. A UK-regulated entity, or any institution answerable to a UK regulator, asking where its validator or custody infrastructure physically sits is not a compliance formality. It is the same question any company would ask about a critical vendor: who exactly can reach this, and under what law.
For teams building or buying chain infrastructure with UK exposure, the practical version of the sovereignty question is short. Name the building. Name the jurisdiction that governs it. Name the documentation that proves both.
Asking us the same questions
Those three questions are the ones worth putting to any provider, and they are the ones we expect to be asked. UK data residency for chain infrastructure is a procurement question with physical and legal answers, not a checkbox, so the answers should be specific enough to verify.
If you are working through them for a validator, oracle or RPC workload with UK exposure, the RPC and validator pages set out where the infrastructure sits, how it is run and what we take on.
Frequently asked questions
Is UK data residency the same as UK sovereignty?
No. Residency is about which region a workload runs in, which is the easy half. Sovereignty is about who can be compelled to hand over the data or the infrastructure, and under whose law. An operator can host in a UK region while the entity controlling the infrastructure sits under another jurisdiction entirely.
What should you ask a provider about UK data residency?
Three things. Where the infrastructure physically sits, naming the buildings rather than a region selector. Who you are actually contracting with, meaning the domicile of the entity the contract sits with. And whether either can be demonstrated on request rather than only asserted in a compliance certificate.
Why does jurisdiction matter more for chain infrastructure than for ordinary workloads?
Because the assets at stake are keys, not just data. A validator signing key, an oracle node's operator credentials or a staking cluster's threshold shares warrant a specific answer about which building they are in, which jurisdiction governs that building, and who else could compel access to it under what law.
Is LinkPool a UK company?
Yes. The infrastructure is owned and operated by LINKPOOL UK LIMITED, Companies House number 14448543, incorporated in October 2022, and infrastructure contracts sit with that UK entity. Every server is owned hardware across three availability zones in Manchester.
Does regulatory compliance answer the sovereignty question?
No, they are separate questions. Compliance frameworks such as MiCA ask which documented controls a regulator wants in place. Sovereignty is the prior question of who physically controls the infrastructure and under whose law. An operator can satisfy every item on a compliance checklist and still be one ownership change away from a different jurisdiction governing its infrastructure.