Validator operations were a fundamentally different discipline in 2019 than they are in 2026. Most of the change happened quietly. The validator software you ran in 2019 still works, the consensus protocols still validate, and the economics still apply. But every layer of how we now operate validators at 01node — hardware, network, key boundary, monitoring, compliance, support — has been reshaped by what the institutional capital flowing into proof-of-stake networks now expects.
This guide is the consolidated picture. It is written for two audiences: the engineer who wants the technical depth, and the counterparty (treasurer, fund manager, custody integrator) who needs the operational framing without the implementation detail. We have tried to make both layers legible without compromising either.
Where things stand on each topic at 01node is documented at /security with explicit active / in-progress / planned tagging — this article is the explanation of why each piece is structured the way it is, not a marketing description of capability.
What changed between 2019 and 2026
Three forces reshaped validator operations across the past seven years. They were not synchronous, and the operators who treated them as separate problems are not the operators running production today.
The first force was the growth of stake into amounts that demanded institutional treatment. In 2019 a validator with $100M in delegated stake was an outlier. By 2026, a single Lido Simple DVT cluster routinely holds an order of magnitude more, and a Babylon Finality Provider holds Bitcoin denominated in low-thousands. At those numbers, the cost of getting key management wrong is not measured in slashing percentages. It is measured in nine-figure liabilities to delegators or to a regulator.
The second force was the transition from single-node validators to threshold and distributed signers. Horcrux became a standard for Cosmos-ecosystem signing in the 2020-2022 window. Web3Signer with slashing-protection databases became the default Ethereum validator companion. Distributed Validator Technology (Obol, then SSV) shipped in 2023, and Lido formalised the Simple DVT Module in 2024. By 2026, "the validator key" as a single artefact stored on a single machine is not how serious operators talk about validator infrastructure.
The third force was the arrival of regulated capital. Spot Ethereum ETFs paying staking yield, OCC trust charters expanding for crypto custody, MiCA enforcement starting July 2026 — each of these pulled validator operations into the same compliance perimeter as traditional financial infrastructure. SOC 2 Type II is now the table-stakes question for institutional onboarding. ISO 27001 is a precondition. Pen-test cadence is itemised in vendor questionnaires.
These three forces interact. Growth in stake forces hardening of the key boundary. Hardening of the key boundary requires a multi-node architecture that no single operator action can compromise. The multi-node architecture is what regulated capital is willing to underwrite. An operator that treated any of the three as optional in 2019 is not running the architecture institutional capital evaluates in 2026.
Hardware: bare metal still wins
Public-cloud validators are operationally simpler. They are also the largest source of correlated failures during chain incidents. The shared transit, shared DNS, shared kernel scheduling, and shared neighbouring tenants of any cloud region make the validator susceptible to events that have nothing to do with the operator's discipline.
A validator on bare metal has its own hardware, its own routing, and its own physical perimeter. A double-block scenario triggered by a kernel bug at a single cloud provider, the kind that occasionally takes out 30% of validators on a chain at once, does not happen to operators with diverse silicon and dedicated routing.
At 01node, every chain we validate runs on owned hardware in two Tier III TIA-942 datacenters in Bucharest. The two datacenters are physically separate, on different power grids, with diverse upstream transit. We operate active-passive across them with rehearsed manual failover. Hardware is AMD EPYC for compute, ECC DDR for memory, enterprise NVMe with ZFS for storage — chosen for sustained-throughput characteristics rather than peak benchmarks.
The bare-metal posture predates the institutional argument. We described the same architecture in our 2019 Medium post. What changed is that the cost of provability now favours bare metal even more — when an auditor asks "where does the signing key live", "in our YubiHSM in datacenter A, with a hot replica in datacenter B" is a single-sentence answer. "On a virtual machine in cloud region X, in a key vault that the cloud provider also has access to" is an asterisk that takes a paragraph to defend.
Network: own ASN, own routes, own DDoS posture
A validator is a network endpoint before it is a signer. Block propagation, peer discovery, oracle data ingest, and consensus message exchange all happen across network paths that the operator either controls or rents.
We operate AS41536 with our own BGP policy. This is not a marketing line. It means our routing decisions are published to the global routing table, our peering relationships with tier-1 carriers are direct, and our 20 Gbps+ of transit is not shared with neighbouring tenants the way cloud egress is. When a Chainlink oracle round needs to publish a price within a 250-millisecond window, the difference between dedicated peering and best-effort cloud transit is measurable in missed reports.
DDoS mitigation lives at the facility boundary, not at a CDN we trust to forward traffic to us. We have 140 Gbps of layer 3/4 mitigation upstream — sufficient for the volumetric attacks that have been used against validator infrastructure in 2024 and 2025. Behind that boundary, we run a sentinel topology: 3 to 6 sentries per chain stand between public traffic and the signing nodes. Public RPC and consensus traffic terminates at sentries; signing nodes never receive direct inbound from the open internet.
Key management: the only thing that matters
If a validator does one thing right, it has to be key management. Everything else is recoverable. A leaked or duplicated signing key is not.
The 01node key boundary has been YubiHSM hardware modules since June 2019. The 2019 architecture had two physical KMS servers, one in each datacenter, both equipped with YubiHSM and operating in primary-and-hot-backup configuration. That part is unchanged in 2026. What we layered on top in the years since is what makes the architecture institutional-grade today.
For Cosmos-ecosystem chains, we run Horcrux as a 2-of-3 threshold signer. Three signing nodes participate in any signature; two are required for a valid signature; no single node holds the full key. The signing key, in the strict mathematical sense, never exists on any one machine — only shards do. The result: even an attacker with full root on one signing node cannot produce a signature for any chain we validate. They would need simultaneous root on a second node, in a different physical and network environment, plus the ability to coordinate within the protocol's signing window.
For Ethereum, we run Web3Signer as the slashing-protected remote signer. Web3Signer maintains a local slashing-protection database that records every block, attestation, and committee vote it has signed. Before producing any signature, it checks that the new request would not duplicate or contradict a prior one. This is the protection that prevents double-sign events even after a validator client restart, a state desync, or a network partition that healed in an unexpected way. It is the layer that, in our reading, the team in our anonymised double-sign anecdote (see "Why a Validator Is Not a Server") had not implemented when they tried to run their own validator.
For Distributed Validator Technology on Ethereum, we participate in 5 Lido Simple DVT Module clusters — 4 with Obol, 1 with SSV. Each of those clusters is itself a threshold-signing arrangement across multiple operators. We are one operator in each. This is the layer above our internal threshold signing: even if our entire infrastructure were compromised in a single coordinated event, the DVT clusters we participate in would not produce a slashable signature without two or more of the other operators agreeing — and we agree to slashable signatures only by following the slashing-protection rules we have already validated against our own infrastructure.
Operator authentication for ops staff is FIDO2 / WebAuthn — hardware passkeys across all administrative systems. SMS-based two-factor authentication is explicitly disallowed; we treat SMS as a public communication channel, not an authentication channel.
Monitoring: sub-second observability
Standard validator monitoring is Prometheus on a 15-second scrape interval feeding Grafana dashboards. This is fine for slow signals. It is far too coarse for the workloads that move proof-of-stake economics in 2026.
A Chainlink oracle report cycle that misses by 200 milliseconds is, from a delegator's perspective, a missed report. A Solana validator that produces vote credits at 96% instead of 99% loses material reward income for delegators. A Cosmos validator that drops a block in a fast-finality chain like Sui or Aptos is contributing to network finality latency in a way that cumulative monitoring summaries simply do not surface.
We built our monitoring stack around eBPF — the in-kernel programmable observability framework that Linux has matured over the past five years. Our eBPF probes alert on the shape of a single oracle report cycle, not on aggregate counters at a 15-second granularity. They detect the early signs of validator client desync seconds before it would surface as a missed attestation. The full architecture is documented at /blog/zero-latency-monitoring-ebpf.
Prometheus still exists in our stack. It still answers slow questions well. But the fast questions — "is the validator about to miss" instead of "did the validator miss" — are the ones that determine whether we operate at the institutional bar or below it.
Compliance: the part regulated capital reads first
Through 2023, compliance for validator operators was largely self-asserted. Operators put "ISO 27001 certified" on their site and rarely had to produce the certificate. By 2026, every institutional onboarding starts with a vendor-risk questionnaire that itemises the compliance evidence required: certificate validity period, audit firm, scope statement, last surveillance audit date, exception list.
ISO 27001 and ISO 9001 are now the floor. They cover information security management and quality management respectively. They are necessary but not sufficient — by 2026 every serious validator operator has both. The differentiator is what comes next.
SOC 2 Type II is the new institutional bar. The Type II part matters: SOC 2 Type I is a point-in-time control design assessment, but Type II is a 6-12 month observation window in which the operator demonstrates that the controls actually run. From engagement to a useful Type II report is typically 12-18 months — which is why we treat SOC 2 as a multi-year track item on the roadmap rather than a quick win. ISO 27001 maps a majority of the SOC 2 Security common criteria, which materially reduces the gap, but the observation window is a pure-time investment that cannot be compressed.
For European operators, MiCA — the Markets in Crypto-Assets regulation — adds the CASP authorisation track on top. Full MiCA enforcement begins July 1, 2026. Operators serving European institutional clients beyond that date need either CASP authorisation or a clear story for why their service does not fall in scope.
Penetration testing on an annual cadence by a Tier 1 vendor (NCC Group, Trail of Bits, Cure53) and a public bug bounty programme (typically Immunefi for crypto infrastructure) round out the assurance posture. Both are now standard line items in vendor questionnaires.
Operations: the support model
Validator operators with thousands of delegators have a hard time providing meaningful per-delegator support. Validator operators with institutional clients cannot avoid it. The institutional support model that has emerged across 2024-2026 has three structural elements.
First, named owners. Every institutional client has a named technical lead and a named commercial owner on the operator side. There is no ticket queue. The technical lead has context on the integration; the commercial owner handles contract, invoicing, and roadmap alignment. Both are reachable by encrypted channel within the response SLA.
Second, defined incident severity tiers with response SLAs. P1 (production-impacting, money-on-the-line) gets a sub-15-minute acknowledgement. P2 (degradation but not outage) gets sub-1-hour. P3 (informational, scheduled work) gets next-business-day. Every P1 and P2 incident receives a written post-mortem within 5 business days.
Third, quarterly executive reviews. A 90-minute structured review covering performance versus SLA, incidents and root causes, roadmap alignment, and upcoming protocol upgrades that affect the client's stack. This is not a sales call. It is the operator and the client jointly auditing the relationship at a cadence the client's own internal governance can rely on.
The full onboarding flow that gets a new institutional client from first call to live (typically 4-8 weeks depending on the client's compliance review pace) is documented at /docs#integration-onboarding.
Economics: commission, MEV, restaking, the math
Validator economics in 2019 were simple. Delegators paid a commission percentage on inflation rewards. Operators ran nodes for the commission revenue minus operating costs.
Validator economics in 2026 have three additional layers.
Maximal Extractable Value (MEV) participation is now meaningful. On Ethereum, validators participating in MEV-Boost capture additional yield from block-construction auctions. On Solana, Jito-based vote validators capture tips. The honest framing for delegators is that MEV is a real revenue source — but it is also volatile, ethically contested in some configurations, and has its own operational risk if implementation is sloppy. We participate in MEV-Boost on Ethereum with a published relay set; we make our policy public.
Restaking is the second layer. EigenLayer on Ethereum, Babylon on Bitcoin, and similar systems on Cosmos chains let staked tokens be reused to secure additional services in exchange for additional rewards. The trade-off is more slashing surface area: a misbehaviour on a service you have restaked to can affect your underlying stake. Operators who treat restaking as a free yield boost are mispricing the slashing exposure. Operators who treat it as a real second-domain operational risk are pricing it correctly.
Distributed Validator Technology fee structures are the third. In a Lido Simple DVT cluster, fees are split among the operators in the cluster according to the protocol's rules. The operator no longer captures 100% of the validator commission on stake delegated to the cluster — they capture a share, weighted by their participation. This is fundamentally an alignment mechanism: it makes operators care about other operators' performance, because their revenue depends on it.
Across these three layers, the simple "what's your commission rate" question has become an inadequate proxy for actual yield delivered. A 5% commission validator with 99.99% vote credit completion, MEV-Boost participation, and a clean restaking posture delivers more to delegators over a year than a 0% commission validator with 96% vote credit completion and no second-layer revenue.
Risk: the slashing surface, expanded
In 2019 the slashing surface was small. Two events on most Cosmos chains: double-sign and extended downtime. By 2026 the surface has expanded along multiple axes that operators now actively manage.
Double-sign remains the worst event. Threshold signing and slashing-protection databases now make double-sign operationally implausible — but only if both layers are correctly deployed. The team in our anonymised double-sign story had neither.
Extended downtime slashing has tightened. Several chains now apply slashing for shorter downtime windows; some extend the slashing penalty if the validator is offline during a critical block production window.
Restaking introduces cross-domain slashing. A validator restaking ETH to secure an EigenLayer Actively Validated Service can have their underlying ETH slashed for misbehaviour on the AVS, even if the validator itself never double-signed on Ethereum. This is what we mean when we say restaking is not free yield.
Reporting-based reputational reduction (Sui validators losing reward share via peer reports, for example) is not slashing in the strict sense, but functionally produces the same outcome — reduced rewards to delegators on poorly-behaved validator infrastructure. We treat reporting-score impact as a slashing-equivalent for operational purposes.
Finality Provider slashing on Babylon spans Bitcoin and Cosmos signature domains. A Finality Provider that double-signs on a Babylon Secured Network can be slashed in BBN and have the BTC stake delegated to them affected. This is multi-chain operational risk in the most literal sense.
What separates institutional operators
After all the architecture and process is in place, what actually distinguishes the operators that institutional capital underwrites from the rest? In our reading, six things.
- Pre-commitment to the architecture, not retrofit. Operators that documented YubiHSM and dual-DC active-passive in 2019 did not have to upgrade their posture in 2024 to win institutional business. They had to add evidence, not architecture. - Zero slashing track record long enough to mean something. A six-month zero-slashing record proves nothing. Six years across forty mainnets demonstrates discipline at the operational depth that produces it. - A line between active, in-progress, and planned controls that holds up to a vendor questionnaire. Marketing pages claim everything; honest pages claim only what is operational and tag the rest accurately. Vendor risk teams learn to spot the difference within minutes. - Named technical and commercial owners reachable by encrypted channel. No ticket queue, no shift-handoff loss of context, no "send an email and we will get back to you within 5 business days". - Public Documentation that engineers actually wrote. Marketing copy reads as marketing copy. Engineering documentation reads as engineering documentation. A counterparty's technical team can tell which they're reading by the second paragraph. - Compliance velocity. Not whether the operator has SOC 2 Type II today, but whether they have a credible engagement, a known auditor, a target observation window, and an honest gap assessment from their existing ISO posture.
What's coming 2026-2027
Three trends will reshape validator operations again over the next 18 months. None of them are speculative; all are visible in the institutional pipeline today.
First, SOC 2 Type II becomes a hard requirement for Tier 1 TradFi onboarding. By mid-2027, validator operators without a Type II report or a credibly-engaged Type II observation window will not pass the floor of vendor risk for Fidelity, BNY, State Street, or comparable institutions. The operators who started SOC 2 engagement in 2025 will be in the consideration set; the ones who started in late 2026 will not.
Second, MiCA CASP authorisation becomes the EU operating licence. After July 2026, EU institutional clients will need their validator operators to have CASP authorisation or a clear scope-out argument. The CASP application process takes months; the operators that started in 2025-2026 will be authorised when the requirement arrives.
Third, zero-knowledge proofs of validator behaviour will move from research to production. Several teams are working on succinct proofs of correct attestation, correct block production, and correct slashing-protection enforcement. When these ship in production, they will allow validators to publish cryptographic evidence of correct behaviour rather than rely on operator attestation alone. Operators who already operate at a level that produces such evidence will benefit; operators who do not will face a credibility gap.
How 01node is positioned
We have been operating bare-metal validator infrastructure on YubiHSM-backed keys in two Tier III datacenters since June 2019. We documented that architecture publicly the same year. We added Horcrux threshold signing in the 2020-2022 window, Web3Signer with slashing protection on Ethereum, eBPF-based monitoring through 2023-2024, and DVT participation across the 2023-2025 window. We are signed into 5 Lido Simple DVT clusters, are an active Babylon Finality Provider since Cap-2, have been a Chainlink Node Operator and Channel Partner since September 2020, and have been a Wormhole Guardian since December 2020.
The compliance roadmap is on /security with explicit status: ISO 27001 active, ISO 9001 active, StakingRewards AA active, SOC 2 Type II planned for the 2026-2027 observation window, MiCA CASP planned, Tier 1 pen-test planned, Immunefi bug bounty planned. Every claim is tagged accurately. Nothing is overclaimed.
The operations model is named owners, sub-15-minute P1 acknowledgement, quarterly executive reviews, and PGP-encrypted credential delivery. The full onboarding flow is at /docs#integration-onboarding.
We are publishing this guide because the criteria above are auditable. If you are evaluating us against another operator, the comparison should not turn on marketing claims; it should turn on which operator can produce the evidence on each line. We are happy to be evaluated on that basis. The trust pack is delivered under NDA on request — request it at [email protected].