# LinkPool: full text > Every LinkPool product page and article as plain markdown. Canonical URLs are given above each section. Index: https://linkpool.com/llms.txt --- Source: https://linkpool.com/ # Dedicated Kubernetes for crypto workloads LinkPool Metal Kubernetes (LP MKS) is dedicated bare-metal Kubernetes for validators, RPC nodes, and archive nodes, on hardware LinkPool owns in UK data centres with a 99.99% uptime SLA. LP MKS is coming soon, and pricing will be published at launch. [Register your interest](/#contact) and we will be in touch before launch. ## Products - [RPC](/rpc): managed RPC endpoints at a fixed monthly cost - [Validators](/validators): staking and validator infrastructure you can verify - [Blog](/blog): news and insights on Web3 infrastructure ## Why LP MKS - Bare metal, no hypervisor: containers run straight on the hardware - Crypto-native operations: purpose-built for legal crypto workloads - UK data centres: three availability zones in Manchester - ISO 27001 and SOC 2 Type II certified [Register your interest](/#contact) --- Source: https://linkpool.com/rpc # RPC endpoints at a fixed monthly cost Managed RPC endpoints on infrastructure LinkPool owns and operates. One fixed monthly cost for the endpoint you need, with no compute units, no per-request metering and no overage bill. LinkPool has operated Web3 infrastructure since 2017, against a 99.99% uptime SLA target, on a 1.5 Tbps+ east-west network with 0.2 ms latency between nodes. ## Metered billing is the problem, not the price Usage-based RPC pricing moves the risk onto you. Credits, compute units and request tiers are the same idea in different clothes: the bill is unpredictable, and it grows fastest on your best day. ### Metered billing punishes growth Compute-unit pricing scales with traffic, so a launch or a volatile market arrives as an overage charge. A fixed monthly cost prices the endpoint once and leaves the bill alone. ### Rate limits are the hidden cost Metered plans cap requests per second as well as total volume. Hitting that ceiling means throttled calls or an upgrade in the middle of an incident. Here the capacity is agreed when the endpoint is sized. ### Egress is not a line item A busy public endpoint serves multiple terabytes of JSON-RPC traffic a month. Bandwidth is a flat monthly port on a network LinkPool owns, so egress never arrives as a separate charge. ## Chains we support RPC nodes across 74 mainnets, plus testnets, alongside oracle infrastructure for the Chainlink Network. Featured: Ethereum, Solana, Polygon, BNB Smart Chain, Bitcoin, Avalanche, Polkadot, Sui, Linea, Starknet, Hedera and the XRP Ledger. Every network: AB, Abstract, ADI, ApeChain, Aptos, Arbitrum (testnet), Arc (testnet), Avalanche, Base (testnet), Berachain, Bitcoin, Blast (testnet), BNB Smart Chain, BOB, Botanix, Celo, Centrifuge, Codex, Conflux, Core, Cronos, Cronos zkEVM, Dogecoin, Edge, Ethereum, Etherlink, Frax, Gnosis (testnet), HashKey, Hedera, Hemi, Hyperliquid, Ink, Kaia, Katana, Lens, Linea, Lisk, Litecoin, Mantle, MegaETH, Merlin, Metal L2, Metis, Mode, Moonbeam, Moonriver, Morph, Neo X, opBNB, Pharos, Plasma, Plume (testnet), Polkadot, Polygon, Ronin, Rootstock, Scroll, Sei, Shibarium, Solana, Soneium, Sonic, Stable, Starknet, Stellar, Sui, Superseed, TAC, Taiko, Tempo, TRON, Unichain, WEMIX, World Chain, X Layer, XDC, XRP Ledger, ZetaChain, Zircuit (testnet), zkLink. More chains are available on request. Tell us the chain and the traffic profile and we will confirm what we can run. ## Built for endpoints that stay up ### Kubernetes on owned hardware Managed clusters on hardware LinkPool owns. Containers run straight on the machine, so no hypervisor sits between your requests and the CPU. ### Guaranteed QoS on Performance Performance reserves capacity, so requests equal limits: no throttling and no eviction when a neighbour spikes. ### Three availability zones Endpoints fail over across three availability zones in Manchester, the location institutional buyers audit. ### Protected and monitored 24/7 DDoS protection in front of every endpoint, continuous health checks behind it, and automatic failover when a node falls out of sync. ## What teams ask us ### Do you charge per request or per compute unit? No. There are no compute units, no credit balance and no per-request metering. You pay one fixed monthly cost for the endpoint, and it does not move when your traffic does. ### How is the cost worked out? Every quote is different because every workload is. We size the endpoint against the chains you need, the traffic profile and whether you need archive data, then quote a single fixed monthly figure for the term. ### Which chains do you support? RPC nodes across 74 mainnets, plus testnets, including Ethereum, Solana, Polygon, BNB Smart Chain, Bitcoin, Avalanche, Polkadot, Sui, Linea, Starknet, Hedera and the XRP Ledger. The full list is on this page, and LinkPool runs oracle infrastructure for the Chainlink Network on the same platform. More chains are available on request. ### What happens when my traffic spikes? The bill does not move. Capacity is agreed when the endpoint is sized rather than sold in requests-per-second tiers, so a spike is a conversation about headroom rather than an overage invoice. ### Can we have a private endpoint rather than a shared public one? Yes. A private endpoint serves you alone rather than sharing a public URL with other traffic. Resources on the platform are shared by default and Performance reserves them, so tell us the throughput and isolation you need and we will size it. ## How we think about RPC - [Self-hosted RPC vs managed RPC: the trade-offs](/blog/managed-rpc-vs-self-hosted-rpc) - [What an RPC endpoint actually costs to run](/blog/rpc-endpoint-hosting-cost-aws-vs-dedicated) - [Archive node hosting: cloud vs dedicated infrastructure](/blog/archive-node-hosting-cost-cloud-vs-dedicated) - [Why LinkPool runs Kubernetes on bare metal](/blog/bare-metal-kubernetes-hosting) ## Get a quote for your RPC workload Tell us the chains, the traffic profile and the scale. We reply with a fixed monthly number, not a deck. --- Source: https://linkpool.com/validators # Staking and validator infrastructure you can verify Running Chainlink oracle nodes since mainnet launch in May 2019, and validators on Ethereum, NEAR, Polygon, Canton and more. Zero slashing events in six years of mainnet operations, rated AAA and certified a Verified Staking Provider by Staking Rewards. LinkPool has operated Web3 infrastructure since 2017, against a 99.99% uptime SLA target, on hardware it owns across three availability zones in Manchester. It is also a core contributor to stake.link, the liquid staking protocol for Chainlink. ## For validators, the risk is the cost A validator earns steadily and loses catastrophically. The infrastructure decision is really about slashing, uptime, and who controls the plug. ### Slashing is the real cost A slashed validator loses stake directly. We have run mainnet validators for six years with zero slashing events. Performance tier gives guaranteed QoS so attestation timing does not degrade when a neighbour spikes. ### Platform risk is a line item In November 2022 a major host removed more than 1,000 Solana validators in a single policy change. Rented infrastructure sits under a host acceptable-use policy that can change. We run on owned hardware under a Web3-native contract. ### You inherit your cloud SLA A validator on public cloud cannot promise more uptime than its host promises you. Owned infrastructure sets its own ceiling: our 99.99% target comes from failover across three availability zones in Manchester, not a pass-through cloud contract. ## Networks we validate Seven networks with public third-party records showing LinkPool's validator or operator role. This is a verifiable set, not an exhaustive inventory. - **Ethereum:** [listed as a Lido Simple DVT mainnet operator](https://blog.lido.fi/a-year-with-simple-dvt-strengthening-ethereum-staking-through-diversity-and-resilience/) - **NEAR Protocol:** [listed on Staking Rewards](https://www.stakingrewards.com/provider/linkpool/supported-assets) - **IOTA:** [listed on Staking Rewards](https://www.stakingrewards.com/provider/linkpool/supported-assets) - **Polygon:** [listed on Staking Rewards](https://www.stakingrewards.com/provider/linkpool/supported-assets) - **Lava:** [listed on Staking Rewards](https://www.stakingrewards.com/provider/linkpool/supported-assets) - **Espresso:** [tracked on the Espresso validator monitor](https://espressonodes.com/operator/0x146bc1b1e64ccde7ee29ba9c58226907e283915a?network=mainnet) - **Canton Network:** [an active validator licence on Cantonscan](https://www.cantonscan.com/party/LinkPool-Validator-01::1220721656df1a998cdd4e2f762143520c2249c77d46cc15d72728d5eef6ccd37106) ### Chainlink: live since mainnet launch in 2019 LinkPool has run Chainlink oracle nodes continuously since the network went live on Ethereum mainnet in May 2019, more than seven years of uninterrupted oracle operations. That network has since enabled more than $34 trillion in transaction value and secures over $56 billion in assets, per [Chainlink Foundation metrics](https://metrics.chain.link/) for September 2026. The same team and the same operating discipline now run the validator, DVT and oracle workloads on this page. LinkPool is also a core contributor to [stake.link](https://stake.link), the sole third-party delegated staking solution for Chainlink Economics 2.0. Staking Rewards rates LinkPool AAA on its AAA to D scale and certifies it a Verified Staking Provider. That rating covers business, operations, reliability and security, and the [full report](https://www.stakingrewards.com/provider/linkpool) is public. ## Built for validators that stay up ### Kubernetes on owned hardware Managed clusters on hardware LinkPool owns. Containers run straight on the machine, so no hypervisor sits between the client and the CPU. ### Guaranteed QoS on Performance Performance reserves capacity, so requests equal limits: no throttling during attestation or proposal windows. ### Three availability zones Validators fail over across three availability zones in Manchester, which is where the 99.99% target comes from. ### Monitored around the clock 24/7 monitoring on every validator, alerting on missed attestations and proposals, and client upgrades handled before they become incidents. ## What teams ask us ### What is a validator? A validator is a node that participates in a proof-of-stake network's consensus, proposing and attesting to blocks, with stake bonded as collateral. Correct behaviour earns rewards. Downtime forfeits them, and provable misbehaviour is slashed, meaning part of the bonded stake is destroyed. Running one well is an availability and key-management problem rather than a trading one. ### Which networks does LinkPool validate on? Public records link LinkPool to validator or operator roles on Ethereum, NEAR Protocol, IOTA, Polygon, Lava, Espresso and the Canton Network. This is a verifiable public set, not a claim that LinkPool operates on only seven networks. LinkPool has also run oracle infrastructure for the Chainlink Network since its mainnet launch in 2019. ### What is your slashing record? Zero slashing events in six years of mainnet validator operations. Avoiding slashing is a function of client configuration, monitoring, and infrastructure that does not degrade under load, which is why the platform reserves resources rather than overcommitting them for timing-sensitive work. ### Do you support distributed validator technology (DVT)? Yes. DVT splits a validator across several operators so no single one is a point of failure. We run distributed validator client software on the same platform as our standard validator and oracle workloads. ### Do you support Chainlink staking? Yes. LinkPool has run Chainlink oracle nodes since the network's mainnet launch in May 2019 and is a core contributor to stake.link, the sole third-party delegated staking solution for Chainlink Economics 2.0. ### Where can we delegate stake to LinkPool? Delegation availability and terms vary by network. Staking Rewards publishes current terms for NEAR Protocol, IOTA, Polygon and Lava, while the Espresso monitor publishes delegation data. For Ethereum DVT, Canton, or a validator run for your own stake, talk to us about the applicable route. ### Should we self-host or use managed infrastructure? Self-hosting adds real operational overhead: on-call rotas, client upgrades, incident response and key management, on top of the hardware. Managed infrastructure removes that without charging for a whole server you will not fully use. The break-even is usually about engineering time rather than hardware. ## Validator and staking guides - [ETH validator hosting cost comparison](/blog/eth-validator-hosting-cost-aws-vs-dedicated) - [What is distributed validator technology?](/blog/what-is-distributed-validator-technology) - [Why in-house institutional staking is hard](/blog/why-in-house-institutional-staking-is-hard) - [How to evaluate managed staking and oracle operators](/blog/how-to-evaluate-managed-ethereum-staking-oracle-operators) - [TradFi institutions running validators](/blog/tradfi-institutions-running-validators) ## Talk to us about validators Tell us the network, how much stake, and whether you need a dedicated validator or a delegation. We reply with specifics, not a deck. --- Source: https://linkpool.com/blog/kubernetes-network-policy-default-deny-rollout Published: 2026-09-02 Author: LinkPool Team # Kubernetes network policy: a safe default-deny rollout A Kubernetes network policy is an allow-list at layers 3 and 4 that decides which pods can reach which other pods and ports. Kubernetes applies none of it by default: every pod can talk to every other pod, in every namespace, and out to anything the node can route to. Moving a namespace to default deny closes that gap, and this guide covers how to do it without taking your own services down. Two failure modes bring teams here, and they are the same worry from opposite ends. One is whether near-zero-CVE base images actually reduce risk. The other is a service that pulled a barely maintained dependency and had it running before review saw it. Both are about what gets into the cluster. A Kubernetes network policy governs what a workload can reach once it is already there, which is the half you still control after the image has landed. The stakes are concrete. A compromised container in your monitoring namespace can open a connection to your validator's signing sidecar, and nothing in the cluster will object. ## What NetworkPolicy controls, and what it does not A `NetworkPolicy` is an allow-list at layers 3 and 4. It selects pods by label and describes which sources may reach them and which destinations they may reach, by pod selector, namespace selector, IP block and port. Four things it does not do cause most of the confusion: | Question | What a Kubernetes network policy actually does | |---|---| | Can it filter by hostname or URL path? | No. Rules match IPs and ports, so `api.example.com` is not something the standard API can express. | | Does it apply to host-network pods? | No. A pod with `hostNetwork: true` uses the node's network namespace and is not selected. | | Is it stateful like a firewall? | Not in the same way. Policies describe direction, and reply traffic on an established connection is allowed, but you must reason about which side initiates. | | Does it work on its own? | No. It does nothing at all unless your CNI enforces it. This is the one that bites. | ## An unenforced manifest is false confidence `kubectl apply` on a NetworkPolicy succeeds whether or not anything in the cluster implements it. The object is stored, `kubectl get netpol` lists it, and traffic carries on exactly as before. Flannel in its default configuration does not enforce NetworkPolicy. Several managed offerings ship a CNI where enforcement is an option you have to switch on. So verify before you write a single rule. Apply a deny-all to a scratch namespace with two test pods, then try to curl one from the other. If it connects, nothing is enforcing and everything you build on top is decoration. ```yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-all namespace: netpol-test spec: podSelector: {} policyTypes: - Ingress - Egress ``` An empty `podSelector` selects every pod in the namespace. With both policy types listed and no rules underneath, nothing is permitted in either direction. ## Start from observed flows, not from a diagram The architecture diagram is wrong. It is not wrong because anyone was careless, it is wrong because it was drawn before the sidecar, the backup job and the third-party agent were added. Before writing policy, record what the namespace actually talks to over a period long enough to include the slow stuff. A week catches nightly batch jobs, certificate renewals and the weekly report nobody remembers owning. Cilium's Hubble, or your CNI's equivalent flow logging, will give you source pod, destination and port. Sort the result into three buckets. Flows you can name and must keep. Flows you can name and want gone. Flows nobody can identify, which are the reason you are doing this at all. ## Deny ingress first, then egress Split the rollout. Ingress and egress fail in different ways and it is much easier to debug one at a time. Ingress is the forgiving half. Apply a default-deny for ingress, then add explicit allows for the callers you identified. If you miss one, that caller breaks loudly and obviously, and the fix is a rule. ```yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: default-deny-ingress namespace: chain-workloads spec: podSelector: {} policyTypes: - Ingress --- apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-gateway-to-rpc namespace: chain-workloads spec: podSelector: matchLabels: app: rpc-endpoint policyTypes: - Ingress ingress: - from: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: gateway podSelector: matchLabels: app: edge-proxy ports: - protocol: TCP port: 8545 ``` Note the shape of that `from` entry. The namespace selector and pod selector sit in one list item, so both must match. Put them in separate list items and you have written "any pod in the gateway namespace, or any pod anywhere with this label", which is far wider than intended. This is a common mistake in hand-written policy. Egress is where outages come from, so do it second and do it with DNS handled first. ## DNS and the platform exceptions The moment egress is denied, name resolution stops, and every symptom you see afterwards will look like something else. Failing readiness probes, timeouts to services that are plainly running, and clients that hang rather than error. Allow DNS to CoreDNS explicitly, on both UDP and TCP port 53. TCP matters for responses too large for a UDP datagram. ```yaml apiVersion: networking.k8s.io/v1 kind: NetworkPolicy metadata: name: allow-dns-egress namespace: chain-workloads spec: podSelector: {} policyTypes: - Egress egress: - to: - namespaceSelector: matchLabels: kubernetes.io/metadata.name: kube-system podSelector: matchLabels: k8s-app: kube-dns ports: - protocol: UDP port: 53 - protocol: TCP port: 53 ``` Then work through the rest of the platform before you touch application rules. Metrics scraping is an ingress allow from your monitoring namespace to the metrics port. Log shipping is usually egress from every pod to a collector. Admission webhooks are ingress to the webhook service from the API server, and that traffic often arrives from a node IP rather than a pod, so it needs an `ipBlock`. Certificate issuance needs egress to the ACME endpoint, which is external. Get those wrong and the breakage will be attributed to the application for a day and a half. ## Stateful workloads have dependencies that outlive a pod Chain workloads make this harder than a stateless web tier, in a specific way. An RPC node holds long-lived peer connections that it initiates outbound to arbitrary internet addresses on non-obvious ports. You cannot enumerate peers, so egress for that pod is a CIDR range and a port range, not a list of hosts. Narrow it by excluding your own internal ranges from the allowed block rather than trying to list the world. A validator has a signing path that should be the most restricted thing in the cluster. That is one client, one destination, one port, and no reason for anything else in the namespace to reach it. An oracle node reads from upstream data providers over TLS and writes transactions through an RPC endpoint. Both directions are external and both should be explicit. Anything with a quorum, and etcd is the obvious case, needs peer-to-peer allows among its own members. Write those as a pod selector matching the set itself, so the rule survives rescheduling. The general rule is that stateful workloads reconnect. A policy that a pod tolerates while running can still break it on restart, when it tries to re-establish everything at once. Test by deleting the pod, not just by watching it. ## Test from both sides, keep a rollback Policy is an intersection. Traffic is permitted only if the source's egress rules allow it out and the destination's ingress rules allow it in. Testing one direction proves nothing. Run each check as a pair. From a pod in the source namespace, attempt the connection. From the destination, confirm arrival. A `nc -zv` and a look at the receiving service's own connection log will do. Also test what should fail. A policy that allows everything you tested and everything you did not is the outcome you are trying to avoid, and it looks identical to success until an incident. Rollback is one delete away, which is the good news. Keep the policies for a namespace in their own directory, apply them as a unit, and make sure whoever is on call knows that removing them restores the previous behaviour immediately. Do not bury network policy inside an application chart where deleting it means redeploying the application. Roll out namespace by namespace, starting with one that is important enough to be watched and not so important that a mistake is a customer incident. ## Failure modes worth knowing before you meet them **Nothing is enforced.** Covered above, and the reason to test the CNI first. **Ingress allow written as two list items.** Widens the rule to an "or". Read every `from` and `to` block for this specific shape. **DNS forgotten, or allowed on UDP only.** Intermittent failures on larger responses, which is worse than a clean break because it looks random. **Policies applied but the pods are not selected.** Labels drift. `kubectl get pods -l ` against the same selector the policy uses is a five second check that saves an hour. **Host-network pods assumed covered.** They are not, and they are often the agents with the most access. **Probes blocked.** The kubelet reaches the pod from the node, so probe traffic can need an `ipBlock` for the node CIDR rather than a pod selector. ## When the standard API is not enough Standard NetworkPolicy is namespaced, allow-only and stops at layer 4. Some requirements sit outside that. If you need to permit egress to a hostname whose IP changes, the standard API cannot express it. If you need a rule that applies cluster-wide rather than per namespace, or an explicit deny that overrides a broad allow, or filtering on HTTP method and path, those are CNI extensions rather than portable Kubernetes objects. Cilium provides all of them. Use them where the requirement is real, and know the trade. Those objects do not move to another CNI, so keep the portable baseline in standard NetworkPolicy and treat the extensions as a documented layer on top. We run dedicated Kubernetes for chain workloads with Cilium eBPF networking in place of kube-proxy, and default deny is the starting position for a namespace rather than a hardening step added later. More on how that cluster is built is in [dedicated Kubernetes for web3 before enterprise](/blog/bare-metal-kubernetes-web3-before-enterprise). ## If you would rather not run this yourself The rollout above is a week of flow logging and a careful sequence, and it has to be repeated for every namespace you care about. That is reasonable work for a platform team that already owns its cluster. It is a poor use of a small engineering team whose actual product is somewhere else. We build and operate dedicated Kubernetes for chain workloads, where default deny is the starting position for a namespace rather than a hardening step added later. If you are weighing that against doing it in-house, the [LP MKS overview](/) sets out how those clusters are put together and what we take on. ## Sources - [Kubernetes network policies](https://kubernetes.io/docs/concepts/services-networking/network-policies/) - [Kubernetes multi-tenancy](https://kubernetes.io/docs/concepts/security/multi-tenancy/) - [Cilium deny policies](https://docs.cilium.io/en/stable/security/policy/deny/) ## Frequently asked questions **What does a Kubernetes NetworkPolicy actually control?** It is an allow-list at layers 3 and 4. It selects pods by label and describes which sources may reach them and which destinations they may reach, by pod selector, namespace selector, IP block and port. It cannot filter by hostname or URL path, and it does not apply to pods running with hostNetwork set to true. **Why does my NetworkPolicy appear to have no effect?** Most likely nothing in the cluster is enforcing it. The API accepts and stores a NetworkPolicy whether or not the CNI implements it, so kubectl get netpol lists the object while traffic carries on unchanged. Flannel in its default configuration does not enforce NetworkPolicy, and several managed offerings require enforcement to be switched on. Test with a deny-all in a scratch namespace before writing real rules. **Should default-deny be applied to ingress or egress first?** Ingress first. Ingress fails loudly and locally, so a missed caller breaks in an obvious way and the fix is one rule. Egress is where outages come from, because denying it stops name resolution and every later symptom looks like something else. **What breaks first when egress is denied in Kubernetes?** DNS. Once egress is denied, pods cannot reach CoreDNS, and the failures present as failing readiness probes, timeouts to services that are plainly running, and clients that hang rather than error. Allow DNS to CoreDNS explicitly on both UDP and TCP port 53, because TCP carries responses too large for a single UDP datagram. **When is standard Kubernetes NetworkPolicy not enough?** When you need egress to a hostname whose IP changes, a rule that applies cluster-wide rather than per namespace, an explicit deny that overrides a broader allow, or filtering on HTTP method and path. Those are CNI extensions rather than portable Kubernetes objects, so keep a portable baseline in standard NetworkPolicy and treat the extensions as a documented layer on top. --- Source: https://linkpool.com/blog/platforms-choosing-chainlink-day-one-oracle Published: 2026-09-02 Updated: 2026-09-07 Author: LinkPool Team # Chainlink oracle adoption: why platforms standardise instead of building their own Chainlink oracle adoption passed a useful marker in August 2026, when two organisations that could comfortably have carried on building their own cross-chain plumbing chose not to, within two days of each other. On 18 August the Wyoming Stable Token Commission [migrated its Frontier Stable Token away from LayerZero to Chainlink CCIP](http://www.prnewswire.com/news-releases/wyoming-stable-token-commission-migrates-to-chainlink-ccip-for-enhanced-operational-security-302854502.html) as its exclusive cross-chain infrastructure, under a multi-year contract, following a security review. On 19 August [Chainlink announced](https://x.com/chainlink/status/2090107591451885745) that Nethermind, one of the most widely run Ethereum execution clients, is deprecating its legacy cross-chain infrastructure and joining the Chainlink Network as a node operator to secure CCIP and Data Feeds. Neither of those two needed Chainlink to survive. Nethermind has some of the deepest Ethereum engineering talent in the industry, and a US state issuing its own stable token has no shortage of technical resources on tap. Both chose to standardise instead of build. ## What standardising actually involves A cross-chain message or a price feed looks simple from a product roadmap. Underneath, it is a live, adversarial system: a decentralised set of node operators that has to stay in consensus, sign correctly, and stay up, indefinitely, while people actively look for the one bad node or the one stale price that breaks something downstream. Chainlink's oracle networks (DONs) reach consensus through off-chain reporting among the participating operators, and CCIP moves both messages and tokens across chains through that same operator set. Standardising on Chainlink means depending on that specific infrastructure and the operators running it, not on an abstract standard. ## Why standardising beats building Building an oracle or cross-chain layer in-house is possible. Chainlink itself proved a decentralised oracle network can be built from nothing. What makes standardising the better choice for most teams is opportunity cost and ongoing operational risk, weighed against a category where a working standard already exists in production at scale. Building in-house means owning three permanent jobs: recruiting and retaining people who understand oracle security specifically, which is a narrower skill set than general blockchain engineering, running an incident response process for a system where a bad price or a stuck message has direct financial consequences, and defending the design against every new attack pattern the rest of the industry discovers. None of that shows up on a roadmap slide. All of it shows up in an incident postmortem, usually a year or two after the original design team has moved on. We looked at that specific tradeoff in [building in-house staking or oracle infrastructure](/blog/building-in-house-staking-oracle-infrastructure). Standardising on Chainlink converts that open-ended cost into a narrower one: choosing and monitoring the node operators who run the network a platform now depends on. That is a real job, not a trivial one, but it is a more tractable job than building the network itself. ## What standardising actually asks of the operators This is where the story moves from "which platform picked which oracle" to something with an actual infrastructure answer. A DON or a CCIP lane is only as good as the node operators running it. When Wyoming routes a state-issued stable token's cross-chain transfers through CCIP, or Nethermind's infrastructure depends on Chainlink's operator network instead of its own, the thing actually being trusted is whether that specific set of operators stays up, signs correctly, and stays independent of each other. Three things follow from that. **Uptime has to be structural, not aspirational.** A node operator on shared cloud that goes down when a region has a bad day takes part of the network down with it. LinkPool runs its Chainlink infrastructure, including Data Streams nodes, on owned hardware across three availability zones in Manchester, backed by a 99.99% target uptime SLA that comes from that redundancy rather than from a single provider's regional promise. **Operator diversity has to be real, not nominal.** A DON with twenty node operators that all run on the same cloud provider, in the same region, has one point of failure wearing twenty different operator names. The value of a large operator set only holds if the operators are genuinely running different infrastructure in different places. **The work has to be continuous, not a launch event.** Running Data Streams infrastructure, for example, means keeping tight clock synchronisation across the network, maintaining connections to multiple upstream data providers, and holding sub-second response times, every round, indefinitely. We wrote about what that specific workload demands operationally in [what goes into running a Chainlink Data Streams node](/blog/chainlink-data-streams-node-operations). ## The infrastructure question buyers should actually be asking If a platform is about to standardise on an oracle network the way Nethermind and Wyoming have, the useful due diligence question is not whether Chainlink supports the chains it needs. It almost certainly does. The useful question is who is running the nodes behind the specific service it depends on, what happens to the integration if one of them has a bad week, and whether the operator set is actually diversified across infrastructure, not just across company names. The point is that choosing Chainlink is a decision about a standard. The infrastructure underneath it is a decision about specific operators, and that decision still belongs to whoever is building on top of it. ## Where that leaves a platform choosing operators Chainlink oracle adoption moves the question rather than answering it. Once a platform has standardised, the remaining risk sits with the operators running the service it now depends on, and that is a procurement decision rather than a protocol one. LinkPool has run Chainlink nodes since the network's mainnet launch in May 2019, and operates Chainlink infrastructure across the major chains, including Data Streams nodes, on owned hardware across three availability zones in Manchester. If you are assessing who runs the nodes behind a service you are about to depend on, the [validators page](/validators) sets out how we run that infrastructure and what we take on. ## Frequently asked questions **Why do platforms standardise on Chainlink instead of building their own oracle infrastructure?** Building in-house means owning three permanent jobs: recruiting and retaining people who understand oracle security specifically, running incident response for a system where a bad price or a stuck message has direct financial consequences, and defending the design against every new attack pattern the industry discovers. Standardising converts that open-ended cost into a narrower one, which is choosing and monitoring the node operators the platform now depends on. **Who has moved to Chainlink CCIP recently?** On 18 August 2026 the Wyoming Stable Token Commission migrated its Frontier Stable Token away from LayerZero to Chainlink CCIP as its exclusive cross-chain infrastructure under a multi-year contract, following a security review. On 19 August 2026 Chainlink announced that Nethermind is deprecating its legacy cross-chain infrastructure and joining the Chainlink Network as a node operator to secure CCIP and Data Feeds. **What should a platform check before standardising on an oracle network?** Not whether the network supports the chains it needs, because it almost certainly does. The useful questions are who runs the nodes behind the specific service the platform depends on, what happens to the integration if one of them has a bad week, and whether the operator set is genuinely diversified across infrastructure rather than only across company names. **Does a large node operator set guarantee decentralisation?** No. A decentralised oracle network with twenty node operators that all run on the same cloud provider in the same region has one point of failure wearing twenty different operator names. The value of a large operator set only holds if the operators genuinely run different infrastructure in different places. --- Source: https://linkpool.com/blog/uk-data-residency-and-sovereignty Published: 2026-09-02 Updated: 2026-09-07 Author: LinkPool Team # 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](/blog/bare-metal-kubernetes-web3-before-enterprise) 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](/blog/mica-staking-compliance-infrastructure). 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](/blog/tradfi-institutions-running-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](/rpc) and [validator](/validators) 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. --- Source: https://linkpool.com/blog/european-cloud-providers-what-to-compare Published: 2026-08-25 Updated: 2026-09-07 Author: LinkPool Team # European cloud providers: what to compare before you choose European cloud providers are not interchangeable. For a validator, RPC node, indexer or oracle service, compare the deployment model, dedicated-resource guarantees, storage path, failure domains, operator responsibility and exact data location before comparing price. A platform that is excellent for a stateless web application can still be the wrong home for stateful blockchain infrastructure. This guide compares four different service shapes rather than declaring a universal winner. The right choice depends on what your team wants to operate itself and what the workload cannot compromise on. ## Europe, the EU and sovereignty are different filters A European data-centre location answers only one question: where a workload can run. It does not, by itself, tell you where the provider is incorporated, who operates the control plane, which law governs the contract, where support staff can access data or how much of the technical stack depends on third parties. The distinction matters even inside official procurement. In April 2026, the European Commission said its [Cloud Sovereignty Framework](https://ec.europa.eu/commission/presscorner/api/files/document/print/en/ip_26_833/IP_26_833_EN.pdf) measures eight objectives, including legal and operational considerations, supply-chain transparency, technological openness and security. Location is part of the decision, not a substitute for it. For UK buyers there is another simple distinction: Manchester is in Europe but outside the EU. Write the actual requirement before shortlisting providers. "European hosting", "EU data location" and "EU-operated sovereign cloud" are three different procurement statements. ## A sourced comparison of European cloud providers The table below is a workload-fit comparison, not a price ranking. It records what each provider publishes about the service shape and European locations, then identifies the unanswered question a blockchain infrastructure buyer should take into procurement. | Provider | Published service shape | Published European locations | What a blockchain infrastructure buyer still needs to verify | |---|---|---|---| | LinkPool | Managed RPC endpoints and validator infrastructure on LinkPool-owned physical servers, with either burstable or guaranteed workload resources; self-service bare-metal Kubernetes (LP MKS) is coming soon | Three availability zones in Manchester, UK | Workload sizing, storage layout, support level, acceptance tests and the agreed rollback window | | [OVHcloud](https://www.ovhcloud.com/en/public-cloud/kubernetes/) | Managed Kubernetes on Public Cloud, plus [dedicated-server ranges](https://www.ovhcloud.com/en/bare-metal/regions-availability/) | Its dedicated-server availability page lists regions in France, the UK, Germany and Poland | Worker-node responsibility, node and storage placement, single-zone versus multi-zone design, backups and the exact service-level agreement selected | | [Scaleway](https://www.scaleway.com/en/kubernetes-kapsule/) | Managed Kubernetes control plane, with nodes and persistent volumes billed as underlying resources; [dedicated servers](https://www.scaleway.com/en/bare-metal/) are also available | Kapsule is published as available in Paris, Amsterdam and Warsaw availability zones | Node type, persistent-volume performance, control-plane option, recovery design and which components need a separate service | | [Hetzner](https://docs.hetzner.com/cloud/general/locations/) | Cloud instances with shared or dedicated vCPU options; dedicated root servers are a separate service | Falkenstein and Nuremberg in Germany, and Helsinki in Finland | The team-owned orchestration and on-call burden, storage failure recovery, cross-location design and whether a cloud VM or whole server fits the workload | **Methodology.** We reviewed each linked provider page on 25 August 2026. The comparison uses public product and location documentation, not negotiated contracts or private benchmarks. It deliberately excludes prices because instance families, commitments, storage and support make headline rates incomparable. Before signing, verify the current order form, responsibility matrix and service-level agreement with the provider. This table is reusable for an initial shortlist, but it is not a substitute for a technical trial. Published availability describes a product catalogue. It does not prove that a specific node remains in sync, that storage meets a database's latency requirements or that a failover procedure works. ## Six questions that expose the real difference ### 1. Is the workload on shared, dedicated or guaranteed capacity? "Cloud" can mean a shared virtual machine, a VM with dedicated vCPUs, a whole physical server or a managed platform on owned hardware. These are not equivalent for a timing-sensitive node. Ask whether CPU requests are guaranteed, whether limits can throttle the workload, whether storage is shared, and what happens during host contention. If a provider cannot describe the isolation boundary in plain language, the buyer cannot model performance risk. ### 2. Who operates the control plane and worker nodes? Managed Kubernetes often means that the provider maintains the Kubernetes control plane while the customer remains responsible for worker nodes, containers, sizing, data and backups. OVHcloud publishes that division explicitly. Scaleway says it manages the control plane and core components, while the allocated nodes and persistent volumes remain part of the customer's cluster design. That can be the right division for a platform team. It is not the same product as a managed infrastructure operator that also owns workload sizing, upgrades, monitoring and incident response. ### 3. What is the storage failure model? Blockchain workloads are stateful. Their databases grow, write continuously and can take hours or days to rebuild. Storage must therefore be evaluated as part of the service rather than as an attachment to a compute quote. Scaleway's documentation makes the issue unusually clear: Kubernetes nodes should be treated as stateless, so stateful applications need persistent volumes. Apply that question to every provider. Where is the volume located? What are its throughput and latency limits? How is it backed up? Can it reattach in another failure domain? How long would a full resync take? ### 4. Are the failure domains real and useful to this workload? Count buildings, power domains, network paths and control-plane zones, not region names. A three-zone control plane does not make a single worker or single storage volume highly available. Conversely, spreading validator keys or node databases across sites without a tested protocol can create a different failure mode. Ask the provider to draw the intended workload across the available failure domains. Then remove one domain from the diagram and describe what continues, what restarts and what needs human intervention. ### 5. What does "European" mean in the contract and architecture? Record at least four facts separately: - the provider's contracting entity and governing law; - the physical location of compute and storage; - the location and operator of the control plane; - the people and subprocessors that can access the service. This prevents a geographic label from carrying claims it cannot support. It also makes security and legal review faster because each team receives a concrete fact rather than a vague sovereignty promise. ### 6. What will migration and rollback look like? A provider comparison is incomplete without a path from the current environment. For a node workload, the useful proposal includes the source data, sync strategy, observability, acceptance threshold, traffic or signing cutover and rollback window. The safest first move is usually one representative workload. Build it beside the current service, synchronise it, test failure behaviour and move production only after it passes the agreed checks. ## A 100-point provider-selection framework To make the decision reproducible, score each shortlisted provider from 0 to 5 against the evidence your team has verified. Calculate each weighted result as `score / 5 x weight`, then add the six results. A missing answer scores zero until it is evidenced. | Criterion | Weight | Evidence required for a full score | |---|---:|---| | Workload and resource fit | 25 | The proposed CPU, memory, network and isolation model is documented and tested with the real workload | | Storage and recovery | 20 | Performance limits, growth allowance, backup, restore and resync timings are documented and tested | | Failure-domain design | 20 | Compute, storage and control-plane dependencies are mapped, with a tested single-domain failure | | Operating responsibility | 15 | A responsibility matrix names who handles upgrades, monitoring, incidents, capacity and recovery | | Location and contractual fit | 10 | Contracting entity, governing law, data location, control-plane location and access paths are recorded | | Migration and commercial clarity | 10 | The quote includes all required resources and support, acceptance tests, cutover steps and rollback | The weighting is designed for continuous, stateful blockchain services. A stateless marketing site would reasonably give storage and recovery less weight. An archive node may give it more. Change the weights before evaluating providers, not after seeing the scores. ## Match the service shape to the team Choose infrastructure as a service or a dedicated server when the team already operates Kubernetes, databases, monitoring and on-call, and wants direct control over the machine or VM. Choose a managed Kubernetes control plane when the team wants to remove control-plane maintenance but is comfortable owning worker-node design, stateful storage, backups and application operations. Choose a managed workload platform when the team wants one operator accountable for the infrastructure design, Kubernetes layer, workload sizing, monitoring and migration. This will usually cost more than an unmanaged server, so compare it with the staff time and operational risk it replaces rather than with the server line alone. The shortlist of European cloud providers should follow that operating-model decision. Starting with logos and headline instance prices produces false comparisons between fundamentally different services. ## Apply the comparison to a blockchain workload LinkPool's [managed RPC](/rpc) and [validator](/validators) services are the managed-workload option in this comparison. They run on Kubernetes on hardware LinkPool owns across three availability zones in Manchester, with workload-level resource choices. [LP MKS](/), the self-service version of the same platform, is coming soon. If you are comparing European cloud providers for an RPC node, validator, indexer or oracle service, send us the current CPU, memory, storage, egress and operational requirements. We will return a target architecture, workload sizing and a staged migration plan so you can compare the complete service rather than a headline compute rate. --- Source: https://linkpool.com/blog/etf-staking-products-infrastructure-bar Published: 2026-07-31 Author: LinkPool Team # What a staking ETF demands of the infrastructure underneath The bar for institutional staking infrastructure is no longer a matter of opinion. It is written into a prospectus. On 28 July 2026, Morgan Stanley Investment Management [listed two staking products on NYSE Arca](https://www.morganstanley.com/press-releases/morgan-stanley-investment-management-launches-ethereum-and-solana-etps): the Morgan Stanley Ethereum Trust (MSSE) and the Morgan Stanley Solana Trust (MSOL). Both carry a 0.14% expense ratio and both integrate staking from launch. The listing got the coverage. The filing terms are the part worth reading if you run validators for a living, because they describe, in numbers, what an issuer will and will not accept from an operator. ## Four numbers that set the specification The expense ratio is 0.14%. Custodians and staking providers deduct a service fee equal to 5% of gross staking rewards, which leaves roughly 95% reaching shareholders, and Morgan Stanley retains none of it itself. MSSE intends to stake between 50% and 80% of the ether it holds under normal conditions. MSOL can stake up to 100% of its SOL. Read those together and you have a specification rather than a press release. The entire cost of running validators for a regulated, exchange-listed product has to fit inside 5% of gross rewards. The staking ratio is a band the operator has to hold, not a target it can drift away from. And the difference between the two products tells you the band is chain-specific, set by how quickly capital can be moved back out. ## A staking ratio is an operational instruction The 50% to 80% band is the part operators tend to underestimate. An exchange-traded product has to meet redemptions, which means it cannot have everything staked. The unstaked portion is not idle capital, it is the liquidity buffer that makes the redemption promise work. Ethereum exits are queued at the protocol level and take as long as the queue takes, which is outside anyone's control on the day. So the operator's job is not simply to stake what it is handed. It is to activate and exit validators on the issuer's schedule, hold the ratio inside the band while flows move in both directions, and have a documented process for partial exits under a redemption event nobody scheduled. Solana stake deactivation resolves at an epoch boundary rather than through an open-ended queue, which is why a Solana product can carry a higher staking ratio than an Ethereum one. The infrastructure consequence is the same in both cases. Capacity planning is driven by the issuer's flow rather than the operator's convenience, and activation headroom has to already exist rather than being provisioned on request. ## Custody and signing are two different jobs The asset sits with regulated custodians. The staking provider runs the validators and never holds the asset. That separation is the structural fact underneath the whole product, and it narrows what the operator is being hired to do. Key generation, signing, availability, and reporting. The operator has to hold validator keys in a way that survives an audit, sign attestations without any single person being able to produce a malicious one alone, and prove both of those on request. [Threshold signing](/blog/threshold-signing-stopped-being-thought-leadership) stopped being a talking point and became a procurement question for exactly this reason. It also means the operator's failure modes show up in someone else's accounts. A missed attestation becomes a line in a report an auditor reads. ## The 5% envelope prices your architecture This is where hardware economics stop being a matter of preference. Everything the operator does has to fit inside that 5% service fee on gross rewards: redundancy, monitoring, on-call cover, key management, reporting, and whatever mechanism covers a slashing event. On hyperscaler pricing, a fully redundant validator fleet with the data depth needed for reporting spends a real share of that envelope on instance hours and egress before anyone has looked at an alert. We have written [the validator hosting cost comparison](/blog/eth-validator-hosting-cost-aws-vs-dedicated) up in detail, and the shape of it is that rented capacity turns a fixed fee into a variable cost that rises with the product's success. Owned hardware changes the shape rather than removing the cost. Capital goes in up front. What follows is a run cost you can hold roughly flat while assets under management grow, which is the only version of this that survives a 0.14% expense ratio being competed downward. ## Reporting has to survive a daily NAV Rewards accrue per validator, per day. A product publishing a daily net asset value needs that accrual attributable at the same granularity, reconcilable against on-chain data, and delivered on a schedule that does not slip because someone was away. Most operator dashboards are not built for this. They are built for the operator, to answer whether anything is broken, and they answer it well. An issuer's accounting team is asking a different question: what did this specific validator earn on this specific date, and can you show the working. Those are different systems, and the second one is usually what is missing when an operator fails diligence for reasons it cannot quite explain afterwards. ## The real change is being named Morgan Stanley named its staking provider publicly at launch. That is the shift, and it matters more than the flows. For most of the past few years the operator sat behind the product. Delegation was a commercial arrangement between two private parties and the end investor never learned who was running the validator. A disclosed operator inside a listed product is a different relationship. Diligence becomes documentary: slashing history across the full operating record, uptime evidence with a stated measurement method, the legal entity and jurisdiction that holds the hardware, key management architecture, incident history, audited financials, and certification status. It is the same movement, seen from the other end, as [institutions choosing to run validators themselves](/blog/tradfi-institutions-running-validators) rather than buy a yield product. An operator that cannot produce those in a form a bank's risk function will accept is not in the running, and its published yield never enters the conversation. That is a harder filter than any rewards table, and it will thin the field faster than fee compression does. ## What to have ready If you want to be on the other side of one of these mandates, the artifacts matter more than the pitch. Uptime evidence with the measurement method stated. Slashing history for the full operating record rather than a recent window. The named legal entity, and the jurisdiction where the hardware physically sits. Key management architecture, written down. Independent fault domains that are genuinely independent, not three logical zones sharing one control plane. Per-validator, per-day reward accrual you can hand to an accountant. A slashing cover mechanism with the claim process described. Current audit and certification status. Our longer piece on [evaluating managed staking and oracle operators](/blog/how-to-evaluate-managed-ethereum-staking-oracle-operators) covers how buyers weigh these against each other. None of it is exotic. Most of it is simply written down, which is the part operators skip. The question worth sitting with: if an issuer published your name in a prospectus next quarter, which of those eight would you have to go and build first? --- About LinkPool. We run staking and oracle infrastructure for Web3 protocols and institutional operators on owned hardware across three availability zones in Manchester. Completing ISO 27001 and SOC 2. AAA Staking Rewards rating across Operations, On-Chain, Security, and Maintenance. Zero slashing across our operating history. Contact: institutional@linkpool.io. ## Frequently asked questions **What does a staking ETF or ETP issuer require from an infrastructure provider?** A disclosed operating record rather than a yield quote. In practice that means slashing history across the full operating record, uptime evidence with a stated measurement method, the legal entity and jurisdiction holding the hardware, key management architecture that survives audit, per-validator reward reporting suitable for a daily NAV, a slashing cover mechanism with a described claim process, and current audit and certification status. The infrastructure also has to hold a staking ratio the issuer sets, not one the operator prefers. **Why do staking ETPs not stake 100% of their assets?** Because the product has to meet redemptions and exits are not instant. Ethereum exits are queued at the protocol level, so an issuer keeps an unstaked buffer to fund redemptions without waiting on that queue. Morgan Stanley's Ethereum trust intends to stake 50% to 80% of its ether under normal conditions. Solana stake deactivation resolves at an epoch boundary instead, which is why its Solana trust can stake up to 100%. **How much of the staking reward reaches the investor?** In the Morgan Stanley products, roughly 95%. The prospectus provides for custodians and staking providers to deduct a service fee equal to 5% of gross rewards, and Morgan Stanley retains none of the remainder. That 5% is the operational envelope. Everything the operator spends on redundancy, monitoring, reporting and slashing cover has to fit inside it. **Does the staking provider hold the assets?** No. In this structure the asset stays with regulated custodians and the staking provider runs validators without taking custody. The operator's scope is key generation and signing, availability, and reporting. That separation is what makes the operator's uptime and reporting quality the thing being diligenced, rather than its balance sheet. --- Source: https://linkpool.com/blog/what-is-an-rpc-node Published: 2026-07-30 Author: LinkPool Team # What is an RPC node, and what it takes to run one on a busy chain An RPC node is a server that accepts requests from applications and wallets, translates them into blockchain operations, and returns the result. It reads chain data such as balances, blocks and contract state, and it broadcasts signed transactions to the network. Every wallet connection and every dashboard load goes through one. That definition is where most explanations stop, and it is the part that matters least once you are responsible for keeping one running. The harder question is what an RPC node needs in order to keep answering correctly when the chain it serves gets busy. Monad's transaction volume and app count have both climbed sharply since mainnet, which reads as a growth story for the people trading on it and a capacity event for everyone serving its data. Transaction rate is the input. Request volume is what actually lands on your RPC nodes, and the two are different numbers. Teams that size on the first one get surprised by the second. ## An RPC node is not a validator node The two get conflated and they do different jobs. A validator node takes part in consensus. It proposes and attests to blocks, it holds a signing key, and it is penalised if it misbehaves or drops offline. An RPC node takes no part in consensus and holds no stake. It serves data. That difference drives how you run each one. A validator is judged on signing reliability and key security. An RPC node is judged on how fast and how correctly it answers a query, and its failure mode is quieter: it can answer every request successfully while serving state that is several blocks out of date. ## Request volume is a multiple of transaction volume One user action in a front end is rarely one call. A single swap can trigger a chain id check, a block number, two or three balance reads, an allowance check, a gas estimate, a simulation, then receipt polling until it confirms. Wallets poll in the background. Dashboards hold open subscriptions. Indexers backfill. Bots poll harder than any human. So the number that drives your sizing is not transactions per second. It is calls per user action, multiplied by concurrent actions, plus everything polling on a timer whether or not anyone is using the app. This is why the number of applications on a chain matters more than its transaction count. Each app arrives with its own polling pattern, and you inherit all of them at once. The measurement is cheap to do and most teams skip it. Instrument your own front end and count the calls behind one completed user action. Then find your peak hour against your daily mean rather than assuming demand is flat. Size against the peak, not the average, because the average never breaks anything. ## Index depth is the second axis Depth gets less attention than throughput and quietly costs more. A busy chain accumulates state and logs fast, and the queries that read history do not get cheaper as it grows. Wide block-range log queries, trace calls, and historical balance lookups all scale with how much chain there is behind you. An indexer backfilling a chain that has been busy for months will hammer the archive tier in a way that normal traffic never does. Two consequences worth planning for. Archive storage growth is continuous rather than stepped, so budget it as a rate and not a one-off. And heavy historical reads compete with light reads for the same node unless you deliberately separate them. We covered the storage side of this in our [archive node hosting cost comparison](/blog/archive-node-hosting-cost-cloud-vs-dedicated). ## Egress is metered and busy chains move a lot of it A public endpoint serving a busy chain produces a lot of outbound data. On hyperscalers that data is billed per gigabyte, so the cost line most teams forget grows in direct proportion to how well the app is doing. It is worth modelling before launch rather than reading it off an invoice. We broke the egress maths down in our [RPC endpoint hosting cost comparison](/blog/rpc-endpoint-hosting-cost-aws-vs-dedicated), and it is regularly the line that decides whether a busy endpoint is affordable. ## Replica count decides reliability as much as throughput Adding replicas to absorb load is the obvious move. The less obvious part is which calls each replica serves. One expensive historical query can occupy a node long enough to starve the light reads queued behind it. The front end then feels slow even though the node is healthy and your request rate is well inside capacity. Splitting pools by call class fixes this: light reads on one pool, heavy historical work on another, subscriptions on a third. Each pool then needs its own spare capacity, because failover is per pool and not per cluster. Sync lag is the metric to alert on. A node that is a few blocks behind still answers every request successfully, and it answers them wrong. Request-rate dashboards will show green while users see stale balances. ## How you know an RPC node has stopped coping The failure is gradual, which is what makes it easy to miss. The signals, roughly in the order they appear: - p99 latency climbs while the mean stays flat, because a small share of calls are queuing behind heavy ones - rate-limit responses start appearing during peak hours only - batch requests time out before individual calls do - the head block served drifts behind the actual chain head - subscription delivery starts lagging, so event-driven flows fire late The user-facing version arrives before any of your dashboards go red. Quotes stop matching execution. Balances look wrong for a few seconds. Transactions appear to vanish and then confirm. Users blame the app, because from where they sit the app is what failed. ## What an RPC node requires before the traffic arrives Requirements for an RPC node are usually quoted as hardware: cores, memory, disk. Those matter, and they are the easy part, because a vendor will tell you them. The four requirements below are the ones that decide whether the node holds up, and they are much cheaper to settle in advance than during a spike. **Your call budget per user action.** If you do not know it, you cannot size anything, and you cannot tell whether a traffic increase or a code change caused the load. **Which call classes get separate pools.** Light reads, heavy historical, and subscriptions have different failure modes and should not share capacity. **Your headroom target.** Pick the multiple of current peak you want to be able to absorb without changing anything, then hold it as capacity grows. **What your bill does under a spike.** This one catches teams out. Credit and compute-unit billing means a traffic spike arrives as an invoice as well as an incident. Fixed request-per-second pricing means the number is known in advance. We price RPC at a fixed sustained request rate with no monthly cap and no overage charges. The point of capacity planning is removing surprises, and a variable bill puts one straight back in. If you are still deciding whether to run the endpoint yourself at all, the trade-offs are in our [self-hosted versus managed RPC breakdown](/blog/managed-rpc-vs-self-hosted-rpc). ## The short version An RPC node is simple to describe and harder to keep healthy. A chain getting busy creates four separate problems for it: more calls, deeper history, more egress, and less tolerance for one slow query. Size for calls rather than transactions, separate the call classes, alert on sync lag rather than error rate, and know what a spike does to the bill before it happens. The work is cheap to do before the traffic arrives. Every part of it costs more once the endpoint is already struggling and someone is asking why quotes do not match execution. --- Source: https://linkpool.com/blog/solana-validator-client-upgrade Published: 2026-07-13 Author: LinkPool Team # Taking a Solana validator through a client upgrade: what actually breaks Solana is running at record load. In the week ending 6 July 2026 the network processed more than one billion non-vote transactions for the first time, and application revenue across the first half of the year averaged roughly 148 million dollars a month, leading every layer-1 and layer-2 on that measure. When a chain is that busy, the cost of a validator falling over during a routine client upgrade is no longer a rounding error. It is missed slots, missed rewards, and a delegator asking why. Client upgrades on Solana are frequent. The Agave client line keeps moving, and operators are expected to keep pace or fall behind on performance and compatibility. The upgrade itself is usually a small change on paper. What breaks is rarely the thing the release notes warn you about. ## What actually breaks **Version skew.** A validator that upgrades while the rest of its setup does not can end up out of step with tooling, monitoring, or a paired RPC node still on the old version. The node runs, but a metrics exporter stops parsing a changed field, or an RPC node serving the same operator disagrees with the validator on state. Skew failures are quiet, because the process stays up and only the edges break. **Config drift.** Flags and defaults change between releases. An option that was safe last version can quietly change behaviour, and you only find out under load. Solana operators accumulate a long list of tuning flags over time, and an upgrade is exactly when a deprecated or re-defaulted flag turns a stable node into one that stalls at the worst moment. **Snapshot and ledger state.** A restart after an upgrade can force a slow catch-up if snapshots are stale, and catch-up while the network is at record throughput takes longer than it did a year ago. A node that took twenty minutes to catch up last year can take far longer today, and every minute behind the tip is a minute of missed voting. **Hardware headroom.** A busier network raises the floor on CPU, memory, and disk throughput. An upgrade that assumes more headroom than the box actually has will show up as degraded vote latency, not a clean failure. This is the failure mode operators miss most often, because the node reports healthy while its skip rate creeps up. ## How to stage the rollout **Test before mainnet.** Run the new client on a non-staked node or a testnet identity first, under representative load, before it touches stake. A synthetic smoke test on an idle box tells you the binary starts. It does not tell you how the node behaves at a billion transactions a week, which is the only condition that matters. **Upgrade one at a time.** If you run more than one validator, never move them together. Stagger the rollout, watch each node settle, and keep a known-good version you can roll back to. Moving a fleet in one step turns a single bad release into a correlated outage across every node you run. **Watch the right signal.** Vote latency and skip rate tell you the upgrade is healthy faster than a green process check does. A validator can be running, connected, and current on version while quietly missing votes because it is a few hundred milliseconds slower than it was an hour ago. Alert on the voting signal, not on whether the process is alive. **Control the hardware.** Staged rollouts are only as safe as your ability to roll back, and that is far easier on infrastructure you control than on a rented instance you have to reprovision. Rollback on owned hardware is a version swap and a restart. On a cloud instance it can mean reprovisioning storage and re-syncing state under time pressure, which is the opposite of what you want mid-incident. ## The infrastructure underneath Record load is a good problem to have, but it moves the failure mode. A year ago a botched upgrade cost you a few slots. Today it lands on a network doing an order of magnitude more work, so the same mistake costs more. The margin for a sloppy upgrade shrinks exactly as the network gets more valuable to be part of. That margin is a property of the infrastructure, not only the runbook. Shared-tenancy cloud instances add a variable you cannot see: a noisy neighbour can move your vote latency without any change on your side, which makes an upgrade regression hard to separate from background contention. On hardware you control, the environment is a constant, so when a metric moves after an upgrade you know the upgrade moved it. LinkPool runs production node infrastructure on owned hardware rather than rented hyperscaler instances, which is what makes a staged, reversible upgrade practical. We are a core contributor to stake.link, the liquid staking protocol for Chainlink, and have operated Chainlink oracle nodes since the early days, so validator reliability under load is the core of what we do. If you want the cost side of that argument, we compared owned hardware against cloud for node operators here: [/blog/archive-node-hosting-cost-cloud-vs-dedicated](/blog/archive-node-hosting-cost-cloud-vs-dedicated). The takeaway is simple. On a chain running at record throughput, the client upgrade is not the risky part. Doing it without a staged rollout and a way back is. ## Frequently asked questions **What breaks most often during a Solana validator client upgrade?** Rarely the change in the release notes. The recurring failures are version skew between the validator and its tooling or paired RPC node, config drift when flag defaults change between releases, slow ledger catch-up after a restart when snapshots are stale, and hardware headroom that was fine last version but is not fine at higher network load. All four show up as degraded vote latency or missed slots rather than a clean crash. **How do you upgrade a Solana validator without missing slots?** Test the new client on a non-staked node or a testnet identity under representative load before it touches stake. If you run more than one validator, upgrade them one at a time and keep a known-good version you can roll back to. Watch vote latency and skip rate during and after the upgrade, because those tell you the node is healthy faster than a green process check does. **Why does Solana's transaction load make client upgrades riskier?** A busier network raises the floor on CPU, memory, and disk throughput, and it makes ledger catch-up after a restart take longer. In the week ending 6 July 2026 Solana processed more than one billion non-vote transactions for the first time. A botched upgrade that cost a few slots a year ago now lands on a network doing an order of magnitude more work, so the same mistake costs more. **Is owned hardware better than cloud for running a Solana validator through upgrades?** Staged, reversible upgrades are only as safe as your ability to roll back and control the environment. That is more predictable on hardware you control than on a rented instance you have to reprovision, and it avoids the shared-tenancy contention that makes vote-latency regressions hard to diagnose. It is also materially cheaper for a sustained validator workload. --- Source: https://linkpool.com/blog/chain-application-revenue-infrastructure Published: 2026-07-06 Author: LinkPool Team # What application revenue tells you about which chains to run infrastructure on Every infra team ends up asking the same question. Which chains deserve dedicated validators and RPC capacity, and which are noise? Most teams answer it with the wrong inputs. Install counts, incentivised TVL, and narrative cycles all move first and mean least. Application revenue moves last and means most. This post explains how to read it, and what it signals for infrastructure demand. ## What counts as application revenue Application revenue is what users actually pay to use apps on a chain. It covers trading fees, app take rates, and protocol fees earned by deployed applications. It is different from chain revenue, which is gas paid to the network itself. Both matter, but application revenue leads. Apps only earn when users transact. Sustained app earnings mean sustained transactions. Sustained transactions mean sustained load on the infrastructure underneath. ## Why the usual metrics mislead Adjust's Finance App Insights 2025 report makes the case in one chart. Crypto app installs grew about 90% year over year. Sessions grew 2%. That gap is the whole story. Installs measure marketing spend. Sessions measure habit. Revenue measures conviction, because paying users have decided the product is worth real money. TVL has a related problem. Incentive programmes can rent deposits for a quarter. When emissions stop, the capital leaves and the growth reverses. Fees paid are much harder to rent. ## Where the fee activity is right now Public fee dashboards put Solana's May application revenue at roughly $91M. Hyperliquid apps earned around $53M and Ethereum apps around $52M. Check the current month before quoting these figures, the league table moves fast. This week's flow data points the same way. Circle minted another $1B of USDC on Solana, taking reported 2026 issuance past $64B. Solana's tokenised RWA market cap climbed past $3B to a record, having added more than $2B in six months. On Ethereum and BNB Chain, Ondo's tokenised stocks went live on Uniswap, listing 430+ assets with a reported $1B+ TVL. The individual numbers matter less than the pattern they make. Chains where users already pay real fees keep attracting the flows that pay more fees. ## What revenue-led chains demand from infrastructure Fee activity translates into infrastructure load in four specific ways. **Trading apps hammer RPC endpoints.** Perp venues and DEX routers poll state constantly and punish slow responses. RPC demand on fee-heavy chains grows with volume, not with headlines. We broke down the cost side in our [RPC endpoint hosting comparison](/blog/rpc-endpoint-hosting-cost-aws-vs-dedicated). **Revenue attracts institutions, and institutions audit operators.** RWA issuers ask about uptime SLAs, key management, and failure domains before they settle real assets. We covered those requirements in [our RWA infrastructure piece](/blog/rwa-growth-onchain-infrastructure-requirements). **Validator economics hold up after emissions.** On revenue-led chains, fee flow supports validator returns without leaning on inflationary rewards. That matters when you are committing hardware for years, not quarters. **Archive and indexing demand compounds.** Every trading app needs historical state, and archive nodes are where cloud storage bills climb fastest. Our [archive node cost breakdown](/blog/archive-node-hosting-cost-cloud-vs-dedicated) shows how far that goes. ## How we use this signal at LinkPool We run validators and RPC infrastructure across the major chains on owned hardware. Capacity planning starts with fee data, not announcement cycles. A chain with rising application revenue earns a place on the roadmap. A chain with rented TVL and flat fees does not. That discipline comes from paying for the hardware ourselves. We have run mainnet infrastructure since 2017, and owned infrastructure makes you honest about where demand is real. ## Where to find the data - DefiLlama tracks fees and revenue per chain and per app, free. - Token Terminal aggregates application revenue and normalises it across chains. - Blockworks Research and Artemis publish chain-level fee dashboards with historical trends. - Stablecoin issuance is visible onchain, and public trackers report large mints in near real time. Cross-check at least two sources before committing capacity. Dashboards differ on what they count as application revenue versus chain revenue. ## How to read the numbers yourself - Pull application revenue by chain from a public dashboard, monthly, same source every time. - Compare the fee trend to the TVL trend. Fees flat while TVL grows suggests rented capital. - Watch stablecoin issuance as a leading indicator of transactional demand. - Check sessions or active-user data where available. Installs alone are marketing. - Then put validator and RPC capacity where the paying users already are. Revenue is not a perfect metric. But it is harder to game than anything else teams use to pick chains. If your infrastructure roadmap ignores it, you are planning around narrative instead of demand. ## Frequently asked questions **What is application revenue for a blockchain, and how is it different from chain revenue?** Application revenue is what users pay to use apps on a chain: trading fees, app take rates, and protocol fees earned by deployed applications. Chain revenue is the gas paid to the network itself. Application revenue leads, because apps only earn when users transact, so sustained app earnings signal sustained load on the infrastructure underneath. **Why is application revenue a better signal than TVL or install counts for choosing which chains to run infrastructure on?** Installs measure marketing spend, and TVL can be rented for a quarter with incentives, but fees paid are much harder to fake because paying users have decided the product is worth real money. A chain where users already pay real fees keeps attracting the activity that generates more fees, which is what actually drives sustained validator and RPC load. **How does application revenue translate into infrastructure demand?** Fee activity shows up as load in four ways: trading apps poll RPC endpoints constantly and punish slow responses; revenue attracts institutions who audit operators on uptime and key management; fee flow supports validator economics after token emissions taper; and every trading app needs historical state, which drives archive and indexing demand. **Where can you find application revenue data by chain?** Public dashboards like DefiLlama and Token Terminal track fees and application revenue per chain and per app, and Blockworks Research and Artemis publish chain-level fee dashboards with historical trends. Cross-check at least two sources before committing capacity, because dashboards differ on what they count as application revenue versus chain revenue. --- Source: https://linkpool.com/blog/managed-rpc-vs-self-hosted-rpc Published: 2026-06-22 Author: LinkPool Team # Self-hosted RPC vs managed RPC: cost and control trade-offs Most teams pick their RPC setup once, early, and never revisit it. Then traffic grows, a few users start complaining that quotes do not match execution, and the question comes back: do we run this ourselves or pay someone to run it for us. This is the self-hosted versus managed RPC decision. It is not really about price per request. It is about who carries the operational weight when an endpoint falls behind, and how much control you are willing to trade for that. ## What an RPC endpoint actually does for you An RPC endpoint is the door between your application and the chain. Every read, every transaction broadcast, every event subscription goes through it. When it is healthy, nobody thinks about it. When it lags, the symptoms show up somewhere else entirely. A pattern worth noticing: users on r/defi have started tracking the gap between a quoted swap output and the amount that actually lands. The quote looks fine, the execution does not match. Some of that is slippage and MEV. But a slow or stale RPC node feeding the front end stale state is a real contributor, and it is invisible until someone measures it. The same week, three separate threads asked which bridge to trust after getting three different quotes from three different bridges for the same transfer. These are not bridge problems or DEX problems in isolation. They are downstream of how fresh and how fast the underlying node data is. The RPC layer is where that freshness is won or lost. ## The case for self-hosting Running your own node gives you control. You choose the client, the hardware, the sync mode, and the geography. You see the raw mempool. There is no third party between you and the chain, which matters for latency-sensitive work like sequencing, oracle updates, or MEV. The costs are operational, not just financial: - **Sync and maintenance.** Full and archive nodes need babysitting. Reorgs, client upgrades, disk pressure, state bloat. A team running its own archive node is signing up for ongoing work, not a one-time setup. - **Storage growth.** Archive state grows continuously. An archive node workload that needs around 16 TB of fast storage is not unusual, and that footprint only goes up. On hyperscalers the storage line alone gets painful fast. - **Egress.** A public-facing RPC endpoint serves continuous JSON-RPC traffic. On cloud, outbound data is metered per gigabyte, and a busy endpoint can generate several terabytes a month. We broke the egress maths down in our [RPC endpoint hosting cost comparison](/blog/rpc-endpoint-hosting-cost-aws-vs-dedicated), and egress is often the line that surprises people. - **On-call.** Someone has to wake up when the node falls behind at 3am. For a small team that is the founder or the one infra engineer, which means it is the most expensive time you have. Self-hosting wins when you need control you cannot buy: custom client config, private mempool access, a specific geography, or sub-millisecond latency where the network path matters. ## The case for managed RPC Managed RPC means someone else runs the node and you call an endpoint. You trade direct control for not carrying the operational weight. The honest version of the trade-off: - **You stop maintaining sync.** Client upgrades, reorgs, disk pressure, and archive growth become the provider's problem. - **Pricing becomes predictable, or it does not.** This is where managed providers differ sharply. Credit and compute-unit billing means your bill moves with traffic and can spike without warning. Fixed request-per-second pricing means you know the number in advance. We price RPC at a fixed sustained request rate with no monthly cap and no overage charges, which is unusual in the market. - **You inherit the provider's reliability, good or bad.** A managed endpoint is only as good as the infrastructure under it. If the provider runs on shared cloud capacity, you inherit their noisy-neighbour risk and their SLA ceiling. Managed wins when RPC is not your differentiator. If you are a protocol team, your edge is your protocol, not your node-ops practice. Paying someone to run the endpoint properly frees the team to build. ## The reliability point most comparisons skip Cost is the easy axis to compare because it is a number. Reliability is the one users actually feel, and it rarely appears in a pricing table. When a quote does not match execution, when a bridge returns a stale balance, when a transaction sits unconfirmed, the user blames the app. They do not know or care whether the RPC node behind it was three blocks behind. The reliability of that node is your product experience, whether you run it or rent it. So the real question is not only "what does this cost per month". It is "what happens to my users when this endpoint degrades, and who is accountable for fixing it". Self-hosting makes you accountable. Managed makes the provider accountable, which is only worth something if the provider is actually good. ## A simple way to decide - **Run it yourself** if RPC performance is a core part of your edge, you need control you cannot buy, and you have or will hire the operational capacity to run nodes properly around the clock. - **Buy managed** if RPC is plumbing rather than differentiation, you want predictable cost and predictable reliability, and you would rather your team spent its time on the product. Either way, measure the gap between quoted and actual behaviour your users see. That number tells you more about your RPC layer than the line item ever will. LinkPool runs validator and RPC infrastructure on our own hardware across three availability zones in Manchester, and we have operated mainnet infrastructure since 2017 with zero slashing. If you are weighing the self-hosted versus managed decision, that operating history is the lens we bring to it. --- Source: https://linkpool.com/blog/rwa-growth-onchain-infrastructure-requirements Published: 2026-06-09 Author: LinkPool Team # Where RWA growth is happening onchain and what it demands of infrastructure Real-world assets onchain stopped being a slide in a pitch deck a while ago. The question now is narrower and more useful for anyone running infrastructure. Which networks are seeing real RWA activity, and what does that activity demand from the validators and nodes underneath it? ## Where the growth is showing up A few signals from recent onchain reporting are worth pulling together, because they point in the same direction. Provenance, a network built specifically for regulated financial assets, has reportedly seen steady total-value-locked growth over recent months. It is not a launch-week spike. It is the kind of gradual month-over-month accumulation institutional settlement tends to produce when it is real rather than incentivised. Euler, a lending protocol, reportedly saw a sharp rise in daily active users after Securitize's VBILL was enabled as collateral. The mechanism there matters more than the number. A tokenised treasury product became usable as collateral in an onchain lending market, and usage followed almost immediately. That is the bridge between a traditional financial instrument and onchain credit working in practice. Cardano's stablecoin supply has reportedly risen sharply over the past year, driven by several dollar-denominated tokens rather than one. Stablecoins are the settlement rail RWA activity rides on. Supply growth on a network is a reasonable leading indicator of where tokenised-asset flows may concentrate next. None of these are LinkPool figures and none should be treated as audited. They are directional signals from onchain reporting. Taken together they say the same thing. RWA activity is not spreading evenly across every chain. It is concentrating on networks that can credibly carry regulated value. ## Why concentration changes the infrastructure question When RWA flows concentrate on a handful of networks, the infrastructure question changes. It stops being "can we run a node on chain X" and becomes "can we run the node that institutions settling real value will actually trust." Those are different bars. A hobbyist validator and a validator carrying tokenised treasuries face the same protocol but very different consequences for downtime, key compromise, or a missed attestation. The closer onchain value sits to regulated financial assets, the less tolerance there is for the failure modes crypto infrastructure has historically shrugged off. ## What institutional RWA settlement demands of the infrastructure underneath Three requirements come up repeatedly once the value at stake is real. **Uptime that holds during the moments that matter.** Settlement does not pause for a maintenance window. LinkPool runs to a 99.99 percent target uptime SLA, backed by redundancy across three availability zones in Manchester. The loss of a single site does not take the service down. **A track record under real conditions, not a testnet.** Institutions delegating to a node operator ask what has actually happened on your watch. LinkPool has operated validator infrastructure since 2017 with zero slashing events, soft or hard, across that period. For RWA settlement, an operator's history of not losing value is the proof that matters most. **Control over the stack, not a rented dependency.** Much crypto infrastructure runs on hyperscaler accounts, where an outage or a policy decision somewhere else can take validators offline. LinkPool runs on owned hardware rather than rented cloud instances, across three availability zones in Manchester. That removes the hyperscaler dependency institutional reviewers increasingly ask about. ## The takeaway for operators If you are deciding where to put infrastructure effort, follow where regulated value is actually settling rather than where the narrative is loudest. The networks carrying real RWA growth are raising the bar on what the infrastructure beneath them has to guarantee. Meeting that bar is mostly about uptime, a clean operating history, and control over the stack. For the operator's view on running infrastructure for high-consequence workloads, we have written about [what TradFi institutions look for when running validators](/blog/tradfi-institutions-running-validators) and about [running Chainlink Data Streams as a node operator](/blog/chainlink-data-streams-node-operations). ## Frequently asked questions **Which networks are seeing real RWA growth?** Onchain reporting points to a handful of networks rather than an even spread. Provenance, built for regulated financial assets, has seen steady total-value-locked growth; Euler saw a sharp rise in daily active users after Securitize's VBILL became usable as collateral; and Cardano's stablecoin supply has risen sharply over the past year. None of these are LinkPool figures or audited, but together they suggest RWA activity is concentrating on networks that can credibly carry regulated value. **How does RWA settlement change the infrastructure requirements for a validator?** It moves the bar from 'can we run a node on this chain' to 'can we run the node institutions settling real value will actually trust.' A validator carrying tokenised treasuries faces the same protocol as a hobbyist validator but very different consequences for downtime, key compromise, or a missed attestation, so tolerance for the failure modes crypto infrastructure has historically shrugged off drops sharply. **What does institutional RWA settlement demand of the infrastructure underneath?** Three things come up repeatedly: uptime that holds during settlement (LinkPool runs to a 99.99 percent target uptime SLA across three availability zones in Manchester), a real operating track record (LinkPool has run validator infrastructure since 2017 with zero slashing events, soft or hard), and control over the stack through owned hardware rather than rented cloud instances. --- Source: https://linkpool.com/blog/archive-node-hosting-cost-cloud-vs-dedicated Published: 2026-06-04 Author: LinkPool Team # Archive node hosting cost: cloud vs dedicated infrastructure in 2026 An Ethereum archive node holds the full historical state of the chain. It is already large, and it grows continuously as the chain produces new state. The compute profile is steady. The storage profile is not. That single fact is what makes archive node hosting cost behave differently from a validator or a full node. It is where cloud and dedicated infrastructure diverge the most. This page covers where the cost actually goes. It also covers why a quote that looks fine in month one does not hold by month twelve. ## What an archive node actually requires A validator needs little storage. A full node needs a few terabytes. An archive node is a different shape of workload. It stores every historical state, so it carries a large and continuously growing storage footprint. It also serves deep historical queries with sustained random reads. The compute and memory lines are predictable. They do not move much month to month. Storage is the line that grows. On cloud it is also the line billed in the way that compounds. ## Cloud cost: compute is fixed, storage is not On shared-tenant cloud the bill splits into two different behaviours. Compute and memory run at a predictable rate that does not change as the node grows. Storage is the problem. Cloud block storage is billed per gigabyte per month. An archive node adds new state every month and never gives any back. The storage line climbs every month and never comes down. The instance you sized at the start is undersized within the first year. The bill has been rising the whole way there. There is no ceiling in that model. You pay for exactly what the chain produces. That reads as efficient until you add up two years of continuous growth and the meter has never stopped. ## Dedicated cost: a fixed line that does not compound On dedicated component-priced infrastructure the same workload is a fixed monthly cost. Storage is priced per terabyte provisioned, not per gigabyte consumed. The rate does not change as the node grows. The dedicated line is flat. You provision storage ahead of the growth curve and keep the same rate as the node expands. The cloud line climbs every month the chain produces state. That difference only shows up when you look past the first invoice. ## The part cloud does not solve Cost is not the only reason archive workloads end up on dedicated infrastructure. The other reason is I/O. Archive queries are sustained random reads against the full state. That is one of the hardest patterns for shared storage to serve predictably. You compete with every other tenant on the same fabric for the same throughput. Local NVMe on owned hardware removes that contention. The reads land on disks nothing else is touching. For a workload measured on tail latency and query throughput, that predictability is worth as much as the cost difference. A cheaper archive node that stalls under load is not cheaper. ## The short version A standard cloud instance sized for an archive node today is undersized within the first year. The storage bill compounds the whole way. Dedicated infrastructure prices the same workload as a flat line, with the I/O profile archive queries actually need. See also: [ETH validator hosting cost: AWS vs dedicated](/blog/eth-validator-hosting-cost-aws-vs-dedicated) for the validator workload in the same series, and [why we run dedicated infrastructure for Web3](/blog/bare-metal-kubernetes-web3-before-enterprise) for the architecture behind it. ## Frequently asked questions **What makes archive node hosting cost different from a validator?** Storage. An archive node stores the full historical state and grows continuously, so on shared-tenant cloud the storage bill compounds month over month while compute stays flat. A validator needs very little storage, so its cost stays stable. **Why does an archive node cost more on cloud than on dedicated infrastructure?** Cloud block storage is billed per gigabyte consumed with no ceiling, so the bill climbs every month the chain produces new state. Dedicated infrastructure prices storage per terabyte provisioned at a fixed rate, so the line stays flat as the node grows. **Do archive nodes need local NVMe storage?** Archive queries are sustained random reads against the full state, which shared storage struggles to serve predictably under tenant contention. Local NVMe on owned hardware removes that contention and gives the predictable I/O archive workloads need. --- Source: https://linkpool.com/blog/dtcc-stellar-tokenized-tradfi-infrastructure Published: 2026-06-04 Author: LinkPool Team # DTCC on Stellar: what tokenised TradFi means for chain infrastructure demand DTCC choosing Stellar for tokenised stocks, ETFs and Treasuries is one of the more significant institutional blockchain developments of the last two years. Most of the public reaction has been about the XLM price. That is the least interesting part. The reason it matters is not which token rallied. It is which entity is moving. The Depository Trust and Clearing Corporation clears and settles infrastructure connected to more than 114 trillion dollars of traditional capital markets. When that entity puts a tokenisation rail on a public chain, the chain stops being a sandbox. Public chains have had institutional pilots before. Most ran on permissioned forks or private subnets. The substance of this announcement is that the rail is the actual public Stellar network, validated by an open operator set, with public block production and public state. That changes the question the institutional buyer asks about infrastructure. ## What changes when TradFi settles on a public chain For the last three years, "what chain do you operate on" was effectively a marketing question for a node operator. You picked your ecosystem, you ran your validators, you published your rating, you moved on. The chain itself was a brand attribute. After a DTCC-style settlement rail goes live, that question moves into the procurement column. Once a tokenised treasury is settling on Stellar, the institution holding that asset has a documented dependency on the validator set producing the blocks. The infrastructure question becomes a real due-diligence question, asked by a real risk committee, with a real audit trail. Three operational properties become external due-diligence requirements rather than internal documentation. The first is zone and fault-domain redundancy at the validator layer. A 99.9% chain availability number aggregates across the validator set. A specific operator's contribution to that number depends on where its nodes sit, how it tolerates a single-zone or single-provider failure, and whether its signing process is isolated from the rest of its compute fleet. The second is RPC reliability for the holder side of the workload. Institutional allocators do not just need a chain to produce blocks. They need read paths from the chain that survive load spikes, mempool congestion, and provider-level outages. RPC procurement starts looking less like a developer tool choice and more like a market data feed contract. The third is incident response under conditions where the off-chain instrument is still active. If a tokenised US Treasury is held on a public chain, and the chain has a 3am operational event, the cash-market position still has overnight rate exposure. The chain operator's response window stops being measured in hours and starts being measured in the same minutes that TradFi operations teams already work to. None of this is hypothetical. The work to be ready for these questions is the same work [institutions moving from delegated staking to running validators directly](/blog/tradfi-institutions-running-validators) have been doing for the last twelve months on validator selection. The same operational-resilience expectations now [showing up in regulation like MiCA](/blog/mica-staking-compliance-infrastructure) point in the same direction. The change is that it now reads as procurement, not optionality. ## The chain choice is downstream of the operator set A useful way to think about the next twelve months is to invert the framing the announcement encourages. The headline framing is: DTCC picked Stellar. The operator-side framing is: DTCC picked the operator set on Stellar. Stellar has a validator selection mechanism, an operator topology, and an existing institutional operator footprint. Those properties are what made the choice viable. If a different chain wanted to host the next DTCC-style announcement, the candidate chain would be evaluated against that same set of operator-layer properties, not just consensus design or throughput claims. The implication is that chains hosting the next tokenised TradFi rail are likely to be chains where the institutional operator set is already deep and visible. That is a different selection criterion to "which chain is fastest" or "which chain has the lowest fees". It is closer to "which chain has the operator coverage a regulator-supervised counterparty can sign off on". There is a second-order effect for allocators evaluating yield. The same property that makes a chain viable for tokenised settlement, a deep and visible institutional operator set, also makes the chain a more defensible place to allocate staking capital. The two questions converge. ## Where this leaves application revenue The day's other relevant infrastructure data point is the May application-revenue picture across chains. Solana led on application revenue last month, ahead of Hyperliquid and Ethereum. The pattern of revenue concentrating in a small number of ecosystems is not new, but the gap is widening. Application revenue and institutional settlement are not the same question. But they share a property. Both reward chains where the operator and application layer can survive sustained external demand. Capital follows that property in both directions: as application fees for the user-funded layer, and as procurement contracts for the institution-funded layer. ## Four questions an institutional buyer should ask now This is not a checklist for chain selection. It is an operator-side observation of what the next twelve months of institutional due diligence look like. If you are an allocator or a treasury looking at exposure to tokenised TradFi on a public chain, these are the four questions that surface fastest. 1. Which validator operators produce blocks on the chain that hosts the tokenised asset, and what is the largest operator's stake or block-production share. 2. What is the fault-domain boundary at the validator layer between an individual operator and the underlying cloud or compute provider. 3. Where does the signing process for the validator and any related custody operations execute, and is that execution isolated from the operator's general-purpose compute. 4. What is the operator's documented incident response window, and how is it tested. These are the same questions institutional staking allocators have already learned to ask. The DTCC announcement just pulls them into a larger conversation than staking yield. The operators that can answer those four questions inside an hour will spend the next year looking like the obvious choice. The operators that cannot will spend the next year explaining. LinkPool runs validators across three availability zones in Manchester on [owned, dedicated hardware](/blog/bare-metal-kubernetes-web3-before-enterprise), with the signing process isolated per cluster. We are happy to walk any institutional allocator through what an operator-side procurement conversation actually looks like in practice. ## Frequently asked questions **What does DTCC settling tokenised assets on Stellar mean for chain infrastructure?** It moves the validator set from a branding detail to a procurement dependency. Once a regulated entity settles tokenised securities on a public chain, the institution holding the asset has a documented reliance on the operators producing the blocks, so validator topology, signing isolation and incident response become external due-diligence questions rather than internal operator documentation. **What should an institutional buyer ask about a public chain's validator set?** Which operators produce blocks and the largest operator's share, the fault-domain boundary between an operator and its underlying cloud or compute provider, where the signing process executes and whether it is isolated, and the operator's documented and tested incident-response window. **Why does RPC reliability matter for tokenised TradFi?** Holders need read paths from the chain that survive load spikes, mempool congestion and provider outages, not just block production. For institutional workloads, RPC procurement looks closer to a market-data-feed contract than a developer tool choice. **Is the chain choice or the operator set more important for tokenised settlement?** The operator set. A chain becomes viable for tokenised settlement because its operator topology and institutional footprint can satisfy a regulator-supervised counterparty. The next tokenised TradFi rail is likely to land on a chain where the institutional operator set is already deep and visible. --- Source: https://linkpool.com/blog/threshold-signing-stopped-being-thought-leadership Published: 2026-05-26 Author: LinkPool Team # DVT stopped being thought leadership in March 2026 For 18 months, distributed validator technology was a thoughtful position for forward-leaning operators. In one month, March 2026, that framing died. The Ethereum Foundation staked 72,000 ETH using DVT-Lite. AWS Marketplace listed DVT-as-a-Service. Vitalik publicly pushed DVT-Lite as the default validator path. DVT stopped being thought leadership. It became the under-published expectation. ## What changed in March 2026 Three events, in the same month, from three different parts of the protocol. The Ethereum Foundation moved 72,000 ETH into staking using DVT-Lite. That is the protocol's largest principal allocating its own capital to a distributed validator architecture. Not a research grant. Not a testnet. Production stake. AWS Marketplace published a Distributed Validator Technology as a Service listing via SSV Network. That is the largest cloud vendor adding DVT to the same catalogue used by every enterprise procurement team in the world. Operators no longer have to explain what DVT is to a buyer who reads the AWS Marketplace. Vitalik Buterin published a public push for DVT-Lite as the one-click validator default on March 10. That is the protocol's most-quoted researcher saying out loud what the EF stake already implied. And in April 2026, SSV Network launched cSSV Genesis Boost, a liquid representation of staked SSV earning ETH-denominated network-fee rewards. The underlying DVT layer is now a tradable financial instrument, not a thesis. When the protocol's largest principal, the largest cloud vendor, and the protocol's most-quoted researcher publicly converge on a position, the position is no longer a thesis. It is the operational stance. ## What threshold signing actually does Threshold signing splits validator keys across multiple operators. A typical configuration is 3-of-4 or 5-of-7 depending on the chain. Any signing decision requires the threshold of operators to agree. No single operator can sign incorrectly. One bad actor or one compromised key store cannot trigger a slashing event because the signature is invalid without the threshold. No single operator can sign nothing. One operator's outage does not cause a liveness failure because the remaining operators meet the threshold without it. The counterparty risk changes from "trust this one operator" to "trust the system of operators." For institutional allocators, this is the same risk shift that moved DeFi protocols from single-multisig to threshold-multisig over the last three years. The argument has already been made and accepted in an adjacent market. ## The asymmetry between the signal and the operator list The named operators on the BlackRock ETHB validator set, which launched 2026-03-12, are Coinbase Prime, Figment, Galaxy, and Attestant. The Lombard BTC institutional staking validator set, announced April 2026, names Figment, Galaxy, Kiln, and P2P. The various pending staking-ETF amendments from Fidelity, Franklin Templeton, Invesco, 21Shares, and VanEck have not all published validator architectures yet. Some of those operators run distributed validator clusters. Most do not, or do so partially. Attestant is the operator on the ETHB list publicly running on dedicated infrastructure, and it runs distributed setups in parts of its book. The rest of the list is a mix of single-operator and partial-DVT architectures. The institutional buyer asking "who runs my staking" is being given a list of operator names. The institutional buyer who asks "what is the architecture behind that list" is getting a different and shorter answer. That asymmetry is the story. The market just signalled that DVT is the default. The named-operator list has not caught up. ## Where the infrastructure question fits DVT changes the operator-side risk shape. It does not change the hardware-side risk shape. Four operators in a DVT cluster all sharing one cloud provider concentrate platform risk back into a single point of failure. In November 2022, Hetzner banned Solana validators from its network. Over 1,000 validators went offline in a single policy decision by one provider. The slashing-domain risk that DVT removes at the signing layer can return at the hosting layer if the cluster is not architected for provider diversity. DVT and dedicated infrastructure are not the same conversation. They answer overlapping questions and the institutional buyer needs both. The list of who runs the validator and the list of what the validator runs on are separate questions. ## What institutional allocators should ask now The post-March-2026 due-diligence questions split between operator-side, architecture-side, and infrastructure-side. Each surfaces a different failure mode. Does the operator run threshold signing as a default rather than as an option. What is the threshold scheme and how many operators are in each cluster. Where is each operator in the cluster domiciled and under what regulatory regime. What hardware does each operator in the cluster run on and is there hosting-provider overlap across the cluster. What is the documented track record on uptime and slashing across the operator's full operating history, not just the marketed period. Each of those questions has a public answer if the operator is willing to give it. The operators that cannot answer them are the operators whose architecture has not caught up to the March 2026 signal. ## The next 18 months Institutional validator participation is going to be evaluated on architecture and infrastructure questions, not on operator-name questions. The named-operator list is settling. The architecture-and-infrastructure list is wide open. Which list does your fund's staking due diligence prioritise today, and which list would you need to revisit if the named-operator list has stopped being the differentiator? --- LinkPool operates Lido SSV distributed validator clusters in production, holds an AAA Staking Rewards rating across all four categories, has zero slashing events across its full operating history, and runs across three availability zones in Manchester with a 99.99% target SLA. Cross-reference: [What is distributed validator technology (DVT)?](/blog/what-is-distributed-validator-technology), [Infrastructure considerations for MiCA compliance](/blog/mica-staking-compliance-infrastructure), [Dedicated Kubernetes for Web3 before enterprise vendors](/blog/bare-metal-kubernetes-web3-before-enterprise). --- Source: https://linkpool.com/blog/building-in-house-staking-oracle-infrastructure Published: 2026-05-15 Updated: 2026-09-07 Author: LinkPool Team # Building in-house staking and oracle infrastructure in 2026 More institutions are evaluating whether to run Ethereum validators and oracle nodes in-house. The question is reasonable: staking rewards compound at scale, and the cost difference between cloud and owned infrastructure is significant. The answer depends on what "in-house" actually means operationally. This is not a case against building in-house. It is a description of what you are actually building. ## The workload A single Ethereum validator has a predictable steady-state resource profile: 8 vCPU of sustained compute, 32 GB RAM, and around 2 TB of NVMe storage growing at roughly 2 TB per year. The workload is memory-bound, not CPU-bound. It is sensitive to latency, not throughput. A validator that misses its attestation window costs money directly. Oracle nodes have a different profile. A Chainlink node serving price feeds or proof-of-reserves operates on an event-driven model: fetch, aggregate, sign, and deliver on-chain within a defined response window. Sub-second response is the expectation for high-frequency feeds like [Chainlink Data Streams](/blog/chainlink-data-streams-node-operations). The node needs stable compute and reliable outbound connectivity more than it needs peak throughput. Both workloads share one characteristic: they need to run all the time, and failure has a direct cost. A missed attestation is a small penalty. A missed oracle update in a DeFi protocol can trigger unintended liquidations. The margin for unplanned downtime is low. ## What in-house actually requires ### Hardware and hosting The first decision is where the hardware runs. Cloud instances are the default for most infrastructure teams. The economics are workable at small scale, but cloud introduces two risks for validator workloads. The first is hypervisor jitter. AWS, GCP, and Azure share physical hardware across tenants. CPU scheduling is dynamic. A hypervisor context switch during an attestation signing cycle can delay the response by 0.3 to 1.2 milliseconds. Over thousands of slots with tight windows, that jitter accumulates into measurable yield reduction. The second is platform risk. In 2022, Hetzner terminated 1,000+ Solana validators in a single policy update. The nodes were gone within hours. That kind of platform-level termination risk does not appear in uptime SLAs. Dedicated hardware resolves both. The compute is isolated. There is no hypervisor scheduling another workload between your validator's signing cycles. The hardware is yours until you choose to decommission it. Hosting dedicated hardware requires either a co-location agreement with a data centre or a managed hosting provider. A production setup for Ethereum validators needs redundant power feeds, out-of-band management access, and hardware replacement SLAs. A home lab or single-site setup introduces single points of failure that compound with geographic concentration risk. ### Client software Ethereum requires running both an execution client and a consensus client. The Ethereum Foundation recommends running a minority client combination to avoid network-wide correlated failures. As of 2026, the dominant client pairs are Geth/Lighthouse and Geth/Prysm. Running Nethermind, Besu, or Erigon on the execution side, and Teku or Nimbus on the consensus side, reduces correlated risk but increases operational complexity. Each client has its own configuration, its own metrics format, its own upgrade cadence, and its own edge cases. A team running a single client pair can develop deep familiarity. A team running minority clients across a larger validator set needs broader expertise and more testing capacity. ### Key management Validator keys are the most sensitive operational element. A validator key compromise can cause slashing. A loss of the key means loss of the validator. Production key management requires a signing approach that limits key exposure, a backup and recovery procedure that can be executed under pressure, and a slashing database that prevents signing the same slot twice across restarts. [Distributed validator technology](/blog/what-is-distributed-validator-technology) (DVT) reduces single-key risk by splitting the validator key across multiple operators using threshold signing. A 3-of-4 cluster means no single key compromise can cause slashing. It also means the key management process is more complex: distributed key generation ceremonies, keyshare storage across multiple locations, and exit coordination across four independent parties. DVT is becoming the expected baseline for institutional Ethereum staking. Lido's [Identified DVT Cluster programme](/blog/lido-identified-dvt-cluster-operators) formalises this for the largest staking protocol. Teams building in-house validator infrastructure in 2026 should plan for DVT integration, not treat it as a future option. ### Monitoring and incident response A validator that goes offline for six hours needs a human to notice within minutes, not hours. That means 24/7 monitoring with paged alerts and an on-call rotation that can respond. For a team where validator operation is a secondary function, that rotation is expensive: engineers on call for infrastructure that is not their primary product. The monitoring stack itself is non-trivial. Execution client health, consensus client sync status, attestation inclusion rates, balance deltas, fee recipient configuration, slashing database integrity, and DVT cluster health are all independent signals that need separate instrumentation and separate alert thresholds. Off-the-shelf monitoring solutions exist, but calibrating them to avoid alert fatigue while catching real issues takes time. Oracle nodes add another layer: data source availability, feed staleness detection, on-chain delivery confirmation, and gas price management during congestion. A Chainlink oracle node that stops delivering during a high-volatility market event can have downstream consequences in DeFi protocols using that feed. ### Staffing The most consistent underestimation in in-house infrastructure builds is staffing cost. Hardware has a one-time cost. Software has a setup cost. The ongoing cost is people. Running Ethereum validators and oracle nodes in production requires at minimum: someone who owns client software maintenance, someone who can respond to incidents at 3am, someone who understands the key management setup well enough to execute an emergency exit, and someone tracking the protocol upgrade schedule across Ethereum, the DVT protocols, and any oracle networks in scope. At a startup or fund where blockchain infrastructure is not the core product, those responsibilities land on engineers who have other priorities. That works until something goes wrong. The question is not whether an incident will happen but whether the team has the depth to handle it when it does. ## Where in-house makes sense In-house operation is the right call when the team has existing dedicated infrastructure, when blockchain node operation is already a core competency, and when the mandate requires direct key custody. An exchange, a custodian, or a protocol that already runs blockchain nodes at scale has the operational foundation. Adding validators or oracle nodes is an extension of existing capability, not a new discipline. It is harder to justify when validators are a new workload, when the team is small, or when staking is a financial position rather than a product line. The yield economics improve with scale, but so does the operational cost. ## The make vs. buy decision The cost comparison is straightforward. A cloud-based validator workload costs around $556 per month on AWS. The same workload fits on a $219 whole server, and [component-priced managed infrastructure](/blog/eth-validator-hosting-cost-aws-vs-dedicated) comes in lower still because it charges for the validator's footprint rather than a whole machine. The hardware saving is real. The staffing cost is harder to quantify but dominates total cost of ownership. A managed provider absorbs client maintenance, monitoring, on-call response, DVT integration, and upgrade coordination. The question is whether that operational load, at whatever scale you are running, is cheaper to build internally or buy externally. Both answers are legitimate. The mistake is underestimating what the in-house answer actually requires. ## Common questions **What hardware does an Ethereum validator node require?** A production Ethereum validator node requires a minimum of 8 vCPU of sustained compute, 32 GB RAM, and 2 TB of NVMe storage for chain data growth over roughly 12 months. The workload is steady-state, not bursty, and is sensitive to latency jitter. Dedicated hardware outperforms cloud instances for attestation timing because it eliminates hypervisor scheduling overhead. **How much does it cost to run an Ethereum validator in-house?** Running a single Ethereum validator workload in-house on a cloud instance costs approximately $556 per month on AWS. The same workload fits on a $219 whole dedicated server, and costs less again on component-priced managed infrastructure that charges only for the slice of a host the validator uses. The hardware cost is the smaller part of total cost of ownership. Staffing an on-call rotation and maintaining client software, monitoring, and key management represents the larger ongoing cost. **What is the operational overhead of running Ethereum validators in-house?** In-house validator operation requires: execution and consensus client software maintenance across multiple client types, key management and slashing protection, 24/7 monitoring with on-call response, DVT protocol integration and ceremony coordination if running distributed validators, upgrade coordination across client releases, and incident response runbooks. Most teams underestimate the staffing cost: a single engineer managing validators as a secondary responsibility will accumulate latent risk. **When does it make sense to run staking infrastructure in-house versus using a managed provider?** In-house operation makes sense when you have existing dedicated infrastructure, a DevOps team already running blockchain nodes, and a mandate to maintain direct key custody. Managed operation makes sense when staking is not your core product, when you want to avoid staffing an on-call rotation for validator work, or when you need DVT support, multi-client redundancy, and SLA guarantees without building the capability internally. ## Frequently asked questions **What hardware does an Ethereum validator node require?** A production Ethereum validator node requires a minimum of 8 vCPU of sustained compute, 32 GB RAM, and 2 TB of NVMe storage for chain data growth over roughly 12 months. The workload is steady-state, not bursty, and is sensitive to latency jitter. Dedicated hardware outperforms cloud instances for attestation timing because it eliminates hypervisor scheduling overhead. **How much does it cost to run an Ethereum validator in-house?** Running a single Ethereum validator workload in-house on a cloud instance costs approximately $556 per month on AWS. The same workload fits on a $219 whole dedicated server, and costs less again on component-priced managed infrastructure that charges only for the slice of a host the validator uses. The hardware cost is the smaller part of total cost of ownership. Staffing an on-call rotation and maintaining client software, monitoring, and key management represents the larger ongoing cost. **What is the operational overhead of running Ethereum validators in-house?** In-house validator operation requires: execution and consensus client software maintenance across multiple client types, key management and slashing protection, 24/7 monitoring with on-call response, DVT protocol integration and ceremony coordination if running distributed validators, upgrade coordination across client releases, and incident response runbooks. Most teams underestimate the staffing cost: a single engineer managing validators as a secondary responsibility will accumulate latent risk. **When does it make sense to run staking infrastructure in-house versus using a managed provider?** In-house operation makes sense when you have existing dedicated infrastructure, a DevOps team already running blockchain nodes, and a mandate to maintain direct key custody. Managed operation makes sense when staking is not your core product, when you want to avoid staffing an on-call rotation for validator work, or when you need DVT support, multi-client redundancy, and SLA guarantees without building the capability internally. --- Source: https://linkpool.com/blog/how-to-evaluate-managed-ethereum-staking-oracle-operators Published: 2026-05-15 Updated: 2026-09-07 Author: LinkPool Team # How to evaluate managed Ethereum staking and oracle operators in 2026 The institutional staking market has consolidated around a small set of managed infrastructure providers. For a fund or protocol treasury deploying $50M or more in staked assets, operator selection is a risk decision as much as a yield decision. Slashing history, infrastructure model, jurisdiction, and protocol breadth vary significantly across providers. This comparison covers the main categories of managed staking operator in 2026, plus the oracle data infrastructure layer that sits alongside staking mandates. ## Managed staking operators: infrastructure approaches | Approach | Network coverage | Infrastructure model | DVT support | |---|---|---|---| | Large multi-chain cloud operators | 40-50+ networks | Cloud (AWS, GCP, Azure) | Varies | | API-first white-label platforms | 20-30 networks | Cloud | Yes | | Enterprise SaaS operators | 40-50+ networks | Cloud, custodian integrations | Limited | | Dedicated-hardware operators | Ethereum, Chainlink, Cosmos | Owned hardware, 3 AZs | Yes (SSV, Obol) | ## What the infrastructure model actually means Every managed staking provider sells uptime and yield performance. The infrastructure model determines whether they can reliably deliver both. Cloud-based operators run validators on instances that share physical hardware with other tenants. AWS, GCP, and Azure allocate CPU time across workloads dynamically. For most applications that flexibility is useful. For Ethereum validators it creates a specific risk: attestation timing. Ethereum attestation windows are short. A hypervisor scheduling delay on a shared instance can cause a late attestation or a missed proposal. Over thousands of slots, those misses accumulate into a measurable yield reduction. Most large operators in the managed staking market run on cloud infrastructure. They manage the cloud risk through client diversity, geographic distribution, and monitoring. Some operators offer API-first white-label models, primarily for exchanges and wallet platforms embedding staking as a product. Dedicated-hardware operators run validators on servers installed in contracted data centre facilities. The workload is isolated. There is no hypervisor scheduling another tenant's job between your validator's signing cycles. This is the same reason low-latency trading infrastructure moved off cloud: the physics do not negotiate. LinkPool operates on dedicated hardware across three availability zones in Manchester. 72 months on Ethereum mainnet with zero slashing events. That track record is on owned infrastructure, not instances that could be terminated or reallocated by a cloud vendor. ## Protocol coverage and client integrations For funds or custodians running a multi-chain portfolio, protocol coverage matters. The largest multi-chain operators support 40 to 50+ proof-of-stake networks. Several have custody integrations with Anchorage, BitGo, and Fireblocks, allowing institutional clients to stake without moving assets off their custody stack. LinkPool's focus is narrower: Ethereum validator infrastructure, Chainlink oracle nodes, and Cosmos ecosystem chains. For institutional buyers who need a [DVT-capable operator](/blog/what-is-distributed-validator-technology) with dedicated hardware and a UK jurisdiction, the set of operators meeting all three criteria is small. ## Oracle data infrastructure Oracle infrastructure sits adjacent to staking in the institutional Web3 stack. Protocols running Chainlink price feeds, proof-of-reserves checks, or cross-chain messaging need credentialed node operators with verifiable uptime and response latency. The infrastructure requirements are the same: low-latency, dedicated hardware, strong operational history. Chainlink's Top-Tier node operator programme credentials operators based on data delivery quality, uptime, and response consistency. LinkPool has run Chainlink nodes on mainnet since the network launched in May 2019. The [Chainlink Data Streams service](/blog/chainlink-data-streams-node-operations) runs at sub-second latency. It requires the same dedicated infrastructure approach that makes validator operation viable at institutional scale. Most managed staking providers do not operate oracle nodes. The two disciplines share infrastructure requirements but sit in different commercial tracks. For a protocol or institution that needs staking and oracle data services from a single operator, the shortlist is short. ## Distributed validator technology DVT (distributing a validator key across multiple independent operators) is the emerging standard for institutional-grade Ethereum staking. Lido's [Identified DVT Cluster programme](/blog/lido-identified-dvt-cluster-operators), Obol's Techne programme, and SSV Network's operator incentive structure point in the same direction: keyshare-based operation is the expected baseline for serious operators over the next 12 to 18 months. Production DVT deployments vary significantly across the market. Some operators have active integrations; others have roadmap commitments without production history. LinkPool holds an active SSV partnership and runs SSV nodes in production alongside [dedicated Kubernetes infrastructure](/blog/bare-metal-kubernetes-hosting) that isolates DVT workloads from other node traffic. ## How to evaluate the shortlist For institutional buyers running a selection process, the criteria that matter beyond fee schedules are: - **Slashing history**: ask for a mainnet incident log going back to genesis participation. Any slashing event, even a small one, reveals something about the operator's key management and monitoring discipline. - **Infrastructure model**: cloud or dedicated. If cloud, which provider, which regions, and what their platform risk policy looks like. Hetzner terminated 1,000+ Solana validators in a single policy change in 2022. - **Jurisdiction**: MiCA compliance is an operational question for EU-regulated funds. UK and Swiss operators sit in defined regulatory environments. Offshore registrations carry different counterparty risk profiles. - **DVT readiness**: if you are considering Lido CSM or SSV staking in the next 12 months, confirm whether the operator has production DVT experience or just a roadmap commitment. ## Common questions **What is a managed staking provider?** A managed staking provider operates validator nodes on behalf of institutional clients. The client deposits assets and retains economic exposure to staking rewards; the provider handles the technical operation: client software, key management, monitoring, slashing protection, and uptime. Providers differ in infrastructure model (cloud vs. dedicated hardware), jurisdictional footprint, and the set of proof-of-stake networks they support. **What is the difference between cloud-based and dedicated-hardware staking operators?** Cloud-based operators run validator nodes on AWS, Google Cloud, or Azure. Dedicated-hardware operators run validators on owned servers in contracted data centre facilities. Cloud infrastructure introduces shared-resource risk: the hypervisor schedules CPU time across tenants. Ethereum attestations are time-bounded; hardware jitter on a shared instance can cause late attestations. Dedicated hardware isolates the validator workload and eliminates hypervisor overhead. **Which staking providers support distributed validator technology?** Distributed validator technology (DVT) splits a validator key across multiple operators using threshold signing (typically 3-of-4). Operators who have deployed DVT in production include Obol and SSV Network at the protocol level, and infrastructure providers who have integrated those protocols. LinkPool operates SSV Network nodes in production and holds an active SSV partnership. **What is a Chainlink oracle node operator?** A Chainlink oracle node operator runs server infrastructure that fetches off-chain data (asset prices, proof-of-reserves, event outcomes) and delivers it on-chain via signed transactions. Top-tier Chainlink node operators are credentialed by Chainlink Labs based on data quality, uptime, response latency, and operational history. LinkPool has operated Chainlink oracle nodes since 2018. ## Frequently asked questions **What is a managed staking provider?** A managed staking provider operates validator nodes on behalf of institutional clients. The client deposits assets and retains economic exposure to staking rewards; the provider handles the technical operation: client software, key management, monitoring, slashing protection, and uptime. Providers differ in infrastructure model (cloud vs. dedicated hardware), jurisdictional footprint, and the set of proof-of-stake networks they support. **What is the difference between cloud-based and dedicated-hardware staking operators?** Cloud-based operators run validator nodes on AWS, Google Cloud, or Azure. Dedicated-hardware operators run validators on owned servers in contracted data centre facilities. Cloud infrastructure introduces shared-resource risk: the hypervisor schedules CPU time across tenants. Ethereum attestations are time-bounded; hardware jitter on a shared instance can cause late attestations. Dedicated hardware isolates the validator workload and eliminates hypervisor overhead. **Which staking providers support distributed validator technology?** Distributed validator technology (DVT) splits a validator key across multiple operators using threshold signing (typically 3-of-4). Operators who have deployed DVT in production include Obol and SSV Network at the protocol level, and infrastructure providers who have integrated those protocols. LinkPool operates SSV Network nodes in production and holds an active SSV partnership. **What is a Chainlink oracle node operator?** A Chainlink oracle node operator runs server infrastructure that fetches off-chain data (asset prices, proof-of-reserves, event outcomes) and delivers it on-chain via signed transactions. Top-tier Chainlink node operators are credentialed by Chainlink Labs based on data quality, uptime, response latency, and operational history. LinkPool has operated Chainlink oracle nodes since 2018. --- Source: https://linkpool.com/blog/why-in-house-institutional-staking-is-hard Published: 2026-05-15 Author: LinkPool Team # Why in-house institutional staking is harder than it looks The economics of Ethereum staking at institutional scale are clear. The operational complexity is less often discussed honestly. Teams that build in-house validator infrastructure discover that the hardest parts are not the ones that appear in setup guides. This is a description of where in-house institutional staking accumulates risk, and why it is structurally harder than it appears. ## The time-bound signing problem Most infrastructure runs on a request-response model. Something asks for something, the system responds. If the response is slow, you investigate and fix it. The work is recoverable. Ethereum attestations do not work that way. Each validator must sign an attestation message within a specific slot window. The window is roughly 4 seconds. Miss it, and the attestation is late. Miss it consistently, and the validator's effective balance decays. There is no retry. There is no catch-up. The slot passes and the opportunity is gone. This changes the operational contract. Slow is not acceptable the way it is for most infrastructure. A validator that is "99% available" in uptime terms will miss thousands of attestations over a year. The yield impact is direct and measurable at the chain level, not just in a monitoring dashboard. The implication: latency sources that would be tolerable elsewhere matter here. Hypervisor scheduling on a shared cloud instance. A disk read slowed by IO contention. A consensus client stuck syncing after a restart. A DVT cluster waiting on a slow operator's key share. Each of these has a cost that compounds across slots. ## The slashing trap Slashing is Ethereum's mechanism for penalising provably malicious or incorrect validator behaviour. The most common cause in production is not malice: it is double-signing: a validator signing two different messages for the same slot. This happens when a validator is restarted without consulting its slashing protection database, or when a validator key is active on two nodes simultaneously during a migration. A slashing event permanently reduces the validator's effective balance by at least 1/32nd and triggers an ejection queue. The penalty is irreversible. The validator must exit and cannot re-enter with the same key. This means every restart, every migration, every hardware replacement, and every client upgrade is a potential slashing event if the operator does not follow the correct procedure. Teams that automate restarts without building in slashing protection checks are not protected by the automation. They are exposed by it. The protection is straightforward: maintain a slashing protection database, import it before any signing starts, and never run the same key on two nodes simultaneously. The difficulty is that these procedures must be followed correctly under pressure, including during incidents at 3am, including by engineers who did not set up the original infrastructure. ## Client diversity as a permanent operational requirement Running minority clients is the correct approach for network health and correlated risk reduction. It is also permanently more expensive to operate than running a single dominant client pair. Each client implementation has its own configuration format, its own metrics schema, its own restart behaviour, its own upgrade notes, and its own edge cases. An engineer who knows Geth well does not automatically know Nethermind well. A monitoring setup calibrated for Lighthouse does not automatically catch the right signals from Teku. For a team running a homogeneous validator set on a single client pair, this is manageable. For a team running multiple client pairs across a large validator set in the interest of diversity, it multiplies the surface area for each upgrade, each incident, and each runbook. The Ethereum Foundation tracks the client distribution across the network. Institutions running a large validator set on a single dominant client are contributing to correlated risk at the network level. Whether that matters to a given institution depends on its mandate, but it is a known tension. ## Hard fork deadlines are not negotiable Ethereum forks activate at a specific block. Not a date range. Not "sometime in Q2." A specific block number, and validators running pre-fork client software produce non-canonical output after that block. The consequence of a missed upgrade is missed attestations starting at the fork block and continuing until the client is updated. For a large validator set, that is material yield loss. For a validator running the wrong fork for long enough, it can trigger ejection from the active set. Upgrade coordination at scale means: testing the new client version against a staging environment, staging the rollout across the validator set to catch issues before they affect every validator simultaneously, confirming correct attestation after the fork, and rolling back if the new version has a critical bug (which means having a tested rollback procedure, not just a theoretical one). For a team where validator operation is secondary to another product, recurring hard fork coordination is an interruption to their primary work. It happens whether or not it is convenient. It has happened on major holidays. It has happened during other incidents. ## DVT multiplies coordination requirements [Distributed validator technology](/blog/what-is-distributed-validator-technology) is increasingly expected for institutional Ethereum staking. A 3-of-4 DVT cluster distributes the validator key across four independent operators, requiring three to sign before an attestation is submitted. No single operator can cause a slashing event alone. No single operator going offline stops the cluster from attesting, as long as three remain active. The coordination requirement is the trade-off. Each cluster upgrade requires coordinating four independent nodes across potentially four independent operators. Each DKG ceremony to onboard a new validator requires scheduling across four parties. Each exit requires coordinating the exit message across the cluster. Each monitoring alert needs to distinguish between a cluster-level issue and an individual operator issue. DVT reduces key risk significantly. It does not reduce operational complexity. For teams running it in-house, it adds a distributed systems coordination layer on top of an already complex validator stack. ## The staffing gap The most structurally difficult aspect of in-house institutional staking is the staffing curve. Validator operation does not justify a full-time dedicated engineer until you are running at significant scale. Below that threshold, the work lands on engineers who have other responsibilities. That arrangement works most of the time. Validators run quietly. Attestation rates look fine. Nothing requires urgent attention. The risk accumulates in the gaps: the runbook that was never tested, the slashing database backup that was never verified, the disk growth that was never projected, the client upgrade that was never staged. When an incident hits, and incidents do hit, the engineer on call may not be the person who set up the infrastructure. They may be working from documentation that was not kept current. They may be making decisions about a slashing protection procedure at 3am with limited context. This is not a staffing failure. It is the structural reality of running a discipline that requires constant operational attention as a secondary function of a team with a different primary product. ## What this means for the build-vs-buy decision The argument for in-house is clear when the team already has the operational foundation: dedicated infrastructure, DevOps engineers with blockchain node experience, and the capacity to absorb validator operation as a genuine first-class workload. In that case, the economics are favourable and the operational cost is incremental. The argument against in-house is clearest when validators are a new workload for the team, when the team is small, or when the cost of a slashing event or a missed hard fork upgrade exceeds the cost of outsourcing the operational risk. A [managed provider](/blog/how-to-evaluate-managed-ethereum-staking-oracle-operators) absorbs the upgrade coordination, the on-call rotation, the DVT complexity, and the incident response. The question is whether the operational load is cheaper to build or buy at your current scale. 72 months on Ethereum mainnet with zero slashing events is not luck. It is the outcome of treating validator operation as a first-class discipline, not a background task. ## Common questions **Why is Ethereum validator operation harder than running other blockchain nodes?** Ethereum validators have three properties that distinguish them from read-only nodes. First, they sign messages on a time-bound schedule: miss the window and the attestation is late or lost. Second, signing the same slot twice causes slashing, which permanently reduces the validator's balance and cannot be undone. Third, the Ethereum protocol upgrades on hard deadlines with no grace period: a validator running a pre-fork client stops attesting correctly at the fork block. These three properties combine to make validator operation a discipline that requires constant attention, not just initial setup. **What is client diversity and why does it matter for institutional stakers?** Client diversity means running different implementations of the Ethereum execution and consensus layer clients across a validator set. If a single client has a bug that causes incorrect attestations or double-signing, validators running only that client are all affected simultaneously. Validators running a minority client are unaffected. The Ethereum Foundation tracks client distribution because a dominant client with a critical bug could affect network finalisation. Institutional stakers running a single client pair face correlated risk across their entire validator set. **How do Ethereum hard fork upgrades affect validator operations?** Ethereum hard forks activate at a specific block number with no negotiation. A validator running pre-fork client software will produce non-canonical blocks after the fork block, causing missed attestations and potential ejection from the active set if the downtime is prolonged. Upgrade coordination requires testing the new client version in advance, staging the upgrade across a validator set to catch issues, and confirming successful attestation after the fork. For teams running multiple clients across a large validator set, this coordination is a recurring operational event. **What goes wrong most often in in-house institutional validator operations?** The most common failure modes are: slashing database corruption or loss causing a double-sign on restart, failed client upgrades before a hard fork causing missed attestations, disk exhaustion from chain data growth stopping the execution client, and missed exit coordination leaving validators active after the institution has wound down its position. Most of these are preventable with proper runbooks and monitoring, but each requires deliberate engineering investment. They do not resolve themselves. ## Frequently asked questions **Why is Ethereum validator operation harder than running other blockchain nodes?** Ethereum validators have three properties that distinguish them from read-only nodes. First, they sign messages on a time-bound schedule: miss the window and the attestation is late or lost. Second, signing the same slot twice causes slashing, which permanently reduces the validator's balance and cannot be undone. Third, the Ethereum protocol upgrades on hard deadlines with no grace period: a validator running a pre-fork client stops attesting correctly at the fork block. These three properties combine to make validator operation a discipline that requires constant attention, not just initial setup. **What is client diversity and why does it matter for institutional stakers?** Client diversity means running different implementations of the Ethereum execution and consensus layer clients across a validator set. If a single client has a bug that causes incorrect attestations or double-signing, validators running only that client are all affected simultaneously. Validators running a minority client are unaffected. The Ethereum Foundation tracks client distribution because a dominant client with a critical bug could affect network finalisation. Institutional stakers running a single client pair face correlated risk across their entire validator set. **How do Ethereum hard fork upgrades affect validator operations?** Ethereum hard forks activate at a specific block number with no negotiation. A validator running pre-fork client software will produce non-canonical blocks after the fork block, causing missed attestations and potential ejection from the active set if the downtime is prolonged. Upgrade coordination requires testing the new client version in advance, staging the upgrade across a validator set to catch issues, and confirming successful attestation after the fork. For teams running multiple clients across a large validator set, this coordination is a recurring operational event. **What goes wrong most often in in-house institutional validator operations?** The most common failure modes are: slashing database corruption or loss causing a double-sign on restart, failed client upgrades before a hard fork causing missed attestations, disk exhaustion from chain data growth stopping the execution client, and missed exit coordination leaving validators active after the institution has wound down its position. Most of these are preventable with proper runbooks and monitoring, but each requires deliberate engineering investment. They do not resolve themselves. --- Source: https://linkpool.com/blog/rpc-endpoint-hosting-cost-aws-vs-dedicated Published: 2026-05-13 Updated: 2026-09-07 Author: LinkPool Team # RPC endpoint hosting cost: AWS vs dedicated infrastructure (2026) A single RPC endpoint workload (16 vCPU, 64 GB RAM, 4 TB NVMe net of replication) costs $1,112 per month on AWS before a single byte of egress is billed. The same workload fits on a $219 whole server. That gap is wider than the equivalent gap for an Ethereum validator or a Chainlink node, and the reason is network egress. RPC endpoints are the only crypto infrastructure workload where bandwidth is a meaningful monthly cost driver, and bandwidth is the line hyperscalers price most aggressively. This page runs the actual numbers for one RPC endpoint workload across the providers an operator actually compares, then explains why the gap looks the way it does. ## The workload A production RPC endpoint at modest institutional scale needs: - 16 vCPU steady-state under JSON-RPC load - 64 GB RAM at the archive-feature ceiling for Ethereum execution plus consensus client memory plus JSON-RPC connection pool overhead - 4 TB NVMe net of replication for state, recent trie depth, recent block storage - continuous high-bandwidth ingress and egress for JSON-RPC traffic - 99.99% uptime target Most RPC cost comparisons treat the workload as "big servers." The cost shape is actually unusual. CPU sits high under sustained load instead of spiking. Memory hits a ceiling that does not move. Storage grows aggressively with archive features and recent trie depth. Egress dominates the bill on public RPC endpoints in a way it does not for any other crypto workload. ## Side-by-side pricing All monthly figures in USD, as published by each provider at the time of writing. | Provider | Monthly cost | Pricing model | |---|---|---| | AWS EC2 | $1,112 | Per-resource, egress on top | | Servers.com SBM | $1,219 | Whole server, smallest SBM that fits | | Latitude.sh | $720 | Whole server | | Hetzner AX162 | $219 | Whole server, fits one workload | Two numbers stand out. AWS is more than 5x the cheapest whole server before egress is added, and egress is where the AWS bill really grows. Hetzner is the only low-cost option in the table and it sells one server, not one workload. The economics under each model are not the same conversation. LinkPool is not in the table. Our [managed RPC endpoints](/rpc) are quoted as one fixed monthly cost per endpoint, sized to the chains, traffic profile and archive requirement, with bandwidth bundled. There is no public rate card to put in a row, and pricing for LP MKS, our self-service bare-metal Kubernetes platform, will be published when it launches. ## Why the gap is wider for RPC than for validators Egress is the single biggest difference. AWS data transfer out runs $0.09 per GB after the first GB. A moderately-loaded public RPC endpoint serves multiple terabytes of egress per month under sustained JSON-RPC traffic. That alone is several hundred dollars per month before any compute, memory, or storage cost. State bloat is the second. The 4 TB net figure today is projected to climb to 5-6 TB by the end of 2026 for archive-feature endpoints. NVMe at scale is priced differently on a hyperscaler than on a colocation host. Read-replica scaling is the third. Hyperscalers price read replicas aggressively. Dedicated infrastructure runs replicas on the same fabric without per-replica licensing or egress between zones. ## When each option is the right call AWS suits short-lived test and development RPC setups, integration environments, and any case where the workload runs less than full-time. The hourly billing model and the surrounding service catalogue carry real value when usage is bursty. Hetzner is the right call for operators running one or two RPC endpoints per server, accepting the platform risk that comes with consumer-grade infrastructure for production crypto work. In November 2022 Hetzner enforced its terms-of-service against 1,000+ Solana validators in a single policy change. That risk has not gone away. Managed infrastructure on burstable QoS fits production RPC work where steady-state cost matters and traffic is predictable. RPC workloads handle burstable well because their CPU sits high under load rather than spiking. Guaranteed QoS fits RPC work where any throttling under contention or any read-replica scaling pressure is unacceptable. Institutional ETH endpoint operators, large dApp backends, and any workload sensitive to JSON-RPC tail latency belong on a guaranteed tier. ## What else changes the bill Three line items that do not appear in a sticker-price comparison but matter at the bill level. Hypervisor overhead adds 0.3-1.2ms per network hop on shared-tenant hosts. For JSON-RPC traffic that is a measurable tail-latency tax. DIY dedicated-infrastructure operations overhead runs £4,000-£13,000 per month in engineering time on a self-managed build. That figure does not appear in a per-server quote. It does appear in the headcount budget. Manchester. Our infrastructure runs across three availability zones in Manchester. That is the location reference operators audit when an institutional buyer asks where the workload runs. ## Common questions **How much does it cost to host an RPC endpoint on AWS?** One RPC endpoint workload (16 vCPU, 64 GB RAM, 4 TB NVMe) costs approximately $1,112 per month on AWS. Egress is charged on top at $0.09 per GB, a significant additional cost for public endpoints with sustained JSON-RPC traffic. **Why are RPC costs higher than validator costs on cloud?** Egress. RPC endpoints serve JSON-RPC traffic continuously. A moderately-loaded public endpoint generates multiple terabytes of outbound data per month. Bandwidth is what hyperscalers price most aggressively, and it is the one crypto workload where that matters. **What is the cheapest RPC endpoint hosting option?** Per server, Hetzner's AX162 at $219 per month is the cheapest option, but it sells a whole server rather than a workload and does not bundle egress. Managed infrastructure with a fixed monthly cost and bundled bandwidth removes the egress line entirely, which is the line that dominates the AWS bill for a public endpoint. **Burstable vs guaranteed QoS for RPC: which should I use?** Burstable suits most RPC workloads. CPU sits high under sustained load rather than spiking, which burstable handles well. Guaranteed QoS is the right call when JSON-RPC tail latency matters or when read-replica scaling pressure is unacceptable. ## Related reading - [ETH validator hosting cost: AWS vs dedicated infrastructure in 2026](/blog/eth-validator-hosting-cost-aws-vs-dedicated), page 1 of this comparison series - [Archive node hosting cost: cloud vs dedicated infrastructure](/blog/archive-node-hosting-cost-cloud-vs-dedicated), the storage side of the same comparison - [Bare-metal Kubernetes hosting: cloud vs dedicated infrastructure](/blog/bare-metal-kubernetes-hosting), the architecture context - [What goes into running a Chainlink Data Streams node](/blog/chainlink-data-streams-node-operations), shared workload-shape framing ## Frequently asked questions **How much does it cost to host an RPC endpoint on AWS?** One RPC endpoint workload (16 vCPU, 64 GB RAM, 4 TB NVMe) costs approximately $1,112 per month on AWS. Egress is charged on top at $0.09 per GB, a significant additional cost for public RPC endpoints with sustained JSON-RPC traffic. **Why are RPC endpoint costs higher than validator costs on cloud?** Egress. RPC endpoints serve JSON-RPC traffic continuously. A moderately-loaded public endpoint generates multiple terabytes of outbound data per month. AWS charges $0.09 per GB after the first GB free tier. That alone adds several hundred dollars per month before any compute or storage cost. **What is the cheapest RPC endpoint hosting option?** Per server, Hetzner's AX162 at $219 per month is the cheapest option, but it sells a whole server rather than a workload and does not bundle egress. Managed infrastructure with a fixed monthly cost and bundled bandwidth removes the egress line entirely, which is the line that dominates the AWS bill for a public endpoint. **What is the difference between burstable and guaranteed QoS for RPC hosting?** Burstable QoS handles most RPC workloads well. CPU sits high under sustained load rather than spiking, which burstable handles. Guaranteed QoS is worth the premium for archive-feature endpoints or any workload where JSON-RPC tail latency matters, because it eliminates throttling under contention. --- Source: https://linkpool.com/blog/tradfi-institutions-running-validators Published: 2026-05-05 Author: LinkPool Team # Why Visa running a validator is the more interesting validator story Two validator stories landed in the same fortnight in April 2026. The one that got most of the coverage was Lombard naming four institutional staking firms as Bitcoin finality providers. The one that mattered more, structurally, was Visa becoming an anchor validator on Stripe's Tempo blockchain alongside Zodia Custody. The shift it signals is from institutions buying staking to institutions running infrastructure. ## Two shapes of institutional validator participation There are two operational shapes in play. The first is delegated. A fund or a custodian buys a staking yield product. An operator runs the validator. The institution holds a receipt and a counterparty exposure. This is the shape most institutional staking conversations have assumed since 2023. The second is operational. The institution runs the validator itself. It holds its own keys, or holds a share of keys via threshold signing. It signs attestations, faces slashing risk directly, and participates in consensus as a first-party operator. Visa on Tempo is shape two. So is Zodia. Both are legitimate. They answer different questions about what institutional involvement in proof-of-stake actually means. ## Why a TradFi institution might pick shape two The economics are similar. The structural reasons are different. Key custody is the core argument. Operating a validator means the institution controls how the validator's keys are generated, stored, and used. That is a different legal and operational posture than holding a third party's yield product. "We sign these attestations on hardware we own" tells one audit story. "We delegated to a counterparty on cloud we cannot inspect" tells another. The regulatory angle reinforces it. Operating an authorised infrastructure component is a different shape from holding a third-party yield product on a balance sheet. CASP-counterparty obligations under [MiCA](/blog/mica-staking-compliance-infrastructure) read more cleanly when the regulated entity owns the infrastructure that produces the regulated outputs. The same applies to operational resilience expectations under DORA. Counterparty risk is the operational case. Delegated staking concentrates operational risk in a single staking provider. Their downtime is your downtime. Their slashing event is your slashing event. Operating directly removes that single point of failure. The cost is building the operational capability in-house. A TradFi firm with a payments rail on the line weighs those reasons differently than a fund optimising for yield. ## What shape two requires operationally Press releases announcing anchor validators do not cover this part. Running a validator at the scale a regulated institution requires has a specific shape. Owned hardware footprint, with documented jurisdiction for the legal entity that holds the hardware. Cloud-bound infrastructure inherits the cloud provider's jurisdiction and the cloud provider's terms of service. Key management architecture that survives audit. HSM at minimum. Threshold signing where the chain supports it. No single operator inside the institution should be able to produce a malicious attestation alone. Multi-zone redundancy that means independent infrastructure paths, not multi-region cloud sitting on the same control plane. The whole point of redundancy is fault independence. Incident response telemetry with retention. Audit trails that survive an incident. On-call ops capability that does not depend on any one engineer. Operational resilience drills with documented results. Continuity plans that have been tested. The ask is structurally similar to what an authorised CASP needs to document under [MiCA](/blog/mica-staking-compliance-infrastructure). That is not a coincidence. This is the part of the work that does not show up in a partnership announcement. ## The hardware question A TradFi institution running a validator has options for the underlying compute. Public cloud. Colocation with rented servers. Owned hardware in a regulated jurisdiction. Public cloud is fastest to spin up. Control over key custody is the lowest. The cloud provider's hypervisor sits between the institution and the signing process. Jurisdiction follows the cloud provider's region, which can change. Colocation with rented servers gives more control. The institution still operates inside a third-party provider's framework. That framework can include shared switching, shared power, and shared procurement timelines. Owned hardware in a regulated jurisdiction with documented multi-zone redundancy gives the highest control and the longest setup. Counterparty surface is smallest. The audit story is cleanest. Shape-two institutions tend toward the owned-hardware option. The regulatory advantage of running your own validator is partly defeated by stacking it on a single hyperscaler. If the differentiation is "we operate our own infrastructure," the underlying compute matters. ## What to watch next Two patterns are worth tracking over the next eighteen months. Anchor validators where the institution operates rather than delegates. Tempo is unlikely to be the only chain that picks up TradFi anchor validators. The same shape will appear on permissioned and semi-permissioned networks. It will also appear on appchains where TradFi firms hold a payments or settlement role. Disclosure expectations will sharpen. "Anchor validator on Chain X" reads one way when the validator runs on a hyperscaler. It reads another way when it runs on dedicated hardware in a specified jurisdiction. Public reporting on infrastructure choices will become a disclosure question. That matters most where regulated entities are involved. The validator-customer category is splitting in two. The yield buyers will keep buying yield. The infrastructure operators will keep building infrastructure. The interesting growth comes from institutions moving from one column to the other. If your institution were to operate a validator directly, where would the underlying compute sit? And what would you want to be able to say publicly about that choice? ## Common questions **What is the difference between delegated staking and running a validator directly?** Delegated staking means buying a yield product from an operator: the institution holds a receipt and counterparty exposure. Running a validator directly means the institution controls its own keys, signs attestations itself, and faces slashing risk as a first-party operator. The second shape gives cleaner regulatory documentation and removes single-operator counterparty risk. **Why are TradFi institutions running their own validators?** Three reasons: key custody control (operating means the institution signs on hardware it owns), regulatory clarity (MiCA and DORA operational resilience requirements are cleaner when the regulated entity runs its own infrastructure), and counterparty risk elimination (delegated staking means inheriting your provider's downtime and slashing events). **What infrastructure do institutional validators need?** Owned hardware with documented jurisdiction, HSM or threshold signing key management that survives audit, multi-zone redundancy with independent infrastructure paths (not multi-region cloud on the same control plane), incident response telemetry with retention, and tested continuity plans. This is materially more demanding than running a personal validator. **Is public cloud appropriate for an institutional validator?** It depends on requirements. Cloud is fastest to deploy but gives lowest control: the hypervisor sits between the institution and the signing process, jurisdiction follows the cloud provider's region, and physical inspection is not available. For regulated entities where the differentiation is direct infrastructure operation, cloud partially defeats that argument. --- About LinkPool. We run staking and oracle infrastructure for Web3 protocols and institutional operators on owned hardware across three availability zones in Manchester. ISO 27001 and SOC 2 completing July 2026. AAA Staking Rewards rating across Operations, On-Chain, Security, and Maintenance. Zero slashing across our operating history. Contact: institutional@linkpool.io. ## Frequently asked questions **What is the difference between delegated staking and running a validator directly?** Delegated staking means buying a yield product from an operator: the institution holds a receipt and counterparty exposure. Running a validator directly means the institution controls its own keys, signs attestations itself, and faces slashing risk as a first-party operator. The second shape gives cleaner regulatory documentation and removes single-operator counterparty risk. **Why are TradFi institutions running their own validators?** Three reasons: key custody control (operating means the institution signs on hardware it owns), regulatory clarity (MiCA and DORA operational resilience requirements are cleaner when the regulated entity runs its own infrastructure), and counterparty risk elimination (delegated staking means inheriting your provider's downtime and slashing events). **What infrastructure do institutional validators need?** Owned hardware with documented jurisdiction, HSM or threshold signing key management that survives audit, multi-zone redundancy with independent infrastructure paths (not multi-region cloud on the same control plane), incident response telemetry with retention, and tested continuity plans. This is materially more demanding than running a personal validator. **Is public cloud appropriate for an institutional validator?** It depends on requirements. Cloud is fastest to deploy but gives lowest control: the hypervisor sits between the institution and the signing process, jurisdiction follows the cloud provider's region, and physical inspection is not available. For regulated entities where the differentiation is direct infrastructure operation, cloud partially defeats that argument. --- Source: https://linkpool.com/blog/chainlink-data-streams-node-operations Published: 2026-04-23 Updated: 2026-09-07 Author: LinkPool Team # What goes into running a Chainlink Data Streams node On April 12, Chainlink Data Streams started carrying near-real-time pricing for U.S. stocks and ETFs on a 24/5 basis. That moves the service past crypto-only pricing into tokenized traditional finance. The infrastructure behind that service is not abstract. Someone runs it. This post is about what that work actually involves. ## What Data Streams is, operationally Most oracle descriptions stop at "delivers prices on-chain". That is the product view. The operations view is different. Data Streams is a pull-based oracle. Reports are generated continuously in a permissioned Data DON (decentralized oracle network). Subscribers fetch them on demand when they need them for a transaction. Each report is signed by the operators in the DON and carries cryptographic proofs that consuming contracts verify before acting. Two implications follow from that design. First, report generation happens whether or not anyone pulls a report. Operators carry the full cost of running the DON around the clock. Second, pull-based retrieval removes the latency tax of waiting for the next scheduled on-chain update. Latency-sensitive use cases (perpetuals, derivatives, tokenized equities) adopted it quickly. ## What the node runs A Data Streams node is a Chainlink node with additional binaries and a different workload profile. The core pieces: - **OCR (off-chain reporting)** as the consensus mechanism between operators. A round gathers observations, aggregates them, and produces a signed report. OCR is designed to complete rounds in sub-second time when operators are well-connected and under light coordination overhead. - **Data Streams-specific components** on top of the standard Chainlink node. Handles report formatting, Mercury transport, and signature generation. - **Connections to data providers.** OCR nodes consume price data from multiple upstream feed providers to form their observations. The LinkPool OCR deployments consume feeds from dxFeed, Framework, Tiingo, XBTO, Bitscrunch, Therundown, and Enet. These are data sources the nodes pull from to produce signed observations. They are not commercial clients of LinkPool. The distinction matters because conflating the two misrepresents both parties. - **Tight clock synchronisation** across the DON. OCR rounds depend on operators agreeing on time within a small tolerance. Drift breaks rounds. ## What the infrastructure has to do The requirements are unforgiving in three places, and each one translates directly to hardware and network design. **Network latency to relayers and peers.** OCR round time is bounded by the slowest operator's round-trip to its peers. An operator on shared public cloud infrastructure carries hypervisor overhead of roughly 0.3 to 1.2 milliseconds per hop. On top of that, the host's noisy neighbours add their own jitter. That does not sound like much until it compounds across a coordination loop that runs many times per second. **Storage throughput.** Each operator retains a local history of signed reports, observation data, and OCR state. On busy feeds the write load is continuous. The read pattern is latency-sensitive when the node is catching up after a restart or handling an integrity check. Gen5 NVMe with a dedicated I/O path handles it without drama. Shared block storage usually does not. **Uptime.** A node that misses OCR rounds loses rewards. More importantly, it degrades the DON's quality score and makes the feed less reliable for everyone consuming it. The target at LinkPool is 99.99%, anchored in three-zone failover across three availability zones in Manchester. etcd quorum survives a single zone going dark. Cilium BGP reconverges in under ten seconds after a spine failure, based on the hold timer configuration. MLAG at every leaf pair means a switch reload is a non-event for the pods running above it. These three requirements are why Data Streams is not a cloud-native workload in the usual sense. Burstable CPU, shared network interfaces, and overcommitted memory all trade tail latency for price. Oracle operations pay for tail latency in missed rounds. The trade does not work. ## The same coordination argument as DVT Running Chainlink OCR feels structurally similar to running distributed validator technology clusters. Both are threshold-signing systems where a fixed set of operators has to agree on a signed message within a deadline. Both fail degraded rather than cleanly when one operator is slow. Both punish hypervisor overhead and reward consistent network latency. The operational principle is the same in both cases: the weakest operator sets the ceiling. In a four-operator DVT cluster, imagine three operators on owned infrastructure and one on burstable cloud. The cluster's attestation timing tracks the cloud operator. OCR rounds work the same way. There is no reward for being the fastest operator. There is a cost for being the slowest. For a deeper look at the same pattern in the staking context, see [what is distributed validator technology?](/blog/what-is-distributed-validator-technology). ## What LinkPool runs Categorically: Chainlink OCR nodes, CCIP lanes, Data Streams (Mercury), Automation, and Keepers. LinkPool has run Chainlink nodes on mainnet since the network launched in May 2019, and all of it now runs on owned infrastructure across three availability zones in Manchester. All on the same dedicated Kubernetes platform that runs our validator work, our RPC endpoints, and our DVT clusters. We do not publish the exact namespace counts or chain counts. The surface covers the major EVM and non-EVM networks, and has done so for years. For the architecture pattern behind the platform, see [bare-metal Kubernetes hosting: cloud vs dedicated infrastructure](/blog/bare-metal-kubernetes-hosting). ## Why the TradFi expansion matters operationally The April 12 expansion into U.S. stocks and ETFs on a 24/5 basis changes the duty cycle. Crypto markets never close, but crypto-only pricing is forgiving about brief degradation during low-volume windows. Equity pricing is not. During a U.S. cash session, any oracle downtime directly affects tokenized equity settlement and ETF share pricing. It also affects the automated strategies that trade on those prices. That raises the stakes on uptime without changing the math on infrastructure. The same dedicated hardware, three-zone failover, and target SLA that carry crypto feeds will carry equity feeds. They just carry more financial consequence per minute. This is critical financial infrastructure, not a side-car to validator ops. ## Common questions **What are the hardware requirements for a Chainlink Data Streams node?** Dedicated infrastructure with guaranteed QoS. The workload requires consistent CPU access without throttling and low-latency network paths. Shared cloud with burstable CPU introduces jitter that violates the sub-second latency requirement. **Can Data Streams and price feed nodes share a cluster?** No. Price feeds tolerate a 15-second heartbeat gap. Data Streams runs sub-second with no jitter budget. Sharing a cluster means competing for CPU and network with a workload that has fundamentally different latency tolerances. **What is the difference between Chainlink price feeds and Data Streams?** Price feeds deliver on-chain aggregated data on a heartbeat or deviation threshold. Data Streams delivers verifiable low-latency market data off-chain for protocols that need sub-second price updates: perpetuals, options, order books. Different SLA, different operational posture. ## Question for operators What does your oracle node operations look like today? Dedicated hardware with a defined failover zone, or shared capacity with cloud-bounded SLA ceilings? ## Frequently asked questions **What are the hardware requirements for a Chainlink Data Streams node?** Chainlink Data Streams nodes require dedicated infrastructure with guaranteed QoS. The workload needs low-latency network paths, consistent CPU access without throttling, and NVMe storage with no I/O contention. Shared cloud with burstable CPU or shared network introduces jitter that violates the sub-second latency requirement. **Can Chainlink Data Streams and price feed nodes share the same cluster?** No. Price feeds tolerate a 15-second heartbeat gap. Data Streams runs sub-second with no jitter budget. Sharing a cluster means the Data Streams workload competes for CPU and network with a workload that has fundamentally different latency tolerances. The operational posture is different enough that they should not share infrastructure. **What is the difference between Chainlink price feeds and Data Streams?** Price feeds are on-chain aggregated data updated on a heartbeat or deviation threshold, and they tolerate a 15-second gap. Data Streams delivers verifiable low-latency market data off-chain for DeFi protocols that need sub-second price updates (perpetuals, options, order books). Different SLA, different operational posture, different infrastructure requirements. --- Source: https://linkpool.com/blog/eth-validator-hosting-cost-aws-vs-dedicated Published: 2026-04-23 Updated: 2026-09-07 Author: LinkPool Team # ETH validator hosting cost: AWS vs dedicated infrastructure (2026) A single ETH validator workload costs $556 per month on AWS. The same workload fits on a $219 whole server, and costs less again when you pay only for the slice of a machine it actually uses. Same memory footprint, same storage growth, same 99.99% uptime target, same operational outcome at the chain. Most cost comparisons stop at that headline. The real question is why each price lands where it does. And when each option is actually the right call for an operator. ## The workload we are pricing One ETH validator steady-state. 8 vCPU of sustained consumption. 32 GB of RAM, fixed by the execution and consensus client memory footprint. 2 TB of network-attached NVMe covering roughly a year of chain growth. Continuous network traffic at a low kbps sustained rate. A 99.99% uptime target because missed attestations and proposals cost money directly. This shape is steady, not bursty. It is memory-bound, not CPU-bound. It is sensitive to latency jitter, not to peak throughput. That matters because the pricing model of each provider is tuned for a different workload shape. ## Side-by-side comparison | Provider | Monthly cost (12-month) | Pricing model | |---|---|---| | AWS | $556 | Reserved EC2, charged per instance size | | Servers.com | $453 | Smallest single-tenant server that fits the spec | | Latitude.sh | $431 | Whole dedicated server | | Hetzner AX162 | $219 | Whole server, flat rate regardless of workload | Prices are 12-month commitments in USD, for the same 8 vCPU, 32 GB RAM, 2 TB network NVMe workload, as published by each provider at the time of writing. LinkPool is deliberately absent from the table. We quote managed validator infrastructure per workload rather than from a public rate card, and pricing for LP MKS, our self-service bare-metal Kubernetes platform, will be published when it launches. The rest of this article explains the pricing model it uses, because that is what moves the number. ## Why each price lands where it does AWS is optimised for bursty, general-purpose workloads. A validator runs at roughly 20-40% CPU steady-state and never bursts. The reserved instance price still reflects the compute-optimised SKU pricing that the platform is built around. You pay for flexibility that this workload will not use. Hetzner and Latitude charge per server. The AX162 at $219 is the floor. You get the whole box regardless of whether the validator consumes 10% of it or 90%. Cheap if you have a single workload that happens to match the hardware. Expensive per watt of validator work if your workload is smaller, and capacity-constrained if it is larger. Servers.com sells the smallest single-tenant server that fits, which for this spec lands at $453. Same whole-server logic, slightly different floor. Component pricing charges for the resources the workload actually consumes: the 8 vCPU, the 32 GB, the 2 TB, and nothing else. The validator pays for its footprint, not for a whole server or for a general-purpose cloud SKU. For a single validator that is a fraction of a 224-vCPU host, so the number lands well under the whole-server floor. A guaranteed-QoS tier is the same workload with CPU requests equal to limits, so the pod never yields to a burstable neighbour. For validators that cannot tolerate throttling during attestation windows, that is the tier to pick, and it costs more than the burstable equivalent because the capacity is reserved whether or not it is used. ## The hidden line: operational overhead The monthly price is not the full cost. Running your own dedicated infrastructure carries operational overhead. DIY validator operators typically measure it at $4,700 to $16,000 per month in engineering time. Server procurement, rack and stack, and network configuration are part of it. So are OS hardening, client upgrades, incident response, and on-call rotation. Hetzner and Latitude hand you a server. Everything above the hypervisor is your team. AWS bundles a managed control plane but not managed validator operations. Managed Kubernetes with support included removes that overhead without charging for a full server you will not use. Run the math at your own burdened engineering rate before comparing raw hardware prices. The $219 number on Hetzner often sits underneath $5,000+ in monthly ops cost for a single-validator shop. ## Platform risk is part of the price In November 2022, Hetzner banned over 1,000 Solana validators from its infrastructure. The workloads were shut down inside the provider's terms of service, not on the chain. Operators moved or lost consensus participation. The Solana Foundation responded publicly. This is a real line item. Rented infrastructure sits under someone else's acceptable use policy. If the policy changes, the workload moves. Owned infrastructure and contracts with Web3-native providers carry a different risk profile on that axis. ## SLA ceiling An AWS customer cannot offer a higher uptime guarantee than AWS offers them. A validator operator running on AWS is bounded by the cloud SLA they sit beneath. Same for GCP, Azure, or any hyperscaler. Owned infrastructure sets its own SLA ceiling. LinkPool's 99.99% target comes from three availability zones in Manchester with failover across them. It does not come from a pass-through cloud contract. ## When each option is right **AWS** fits short-lived test workloads and testnet validators. Also teams that already run on AWS and want to consolidate billing. **Hetzner AX162** fits operators running exactly one validator per server, with no managed Kubernetes requirement. They need enough in-house ops to absorb platform risk. **Latitude and Servers.com** fit teams that want dedicated hardware with a polished provisioning layer and are comfortable paying per server. **Component-priced managed infrastructure** fits continuous validator workloads where managed Kubernetes, paying for the footprint rather than the server, and Web3-native support are the priority. Pick the guaranteed-QoS tier where any throttling during attestation or proposal windows is unacceptable. For the architecture pattern behind the pricing, see [bare-metal Kubernetes hosting: cloud vs dedicated infrastructure](/blog/bare-metal-kubernetes-hosting) and [we built bare-metal Kubernetes for Web3 before the enterprise vendors caught up](/blog/bare-metal-kubernetes-web3-before-enterprise). ## Common questions **How much does it cost to host an ETH validator on AWS?** One ETH validator workload (8 vCPU, 32 GB RAM, 2 TB NVMe) costs approximately $556 per month on AWS using Reserved EC2 pricing. Data transfer costs are on top of that figure. **What is the cheapest way to host an Ethereum validator?** Per server, Hetzner's AX162 at $219 per month is the cheapest production-grade option, but you pay for the whole machine whether the validator uses 10% of it or 90%. Component-priced managed infrastructure charges for the 8 vCPU, 32 GB and 2 TB the validator actually consumes, which is why it undercuts whole-server pricing for a single validator. **Why is dedicated infrastructure cheaper than cloud for validators?** ETH validators have a stable, predictable workload: steady CPU consumption, fixed memory footprint, low network traffic. Cloud providers price for bursty workloads. Component pricing charges for the exact resources the validator uses, with no idle headroom baked in. **Is Hetzner a good option for ETH validator hosting?** Cost-competitive at $219 per month (AX162), but you pay for the whole server. In November 2022, Hetzner enforced its terms of service against 1,000+ Solana validators in a single policy change. That platform risk remains. ## Run the number for your own workload Pull your current invoice. Multiply your validator count by the number above that matches your provider. Then [tell us the workload](/validators#contact) and we will quote the same spec on managed infrastructure. The delta is either noise or your Q3 budget. Which one is it? ## Frequently asked questions **How much does it cost to host an ETH validator on AWS?** One ETH validator workload (8 vCPU, 32 GB RAM, 2 TB NVMe) costs approximately $556 per month on AWS using Reserved EC2 pricing. This includes compute and storage but does not include data transfer costs. **What is the cheapest way to host an Ethereum validator?** Per server, Hetzner's AX162 at $219 per month is the cheapest production-grade option, but you pay for the whole machine whether the validator uses 10% of it or 90%. Component-priced managed infrastructure charges for the 8 vCPU, 32 GB and 2 TB the validator actually consumes, which is why it undercuts whole-server pricing for a single validator. **Why is ETH validator hosting cheaper on dedicated infrastructure than cloud?** ETH validators have a stable, predictable workload: steady CPU load, fixed memory footprint, and low network traffic. Cloud providers price for bursty workloads and charge for headroom you don't use. Dedicated component pricing charges for the exact resources the validator consumes. **Is Hetzner a good option for ETH validator hosting?** Hetzner is cost-competitive at $219 per month (AX162 server), but you pay for the whole server regardless of utilisation. In November 2022, Hetzner enforced its terms of service against 1,000+ Solana validators in a single policy change. That platform risk has not been removed. --- Source: https://linkpool.com/blog/lido-identified-dvt-cluster-operators Published: 2026-04-23 Author: LinkPool Team # What Lido's Identified DVT Cluster vote means for independent operators Lido's Snapshot vote on the Identified DVT Cluster operator type closed on April 13, 2026. The result clears the way for a new operator class inside Lido's Community Staking Module. CSM v3 is targeted for Q2 or Q3 2026. The mechanics are straightforward. Each Identified DVT Cluster (IDVTC) is four independent community stakers running a single validator through [distributed validator technology](/blog/what-is-distributed-validator-technology). Obol and SSV Network are the two protocols named in the proposal. Distributed key generation splits the validator key across the four operators at genesis. No single party ever holds the full key. Signing requires three of the four operators to agree on every message. Read as a governance outcome, that is an incremental change to Lido's operator set. Read as an infrastructure statement, it is something different. Lido has explicitly framed the new type around "decentralization and network resilience" rather than raw TVL. That language rewards operators who run the hardware. It does not reward operators who build products on top of someone else's infrastructure. ## What an IDVTC actually requires operationally Start with the day-to-day reality. A standard single-operator validator has one key, one signing process, and one operator on the hook for everything. An IDVTC has four of each, running in parallel, coordinating every slot. Distributed key generation means the four operators never meet the full key. Each operator holds a keyshare. Reconstructing the key requires three of the four shares combined off-chain, which never happens in production. Attestations and block proposals are signed by combining three partial signatures into one valid BLS signature. The three operators have to agree on the message, produce their shares, and combine them before the attestation window closes. That coordination step is the whole story. It is also the reason this is an infrastructure question dressed as a governance question. ## Why dedicated hardware sets the ceiling Ethereum attestations are time-bounded. Miss the window and the attestation is late or missed entirely. In a single-operator setup, the only latencies that matter are the client's and the network's. In a four-operator DVT cluster, the round completes at the speed of the slowest operator. Picture a four-operator cluster. Three operators run on owned infrastructure with predictable CPU. The fourth runs on a burstable public cloud instance. Hypervisor overhead on that fourth node adds 0.3 to 1.2 milliseconds per hop. The fourth operator sets the pace for the cluster. Over a single slot, that overhead is survivable. Over ten thousand slots with coordination, retries, and cloud maintenance windows, the degradation compounds. Effective performance drifts toward the weakest operator. This is not a theoretical argument. It is the same coordination physics that punishes any distributed consensus workload running on shared infrastructure. If you have seen it in oracle networks or sequencer fleets, you will see it here. Operators running on dedicated, owned infrastructure do not guarantee any cluster will perform. They guarantee that their contribution to the cluster will not be the bottleneck. In a 3-of-4 system, being consistently not-the-bottleneck is how clusters stay healthy. ## What CSM v3 means for capacity planning now CSM v3 is targeted for Q2 or Q3 2026, which is close. Operators who intend to apply as IDVTC members should be thinking about three things this quarter. First, DVT protocol choice. Obol and SSV Network solve the same problem with different trust assumptions, ceremony models, and client integrations. The Obol vs SSV decision is made at the cluster level, not the operator level. Operators who have already run one protocol in production have a real advantage on readiness. Our SSV DVT work in production since the network opened has given us a view of the operational load. It is not trivial. Second, key management. DKG ceremonies, keyshare rotation, and exit coordination are new operational disciplines. Any operator relying on a vendor's managed key service inherits that vendor's uptime and their jurisdictional exposure. Third, capacity. IDVTC clusters are not a drop-in replacement for existing single-operator validators. They are a new product line. They want their own capacity allocation, their own monitoring, and their own runbooks. ## The structural shift hiding in a governance vote Step back from the mechanics. Lido has a long-running tension between two operator archetypes. One builds yield products, wraps third-party infrastructure, and competes on TVL. The other runs the hardware. Over the last eighteen months, Lido's governance has been tilting steadily toward the second group. The Identified DVT Cluster vote is the clearest expression of that tilt so far. Four independent operators per cluster, all running DVT, all coordinating signatures in real time. The design selects against thin-margin yield aggregators. Running a keyshare properly is not something you can abstract away at the protocol layer. You either run the hardware or you do not. We have zero slashing across roughly seventy-two months of mainnet operations. We have an existing SSV partnership. We have capacity on [owned bare-metal Kubernetes infrastructure](/blog/bare-metal-kubernetes-web3-before-enterprise) across three availability zones in Manchester. For operators with that profile, this is the governance signal we have been watching for. For operators whose business depends on reselling someone else's compute, the next twelve months will get harder. If you are planning to run an IDVTC, five documents need to exist by Q2. Your DKG ceremony plan. Your keyshare storage and rotation policy. Your exit coordination runbook. Your slashing-incident response plan. Your attestation latency budget broken out by network hop. What belongs in that latency budget that most operators have not yet measured, and how would you verify it? ## Common questions **What is a Lido Identified DVT Cluster?** A Lido Identified DVT Cluster (IDVTC) is a validator operated by four independent community stakers using distributed validator technology. Each operator holds a key share generated at a DKG ceremony. Signing requires three of the four operators to agree on every attestation. No single party ever holds or reconstructs the full validator key. **When is Lido CSM v3 launching?** Lido Community Staking Module v3 is targeted for Q2 or Q3 2026. The Snapshot vote on the Identified DVT Cluster operator type closed April 13, 2026, clearing the way for the new operator class inside the Community Staking Module. **What does an IDVTC operator need to run?** Each of the four operators needs dedicated infrastructure for their DVT node (Obol or SSV), participation in a distributed key generation ceremony, keyshare storage and rotation policy, exit coordination runbook, and slashing-incident response plan. Each operator's latency contribution directly affects cluster attestation timing. **Why does dedicated hardware matter for DVT cluster operators?** In a 3-of-4 threshold signing cluster, attestation timing is set by the slowest operator. A burstable cloud instance adds 0.3–1.2ms of hypervisor overhead per hop. Over thousands of slots with coordination retries and cloud maintenance windows, that degradation compounds. Dedicated infrastructure ensures your contribution is not the cluster's bottleneck. ## Frequently asked questions **What is a Lido Identified DVT Cluster?** A Lido Identified DVT Cluster (IDVTC) is a validator operated by four independent community stakers using distributed validator technology. Each operator holds a key share generated at a DKG ceremony. Signing requires three of the four operators to agree on every attestation. No single party ever holds or reconstructs the full validator key. **When is Lido CSM v3 launching?** Lido Community Staking Module v3 is targeted for Q2 or Q3 2026. The Snapshot vote on the Identified DVT Cluster operator type closed April 13, 2026, clearing the way for the new operator class inside the Community Staking Module. **What does an IDVTC operator need to run?** Each of the four operators needs dedicated infrastructure for their DVT node (Obol or SSV), participation in a distributed key generation ceremony, keyshare storage and rotation policy, exit coordination runbook, and slashing-incident response plan. Each operator's latency contribution directly affects cluster attestation timing. **Why does dedicated hardware matter for DVT cluster operators?** In a 3-of-4 threshold signing cluster, attestation timing is set by the slowest operator. A burstable cloud instance adds 0.3–1.2ms of hypervisor overhead per hop. Over thousands of slots with coordination retries and cloud maintenance windows, that degradation compounds. Dedicated infrastructure ensures your contribution is not the cluster's bottleneck. --- Source: https://linkpool.com/blog/mica-staking-compliance-infrastructure Published: 2026-04-15 Author: LinkPool Team # Infrastructure considerations for MiCA compliance: what changes after July 1, 2026 July 1, 2026 is the end of the grandfathering period for crypto asset service providers operating in EU member states. The Netherlands closed their transition period in July 2025. Several member states have announced earlier deadlines. Most MiCA content focuses on legal authorisation: entity structure, capital requirements, application timelines. Almost nothing covers where the infrastructure should sit, and why it matters to a compliance review. Here is what infrastructure teams should have documented before July 1. ## Jurisdiction: where is the hardware? MiCA does not mandate a specific infrastructure jurisdiction. But authorising authorities will ask about operational resilience. "We run on AWS us-east-1" is a different answer to "we own the hardware in a named jurisdiction." The question is not whether cloud infrastructure is legally compliant. It is whether the answers you give during a CASP review are auditable and defensible. Jurisdiction is auditable when the hardware is owned and physically located in a specific place. UK-domiciled infrastructure sits outside the EU policy perimeter. The UK is not EU post-Brexit, but it operates under a separate, established regulatory framework. Hardware in Manchester, owned by the operator, is not in an unregulated grey zone. ## Operational resilience Article 74 of MiCA requires CASPs to have business continuity plans. Article 75 requires documented ICT risk management. Neither mandates bare-metal infrastructure. Both ask you to document what happens when things go wrong. For [bare-metal infrastructure](/blog/bare-metal-kubernetes-hosting) across three availability zones in a single city: one datacenter goes offline and the cluster continues. Failover at the leaf switches is automatic. The etcd cluster is distributed across all three buildings. The Kubernetes control plane stays up even if one site loses power. For cloud-hosted validators, the equivalent question is: what is your SLA if your cloud provider changes its acceptable-use policy for crypto workloads? That has happened. "We migrate" is a recoverable position. It is harder to document as a continuity plan than hardware you own. Uptime: 99.99% SLA, justified by redundant power, networking, and compute across three locations. ## Key management Key management is where CASP reviews get specific. Regulators want to know who holds the keys, what the custody model is, and what happens if a keyholder is unavailable. For validator operations, [distributed validator technology](/blog/what-is-distributed-validator-technology) adds a second layer: key shares distributed across independent operators, so no single operator can sign on behalf of the validator. Fireblocks multi-sig key management means no single person holds an unencrypted key. This is auditable. It does not change based on which datacenter your validators run in. Penetration testing by Bulletproof is on the record. Harris & Trotter LLP has independently verified financial disclosures. ISO 27001 and SOC 2 are completing in July 2026. These are not marketing claims. They are the documentation that a compliance review will ask to see. ## Physical auditability One question that rarely comes up until it matters: if an authorising authority wants to inspect your infrastructure, what happens? For cloud-hosted validators, the answer is that you do not own the datacenter and you cannot arrange a walkthrough. The cloud provider has its own compliance certifications, but those are the provider's certifications, not yours. For owned bare-metal in a named facility: a physical walkthrough is available. You can show a compliance reviewer the rack. You can demonstrate which server hosts which workload. ## What to ask your infrastructure provider before July 1 Whether you own your infrastructure or use a managed provider, these are the questions worth answering before July 1: - What jurisdiction is the hardware in, and is it owned or rented? - What is your documented continuity plan if one datacenter goes offline? - What is your SLA, and who backs it? - Can you arrange a physical inspection if requested during a CASP review? - What are your key management controls, and are they independently audited? The answers matter more than the infrastructure model. But the infrastructure model determines which answers are available to you. Working through a MiCA CASP authorisation? What has come up in your review so far? ## Common questions **What does MiCA require for staking infrastructure?** MiCA Articles 74 and 75 require documented business continuity plans and ICT risk management. For staking CASPs this means: documented hardware jurisdiction, a tested failover plan if a datacenter goes offline, independent key management controls, and an auditable answer to physical inspection requests from authorising authorities. **When does the EU MiCA grandfathering period end?** The EU-wide MiCA grandfathering period ends July 1, 2026. Several member states set earlier deadlines; the Netherlands closed its transition period in July 2025. CASPs operating without authorisation after their member state's deadline face enforcement risk. **Can you run a MiCA-compliant staking operation on public cloud?** Technically yes, but cloud creates documentation gaps. Cloud-hosted validators cannot arrange a physical inspection if requested during a CASP review. Infrastructure jurisdiction follows the cloud provider's region and can change without notice. The cloud provider's compliance certifications belong to them, not the CASP. **What infrastructure documentation should a CASP prepare for MiCA?** Hardware jurisdiction documentation, a tested business continuity plan with specific failover evidence, key management architecture and custody controls, independent audit records (penetration testing, financial verification), and confirmation of physical inspection availability. ISO 27001 and SOC 2 are increasingly expected in CASP reviews. ## Frequently asked questions **What does MiCA require for staking infrastructure?** MiCA Articles 74 and 75 require documented business continuity plans and ICT risk management. For staking CASPs this means: documented hardware jurisdiction, a tested failover plan if a datacenter goes offline, independent key management controls, and an auditable answer to physical inspection requests from authorising authorities. **When does the EU MiCA grandfathering period end?** The EU-wide MiCA grandfathering period ends July 1, 2026. Several member states set earlier deadlines; the Netherlands closed its transition period in July 2025. CASPs operating without authorisation after their member state's deadline face enforcement risk. **Can you run a MiCA-compliant staking operation on public cloud?** Technically yes, but cloud creates documentation gaps. Cloud-hosted validators cannot arrange a physical inspection if requested during a CASP review. Infrastructure jurisdiction follows the cloud provider's region and can change without notice. The cloud provider's compliance certifications belong to them, not the CASP. **What infrastructure documentation should a CASP prepare for MiCA?** Hardware jurisdiction documentation, a tested business continuity plan with specific failover evidence, key management architecture and custody controls, independent audit records (penetration testing, financial disclosure verification), and confirmation of physical inspection availability. ISO 27001 and SOC 2 are increasingly expected. --- Source: https://linkpool.com/blog/bare-metal-kubernetes-web3-before-enterprise Published: 2026-04-14 Updated: 2026-09-07 Author: LinkPool Team # Bare-metal Kubernetes for Web3: we ran it before enterprise caught up On April 7, Nutanix announced NKP Metal -- bare-metal Kubernetes for enterprise infrastructure. They position it at edge deployments and AI GPU workloads. For Web3 operators, this is not a new category. It is a description of what production already looks like. ## Why Web3 arrived at bare-metal first The reason is not preference. It is physics. An Ethereum validator's attestation window is 12 seconds. Miss it and you lose rewards. Hypervisor overhead adds 0.3 to 1.2ms of latency per hop. On cloud infrastructure, you do not control the hypervisor. You cannot eliminate the overhead. Chainlink Data Streams operates at block-level timing. A feed needs to land before the next block. That constraint is not negotiable. A burstable instance whose CPU gets throttled mid-delivery is not slow. It is wrong. RPC endpoints under query load need guaranteed storage I/O. When storage is shared with co-tenants, write latency spikes without warning. Archive nodes for Ethereum need tens of terabytes of sequential reads. On cloud storage, those reads compete with whoever happens to sit next to you. Platform risk is the third driver. In November 2022, a cloud hosting provider removed more than 1,000 Solana validators from its platform. No migration window. No appeal. The projects running that infrastructure learned that a hosting contract is not the same as infrastructure control. These are not edge cases. They are the operating conditions for production Web3 infrastructure every day. ## What production looks like LinkPool runs Chainlink oracle services -- OCR, CCIP, Data Streams, Automation, and Keepers -- alongside Ethereum validators with [DVT](/blog/what-is-distributed-validator-technology) and RPC endpoints. All of it runs on owned bare-metal servers across three availability zones in Manchester. The servers are 224-vCPU, 1.5 TB DDR5 hosts with 128 TB of local NVMe on each machine. The east-west fabric runs at 1.5 Tbps+ across the three buildings, at 0.2 ms latency. The cluster is designed so that a single datacenter can go offline and workloads keep running -- etcd quorum is distributed across all three buildings, with redundant network paths across the spine. Kubernetes runs directly on bare-metal using eBPF networking. No hypervisor. No scheduling layer between the workload and the hardware. The result is deterministic performance. Not performance that is usually good. Consistent by design. For validators, that means attestation timing that holds under load. For oracle nodes, it means feed delivery that stays inside the block window. For RPC endpoints, it means response times that do not degrade when adjacent workloads spike. We have operated this infrastructure since 2017. Zero slashing events across all validator deployments. ## The cost gap The timing argument is often the first one. The cost gap is the one that closes the conversation. An ETH validator workload costs $556 per month on AWS and fits on a $219 whole dedicated server. On component-priced bare metal, where the workload pays for its 8 vCPU, 32 GB and 2 TB rather than a whole machine, it lands lower again. A Chainlink node, at a fraction of that footprint, shows the same gap against its $278 AWS equivalent. That gap exists because owned hardware carries no cloud margin. The workload pays for compute, not the privilege of using someone else's infrastructure. DIY bare-metal has its own overhead: engineering time for OS updates, network changes, hardware failures, and on-call rotation. That overhead runs $4,700 to $16,000 per month before a single workload runs. Managed bare-metal removes that cost. ## What the Nutanix announcement actually means Enterprise infrastructure teams are arriving at the same architectural conclusion that Web3 operators reached under operational pressure. Their drivers are different -- edge latency and GPU density, rather than attestation windows and oracle timing. But the architecture converged from opposite directions. The significance is practical. The category has a name now. Enterprise buyers are starting to evaluate bare-metal Kubernetes as a deliberate choice, not an unusual constraint. That changes the procurement conversation. For Web3 teams still running validators or oracle nodes on EKS or GKE: the cost case has not changed. Neither has the performance case. What has changed is that the question will come up in more conversations. ## What moves the decision Most operators who have run production validators on cloud eventually hit one of three events: an outage that causes missed attestations, a platform policy change that threatens their workload, or a cost review that surfaces the gap. For operators with EU exposure, [MiCA compliance](/blog/mica-staking-compliance-infrastructure) is a fourth: the July 2026 deadline is creating hard questions about infrastructure jurisdiction and physical auditability that cloud-hosted validators cannot answer cleanly. None of those are hypothetical. All of them have happened to production operators in the last three years. If you are running steady-state validator or oracle workloads on cloud today, the question is not whether bare-metal performs better. The question is what event changes the calculus. What has been the forcing function for teams you know who made the switch? ## Common questions **Why did Web3 operators adopt bare-metal Kubernetes before enterprise?** Web3 workloads have hard latency deadlines: Ethereum attestations have a 12-second window, and Chainlink Data Streams feeds must land before the next block. These constraints made cloud virtualisation unacceptable years before enterprise AI and edge workloads created similar demand. **How much does it cost to run an ETH validator on AWS vs dedicated infrastructure?** One ETH validator workload (8 vCPU, 32 GB RAM, 2 TB NVMe) costs $556 per month on AWS Reserved pricing, and $219 on the cheapest whole dedicated server. Component-priced dedicated infrastructure charges only for the resources the validator consumes, not a whole machine or cloud burst headroom, so it lands lower again. **What is the performance difference between cloud and bare-metal for validator hosting?** Hypervisor overhead on cloud adds 0.3–1.2ms of latency per hop. For Ethereum validators this translates to degraded attestation timing under load. Bare-metal removes the hypervisor entirely, so containers talk directly to the kernel and hardware, giving consistent latency that does not degrade when adjacent workloads spike. **What are the risks of running Ethereum validators on public cloud?** Three main risks: performance variability from burstable CPU and shared storage causing missed attestations; platform risk (in November 2022 a cloud provider removed 1,000+ validators with no migration window); and compliance gaps, because cloud-hosted validators cannot provide physical auditability, which some MiCA CASP reviews require. ## Frequently asked questions **Why did Web3 operators adopt bare-metal Kubernetes before enterprise?** Web3 workloads have hard latency deadlines: Ethereum attestations have a 12-second window, and Chainlink Data Streams feeds must land before the next block. These constraints made cloud virtualisation unacceptable years before enterprise AI and edge workloads created similar demand. **How much does it cost to run an ETH validator on AWS vs dedicated infrastructure?** One ETH validator workload (8 vCPU, 32 GB RAM, 2 TB NVMe) costs $556 per month on AWS Reserved pricing, and $219 on the cheapest whole dedicated server. Component-priced dedicated infrastructure charges only for the resources the validator consumes, not a whole machine or cloud burst headroom, so it lands lower again. **What is the performance difference between cloud and bare-metal for validator hosting?** Hypervisor overhead on cloud adds 0.3–1.2ms of latency per hop. For Ethereum validators this translates to degraded attestation timing under load. Bare-metal removes the hypervisor entirely, so containers talk directly to the kernel and hardware, giving consistent latency that does not degrade when adjacent workloads spike. **What are the risks of running Ethereum validators on public cloud?** Three main risks: performance variability from burstable CPU and shared storage causing missed attestations; platform risk (in November 2022 a cloud provider removed 1,000+ validators with no migration window); and compliance gaps, because cloud-hosted validators cannot provide physical auditability, which some MiCA CASP reviews require. --- Source: https://linkpool.com/blog/what-is-distributed-validator-technology Published: 2026-04-10 Author: LinkPool Team # What is distributed validator technology (DVT)? Ethereum validators have a structural problem. Each validator is controlled by a single private key. Whoever holds that key can sign on behalf of the validator. If they make a mistake, the validator gets slashed. DVT solves this by distributing control across multiple independent operators. No single key. No single point of failure. ## The problem DVT solves Three things can go wrong with a traditionally operated validator. Loss. If the private key is lost or the machine holding it becomes permanently unavailable, the validator goes offline and stops earning yield. Slashing. If the same validator key accidentally runs on two machines simultaneously -- which can happen during failovers or migrations -- the validator double-signs and gets penalised. Ethereum calls this slashing. It deducts from staked ETH. Compromise. If the key is stolen, an attacker can sign on your behalf or hold the threat of a slashing event as leverage. DVT addresses all three through architecture, not process. ## How it works A DVT cluster uses a cryptographic technique called Distributed Key Generation (DKG). Instead of one private key, the cluster generates multiple key shares held by separate operators on separate infrastructure. To sign an attestation or propose a block, a threshold of operators must agree. With SSV Network, the standard is four operators with a 3-of-4 signing threshold. Three of the four must sign together. No single operator can act alone. From Ethereum's perspective, this is a standard validator. The distributed coordination happens below the consensus layer. On-chain, nothing changes. The slashing risk disappears structurally. Double-signing requires one key to sign twice. When no single key exists, it cannot happen. ## SSV Network and Obol Two protocols implement DVT for Ethereum: SSV Network and Obol. SSV Network runs a decentralised operator network with on-chain coordination. Obol uses distributed key generation with a different cryptographic approach and a permissioned operator model. Both implement the same principle: no single party controls the validator. LinkPool operates Lido DVT clusters using both SSV Network and Obol. ## The Lido integration Lido Protocol has integrated DVT via its Node Operator Module. Institutional stakers can access DVT-protected Ethereum staking through Lido and receive stETH immediately as a liquid receipt token. There is no entry queue wait. Validator activation is handled through Lido protocol routing. Net institutional yield runs at approximately 3.0-4.0% APR. Yield varies with network conditions. The execution layer runs Geth, Nethermind, and Besu. Consensus runs Prysm, Lighthouse, and Teku. Client diversity means a bug in any single client doesn't take the validator offline. ## DVT doesn't fix infrastructure quality DVT solves key management. It doesn't fix the infrastructure underneath. A validator running on shared cloud with a DVT key setup still has a noisy neighbour problem. SLA ceilings are still set by the cloud provider. If the cloud provider has a maintenance window, the validator misses attestations regardless of how well the key is distributed. Our Lido DVT clusters run on [owned bare-metal Kubernetes infrastructure](/blog/bare-metal-kubernetes-web3-before-enterprise) across three availability zones in Manchester. No hypervisor layer. Three independent datacenters, each hosting its own operator node. The SLA ceiling is set by our infrastructure design, not a third-party cloud contract. Physical auditability is available. If your compliance team needs to inspect the facility, a walkthrough can be arranged. ## Who DVT is designed for DVT is practical for institutional stakers who need documented slashing protection, compliance-friendly key management, and infrastructure that survives single-operator failure. Protocol teams moving large ETH allocations also benefit. The consequences of a key management mistake at scale are material. Institutional interest in staked ETH is growing. The infrastructure layer that holds the keys matters more than it used to. ## The right questions If you are evaluating Lido node operators or planning an ETH staking programme, these are the questions worth asking. Where are the validator keys distributed? Can you verify that key shares sit with independent operators on genuinely separate infrastructure? Not multiple nodes in the same datacenter or cloud account. What happens if one operator goes down? Three-of-four means one operator can fail without interrupting the validator. Ask what the recovery plan looks like if two fail simultaneously. What is the SLA ceiling on the hardware? DVT protects the key. It doesn't protect attestation performance. If the hardware is cloud-based, read what the service agreement actually guarantees. Can you inspect the infrastructure? Physical auditability is a [MiCA compliance requirement](/blog/mica-staking-compliance-infrastructure) for some institutional stakers. Most cloud-hosted validators can't offer it. ## Common questions **What is distributed validator technology?** DVT distributes an Ethereum validator key across multiple independent nodes using threshold cryptography. A 3-of-4 threshold means any three of the four operators must sign before a validator duty executes. No single operator holds the complete key. **How does DVT prevent slashing?** By removing the single point of failure. A compromised or offline node cannot submit a slashable action without threshold agreement from the other operators. The remaining nodes continue operating normally. **What is SSV Network?** SSV Network is a DVT protocol for Ethereum. It splits validator keys using Shamir's Secret Sharing and coordinates duties through a p2p network. Lido's DVT programme runs on SSV. **What is the difference between Obol and SSV?** Both implement DVT for Ethereum but coordinate validator duties differently. SSV uses an off-chain p2p network. Obol uses a consensus layer called Charon. Lido integrates both protocols; SSV is the dominant path for Lido DVT clusters currently. ## Frequently asked questions **What is distributed validator technology (DVT)?** DVT distributes an Ethereum validator key across multiple independent nodes using threshold cryptography. A 3-of-4 threshold means any three of the four operators must sign before a validator duty executes. No single operator holds the complete key, eliminating single points of failure. **How does DVT prevent slashing?** DVT prevents slashing from key compromise and single-node failure. Because no single operator holds the complete private key, a compromised or offline node cannot submit a slashable action on its own. The remaining nodes in the cluster continue operating and reach threshold without the failed operator. **What is SSV Network?** SSV Network is a DVT protocol for Ethereum. It splits validator keys using Shamir's Secret Sharing and distributes key shares to independent node operators. Validator duties (attestations, proposals, sync committees) require threshold signature aggregation before submission to the beacon chain. **What is the difference between Obol and SSV for DVT?** Both protocols implement DVT for Ethereum. SSV uses an off-chain p2p network for duty coordination with on-chain slashing protection. Obol uses a consensus mechanism called Charon with a different cryptographic approach. Lido's DVT programme integrates both. SSV is currently the dominant integration path for Lido DVT clusters. --- Source: https://linkpool.com/blog/bare-metal-kubernetes-hosting Published: 2026-04-07 Updated: 2026-09-07 Author: LinkPool Team # Why We Chose Bare Metal Kubernetes for Web3 Infrastructure When you are running infrastructure that secures hundreds of millions of dollars in onchain assets, every millisecond of latency and every layer of abstraction matters. That is why LinkPool runs its entire stack on bare metal Kubernetes: no cloud providers, no hypervisor, no compromises. ## The Problem with Cloud for Web3 Cloud platforms like AWS, GCP, and Azure are excellent for many use cases. But for mission-critical Web3 infrastructure, they introduce risks that are difficult to accept: - **Overcommitted hosts:** cloud VMs share CPU through a hypervisor with no way to reserve it, so a neighbour's spike becomes your latency - **Latency overhead:** virtualisation layers add milliseconds that compound across thousands of daily transactions - **Vendor lock-in:** dependence on a single provider creates a centralisation risk that contradicts the ethos of decentralised infrastructure - **Cost at scale:** cloud pricing becomes prohibitive when you are processing billions of requests per month > Running Web3 infrastructure on centralised cloud providers is an irony we chose not to live with. ## Our Bare Metal Setup LinkPool operates across **three availability zones in Manchester**, in three independent data centres. Here is what that means in practice: ### Hardware The fleet is one class of high-end host rather than a different machine per workload. A current production worker is: - **224 vCPUs** of AMD EPYC, so a single validator or RPC endpoint is a small slice of the machine - **1.5 TB of DDR5 RAM** with ECC - **128 TB of local NVMe**, ten enterprise drives per host, for chain state and archive data Validators, oracle nodes and RPC endpoints share these hosts under Kubernetes. What keeps them from interfering is not separate machines but reserved capacity: on the Performance tier, CPU requests equal limits, so a workload never yields to a neighbour. We own our hardware outright. Every rack, every switch, every cable is ours. ### Network Our network architecture is designed for both performance and resilience: 1. **Dual uplinks** from independent transit providers at each data centre 2. **Sub-millisecond latency** between hosts in each facility 3. **A 1.5 Tbps+ east-west fabric** across the three data centres at 0.2 ms, with up to 200 Gbps per host 4. **BGP peering** with major exchanges for optimal routing to blockchain networks worldwide ### Power and Cooling Each facility runs redundant power and cooling, and the platform is designed so that a whole data centre can go offline and workloads keep running: - Dual power feeds with UPS and generator backup at each site - Redundant cooling - Three sites, so failover never depends on a single building - A 99.99% uptime SLA target set by our own failover design, not a pass-through cloud contract ## Why Kubernetes on Bare Metal Running Kubernetes without a cloud provider sounds daunting, but it gives us capabilities that managed Kubernetes services cannot match. ### Full Control Over Scheduling We control exactly which workloads run on which hardware and how much of it they are guaranteed. Validators run with reserved CPU and memory, so they never compete for resources with other services on the same host. This eliminates the performance variance that plagues cloud-hosted validators. ### Custom Networking Without cloud networking abstractions, we can optimise packet paths directly. Our CNI configuration is tuned for minimum-latency pod-to-pod communication, and we use SR-IOV for workloads that need direct NIC access. ### No Abstraction Tax Every layer of virtualisation adds overhead. On bare metal, our containers talk directly to the kernel, which talks directly to the hardware. The result is measurably lower latency and higher throughput compared to equivalent cloud instances. ### Hardware-Level Security We control the full stack from BIOS to application. This means: - **Secure boot chains** verified at every level - **Hardware security modules** for key management - **Physical security** with biometric access controls and 24/7 monitoring - No third-party hypervisors or firmware we did not choose ## The Numbers Speak What this platform has delivered, on record: - **Zero slashing events** across six years of mainnet validator operations - **Chainlink nodes live since mainnet launch** in May 2019, on the same operating discipline - **AAA rating** from Staking Rewards, with Verified Staking Provider certification - **A 99.99% uptime target** backed by failover across three availability zones These are the outcomes the protocols and enterprises that depend on our infrastructure actually measure. ## Operational Challenges Running bare metal is not without its challenges. Here is what we have learned: ### Capacity Planning There is no auto-scale button. We forecast demand months in advance, order hardware, rack it, burn it in, and integrate it into our clusters. This requires discipline but also means we are never surprised by a cloud provider's capacity limits. ### Upgrades and Maintenance Rolling upgrades on bare metal require careful orchestration. We have built tooling that can drain nodes, update firmware, upgrade the OS, and return nodes to service with zero downtime. Every maintenance window is rehearsed before execution. ### Monitoring and Alerting When you own the hardware, you own every failure mode. Our monitoring stack tracks everything from CPU temperature and disk SMART data to kernel metrics and application-level SLOs. We detect hardware degradation before it becomes a failure. ## Looking Ahead We are continuously investing in our infrastructure. Current projects include: - **GPU nodes** for emerging AI-powered oracle use cases - **Expanded edge presence** to reduce latency for Asian and South American networks - **Next-generation storage architecture** for historical blockchain data at petabyte scale Our commitment to bare metal is not going to change. For the reliable, performant and truly decentralised infrastructure that Web3 demands, there is no substitute for owning every layer of the stack. --- If you are building a protocol or enterprise application that needs infrastructure you can count on, we would love to talk. Reach out through our [website](https://linkpool.com) or find us on [Twitter](https://twitter.com/linkpoolio). ## Common questions **What is bare-metal Kubernetes hosting?** Bare-metal Kubernetes hosting runs container workloads directly on physical servers without a hypervisor layer. Containers communicate with the kernel and hardware directly, eliminating virtualisation overhead. For Web3 workloads this means lower and more predictable latency than equivalent cloud instances. **Why use bare-metal instead of cloud for Web3 infrastructure?** Cloud virtualisation adds 0.3–1.2ms of hypervisor overhead per hop and introduces noisy-neighbour variability. Web3 workloads such as validator attestations, oracle feeds and RPC endpoints have latency deadlines measured in milliseconds. Bare-metal removes the overhead and gives deterministic performance that cloud cannot match. **How does bare-metal Kubernetes differ from managed Kubernetes like EKS or GKE?** Managed Kubernetes runs on cloud virtual machines with a hypervisor between your containers and the hardware. Bare-metal Kubernetes runs directly on physical servers. You control hardware scheduling, tune the network layer for minimum latency, and have no shared-tenancy risk. The tradeoff is that hardware management, including firmware updates, failures and capacity planning, sits with the operator. ## Frequently asked questions **What is bare-metal Kubernetes hosting?** Bare-metal Kubernetes hosting runs container workloads directly on physical servers without a hypervisor layer. Containers communicate with the kernel and hardware directly, eliminating virtualisation overhead. For Web3 workloads this means lower and more predictable latency than equivalent cloud instances. **Why use bare-metal instead of cloud for Web3 infrastructure?** Cloud virtualisation adds 0.3–1.2ms of hypervisor overhead per hop and introduces noisy-neighbour variability. Web3 workloads such as validator attestations, oracle feeds and RPC endpoints have latency deadlines measured in milliseconds. Bare-metal removes the overhead and gives deterministic performance that cloud cannot match. **How does bare-metal Kubernetes differ from managed Kubernetes like EKS or GKE?** Managed Kubernetes runs on cloud virtual machines with a hypervisor between your containers and the hardware. Bare-metal Kubernetes runs directly on physical servers. You control hardware scheduling, tune the network layer for minimum latency, and have no shared-tenancy risk. The tradeoff is that hardware management sits with the operator.