How ETF Issuers Should Evaluate Validator Infrastructure: An Operational Guide

Post preview image

Series: Validator Playbook

The Validator Playbook is P2P.org's infrastructure education series for institutional Ethereum operators. Each article addresses a specific operational, risk, or governance decision that validator infrastructure teams, staking product managers, ETF issuers, custodians, asset managers, and risk committees face when building or evaluating proof-of-stake infrastructure.

Previously in the series: Ethereum Validator Consolidation After Pectra: What Institutional Operators Need to Decide


Learnings for Busy Readers

What Changed on March 17, 2026

For over a year, the primary obstacle to staking-enabled ETF structures in the United States was legal uncertainty about whether staking rewards constituted securities. That uncertainty was resolved in a single regulatory event.

The SEC and CFTC issued a joint interpretive release on March 17, 2026, that classified staking rewards from 16 named digital commodities, including ETH, as non-securities, confirming that protocol staking is not a securities transaction and that staking rewards do not create a securities-type relationship. The interpretive release explicitly covers solo, self-custodial, custodial, and liquid staking models. None of these structures triggers securities law obligations. Source: Jenner & Block LLP

The regulatory shift formalized what the market had already begun pricing in. BlackRock debuted the iShares Staked Ethereum Trust on Nasdaq on March 12, 2026, with $107 million in seed assets, staking 70 to 95% of its holdings and distributing monthly protocol-attributed participation rewards. The March 17 ruling then removed the remaining legal uncertainty that had kept other issuers on the sidelines. US spot ETH ETFs now hold approximately $12 billion in combined assets with roughly $11.6 billion in cumulative net inflows since launch. Source: CoinDesk

The ruling also expanded the addressable market for institutional staking infrastructure well beyond Ethereum. The commodity classification means compliance departments no longer have such grounds to restrict exposure based on securities risk, applying to proof-of-stake assets across the named 16 and validating existing staking products, including ETFs and exchange-based products. The addressable market for institutional staking infrastructure expanded materially on March 17. Source: Bitcoin Foundation

For ETF issuers that have not yet built a staking-enabled structure, one major legal barrier has been removed. What remains is an operational and procurement decision: which validator infrastructure supports a regulated product at the scale, compliance posture, and risk profile an ETF sponsor requires.

Why Validator Infrastructure Is Now a Regulated Product's Backend

The framing that most ETF issuers still apply to validator infrastructure is wrong. They treat it as a utility service purchased at a rate. It is not.

Staking-enabled spot ETFs do not just give institutions exposure to ETH or SOL. They create a structural, recurring source of validator demand that flows to compliant, non-custodial infrastructure underneath the product wrapper. ETF issuers and their custodians source validator infrastructure the way they source prime brokerage: on counterparty risk. Source: P2P.org Blog

That framing has direct operational implications. When a validator provider goes offline, misses attestations, or suffers a configuration error, the protocol responds with penalties. Those penalties reduce the participation rewards that the ETF distributes to shareholders. A validator infrastructure failure is not an internal IT incident. It is a fund-level performance event with a direct impact on the product the issuer has marketed to regulated investors.

For regulated financial institutions and custodians, third-party infrastructure providers sit inside the same vendor due diligence process as any cloud provider or payment processor. Before a contract clears internal security review, the provider typically needs to demonstrate recognized certifications, with SOC 2 Type II and ISO 27001 coming up most consistently because they map directly onto the control categories these institutions already audit internally across access management, incident response, availability, and data integrity. Source: Chainstack

The procurement workflow is the one ETF issuers already know. The evaluation framework is not new. What is new is that validator infrastructure now belongs inside it.

The Four Dimensions of ETF-Grade Validator Infrastructure Evaluation

The four dimensions ETF issuers should run against any validator provider before delegating staking exposure inside a regulated product structure.

1. Uptime and Attestation Performance

Validator infrastructure for an ETF product requires 24/7 operational continuity without exception. When a validator goes offline, it misses block proposals and attestations. Those missed events reduce protocol-attributed participation rewards directly.

The evaluation question is not whether a provider advertises high uptime. It is whether the provider can evidence it across an independently verifiable observation period. Commission rates are the most visible differentiator between providers and the least informative. A provider with a higher commission rate, strong uptime history, and documented slashing protection will consistently produce better outcomes for an ETF product than a provider with a lower rate on shared cloud infrastructure with no operational redundancy.

For ETF issuers, the specific questions to put to any validator provider are:

What is the documented uptime rate across the past 12 months, and is it independently verifiable?

Is infrastructure distributed across multiple geographic regions and cloud providers, or concentrated in a single data center?

What is the failover architecture, and has automated failover been tested under production conditions?

What does the monitoring stack look like, and how are anomalies escalated?

2. Slashing Protection Architecture

Slashing is the protocol-level penalty applied to validators that behave maliciously or experience specific configuration failures. For an ETF product, a slashing event is a capital loss event that the issuer must disclose and that directly reduces net asset value.

How a provider manages validator signing keys is one of the most critical security considerations most critical security consideration. Leading providers use hardware security modules for key storage and multi-party computation for key operations, ensuring that no single individual or process can unilaterally sign a transaction.

The slashing risk that ETF issuers need to understand is not just individual validator failure. It is a correlated failure. If a provider operates a large concentration of an issuer's validator set on a shared infrastructure stack, a single software bug, cloud region outage, or configuration error can affect multiple validators simultaneously. The correlation penalty on Ethereum scales with the total ETH slashed across the network in the surrounding period, meaning correlated failures produce penalties that are materially larger than the sum of individual events.

Questions for provider evaluation:

Does the provider use hardware security modules and multi-party computation for key operations?

What is the slashing incident history across the provider's full validator set?

What is the provider's approach to client diversity across consensus implementations?

How are signing keys isolated across different client accounts?

P2P.org has maintained a zero-slashing-incident track record since 2018 across 40+ proof-of-stake networks, with dedicated hardware, geographic distribution, and client diversity across consensus implementations as standard infrastructure architecture.

3. Non-Custodial Architecture and Key Control

For ETF staking structures, non-custodial architecture is not a preference. It is a structural requirement.

Non-custodial staking infrastructure is suitable for ETF staking because it gives the issuer, not the infrastructure provider, control of client assets. The institution retains control of private keys and withdrawal credentials at all times. This model reduces counterparty risk and aligns with most institutional custody mandates.

The custody question is the most consequential due diligence item for an ETF sponsor's legal team. In a custodial staking arrangement, the provider holds private keys and withdrawal credentials. In the event of provider insolvency, regulatory enforcement, or operational failure, the assets may be inaccessible or treated as part of the provider's estate. That custody risk is not acceptable inside a regulated ETF structure.

Issuers should confirm explicitly:

Does the provider take custody of private keys or withdrawal credentials at any point?

Who holds withdrawal address control throughout the staking lifecycle?

What is the technical mechanism through which the issuer retains key custody while the provider operates validation?

How does the provider's custodian integration work, and which custodians have native integrations?

4. Compliance Attestations and Vendor Risk Program Fit

SOC 2 Type II provides audited evidence that security controls actually work, measured continuously over a three to twelve-month observation period rather than a single point-in-time assessment. Together with ISO 27001, these certifications answer the due diligence requirements of institutional clients who need institutional-grade security assurances before routing assets through validator infrastructure.

For ETF issuers operating under fiduciary obligations, a validator provider without SOC 2 Type II attestation creates a gap in the issuer's own vendor risk program. The compliance team cannot map an unattested provider's controls onto the institution's internal security framework. The deal stalls or the provider is excluded from consideration.

The compliance evaluation should include:

Current SOC 2 Type II report: scope, observation period, and any exceptions noted

ISO 27001 certification status and Statement of Applicability

Jurisdictional compliance posture for the markets the ETF will serve

Business continuity and disaster recovery documentation

Incident notification and reporting commitments under contract


The institutional digital asset space moves fast.

Our subscribers get structured analysis across staking, DeFi vaults, and regulation through DeFi Dispatch, Institutional Lens, DeFi Infrastructure for Institutions, and Legal Layer.

No noise. Just the signals that matter.

Subscribe to the newsletter at the bottom of this page.

The ETF Validator Infrastructure Evaluation Checklist

The checklist below is structured for the procurement motion ETF issuers already run for other regulated infrastructure counterparties. It is organized by evaluation category, not by provider marketing claims.

Operational performance

[ ] Documented uptime rate across a minimum 12-month independently verifiable observation period

[ ] Multi-region, multi-cloud or bare-metal infrastructure with no single geographic concentration

[ ] Automated failover with documented recovery time objective

[ ] 24/7 monitoring with defined escalation protocols and incident notification timelines

Slashing protection

[ ] Zero or documented-near-zero slashing history across the full validator set, not just client-specific validators

[ ] Hardware security module used for key storage with multi-party computation for key operations

[ ] Client diversity across consensus implementations (minimum two consensus clients in production)

[ ] Documented approach to isolating signing keys across client accounts

Custody and key control

[ ] Explicit contractual confirmation that the provider does not take custody of private keys or withdrawal credentials

[ ] Withdrawal address control retained by the issuer or designated custodian throughout

[ ] Native integrations with the issuer's existing custodian(s)

[ ] Clear technical documentation of the key custody architecture

Compliance attestations

[ ] Current SOC 2 Type II report: read the report’s scope and exceptions rather than filing it without review

[ ] ISO 27001 certification with current Statement of Applicability

[ ] Jurisdictional compliance documentation for relevant markets

[ ] Business continuity and disaster recovery plans reviewed and tested

[ ] Contractual incident notification obligations confirmed

Counterparty risk

[ ] Provider concentration across the issuer's validator set assessed and within acceptable limits

[ ] Fourth-party dependencies (cloud providers, infrastructure subcontractors) documented

[ ] Provider financial standing reviewed

[ ] Governance and key personnel stability assessed

Reporting and integration

[ ] Validator-level reporting available for NAV calculation and shareholder distribution workflows

[ ] Audit trail documentation compatible with internal compliance reporting requirements

[ ] API or custodian integration confirmed for reward attribution and reconciliation

What Correlated Failure Risk Means for ETF Products

One risk category that most ETF issuers underweight is provider concentration. A large staking position delegated entirely to a single validator provider on a shared infrastructure stack introduces correlated failure exposure that individual uptime statistics do not capture.

As institutions deploy into staking, the infrastructure requirements extend beyond standard validator operations to include actively validated service participation, slashing risk management across multiple protocols, and more complex reporting requirements. Source: Bitcoin Foundation

For an ETF product, correlated failure has three forms that the issuer's risk committee needs to evaluate:

1. Infrastructure concentration

If the provider runs all of an issuer's validators on the same cloud region or software stack, a single outage affects the full position simultaneously.

2. Network-level concentration

If the issuer's provider controls a large share of total staked ETH on the network, a provider-wide failure triggers network-level events including delayed finality and emergency protocol responses that affect every participant.

3. Client concentration

If the provider runs a single consensus client implementation across its full validator set, a client-specific bug affects all validators simultaneously. Client diversity across implementations is the mitigation, not a preference.

Risk committees evaluating validator providers should request explicit documentation of the provider's infrastructure architecture, client diversity posture, and concentration limits per client account.

Key Takeaway

The March 2026 regulatory shift transformed staking-enabled ETFs from a compliance question into an operational one. For custodians, asset managers, ETF and ETP issuers, treasury teams, staking product managers, and risk committees, the validator infrastructure decision is now a counterparty risk decision that belongs inside the same procurement framework applied to prime brokers and custodians.

The evaluation framework is built on four dimensions: uptime and attestation performance evidenced over a verifiable observation period; slashing protection architecture grounded in hardware security modules and client diversity; non-custodial key control that keeps withdrawal credentials with the issuer throughout; and compliance attestations, including SOC 2 Type II, that fit into the institution's vendor risk program. Rate optimization is the last consideration, not the first.

Institutions that build validator infrastructure evaluation on operational commitments rather than headline rates are better positioned to protect the regulated product their investors hold.

To explore how P2P.org supports ETF issuers and institutional staking programs with non-custodial validator infrastructure, visit p2p.org/networks.

Frequently Asked Questions (FAQ)

What did the March 2026 SEC and CFTC ruling change for ETF issuers evaluating staking infrastructure?

The joint interpretive release issued on March 17, 2026, classified staking rewards from 16 named digital commodities, including ETH as non-securities. The ruling explicitly confirmed that protocol staking is not a securities transaction and that staking rewards do not create a securities-type relationship between validators and token holders. For ETF issuers, this removed the primary legal basis on which institutional compliance departments had restricted staking-enabled product structures. Compliance officers who had blocked staking ETF development on securities grounds can no longer cite that uncertainty. The ruling validated existing staking ETF products and cleared the approval path for new ones across the 16 named assets. The operational and procurement question is all that remains.

Why does non-custodial architecture matter specifically for ETF staking products?

In a custodial staking arrangement, the validator provider holds private keys and withdrawal credentials on behalf of the client. In the event of provider insolvency, regulatory enforcement action, or operational failure, the staked assets may be inaccessible or treated as part of the provider's estate. For an ETF product operating under fiduciary obligations, that counterparty exposure is not acceptable. Non-custodial architecture means the issuer or its designated custodian retains control of private keys and withdrawal credentials throughout the staking lifecycle. The validator provider operates the consensus infrastructure but cannot access or move the underlying assets. This model aligns with most institutional custody mandates and is the structure that regulated ETF products require.

What compliance attestations should ETF issuers require from a validator provider?

SOC 2 Type II is the baseline. It provides independently audited evidence that a provider's security and operational controls function as designed, measured over a continuous observation period rather than a single point-in-time assessment. Issuers should read the report for scope and any noted exceptions rather than filing it as received. ISO 27001 certification adds a governance layer, covering the policies and risk management processes that define how the provider protects its information assets. Issuers operating across European markets should also assess provider compliance posture against DORA and MiCA requirements. Providers that cannot produce current attestations create a gap in the issuer's own vendor risk program that the compliance team will flag during internal review.

How should ETF issuers think about provider concentration risk?

Delegating a large staking position entirely to a single validator provider on a shared infrastructure stack introduces correlated failure exposure that individual uptime statistics do not surface. If a provider's infrastructure fails across a cloud region, all validators in that region fail simultaneously. If a provider uses a single consensus client across its full validator set, a client-specific bug affects all validators at once. At the network level, a provider controlling a large share of total staked ETH introduces systemic exposure that affects all participants in a network-level event. Risk committees should request explicit documentation of a provider's infrastructure architecture, client diversity posture across consensus implementations, and concentration limits per client account. These are not secondary considerations. They belong in the same risk model as individual validator uptime.

What is the difference between how ETF issuers should evaluate validator infrastructure versus how other institutional stakers do?

The evaluation framework is similar in structure but different in stakes. Any institutional staker should assess uptime history, slashing protection, key custody architecture, and compliance attestations. For ETF issuers specifically, the consequences of infrastructure underperformance are fund-level events: reduced participation rewards that flow directly to shareholder distributions, potential NAV impacts that require disclosure, and vendor risk program requirements that apply to all regulated counterparties. The validator provider sits inside the ETF's operational stack in the same category as a prime broker or custodian. The procurement standards that apply to those relationships apply here. Rate optimization is relevant but secondary. Operational commitments, compliance standing, and counterparty risk documentation are the primary evaluation criteria.

How does Ethereum validator infrastructure differ from Solana validator infrastructure for ETF staking products?

The two networks have structurally different validator economics and operational profiles that shape how an issuer provisions infrastructure for each. Ethereum validators operate in fixed stake units with an activation and exit queue, while Solana validators stake across variable delegation amounts with different unbonding mechanics. Protocol-attributed participation reward rates also differ: Solana runs at approximately 6% to 7% gross versus Ethereum's approximately 3.1% to 3.3% at current network conditions. For multi-asset staking ETF products, these differences are structural inputs to infrastructure provisioning and reward distribution design, not comparable rates on a single scale. Issuers building multi-network staking products need provider infrastructure and reporting capability that handles both networks independently, with validator-level reward attribution for each.


About P2P.org

Founded in 2018, P2P.org helps institutional capital protect digital asset yield across non-custodial staking infrastructure and curated DeFi strategies. With over $10B in assets secured and operating on 40+ proof-of-stake networks, P2P.org maintains a zero-slashing-incident track record, is trusted by over 190 institutional clients and is SOC 2 Type II attested. To explore how P2P.org can support your institution's staking or DeFi infrastructure needs, get in touch with our team.


Disclaimer

This material is provided for informational purposes only and does not constitute investment, financial, legal, or tax advice. P2P.org accepts no liability for any actions taken based on it. Latency and performance figures referenced are estimates based on internal benchmarks and may vary depending on network conditions, geography, and client infrastructure. Past performance is not indicative of future results.

Subscribe to P2P-economy

Get the latest posts delivered right to your inbox

Subscribe
Read more