FP Validated Infrastructure Overview
FP Validated operates blockchain infrastructure as an institution-grade Kubernetes platform, not as a collection of one-off nodes. The public model is simple:
This page intentionally describes architecture patterns, not exploitable implementation details. We do not publish exact IPs, private hostnames, VPN peer configuration, Vault paths, kubeconfigs, token names, or runbook commands that could increase operational risk.
Platform layers
| Layer | Responsibility | Public-safe implementation pattern |
|---|---|---|
| Management cluster | Central platform services and operator access | EKS-based control plane with ArgoCD, Vault/External Secrets, Authentik-protected management UIs, observability access, and platform AppProjects. |
| Validator Kubernetes platforms | Chain nodes and chain-specific runtime | Kubernetes runtime for validator/storage/signing workloads with independent GitOps roots. |
| Chain deployment repos | Per-chain values, overlays, signer topology | common-values.yaml plus role/node overlays, rendered through Helm and ArgoCD Applications. |
| Guard API | Operational API and incident intake | FP Validated Guard exposes health, incident/reporting, validator metadata, and controlled Kubernetes operations. |
| Monitoring repo | Node agents, dashboards, alert rules | Per-node ApplicationSet rollout, chain-specific alert rules, Grafana dashboards, Alertmanager routing. |
Why split management and validator planes?
The management plane should help operate validator infrastructure, but it should not become a single blast radius for validator signing. FP Validated therefore treats management and validator Kubernetes platforms as separate planes:
- The management platform owns management services and operator workflow.
- Validator Kubernetes platforms remain the runtime for chain workloads.
- Validator platforms keep their own GitOps roots and can remain operational while the management plane is paused or rebuilt.
- Migration between planes is phase-gated; validator workloads are not moved implicitly.
Public architecture principles
- GitOps first — cluster state is described in repositories, rendered through ArgoCD, and promoted through explicit Applications.
- Separation of concerns — platform, access, observability, security, and chain workloads are separated by project/domain.
- Secrets never live in docs or manifests — Vault and External Secrets deliver runtime secrets; public docs describe classes of secrets only.
- Private management access — dashboards and control UIs are protected behind identity-aware access paths.
- Fail closed on signing safety — ambiguous validator or signer state results in no signing, not risky failover.
- Observable by design — nodes ship metrics/log signals through a standard agent pattern before becoming production workloads.