Validator & RPC Infrastructure
Institutional Staking Infrastructure

“Validated for
Confident Decisions”

FP Validated is a blockchain infrastructure service provider that aims to enable the growth and maturation of digital asset networks.
Model
Validator · RPC
Footprint
5 providers
Posture
SOC 2 / ISO 27001
Version
2026.6
1
Rule above all — stop before restarting any active signer
0
Validator signing keys exposed on a server
2
Planes — control and workload, never co-located
100%
Changes reconciled & auditable through GitOps
↓ Scroll
01 — Vision

Validator as a Prepared & Trusted Partner for builders & institutions.

Validators form the backbone of every protocol, providing the foundational layer where new value is first generated. FP Validated delivers robust, institutional-grade infrastructure that enables builders and institutions to scale digital asset networks with confidence.

02 — Footprint

Live Today

Capacity is intentionally distributed across independent providers, eliminating reliance on any single vendor as a potential point of failure.

Azure AKS · Management plane Argo CD · Vault · Observability GitOps fp:* summary OVH Cluster · k3s workload plane Encrypted private overlay OVH Worldstream Azure LA Cherry
14
Workload nodes — all Ready
5
Cloud providers
24
Chain networks operated
99.9%+
Effective uptime
How we're built differently
Signing Model
FP ValidatedThreshold Signing
Common SetupSingle Key File
Active Keys in K8s Secrets
FP ValidatedNever
Common SetupFrequently
Control vs Workload
FP ValidatedSeparated Planes
Common SetupCo-located
Provider Diversity
FP Validated5 Providers · Multi-region
Common SetupSingle Provider
Change Traceability
FP ValidatedGitOps + Audit Evidence
Common SetupManual / Ad-hoc

Comparison reflects architectural posture, not vendor benchmarks. “Common Setup” = a typical single-cluster, single-provider validator deployment.

03 — Team

Who We Are

FP Validated has been operating since 2024, but 2026 marked a major inflection point in its growth. Through the acqui-hire of leadership and core talent from A41, formerly one of Asia’s largest validator companies, FP Validated began scaling its team and infrastructure more aggressively, rapidly building an institution-grade operating foundation backed by veteran SREs with experience operating hundreds of nodes under a SOC 2-compliant environment.

With this foundation, FP Validated is expanding its AUS rapidly and is already working with institutions, VCs, and companies on white-label validator offerings and technical supports. As builders and institutions increasingly seek secure, scalable, and compliance-ready access to staking and blockchain infrastructure, FP Validated is positioned to become one of the most "Prepared and Trusted" validator partners in the global market.

Node operations team · 5 members
Jaehwan Jeong
Co-founder & Head of Validator
Former Head of Validator Governance at A41.
Hyuksoo Jang
Validator Advisor & Tech Researcher
Former Head of Validator and Tech Lead at A41; Former Cloud Architect Engineer at Samsung SDS Research / Cloud Business Division.
Hyunmin Kim
SRE
Former SRE at A41; Former Node Operator at Lambda 256.
Seokhyun Sim
SRE
Former Node Operator at DSRV and Shinlabs.
Yeonghyun Sim
SRE
Former Node Operator at Shinlabs.
Executive & research team · 8 members
Namwoong Kim
Co-founder & CEO
Co-founder and Former Head of Research at A41.
Heechang Kang
Co-founder & CSO
Former Researcher at Xangle.
Jinsol Bok
Co-founder & Head of Research
Former Researcher at A41.
+ team
Additional sector-specialized researchers and data engineers across the team.
04 — Networks

What We Operate

Every network runs on a single Kubernetes-based, institution-grade operating model, covering Cosmos-SDK chains, Sui and Walrus, Canton, Ethereum and Solana, and ten mainnet EVM/RPC networks, with all workloads reconciled by Argo CD.

Validators · 14 networks
Ethereum mainnet Ethereum testnet Solana testnet Canton Splice Sui mainnet Sui testnet Stable mainnet Stable testnet Sei mainnet LayerZero DVN · mainnet Walrus mainnet Walrus testnet Initia mainnet Initia testnet
RPC · 10 mainnet endpoints
Ethereum BSC Solana Hyperliquid Avalanche Polygon Arbitrum Optimism Base Tempo
More to come
05 — Principles

Delegating stake means handing over signing authority and slashing risk. Most failures can be recovered from; double-signing or key compromise cannot. Our entire operator architecture is built around one principle: safety before availability.

Pillar 01

Control / Workload

SEPARATE THE PLANES

A hardened management plane governs identity, secrets, and policy, while chains run on a separate workload plane. Even if the management plane goes down, it can never restart a validator.

Pillar 02

Key Safety

PROTECT THE KEY

Threshold signing, keys kept outside Kubernetes Secrets, and no signer failover triggered by alerts. Any signer-state change is treated as a SEV-1 procedure, not routine operations.

Pillar 03

Observability

SEE BEFORE YOU ACT

Raw, high-cardinality detail stays at the edge, while low-cardinality summaries flow to the center. Alerts explain what is happening; they never execute dangerous actions on their own.

Pillar 04

Compliance

PROVE EVERYTHING

GitOps desired state, tiered RBAC, and audit evidence are designed for SOC 2 and ISO 27001 from the first commit — verifiable, not merely promised.

06 — Architecture

One Clean Seam

An Azure-managed control plane governs an external multi-provider workload cluster using diff-only sync with pruning disabled. Across the boundary, only two flows are permitted — and nothing else.

MANAGEMENT PLANE · AKS Govern Argo CDGitOps Vault + ESOsecrets Grafana · Prometheus · Alertmanager SSO / RBAC · Kyverno · Audit WORKLOAD PLANE · k3s Execute Validators · threshold signers RPC endpoints10 chains Exporters · Edge Prometheus Encrypted private overlay GitOps · prune OFF fp:* summary Azure Key Vault · Workload Identity · 0 static secrets
Management never runs chain workloads. The workload plane never holds the keys to its own kingdom.
07 — Key Safety

Safety First

Signing keys are secured in cloud KMS/HSM, sealed by HashiCorp Vault, and accessed exclusively through a Kubernetes-native key management layer with short-lived workload identities. The raw key material is never written to a pod or committed to a Git repository.

KEY-MANAGEMENT FLOW Cloud KMS / HSM root key, sealed HashiCorp Vault seal · auto-unseal Workload Identity short-lived access Signer calls KMS to sign Validator / Chain one valid signature Raw key never exported · Git stores references, not values · no usable key on any single server
Layered key management — cloud KMS / HSM sealed by Vault, reached only through short-lived workload identity — no single node, and no single layer, ever holds a usable key.
01
KMS / HSM-backed signing

The Raw Key Never Leaves The Vault

Validator signing keys are generated and held in cloud KMS / HSM. The signer calls KMS to produce signatures, while the key material is never exported to the node.
02
Vault-sealed, auto-unseal

Sealed, Not Stored

HashiCorp Vault seals every operational secret and auto-unseals against cloud KMS. Git holds references, never values; no long-lived credentials live in a pod.
03
Threshold signing

No Single Machine Holds A Usable Key

Where supported by the network, validators sign through a threshold signer that distributes signing across independent nodes — double-sign resistant by design, and already live on Initia and Stable.
04
Kubernetes-native boundaries

Key Access Is Bounded & Audited

Active keys are kept out of Kubernetes Secrets. Access is bounded by Workload Identity and network policy, with every key use audited. Signer failover never runs automatically from an alert.
08 — Observability

Raw at the Edge,
Summary at the Center

High-cardinality detailed data remains close to the workload, while only low-cardinality fp:* summary data is sent to the central layer. This keeps costs low and is designed to support compliance evidence.

EDGE — RAW · SHORT RETENTION Exportersnode·chain·proc Edge Prometheusdrill-down, local remote_write fp:* only CENTER — SUMMARY Central Prometheus Grafana · Alertmanager FP Validated Guard Telegram · Slack · PagerDuty
Alerts are evaluated by PrometheusRule → Alertmanager. Grafana visualises only; the Guard explains and humans approve dangerous actions.
block height & lagpeer countsync status validator healthRPC latencyerror rate
09 — Operations

Explainable & Reversible

Every change is assessed based on its blast radius. The workload cluster operates in diff-only mode with pruning turned off, so any drift is reviewed explicitly instead of being automatically reconciled.

01
Tiered change classes

From Docs to Signer/Key

Documentation, monitoring, management apps, workload policy, chain runtime, and signer/key changes each carry their own approval threshold and rollback path.
02
Evidence-gated onboarding

Join ≠ Activate

A new worker is provisioned, joined, isolated by taint, observed, and recorded before any chain is scheduled onto it — a seven-step gate before activation.
03
Stop conditions

We Halt When Unsure

Unclear signer impact, an ambiguous deploy target, pruning that may touch runtime state, a monitoring blind spot, or the absence of a rollback path — any one of these stops the change.
04
Recovery order

Safety First, Always

Confirm there is no signer/key risk → freeze evidence → restore visibility → isolate the workload → proceed with controlled recovery. Backups are stored in zone-redundant storage.
10 — Coverage

Value We Secure

Asset Under Staked (Data as of 23rd June, 2026)
FP Validated — total delegated value across chains
FP Validated dashboard — delegated value across 6 chains

*Note: On Ethereum, we actively participate in Lido's CSM and IDVTC modules and are preparing non-custodial white-label staking solutions through stVaults. Through these initiatives, we aim to provide institutions and ecosystem partners with secure, scalable, and battle-tested staking infrastructure.

11 — Live

Validator Node Performance

Public explorers and dashboards across every network we operate

Node performance · public explorers
FP Validated Guard · internal operations

Our in-house operations tool monitors upgrade readiness, live resources, and logs, forming the backbone of our safety-first approach to change management.

12 — Roadmap

What's Next

2026 H1Live

Multi-Provider Platform

Two-plane architecture in production: validators running across five providers, ten mainnet RPC endpoints, and threshold signing live on Cosmos-SDK chains.

2026 H2In Progress

Compliance Attestation

SOC 2 / ISO 27001 evidence packets, monthly access reviews, and continuous Azure inventory are being matured into formal audit readiness.

2027 H1Planned

Region & Provider Expansion

Expand into additional independent regions and bare-metal providers, with dedicated per-chain capacity sets and tighter private-access controls.

2027Goal

SOC 2 Type II Certification

Complete an independent SOC 2 Type II audit on top of ISO 27001-aligned controls, providing formal assurance for institutional clients.

FP Validated · Litepaper 2026
Validator & RPC Infrastructure · © 2026 Four Pillars Inc.