Hello everyone,
We are FP Validated, the validator arm of Four Pillars, a Korea-based, Asia-leading institutional research firm. Backed by institutional-grade infrastructure and a rapidly expanding validator operation, we are actively contributing to multiple blockchain ecosystems across research, governance, and validator services.
We strongly support Lido’s vision of serving as Ethereum’s staking layer while remaining aligned with Ethereum’s core values. In particular, we appreciate Lido’s efforts to sustainably expand different staking modules designed for different personas, all under a governance framework that seeks to balance and represent a diverse set of stakeholders.
As part of this commitment, we want to actively support and promote the IDVTC module.
If you are a member of the Lido community who has obtained ICS and are interested in teaming up with us for an IDVTC application, we would love to hear from you.
Please refer to the proposal and terms below, and submit the Google Form (here & linked at the bottom as well).
Excited to build together 
-
Lido IDVTC Cluster Proposal
v1.0 · 2026-06-05 · Coordinator: FP Validated · IDVTC Node Operator
§1–6 are the cluster’s own rules. Protocol parameters are in §7.1 - confirmed values from the IDVTC proposal (#188). This proposal is subject to change: if Lido issues official IDVTC guidance or finalized parameters, the affected sections are updated and re-signed.
1. Overview
1.1 Summary
A four-member, SSV-based Lido IDVTC cluster run as one IDVTC Node Operator. Economics run on Member Share - each member’s share, set by the keys they fund - which governs reward, cost, and loss alike. Control is a 4-owner Safe at 3-of-4.
1.2 Design at a Glance
| Item | Design |
|---|---|
| DVT provider | SSV (uniform across all operators) |
| Topology | 4 members → 4 SSV operators → 1 IDVTC Node Operator |
| Owner / Manager / Rewards | Cluster Safe |
| Cost & loss flow | Safe-controlled ETH cost vault / splitter |
| Economic key | Member Share → reward, cost, loss |
| Signing threshold | 3 of 4 SSV operators |
| Initial scale | 1 shared base key, then members add their own (§6.2) |
| Protocol parameters | §7.1 |
1.3 Member Profile & Eligibility
| Area | Requirement |
|---|---|
| Eligibility | ICS-approved and IDVTC-eligible. A member may participate in only one IDVTC and hold only one ICS Node Operator. |
| SSV operator | An SSV Verified Operator, or a live operator with ≥98% uptime over the trailing 3 months; operator ID + evidence before activation |
| Infrastructure | Own EL + CL + SSV + MEV; no reliance on another member |
| Monitoring | Enrolled in SSV Network automatic metrics for all nodes (a type requirement, §5.2) |
| Reliability | Meets incident-response targets (§5.3) and action SLAs (§5.5) |
| Security | Hardware signer for Safe; 2FA; least privilege; no shared accounts |
| Capital | Funds the bond for its own keys and its share of runway (§4.1–4.2) |
| Governance | Signs the 4-signature cluster statement (§7.5); reviews Safe transactions and accounting |
2. Architecture
2.1 Topology & Key Custody
- One IDVTC Node Operator (an IDVTC-type Node Operator in CSM); Manager and Rewards addresses are the cluster Safe.
- Four SSV operators (one per member) jointly run every validator at a 3-of-4 signing threshold; the validator halts only at 2+ operators offline.
- Keys are generated by 4-operator DKG (
proofs.jsonartifact); each member holds one key share. - Priority deposit allocation is a cluster-level cap (§7.1).
2.2 Infrastructure Diversity
The cluster signs at 3 of 4, so only one operator may fail without halting the validator. Clients are diversified as far as practical to limit the risk of a single client bug taking 2+ operators offline.
| Layer | Rule |
|---|---|
| Clients | Diversify EL and CL clients as much as possible; avoid 2+ members on the same client where feasible. |
| Hosting | Diversify hosting as much as possible; avoid 2+ members on the same cloud provider + region where feasible |
| Endpoints | Each member runs its own EL, CL, MEV-Boost; no shared endpoints |
| Access | Separate production access; no shared accounts or signer devices |
| Alerting | Own alerting; critical alerts mirrored to the cluster channel |
Client allocation (diversify where feasible; finalized before activation):
| Member | EL | CL |
|---|---|---|
| FP Validated | Geth | Lighthouse |
| Member 2 | TBD | TBD |
| Member 3 | TBD | TBD |
| Member 4 | TBD | TBD |
2.3 SSV Operator Setup
FP Validated runs the stack below; other members run independent stacks with diversified clients per §2.2.
| Layer | Component |
|---|---|
| Orchestration | Kubernetes cluster; GitOps via ArgoCD — declarative config, automated sync/rollout, health checks |
| Hosting | OVH, Germany |
| SSV | SSV Verified Operator; holds this member’s key share only; DVT duties at the 3-of-4 threshold |
| Execution | Geth (primary), with fallback endpoint |
| Consensus | Lighthouse (primary beacon), with fallback endpoint |
| MEV | MEV-Boost restricted to Lido’s relay allowlist (§5.1) |
| Secrets & keys | DKG key share in HashiCorp Vault, delivered to pods via External Secrets Operator (ESO); encrypted at rest; no complete validator key on any node |
| Monitoring | SSV Network automatic metrics + Prometheus / Grafana; alerts to member and cluster channels (§5.2) |
| Redundancy | Geth + Lighthouse fallback endpoints with health-checked failover |
| Network & security | Segmented internal network, firewalled, least-privilege RBAC; isolated from personal and public infrastructure (§3.4) |
3. Governance
3.1 Authority & Voting
Four Safe owners; 3-of-4 operational threshold. One member, one vote (not share-weighted).
| Decision | Threshold |
|---|---|
| Routine operational | 2 of 4 |
| Emergency response start | 2 of 4 |
| Safe / reward / cost-vault transaction | 3 of 4 |
| Emergency on-chain action | 3 of 4 |
| Validator expansion | 3 of 4 |
| Member replacement | unanimous among non-affected (3 of 3) |
| Economics change | 4 of 4 |
| Governance-parameter change | 4 of 4 |
| DVT-provider change / wind-down | 4 of 4 |
A DVT-provider change must stay within Lido’s approved set (Obol / SSV) and requires an exit-enter procedure (exit current validators, re-enter under the new provider) — providers cannot be mixed within one cluster.
3.2 Governance Parameters
| Parameter | Rule |
|---|---|
| Safe owners / threshold | 4 / 3-of-4 operational |
| Manager & Rewards | Cluster Safe |
| SSV operator fee | 0 at start; uniform across operators; change requires the economics threshold (4-of-4, §3.1) |
| Accounting period | Monthly, plus after any high/critical incident |
| Reward unit | Per period, by Member Share |
| Evidence standard | Monitoring, SSV state, duty data, Safe txs, CSM records, logs, timestamps, signed approvals |
| Non-response | No acknowledgement or action in the Telegram channel within the SLA (§5.5) |
| Cluster strike | 2 strikes within any rolling 4 months → mandatory removal (§6.1) |
3.3 Roles & Responsibilities
| Role | Owner | Scope |
|---|---|---|
| Cluster coordinator | FP Validated | Lido-facing comms, cluster creation and onboarding (§7.2), coordination, incident lead (single coordinator required by Lido onboarding) |
| Safe owners | All members | Approve governance and on-chain actions |
| SSV operators | All members | Operator availability and alerts |
| Accounting | All members | Off-chain Member-Share / bond ledger, penalties, reimbursements, and settlement on member changes or wind-down (reward splits are automated via the splitter, §4.3) |
The coordinator holds no extra authority and is subject to the replacement triggers in §6.1.
3.4 Security
- No private or complete validator key shared in plaintext.
- Hardware signer for Safe ownership; no production access through personal accounts.
- DKG artifacts (
proofs.json) stored only in approved, access-controlled locations. - Suspicious activity reported immediately; offboarding = access removal + ownership review.
4. Economic Model (Member Share)
4.1 Bond & Member Share
Each member economically owns the keys they fund — posting the bond, and earning the rewards and bearing the losses for their own keys. The cluster’s first key is a shared base key owned equally by all four. On-chain the bond is pooled at the cluster (one NO); key->member attribution and Member Share are tracked off-chain (proposal #188).
| Item | Rule |
|---|---|
| Base key | The first key is funded equally (≈0.375 ETH each, ¼ of the first-key bond); its reward, cost, and loss split 25% each |
| Member keys | After the base key, each member funds the bond for their own additional keys (≈0.5 ETH/key) and owns their reward, cost, and loss in full |
| Member Share | A member’s share of cluster rewards / costs / losses = (their funded keys + ¼ of the base key) ÷ total keys; recomputed when keys change |
| Funding flow | Members fund the Safe cost vault; the Safe posts the bond and registers the keys (§3.1); mechanics → §7.1 |
| Settlement | Each period, Member Share is settled off-chain, agreed by all members, and set into the reward splitter via the Safe (3-of-4, §3.1) |
| Shortfall | A member who doesn’t fund their keys’ bond cures it before those keys are registered, else replacement review (§6.1) |
| Model change | 4 of 4 (§3.1) |
4.2 Funding & Runway
The four members are their own operators, so the SSV operator fee is set to 0 at start (charging fees among themselves would be circular). The cluster funds only the SSV network fee and liquidation collateral.
| Item | Rule |
|---|---|
| Operator fee | 0 at start, uniform across all four operators; a change is an economics decision (§3.1) |
| Cost split | Network fee + collateral funded by Member Share (§4.1) — your keys, your cost; base key shared equally |
| Path | Members → Safe cost vault → SSV cluster balance |
| Top-up | Before runway falls below the signed threshold (§7.4) |
| Advance | Only if the vault cannot execute in time; reimbursed on-chain |
| Late funding | Cure the shortfall before adding keys; reimburse any penalty caused (§4.5) |
4.3 Reward Distribution
All rewards accrue to the single Rewards address. Each accounting period, entitlements are settled off-chain by Member Share (§4.1) — each member earns the rewards of the keys they own, the base key split equally — then agreed by all members and paid through the reward splitter (or Safe accounting), set via the Safe (3-of-4, §3.1).
4.4 Offline Handling
| State | Consequence |
|---|---|
| 1 operator offline | Validator still performs at 3-of-4; rewards unaffected. Counts as a cluster strike (§6.1) — no reward adjustment. |
| 2+ operators offline | Validator does not perform; no rewards are generated; consequences are penalties (§4.5). |
4.5 Penalty, Slashing & Loss Allocation
Default: loss by Member Share unless one member’s documented fault isolates it.
| Case | Consequence |
|---|---|
| Individual fault | Responsible member reimburses the direct loss |
| 1 operator offline | No penalty (validator still performs at 3-of-4); cluster strike only (§6.1) |
| 2+ operators offline | Offline members reimburse the penalties by their Member Shares; online members bear nothing |
| Missed bond / funding | Cure the shortfall + reimburse penalty, liquidation cost, or advance caused |
| Per-validator protocol penalty (EL-stealing fine, bad-performance penalty, exit-delay penalty) | Borne by the member who owns the affected validator; the shared base key’s penalty is split equally (§4.1) |
| Relay / MEV-theft | Emergency review and possible replacement (§6.1); the EL-stealing fine is borne by the owner (above) |
| Key-share / access violation | Responsible-party loss allocation; removal (§6.1) |
| External / market | By Member Share |
| Shared fault | Among responsible members, else by Member Share |
Slashing waterfall: loss recorded (§5.3) → allocated by Member Share unless isolated to one member → replenish to the required level by the signed deadline; rewards may be withheld and expansion gated until restored (§6.2). Settlement via the Safe / cost vault.
5. Operations
5.1 MEV & Relay Compliance
Operators run MEV-Boost only on Lido’s relay allowlist. A non-allowlisted relay or MEV theft is a critical incident (§5.3); the protocol fine is allocated to the responsible member (§4.5). Allowlist and fine → §7.1.
5.2 Monitoring
All nodes are enrolled in SSV Network automatic metrics (a type requirement); each member also runs the stack below.
| Layer | Signals |
|---|---|
| SSV | Operator status, cluster ETH balance, liquidation risk, validator state, runway |
| Duties | Attestation effectiveness, proposals, missed duties, inclusion delay, sync committee |
| Clients | EL/CL sync, peers, disk, memory, CPU, restarts |
| CSM | Bond vs requirement, rewards, protocol strikes, validator count, withdrawal credentials, Lido exit requests |
| Governance | Safe owners, threshold, pending transactions, signed decisions, accounting |
5.3 Incidents
| Severity | Trigger | Response |
|---|---|---|
| Critical | 2+ operators offline, liquidation/slashing risk, wrong-address config, key-share compromise, relay/MEV violation, 2nd CSM protocol strike, downgrade risk | Within 2 h; emergency channel; Safe action if needed |
| High | 1 operator offline, degraded performance, low runway, client failure, monitoring outage, missed governance response, 1st CSM protocol strike | Within 6 h; documented |
| Medium | Non-critical maintenance, delayed report, minor alerting gap | Within 3 days |
| Low | Documentation, non-urgent improvement | Within 7 days; logged |
Incident record (each high/critical): time (UTC); severity; impact; offline interval (start/end/operators/evidence); root cause; actions; loss allocation (amount/basis/payers); reimbursement (tx or pending Safe); follow-up (owner/deadline).
5.4 Maintenance
Announce availability-affecting maintenance before it starts (start/end, components, rollback). Upgrades are rolling: at most one operator offline at a time — never take 2+ operators down simultaneously (it breaches the 3-of-4 threshold and halts the validator). Coordinate windows in Telegram so they do not overlap another member’s maintenance or outage. Unannounced maintenance causing missed duties is an offline incident (§5.3) and a cluster strike (§6.1).
5.5 Communication & Response SLAs
The cluster runs a dedicated Telegram group as its emergency and coordination channel; all members join, and critical alerts are mirrored there (§2.2). Specific action SLAs (incident response targets by severity are in §5.3):
| Event | Required action | SLA |
|---|---|---|
| Emergency Safe action (3-of-4) | Review + sign or object | 1 h |
| Operational Safe signing (3-of-4) | Review + sign or object | 3 h |
| Lido-requested validator exit | Sign the exit | within the protocol window (§7.1); target ≤ 6 h |
| Funding / top-up call | Fund your Member Share | 24 h, or the signed deadline |
| Governance vote (non-emergency) | Respond / vote | 48 h |
Missing a required SLA without prior notice is a non-response (§3.2) and a cluster strike (§6.1).
6. Lifecycle
6.1 Member Replacement
Cluster strikes are aligned to the protocol strike cadence (§7.1): two strikes within any rolling 4-month period start mandatory removal; strikes expire after 4 months.
Immediate replacement:
| Trigger | Consequence |
|---|---|
| Security or key-share violation | Immediate access removal + replacement |
| Sustained inability to run the operator / infrastructure | Immediate replacement |
| Loss of ICS eligibility | Immediate; Lido notification |
Cluster strikes — two within any rolling 4-month period start mandatory removal (the member is retained only if all non-affected members approve after verified remediation); each is logged and the member notified. A CSM protocol strike on the member’s operator counts as a cluster strike. Strike events:
- a confirmed offline incident
- a missed response SLA during a critical incident or funding call (§5.5)
- a funding obligation not cured by the signed deadline
- a monitoring or reporting failure
A trigger starts the process; removal executes at the §3.1 threshold. A member under replacement must cooperate with reshare / exit signing; pending rewards and reimbursements are withheld until cooperation, and non-cooperation forfeits them and is itself a critical incident.
Replacement requires: an ICS-approved candidate not already in another IDVTC (§1.3); updated Safe ownership; updated SSV operator set; DKG or reshare; a new 4-signature cluster statement submitted to CSM with monitoring kept in place for all nodes; a signed governance update; final accounting including bond return net of dues.
6.2 Validator Expansion
The cluster starts with 1 shared base key (funded equally, §4.1). After that, any member may add as many keys as they want — the member funds the bond for the new keys, the keys are registered via the Safe as a routine action (§3.1), and that member’s Member Share recomputes (§4.1). The only blocks: the cluster bond must cover all existing keys (no unreplenished slashing shortfall, §4.5), and no member is under replacement review.
The cluster’s priority deposit allocation (§7.1) is split equally among the four members, with the shared base key’s slot absorbed by FP Validated (FP holds one fewer individual slot, since the base key is owned collectively). Reallocation is by consent: with the holder’s agreement, a member may use another member’s allocation — including when a member does not intend to use their full quota — to register in the priority queue.
The first-64-key high-reward tier (3.5% NO reward vs 2% thereafter, §7.1) is allocated on the same basis: split equally (16 each), with the shared base key’s slot absorbed by FP Validated. Reallocation is by consent: with the holder’s agreement, a member may use another member’s allocation — including when a member does not intend to use their full quota — to register keys.
6.3 Validator Exit & Withdrawal
- Exit messages require the 3-of-4 SSV signing threshold.
- Withdrawal credentials are Lido’s; principal returns to the protocol; bond and rewards are claimed to the Safe.
- Lido-requested exits are processed within the protocol window (§7.1); a miss is a critical incident and a cluster strike (§6.1).
- Voluntary or wind-down exits require Safe approval (§3.1) and coordinated signing.
- Any key removal fee is paid by the member who owns the affected keys; the shared base key’s fee is split equally (§4.1).
6.4 Voluntary Exit & Wind-Down
≥4 weeks notice announced in the Telegram channel; an agreed exit plan; Safe approval for on-chain action; coordinated validator exit (§6.3); final reward / penalty / bond / reimbursement accounting including bond return net of dues; an archive of decisions and transaction hashes; Lido notification if required.
6.5 Type Maintenance & Downgrade
The IDVTC type is maintained by the Lido CSM Committee, which sets requirements, manages the IDVTC list via Easy Track, and may pause intake. If the cluster is found not running DVT or otherwise failing type requirements (DVT operation, monitoring, four valid signatures, eligibility), the Committee downgrades the operator to a default CSM type: bond and fee revert to default, which can render keys unbonded and force their exit, and participants’ ICS type may also be downgraded. Maintaining type compliance is a continuous obligation; any downgrade risk is a critical incident (§5.3).
7. Activation
7.1 IDVTC Parameters
Confirmed from the IDVTC proposal (#188):
| Parameter | Value |
|---|---|
| Node Operator reward | 3.5% for the first 64 keys (32 ETH), 2% for subsequent keys |
| Bond | 1.5 ETH first key, 0.5 ETH subsequent — cluster-level on-chain, split off-chain by Member Share (§4.1) |
| Priority queue | Up to 40 keys over the cluster lifetime via priority queue (below ICS); remaining keys via the general queue |
| Protocol strikes | 2 strikes → key exit; strike lifetime 4 months |
Still to confirm with the Lido IDVTC contact / final CSM v3 release:
| # | Item | Used by |
|---|---|---|
| 1 | Bond submission mechanics (contact: first-key bond from Rewards/Manager address at creation; confirm subsequent keys) | §4.1 |
| 2 | Bond token form (ETH/stETH/wstETH) and rebase treatment | §4.3 |
| 3 | Exit-request window and exit-delay penalty | §6.3 |
| 4 | MEV-theft / EL-stealing fine amount and the relay allowlist | §5.1, §4.5 |
| 5 | Withdrawal-credential and bond/reward claim flow | §6.3, §4.3 |
| 6 | Manager vs Rewards address permissions | §3.2 |
| 7 | DVT incentive allocation (separate mechanism) applicability | §4.3 |
7.2 Onboarding Flow
- Each participant signs a standardized address-ownership message.
- The cluster coordinator (FP Validated) creates the cluster and posts the four signed messages plus cluster contact information.
- The application is submitted to the CSM Committee for assessment.
- On approval, the cluster address is added to the CSM gate via an Easy Track motion; DKG and key registration follow (§2.1, §3.4).
7.3 Activation Checklist
| Area | Required |
|---|---|
| Members | 4 confirmed ICS-approved, none in another IDVTC |
| SSV operators | IDs, 3-month uptime, identical fees, pubkeys, endpoints reviewed; SSV-metrics monitoring enrolled |
| Diversity | §2.2 satisfied |
| Safe | 4 owners, 3-of-4, secure-signer hygiene |
| Member Share | Set, recorded, signed (§4.1) |
| Cost vault | Selected, or temporary Safe fallback approved |
| Reward path | Distributor / splitter or Safe accounting selected |
| Bond & runway | Commitments, initial runway, top-up threshold, reimbursement rules signed |
| Onboarding | Address-ownership signatures collected; CSM Committee assessment passed (§7.2) |
| §7.1 | Remaining protocol items confirmed with the contact |
| Monitoring | Dashboards and emergency channel ready |
| Signatures | 4-signature cluster statement, economics, emergency process signed |
7.4 Open Decisions
| Decision | Status |
|---|---|
| Final member set | Open |
| Client allocation (diversify EL/CL across members) | Open |
| Per-member key plan (after the shared base key) | Open |
| Runway threshold + top-up trigger | Open |
| SSV operator fee | 0 at start (§4.2) |
| Reward distributor vs Safe accounting | Open |
| Emergency/comms channel | Telegram group (FP Validated to create) |
| Shared monitoring dashboard | Open (FP Validated) |
| Response SLA values (§5.5) | Proposed; confirm at signing |
| Activation date | Open |
7.5 Signatures
The 4-signature cluster statement linking each participant’s ICS identity to the cluster (signed before DKG; re-signed on any member replacement, §6.1).
| Member | Entity | Safe owner address | SSV operator ID | Member Share | Signature |
|---|---|---|---|---|---|
| 1 | FP Validated | TBD | TBD | TBD | Pending |
| 2 | TBD | TBD | TBD | TBD | Pending |
| 3 | TBD | TBD | TBD | TBD | Pending |
| 4 | TBD | TBD | TBD | TBD | Pending |
FP Validated’s operator performance: Rated Network · SSV Operator
-
Submit: Lido IDVTC Partnership Interest Form (by FP Validated)