On 11 June 2019 we published a short article titled "On Validator Setup — Part 2" on our Medium account. It was not written for marketing. It was a technical note for other operators, spelling out the physical and network architecture we had just committed to as a brand-new validator — two datacenters, dual YubiHSM, VPN-only access, three-to-six sentries per network, active-passive failover. No clouds.
Seven years later, that post is still online, and the architecture it describes is still our floor. Forty-plus mainnets, zero slashing events, and five Lido Simple DVT Module clusters later, most of what we said in 2019 has aged cleanly. Some of it we would say more sharply today. This is what kept, what changed, and what we would do differently if we were starting over.
What we kept
The headline is boring: we did not re-platform. The exact sentences from the 2019 article — "2 physical KMS servers (one in each location) equipped with YUBIHSM. One primary and one as a backup." and "Access to our nodes is only possible through VPN connection from specific locations" — are still true in April 2026.
We kept the dual-datacenter, active-passive topology across two Tier III TIA-942 facilities in Bucharest. We kept the YubiHSM 2 as the key boundary; validator signing keys have never existed outside that boundary on our infrastructure. We kept the VPN-only access posture; there is no public ingress to any signer, and there never has been. We kept the sentinel/relayer topology — three to six sentries per network — standing between public traffic and a validator node.
The reason we kept all of that is unromantic: it worked. Zero slashing across 40+ mainnets over six years is a lot of production evidence. Re-platforming the key boundary, the network edge, or the failover model would have had to clear a very high bar, and none of the alternatives we evaluated did.
What we added between 2019 and 2023
The 2019 setup was correct for a Cosmos-ecosystem validator with a handful of chains. It needed four additions to stay correct through 2023.
- Our own AS. In 2019 we described colocated infrastructure with upstream transit. By 2024 we were operating AS211396 with our own BGP policy and 20 Gbps+ of direct peering to tier-1 carriers. The difference matters for Chainlink oracle workloads and for any chain where a 300 ms of shared-cloud jitter can push an attestation or a price submission out of the acceptance window. - Monitoring that is not just Prometheus. Prometheus on a 15-second scrape interval is far too coarse for oracle operations or for block-production timing on fast chains. We built an eBPF-based probe stack that alerts on the shape of a single oracle report cycle or consensus-vote window. Prometheus is still in our stack for the slow signals; eBPF covers the fast ones. - Chain-upgrade discipline. The 2019 article was silent on upgrade testing. Over the 2020 and 2021 cycles we made it a hard rule: every chain upgrade is applied to our internal testnet infrastructure before production, and we do not upgrade on day one unless we have personally verified the binary. - Remote signing where protocols supported it. We started routing Cosmos-ecosystem signing through threshold signers (Horcrux) as networks began supporting remote-signer interfaces. On Ethereum we moved to Web3Signer. The YubiHSM is still the key boundary; the signers are additional isolation, not a replacement.
What we added from 2023 onward
Two things changed in 2023 that forced us to extend the architecture rather than refine it.
Distributed Validator Technology (DVT) arrived on Ethereum. In September 2023 we deployed our first Obol DVT cluster on their testing phase — 1,001 validators, 3-of-4 threshold, fully up in under 48 hours. After one round of fine-tuning with the Obol team, the cluster's missed-attestation count dropped to zero.
In December 2023 we became a Launch Partner with SSV Network during its permissioned phase, running alongside Everstake, Forbole, P2P Validator and cryptomanufaktur on the public SSV staking pool. Our first 30 days on SSV delivered 99.78% uptime.
Through 2024, Lido Finance opened its Simple DVT Module. We were signed into five clusters — four with Obol (Bountiful Bison, Quixotic Quail, Unfettered Urial, Ethereal Elf) and one with SSV (Resilient Rabbit). Each operating-rules acceptance is on-chain signed and verifiable on Etherscan. DVT is the first change since 2019 where the validator key boundary itself shifted — not out of the HSM, but into a threshold where no single operator, including us, can sign alone.
Institutional traffic on Chainlink rewrote the oracle requirement. Chainlink's cross-chain standards are now in production with Swift, Euroclear, Mastercard, UBS, Fidelity International and ANZ for tokenised assets, onchain NAV and cross-chain settlement. That shifted the performance bar for a Chainlink node from "DeFi retail tolerant" to "regulated capital markets tolerant". We re-evaluated the oracle node infrastructure against that bar and kept it there. Sub-millisecond probes, sub-second data source cross-checks, HSM-backed signing. The bar moved; the architecture held.
What we would do differently if we were starting today
If we were bringing up 01node from scratch in April 2026, three things from the 2019 article would look different.
- Write the compliance track in from day one. In 2019 we wrote the architecture but did not instrument it for third-party attestation. ISO 27001 came later, ISO 9001 came later, SOC 2 Type II is in progress now. If we started today we would run SOC 2 Type I within the first six months and Type II immediately after. The controls were there in 2019; the evidence trail was not. - Key ceremony protocol in writing. Our 2019 article implied careful key handling, but we did not publish the key-ceremony document. A written, versioned ceremony protocol — generate in-HSM, never export, dual-controlled rotation, counter-signed logs — is table stakes for any institutional counterparty in 2026 and should have been written down in 2019. - FIDO2 from the start. The 2019 setup did not specify operator authentication. We now run hardware-backed FIDO2 / WebAuthn passkeys across all administrative systems and explicitly disallow SMS-based 2FA. If we were starting today we would bake that in from day one, not retrofit.
What is not in the architecture
An equally useful list is what we deliberately did not add. We did not move validator signing to a shared public cloud, ever. We did not add a custody product that would put us on the wrong side of the client's key boundary. We did not emit a token of our own. We did not take on MEV integrations where the operational model was not transparent.
Some of that was technical discipline. Some of it was a bet that in the five-year window the institutional requirement would arrive, and that the operators who had pre-committed to sovereign infrastructure would be the short list when it did. The bet landed: ETH staking ETFs now pay validator-earned yield, OCC trust charters have expanded, and MiCA enforcement begins fully on July 1, 2026. Each of those events pulled the institutional bar closer to the posture we had in 2019.
Why this article exists
Marketing teams write security pages that describe what a company would like to be. Engineers write posts like the 2019 Medium article, which describe what actually runs.
We wrote the 2019 post for ourselves and for other operators, and we are writing this one for the same audience, plus one: the counterparty deciding whether to use 01node for regulated staking infrastructure. If that is you, every claim on this page is either verifiable on-chain, available on our /operator-credentials page with a third-party link, or listed on /security with an explicit status of "active", "in progress" or "planned". The boundary between "what we have" and "what we are building" is a bright line in this architecture, and it stays a bright line on our website.
Seven years is not a moat by itself. Seven years of not slashing, not re-platforming the key boundary, and not overclaiming the controls — that is a moat.