Marinade has disclosed that four autonomous system numbers control roughly two-thirds of the stake distributed through its Stake Auction Marketplace, with AS395201 alone accounting for 36.94%, a concentration that could leave many apparently independent validators exposed to the same infrastructure failure.
The liquid-staking protocol made the disclosure in a post on X while responding to a broader discussion about Solana’s network resilience. The message was brief but unusually direct:
“Our own numbers, since we’re pointing at everyone else’s. Four ASNs hold two thirds of the stake SAM allocates. AS395201 alone is 36.94%. Nobody should be comfortable with that, us included.”
The statement does not identify the companies or hosting providers associated with those autonomous system numbers. It also does not announce a change to Marinade’s delegation policy, a timetable for reducing the concentration or a technical explanation for how the figures were calculated. But it provides a concrete measure of a risk that is often obscured by validator counts: a blockchain can have thousands of validator identities while still relying heavily on a small number of underlying networks.
Marinade’s figures make the point concrete: the concentration of validators across four autonomous systems (ASNs) shows why a network can have many validators while still relying on a small number of independent operators. Validator counts, in other words, can overstate the network’s operational independence.
Marinade’s disclosure is especially relevant because the concentration concerns stake allocated through a system designed to distribute capital among validators. The Stake Auction Marketplace, or SAM, is intended to create a competitive mechanism through which validators receive delegated SOL. If that process rewards validators that are technically reliable but connected through the same infrastructure provider, stake can become concentrated at the network layer even when it appears diversified at the account level.
The number behind the warning
An autonomous system number is an identifier used to distinguish an independently managed network on the internet. Internet service providers, cloud companies, hosting firms, universities, enterprises and other organizations can operate autonomous systems. These systems announce routes and exchange traffic using the Border Gateway Protocol, or BGP, which helps data find its way across the internet.
For blockchain analysis, ASNs can act as a useful infrastructure fingerprint. If a large group of validators is reachable through the same ASN, that may indicate that they share a hosting company, network operator or connectivity provider. The relationship is not conclusive on its own: an ASN can contain different customers, locations or organizations. Nevertheless, it gives researchers a way to look beyond validator names and wallet addresses.
Marinade’s figures point to a sharp imbalance within the stake distributed by SAM. Four ASNs hold approximately two-thirds of that stake, while AS395201 represents 36.94% on its own. In practical terms, more than one-third of the stake allocated by the marketplace is associated with a single network identifier.
That does not mean that 36.94% of all SOL securing Solana sits behind AS395201. The statement is narrower. It refers to the stake that SAM allocates, not necessarily Marinade’s entire liquid-staking position, the entire Solana stake distribution or all validators operating on the network. The distinction matters because a percentage calculated within one delegation program cannot automatically be extended to the whole chain.
Even with that limitation, the number is significant. Stake determines voting influence and contributes to the economic security of a proof-of-stake blockchain. If the machines carrying that stake lose connectivity, fail simultaneously or become unable to communicate with the rest of the network, their combined absence can affect the chain’s ability to process and finalize blocks.
The risk is not limited to a total shutdown. A concentrated infrastructure provider could suffer a partial outage, routing leak, denial-of-service event, hardware failure, power disruption or operational mistake. Validators might remain online from the perspective of their own monitoring systems while becoming unreachable by a meaningful share of the network. The result could be delayed votes, slower confirmation, missed rewards or a more serious impact on finality.
Why validator counts can be misleading
Public blockchain dashboards commonly emphasize the number of validators. That measure is useful, but it can create a misleading impression of decentralization when validator identities are not matched with infrastructure data.
Suppose a network has hundreds of validators, and those validators are controlled by different companies. If a large portion of them rent servers from the same cloud provider, use the same network operator or depend on the same internet exchange, an outage at that common point may affect many of them at once. They may be legally and economically independent while remaining operationally correlated.
The same issue can appear within a single professional hosting environment. A provider may offer separate virtual machines to many validator operators. The machines have different keys and accounts, but they can still share power, upstream connectivity, network equipment, staff and maintenance schedules. A failure at the provider level can therefore look like a failure across many supposedly separate validators.
This is an example of correlated failure. In a decentralized system, the important question is not only whether failures are spread across many identities. It is whether those identities fail independently enough to preserve the chain’s operation when one component breaks.
The ASN metric does not capture every form of correlation. Two validators can use different ASNs but share a cloud region, data center, power grid, software release or operations team. Conversely, several validators may appear under one ASN while being operated by unrelated customers in separate facilities. ASN concentration is therefore a signal, not a complete map of decentralization.
Its value is that it reveals a layer that ordinary stake-weighted validator lists may not show. A network can claim a large number of validators while its traffic is still routed through a narrow set of organizations. Marinade’s statement brings that hidden layer into the discussion.
The routing dimension of Solana resilience
The disclosure comes as the Solana community considers how routing and connectivity can threaten consensus. Community discussions have raised concerns that routing failures could disrupt validator communication and affect the network’s ability to reach consensus.
Finality is the point at which a block is considered irreversible under a network’s consensus rules. Solana can continue producing blocks only if enough validators communicate, vote and maintain a consistent view of the chain. If a sufficient share of voting power becomes isolated or fails to participate, the network may continue operating at reduced performance, or it may struggle to finalize new blocks.
This is different from an ordinary application outage. A decentralized application can sometimes tolerate a single server going offline because users can connect through another endpoint. Consensus is more demanding. The system needs a sufficiently large and well-connected group of validators to exchange blocks and votes within the expected timing constraints.
Routing incidents can be particularly difficult because they may not look like traditional downtime. A validator can remain powered on and continue running its software, while internet routes prevent other validators from reaching it. A regional routing problem can split the network into groups that can communicate internally but not reliably with one another. When stake is concentrated behind a few network operators, the consequences of such an event can be amplified.
The point is not that AS395201 is currently failing or that the four identified ASNs constitute a single operator. Marinade’s post makes no such claim. The point is that infrastructure concentration increases the number of validators that may be exposed to a common network-level event.
A routing bug affecting one provider may have a much wider impact than a hardware failure affecting one validator. If the provider carries a substantial portion of the stake used by a delegation marketplace, a problem at that provider could remove a large amount of voting power from the active network at the same time.
How delegation can reinforce concentration
Delegation systems are designed to make staking accessible. Most token holders do not want to run validator infrastructure, monitor servers around the clock or manage upgrades. Liquid-staking protocols such as Marinade allow users to deposit SOL and receive a liquid representation of their staked position, while the protocol delegates the underlying stake to validators.
That model can improve capital efficiency and broaden participation. It can also introduce a new decision-making layer. Instead of every token holder independently choosing a validator, the protocol selects validators according to its own criteria and distributes stake among them.
SAM is part of that allocation process. A marketplace-based system can use competition, validator performance and other criteria to determine which operators receive stake. The goal is to direct capital toward reliable infrastructure while creating a transparent mechanism for validators to compete for delegation.
But optimization around validator-level performance can produce an unintended result if infrastructure relationships are not considered. Several validators may independently score well on uptime, voting performance and commission terms while all relying on the same underlying network. If the allocation model treats them as separate choices, it may reward the same infrastructure cluster multiple times.
This is a classic challenge in designing decentralized systems. An incentive mechanism can improve one dimension while weakening another. A system that efficiently identifies high-performing validators may unintentionally reduce geographic or network diversity. A system that minimizes missed votes may prefer professional operators concentrated in the same data centers. A system that seeks low fees may push participants toward hosting arrangements with similar economies of scale.
The issue is not that performance metrics are unimportant. Reliable validators are essential to the network. Rather, performance should be evaluated together with failure independence. A validator that is highly reliable in normal conditions may still add less resilience if it shares a critical dependency with a large group of other validators.
Marinade’s post implicitly acknowledges that stake allocation is part of the infrastructure problem. The protocol said “nobody should be comfortable with that, us included,” placing itself inside the group responsible for addressing the concentration rather than treating the issue as a problem created only by independent operators or external cloud companies.
What the figures do, and do not, show
The X post supplies two central facts: four ASNs account for roughly two-thirds of SAM-allocated stake, and AS395201 represents 36.94%. It does not provide the full distribution among the four ASNs, the number of validators within each network or the amount of SOL covered by SAM.
It also does not establish the identity of AS395201’s operator. An ASN registry can help associate a number with a registered organization, but the registered organization is not always the same as the company hosting every server using the ASN. Network operators can provide transit, colocation or connectivity to customers, and infrastructure can be layered across multiple providers.
This means the figures should not be read as proof that one company controls 36.94% of the marketplace’s stake. They show that the stake is mapped to one autonomous system. Determining who actually operates the validators would require additional information, including validator ownership, hosting agreements, data-center locations and network topology.
Nor does the concentration automatically imply an imminent consensus failure. The validators behind one ASN may be distributed across multiple facilities. They may have redundant upstream connections, independent power systems and failover arrangements. They may also be able to migrate traffic quickly during an incident. The risk depends on the nature of the common dependency, not merely its existence.
Still, the absence of an immediate failure does not make the concentration irrelevant. Resilience is measured before a crisis, when operators can identify dependencies and reduce them at a manageable cost. Waiting for a provider outage to reveal the extent of shared infrastructure is a more expensive way to learn about system design.
The data would become more informative if accompanied by several additional metrics: the percentage of SAM stake held by each ASN, the number of validators represented, the geographic distribution of those validators, the number of independent operators and the overlap between ASNs and data centers. It would also help to know whether the figures are based on current network announcements, historical observations or a longer sampling period.
Those details would allow the community to distinguish between durable concentration and a temporary allocation pattern. They would also show whether a handful of large validators account for the result or whether many smaller validators are clustered behind the same provider.
The trade-off between efficiency and independence
Professional infrastructure providers have real advantages. They can offer high-bandwidth connections, redundant power, specialized monitoring and experienced operations teams. These features are valuable for a high-throughput blockchain such as Solana, where validators need to process significant volumes of data and exchange information rapidly.
Geographic and network diversity, however, can conflict with those efficiencies. The cheapest or highest-performing infrastructure may be concentrated in a few regions and providers. A protocol that distributes stake without accounting for this pattern can create a system that is efficient during ordinary operation but fragile during unusual events.
This trade-off is not unique to crypto. Banks diversify custodians and payment processors because a single operational dependency can interrupt service across an entire business. Cloud users distribute workloads across regions and providers because a common outage can affect thousands of applications. Internet routing itself depends on multiple networks because no single path should determine whether traffic can move.
Blockchain protocols face the same engineering problem, with an added complication: the assets being secured are directly tied to consensus participation. When stake is delegated, concentration has an economic dimension as well as a technical one. A common infrastructure provider can carry a large amount of voting power even when no single validator account appears dominant.
For liquid-staking protocols, the design question is therefore broader than how to maximize staking returns. It includes how to allocate capital without creating hidden systemic dependencies. This may require accepting slightly higher operating costs, lower short-term performance or more complex monitoring in exchange for greater independence.
That choice cannot be made by infrastructure operators alone. Delegators, protocols and validator marketplaces all influence the result. If users reward only yield and reliability, allocation systems may have little incentive to pay for redundancy that becomes visible only during a failure. If protocols make infrastructure diversity a public objective, validators may have stronger commercial reasons to use separate networks and locations.
Potential paths for improvement
Marinade has not announced a corrective measure in the cited post, so any response remains a matter for future policy rather than a reported change. Several approaches could nevertheless reduce the risk.
The most direct is to introduce ASN-aware allocation limits. A delegation system could place a ceiling on the amount of stake assigned to any one ASN or set of related ASNs. Such limits would prevent one network from accumulating an outsized share, although they would need to be calibrated carefully. A strict cap could push stake toward smaller providers that are less reliable or could be difficult to enforce when operators use multiple network identities.
A second approach is to score validators according to infrastructure diversity. Instead of treating every validator as independent, the allocation system could evaluate ASN, data-center, geographic and ownership information. Stake could then be distributed across clusters with low apparent correlation.
This would require better data. ASN mappings change, validator operators may use multiple providers and ownership information is not always public. A transparent self-reporting system could help, but protocols would need ways to verify those claims. Network measurements, route analysis and independent audits could supplement operator disclosures.
Protocols could also create incentives for validators to diversify their connectivity. A validator using multiple upstream providers, separate regions or an independent bare-metal facility might receive a preference in delegation. The advantage would be that resilience becomes part of validator competition rather than an external compliance requirement.
Another option is to publish concentration dashboards. Delegators could see not only which validators receive stake, but also how that stake is distributed by ASN, location, operator and hosting environment. Transparency would allow users to make their own decisions and would make it harder for concentration to remain hidden.
The challenge is avoiding simplistic decentralization scores. A single metric can be gamed or misunderstood. Operators might move validators to separate ASNs without changing the underlying ownership or physical location. A low ASN concentration could therefore coexist with high operator or data-center concentration.
The most robust approach would combine several dimensions: validator identity, operator ownership, ASN, region, data center, cloud provider and software implementation. No model will perfectly capture real-world dependencies, but a multidimensional view is more useful than an account count alone.
Implications for liquid staking
Liquid staking protocols are becoming important coordination layers in proof-of-stake ecosystems. They aggregate user deposits, select validators and issue liquid assets that can be used elsewhere in decentralized finance. This gives them influence beyond the individual users who hold their tokens.
That influence creates an obligation to consider network-level effects. A liquid-staking protocol can improve participation by directing stake to smaller or underrepresented validators. It can also unintentionally centralize participation by favoring a narrow group of professional operators.
Marinade’s disclosure illustrates why the success of liquid staking should not be measured only by assets under management, staking yield or validator uptime. A protocol can grow its deposits and maintain strong operational performance while increasing the concentration of the infrastructure that supports the underlying chain.
The same concern applies to competing staking products and centralized exchanges. Any organization that controls a large delegation pool can materially shape validator economics. If multiple large allocators rely on the same performance rankings or provider relationships, infrastructure concentration may increase across the network even when each allocator believes it is acting independently.
This makes delegation policy a form of protocol governance. Decisions about caps, eligibility and performance scoring can affect the resilience of the entire ecosystem. Users who deposit into liquid-staking products are not merely choosing a financial wrapper; indirectly, they are participating in the selection of the infrastructure that validates transactions.
That does not mean liquid staking is inherently harmful. Delegation coordination can make staking more accessible, improve validator monitoring and distribute capital to operators that individual users would never discover. The design objective should be to preserve those benefits while making the underlying dependencies visible and manageable.
A warning for Solana’s next phase
Solana’s technical ambitions depend on more than raw throughput. As the network supports payments, decentralized finance, consumer applications and tokenized assets, reliability becomes a business requirement. Developers need confidence that transactions will continue to confirm. Financial institutions need predictable settlement. Users expect applications to remain available even when individual operators experience problems.
Infrastructure concentration is one of the risks that becomes more important as usage grows. A network can tolerate some centralization during early experimentation if operators can respond quickly and the economic stakes are limited. As more value and activity depend on the chain, the cost of correlated failure rises.
The ASN figures do not prove that Solana is currently centralized at the network level. They do show that one important stake-allocation channel contains a concentration that deserves scrutiny. The fact that the disclosure came from Marinade itself makes it more consequential. It suggests that the protocol is willing to apply the same standards to its own operations that it applies when discussing wider ecosystem risks.
The next step is measurement. The community needs clearer information about who operates validators, where they are hosted and how much stake depends on common networks. It also needs simulations and incident analysis that test what would happen if a major ASN, region or hosting provider became unreachable.
Those exercises should not be treated as criticism of individual operators. Large providers often deliver valuable infrastructure, and validators may have good reasons to use them. The objective is to understand the system’s dependencies so that operators, protocols and delegators can make informed trade-offs.
Marinade’s post offers a simple conclusion: counting validator identities is not enough. Four ASNs carrying roughly two-thirds of SAM-allocated stake is a measurable concentration, and a single ASN carrying 36.94% is a clear reason to investigate how stake is distributed beneath the surface.
For proof-of-stake networks, decentralization is ultimately about maintaining independent paths to consensus. That requires economic diversity, geographic diversity, operator diversity and network diversity. A validator set can look broad on a dashboard while remaining vulnerable to a failure in a much smaller infrastructure layer.
The significance of Marinade’s disclosure is therefore less about the identity of AS395201 than about the question it raises. If delegated stake is allocated efficiently but clusters around a few networks, can the system still be called resilient? The answer will depend on how protocols measure independence, and whether they are willing to make resilience an explicit part of the allocation process.