Brand HomeFP ResearchFP ValidatedFP Institution
FP Validated
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
01Vision

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.

02Footprint

Live Today

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

Azure AKS · Management planeArgo CD · Vault · ObservabilityGitOpsfp:* summaryOVH Cluster · k3s workload planeEncrypted private overlayOVHWorldstreamAzureLACherry
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.

03Team

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.
04Networks

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 · 17 networks
CantonSpliceEthereummainnetEthereumtestnetInitiamainnetInitiatestnetInjectivemainnetLayerZeroDVN · mainnetOptimumtestnetSeimainnetSolanatestnetSSVmainnetStablemainnetStabletestnetSuimainnetSuitestnetWalrusmainnetWalrustestnet
RPC · 10 mainnet endpoints
EthereumBSCSolanaHyperliquidAvalanchePolygonArbitrumOptimismBaseTempo
More to come
05Principles

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.

06Architecture

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 · AKSGovernArgo CDGitOpsVault + ESOsecretsGrafana · Prometheus · AlertmanagerSSO / RBAC · Kyverno · AuditWORKLOAD PLANE · k3sExecuteValidators · threshold signersRPC endpoints10 chainsExporters · Edge PrometheusEncrypted private overlayGitOps · prune OFFfp:* summaryAzure Key Vault · Workload Identity · 0 static secrets
Management never runs chain workloads. The workload plane never holds the keys to its own kingdom.
07Key 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 FLOWCloud KMS / HSMroot key, sealedHashiCorp Vaultseal · auto-unsealWorkload Identityshort-lived accessSignercalls KMS to signValidator / Chainone valid signatureRaw 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.
08Observability

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 RETENTIONExportersnode·chain·procEdge Prometheusdrill-down, localremote_writefp:* onlyCENTER — SUMMARYCentral PrometheusGrafana · AlertmanagerFP Validated GuardTelegram · Slack · PagerDuty
Alerts are evaluated by PrometheusRule → Alertmanager. Grafana visualises only; the Guard explains and humans approve dangerous actions.
block height & lagpeer countsync statusvalidator healthRPC latencyerror rate
09Operations

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.
10Coverage

Value We Secure

Asset Under Staked (Data as of 23rd June, 2026)
$52,138,342
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.

11Live

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.

12Roadmap

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.