Ask most institutions how they manage staking risk, and the answer usually starts the same way: “we work with more than one provider.” Institutional staking diversification has become shorthand for exactly that: spreading a position across two or three vendors and calling the risk managed. It’s a reasonable instinct, borrowed directly from traditional portfolio theory. It’s also, on its own, an incomplete answer.
Adding a second or third staking provider addresses one kind of risk: counterparty risk. If one vendor becomes insolvent, gets hacked, or simply underperforms, the damage is contained to a fraction of the portfolio. That matters, and no institution should be staking meaningful volume through a single vendor relationship. But counterparty diversification says nothing about what’s happening underneath each of those providers: the client software they run, the cloud regions they depend on, the physical hardware their validators sit on. Two “different” providers can still share the same execution client, the same cloud region, and the same failure mode. When that happens, an institution that believes it has diversified has actually just duplicated its exposure under two different logos.
This is the gap that a real institutional staking diversification strategy has to close: providers, geographies, and hardware are three separate layers of risk, and each one needs its own due diligence. Treating any single layer as a proxy for the other two is how institutions end up with a diversification strategy that satisfies an internal risk memo without actually reducing correlated exposure.
Why Provider Count Alone Isn’t a Risk Strategy
Institutional capital entering proof-of-stake networks has grown fast enough that staking is now treated less like an experimental yield source and more like a fixed-income-adjacent allocation: something with an expected return, a risk profile, and a due diligence process attached to it. That shift has pushed compliance and risk teams to ask sharper questions than “what’s the APY,” and provider count is usually the first lever they reach for.
The logic is sound as far as it goes. A validator operator can go offline, mismanage keys, or shut down entirely, and an institution spread across several operators is protected from any single one of those events wiping out its position. But provider count is a surface-level metric. It tells you how many logos are on your statement, not how independent those relationships actually are from one another.
Two staking providers can be legally and operationally distinct companies while still running the same consensus client, hosting validators in the same handful of cloud regions, and following similar approaches to failover and uptime. If a bug in that shared client causes a mass slashing event, or the shared cloud region has an outage, both providers go down together, and so does the diversification an institution thought it had purchased. Real institutional staking diversification has to look past the provider relationship and into the infrastructure each provider actually runs.
The Geography Layer: Why Location Concentration Is a Systemic Risk
Geographic concentration is one of the least visible risks in institutional staking, largely because it doesn’t show up in a fee schedule or a service level agreement. It shows up during an outage.
Cloud infrastructure concentration is a well-documented problem across the validator landscape. Independent analysis has found that roughly two-thirds of Ethereum validators run on just two cloud providers, AWS and Google Cloud, according to research published by ChainScore Labs. That level of concentration means a regional outage at either provider has the potential to affect a majority of network validators simultaneously; not a handful of unlucky operators, but a systemic event.
For an institution, the practical consequence is straightforward: staking through three providers that all deploy their infrastructure in the same AWS region provides almost none of the resilience that three geographically distributed providers would. A regional power event, a fiber cut, a misconfigured update pushed by a cloud provider, or a natural disaster can take an entire region offline regardless of how many validator operators sit inside it. None of those events discriminate between vendors.
This is why geographic and infrastructure diversity deserves the same due diligence institutions already apply to counterparty risk. Questions worth asking of any staking partner include which cloud regions and jurisdictions their validators run in, whether any part of their operation relies on bare-metal infrastructure outside the major cloud providers, and how they’d describe their exposure if a single region went dark for six hours. A provider that can answer those questions with specifics, rather than reassurances, is demonstrating the kind of operational maturity that institutional staking diversification is actually meant to protect.
Jurisdiction adds a second dimension to the geography question that’s easy to overlook. Validators sitting in a single legal jurisdiction are exposed not just to physical outages but to that jurisdiction’s regulatory environment: a change in local policy, a data center compliance order, or a sanctions action can affect an entire cluster of validators at once, regardless of which provider technically operates them. Institutions building a staking program that’s meant to hold up across market cycles and regulatory cycles alike have good reason to ask providers about jurisdictional spread, not just physical infrastructure spread.
The Hardware and Client Layer: The Risk Institutions Usually Miss
If geography is the risk institutions underweight, client software concentration is the one most institutions never learn to ask about at all.
Every validator runs client software to communicate with its blockchain network, and that software comes from a small number of independent teams. On Ethereum, tracking maintained by Ethernodes has repeatedly shown execution and consensus clients concentrated well above the safety thresholds the Ethereum community itself recommends, with single clients frequently holding more than 40% of network share. When one client implementation dominates that heavily, a bug in that specific piece of software doesn’t stay contained to one validator or one operator; it can propagate across every validator running it, regardless of which company operates them or which cloud region they sit in.
This isn’t a hypothetical. In December 2025, a bug in the Prysm consensus client caused validators running that software to miss blocks and attestations following Ethereum’s Fusaka network upgrade, resulting in an 18.5% missed slot rate and roughly 382 ETH, worth over $1.1 million at the time, in lost rewards, as documented by incident tracker Web3 is Going Great. It wasn’t the first time a client-level bug has had network-wide consequences: in May 2023, Ethereum mainnet briefly lost finality twice within 24 hours because of a bug affecting both the Prysm and Teku consensus clients. Ethereum has recorded well over 260 slashing incidents to date, and while most trace back to operator error rather than client bugs specifically, the pattern is consistent: concentration at the software layer turns an isolated bug into a correlated, network-wide event.
Institutional staking diversification that stops at the provider layer will never catch this. An institution staking through three different providers that all default to the same dominant client is exposed to exactly the same tail risk as an institution using a single provider, because the failure mode, a client bug, a double-signing event triggered by that bug, hits every validator running that software at the same moment.
The same logic extends to physical hardware. A staking provider that runs its own bare-metal infrastructure, rather than leasing generic cloud compute, has more direct control over uptime, security hardening, and failover behavior, but it also needs to demonstrate genuine redundancy across its own hardware footprint, not just diversity relative to competitors. Institutions evaluating a provider’s hardware strategy should be asking whether validators are distributed across independent physical sites, what the provider’s failover process looks like during a hardware failure, and whether that process favors safety over marginal uptime when the two are in tension. A provider that would rather go briefly offline than risk a double-signing event is making a defensible, risk-managed choice, even though it looks, on a simple uptime dashboard, like slightly worse performance.
Diversification as a Compliance and Reporting Function, Not Just a Risk One
There’s a version of this conversation that stays purely technical: client software, cloud regions, hardware redundancy, and misses why institutions actually need to document all of it in the first place. For a compliance or risk team, institutional staking diversification isn’t just a defensive posture against outages; it’s an audit trail. Boards, auditors, and increasingly regulators expect institutions holding staked positions to demonstrate that they understand where the risk in that position actually sits, not just that a return was generated.
That reporting obligation is precisely where a provider-count-only approach breaks down fastest. If an institution can name three staking providers but can’t say which consensus clients those providers run or which cloud regions their validators depend on, that institution has a diversification claim it can’t actually substantiate under scrutiny. The same is true in reverse: a provider that can supply client distribution data, regional breakdowns, and a documented failover philosophy on request is handing an institution’s risk team exactly the paper trail it needs to satisfy internal governance and external audit requests.
This is also where the custody model intersects with the other three layers. A non-custodial arrangement, where the institution retains control of withdrawal keys while the provider manages signing operations, limits the blast radius of a provider-level failure regardless of what’s happening at the geography or hardware layer underneath it. Custody, in other words, isn’t a fourth diversification layer so much as a backstop that determines how much the other three layers actually matter if something goes wrong.
What Genuine Diversification Actually Requires
Pulling these three layers together, a workable framework for institutional staking diversification looks less like “pick three vendors” and more like a due diligence checklist that has to be applied to each layer independently:
- Provider layer: How many independent operators hold delegated authority over the stake, and what does each provider’s custody model look like: custodial, non-custodial, or hybrid?
- Geography layer: Across which physical regions and cloud providers is the stake actually distributed, and how much of it sits inside a single cloud provider’s footprint?
- Hardware and client layer: What consensus and execution client software does each validator run, and how concentrated is that mix relative to the wider network?
None of these questions has a single correct answer that applies to every institution. A treasury team with a smaller allocation may reasonably accept more concentration than a large asset manager running a staking program across billions in assets. What matters is that the decision is made deliberately, with visibility into all three layers, rather than being made implicitly by whichever combination of providers happened to be easiest to onboard.
It’s also worth being honest about the limits of self-directed diversification. Manually tracking client distribution, cloud region exposure, and hardware redundancy across several independent staking providers is a real operational burden, and the data needed to do it well; a given provider’s client mix, its regional footprint, its failover philosophy, is not always disclosed by default. Institutions that want this level of visibility need to ask for it explicitly during due diligence, and should treat a provider’s willingness to share it as a signal in itself.
There’s also a practical trade-off worth naming honestly: diversification across more providers, regions, and hardware configurations adds operational overhead. Every additional provider relationship means another set of reporting formats, another fee schedule, another point of contact during an incident, and another set of internal controls to maintain. This is precisely why the underlying diversity within each provider matters as much as the number of providers, an institution that concentrates its stake with a single, deeply diversified partner can end up with better real-world resilience than one spread thin across many shallow relationships, provided that single partner can prove its internal diversity across geography, hardware, and client software rather than simply asserting it. The goal was never diversification for its own sake; it’s resilience, and resilience can come from depth as easily as it can come from breadth.
Where This Leaves Institutional Allocators
Staking has moved from a niche activity to a standard component of institutional digital asset strategy, and the questions being asked of staking providers have matured along with it. “What’s your APY” was never the right question on its own, and “how many providers do you use” isn’t either. Institutional staking diversification, done properly, means treating provider selection, geographic distribution, and infrastructure design as three distinct risk categories; each with its own due diligence, each capable of undermining the other two if it’s ignored.
The institutions that get this right aren’t necessarily the ones with the most vendor relationships. They’re the ones asking better questions of the vendors they already have: where does the infrastructure actually live, what software is it running, and what happens to this position if a single cloud region, or a single piece of client software, has a bad day. Those are the questions that separate genuine risk management from a diversification strategy that only looks good on paper.
At GlobalStake, we think about staking infrastructure through exactly this lens, as a set of layered decisions about custody, geography, and hardware, not just a vendor count. Institutions evaluating any staking partner, GlobalStake included, should feel comfortable asking these same questions before allocating.