Proposal Summary
This proposal amends and extends [DIP-31] Development Roadmap for 2025-mid-2026 by SSV Labs (hereinafter: “DIP-31”), as previously amended by [DIP-53]. DIP-31 funded an engagement that commenced on January 1, 2025. This proposal extends it to June 30th, 2027, so that DIP-31, as amended, covers the period from January 1, 2025, to June 30th, 2027, narrows its scope as of July 1st, 2026, and restructures the remaining installment.
SSV Labs proposes to the ssv.network DAO (hereinafter: “DAO”) to continue providing network stewardship efforts for the ssv.network protocol (hereinafter: the “Protocol”) for the period commencing on June 30th, 2026 and ending on June 30th, 2027 (hereinafter: the “Extension Period”), extending the term of DIP-31 so that it runs from January 1, 2025 to June 30th, 2027 (hereinafter: the “Grant Term”).
The Extension Period has two parts. In the first two quarters, from June 30th, 2026 to January 1, 2027, SSV Labs shall deliver the network stewardship roadmap set out below. In the following two quarters, from January 1, 2027 to June 30th, 2027 (hereinafter: the “Maintenance Period”), SSV Labs commits to maintenance of the Protocol.
The first two installments under DIP-31, covering 2025, are unchanged. For 2026, SSV Labs requests 1,500,000 USDC. For the first half of 2027, SSV Labs requests 2,700,000 SSV tokens, with 1,000,000 SSV payable initially and the remaining 1,700,000 SSV subject to an option that either converts to USD or is paid in tokens across monthly installments. This structure is aligned with requests made by the community and DAO contributors to waive or defer the third installment under DIP-31 already due. The Finances section sets out the schedule.
This proposal also grants SSV Labs a first-ranking security interest over 900,000 USD held by the SSV Foundation.
Motivation
This proposal suggests amending DIP-31 to extend the engagement on narrower terms.
Due to current market conditions and the DAO’s financial position, the efforts funded here are limited compared to previous years and plans. They are focused on maintenance rather than an expansive roadmap.
SSV Labs handles maintenance for the Protocol implementation, the network’s fork-readiness, the live mainnet smart contracts, and every operational and user-facing surface. The first half of the Extension Period carries two mandatory network upgrades and the checkpoint-sync work that Ethereum’s history expiry makes unavoidable.
The third and final installment under DIP-31, 1,736,111.11 SSV, has not been paid. The commercial arrangement shall be revised and restructured, as set forth in this proposal.
Proposal Particulars
Network Stewardship Roadmap
The roadmap covers the first two quarters of the Extension Period, structured as two quarterly milestones and the ongoing work listed below.
Q3 2026 (July – September)
1. Boole network fork — testing and rollout. The Boole fork is an upgrade of the ssv.network protocol that requires a coordinated, mandatory update by every network staker and operator. The implementation is complete and in final review. The remaining work comprises:
- a three-stage acceptance test — normal operation before the fork, the fork transition itself, and normal operation after the fork — run on dedicated test networks with multiple operators, currently in progress;
- compatibility testing between the two client implementations, with every test run producing a report that records the exact software versions tested and the results, kept as a permanent record;
- a staged rollout: a rehearsal of the fork on the public test network (Hoodi), in which both client implementations participate on their own infrastructure, followed by the scheduled mainnet fork, a mandatory operator release, release notes, and operator communications and support throughout the fork window; and
- an automated reporting system that continuously shows, feature by feature, whether each implementation meets the fork’s acceptance criteria. This system will serve every future network upgrade.
The milestone is complete when the mainnet fork has taken place, all operators run the mandatory release, and no regressions affecting validators have occurred. The final fork date is set once the compatibility testing between the two implementations is complete.
2. Glamsterdam (ePBS) readiness — Ethereum hard-fork compliance. Ethereum’s next hard fork changes the duties that validators perform. The Protocol must implement, test, and ship support before the fork reaches Ethereum mainnet; for a live staking protocol, this work is not optional. The Q3 programme comprises:
- implementation of the three new validator duty types (code substantially complete and in final review);
- a dedicated test suite for the fork transition itself — the point where errors are most likely — together with validation of all post-fork duties on local test networks;
- updates to the node’s internal duty-processing pipeline (E2M) for the new duties, with further updates tracked against Ethereum’s design changes as they continue to land; and
- a single node release that supports both the pre-fork and post-fork interfaces, together with updated support for the latest Ethereum libraries and clients.
The Q3 portion is complete when all new duties are validated on local test networks, the transition test suite passes, and the implementation is ready to join the public test network in Q4.
3. Checkpoint sync — node startup and recovery. A node currently syncs by replaying every contract event since deployment. Ethereum’s history expiry removes the old chain history that this path depends on, so it is closing; without checkpoint sync, new operators would have no standard way to join. Checkpoint sync replaces replay with the import of a recent, signed snapshot of network state. The specification is published as a SIP and is in community review; implementation begins once it is accepted. Unlike the two forks, this ships as an optional feature in a regular node release and requires no coordinated network upgrade. The Q3 work is to drive the SIP through review to acceptance, then begin implementation of snapshot generation, verification, and import, with conformance tests on the existing test infrastructure. The Q3 portion is complete when the SIP is accepted, and implementation is under way.
4. Staking migration — operations and monitoring. The ongoing staking migration is operated and monitored continuously by the core team: tracking each migration’s state, detecting anomalies, supporting operators, and intervening where migrations stall or misbehave.
Q4 2026 (October – December)
1. Glamsterdam fork execution. Participation in the fork on the public test network, a mandatory operator release, support through Ethereum’s mainnet fork window (currently expected in Q4 2026), and post-fork stabilization. As with every Ethereum hard fork, this is a network-critical, deadline-driven programme whose dates are set externally.
2. Checkpoint sync — completion and rollout. Complete the implementation, validate it on local multi-operator test networks, and roll it out through the regular release process: public test network validation, inclusion in a node release, documentation and operator communications. Rollout timing depends on when the SIP clears review; since no coordinated network upgrade is required, it can ship in any regular release.
3. Continued network stewardship. All ongoing work set out below runs through Q4 unchanged. Q4 additionally absorbs the follow-up from both forks: remaining operator upgrades, support for the last operators to move, and post-fork monitoring.
Ongoing work (every quarter)
| Area | What it covers |
|---|---|
| 24/7 network monitoring & incident response | Round-the-clock monitoring of network health, validator performance and operator availability, toward a target of 99.95% of validator duties performed successfully; alerting, incident response and incident reviews, staffed through an on-call rotation across the core engineering team; operator health tooling (the Pulse health-check and log tools). |
| Node maintenance & releases | Regular node releases: bug fixes, security patches, and keeping dependencies and Ethereum client compatibility current. Every change is reviewed by multiple engineers and passed through automated testing. Includes release engineering, release notes and operator upgrade support. |
| Smart-contract stewardship | Upkeep of the live mainnet contracts: monitoring, incident readiness, triage and remediation of security reports, and maintenance of the contract code, which is frozen to new features. |
| Protocol specification review & implementation | Review of protocol improvement proposals (SIPs) affecting the ssv.network and implementation of accepted changes. Deliberately reduced in scope under this engagement: review and implement, not a research programme. |
| Web properties & tooling | The network explorer(s), the web application, the developer tools (ssv-keys, ssv-dkg, ssv-scanner and the SSV SDK) and the documentation — kept current, secure and compatible with node and contract releases. |
| Testing infrastructure | The local multi-operator test network (SSV-mini), the fork-simulation tools, and the automated system that reports whether each implementation meets the acceptance criteria — the shared backbone that makes the two fork milestones executable and repeatable, built once and serving both client implementations and every future upgrade. |
What this proposal does not include
No development of new products or protocols is included in, or compensated under, this proposal, and it neither includes nor amends any marketing or project-promotion budget. This proposal represents the work required to keep the ssv.network running, safe and compliant with Ethereum’s own upgrade schedule.
Finances
Compensation is split across the periods set out below. The first two installments under DIP-31, covering 2025, are unchanged.
If this proposal were to pass, the ssv.network DAO Multi-Sig Committee (hereinafter: “MC”) will send 1,500,000 USDC to the SSV Foundation in the first scheduled batch of January 2027, and 2,700,000 SSV in the first scheduled batch of July, 2027, subject to the terms of the Conversion Option detailed below, to be held by the SSV Foundation for payment to SSV Labs.
After receiving each transaction, the SSV Foundation will effect payment to SSV Labs within thirty (30) days, or for the installments at the times set out below, to the address 0xB0B83C72AD8cA979bDDD4f0BD3777c42C4a67CFE; SSV Labs retains the right to notify the SSV Foundation to execute the transfer to another wallet address.
Conversion option. Of the 2,700,000 SSV payable for 2027, SSV Labs is granted an exclusive and discretionary option (hereinafter: the “Conversion Option”) to receive 900,000 USDC instead of 1,700,000 SSV, on the following terms:
(i) Amount and Price. The Conversion Option is valid as a whole only: 1,700,000 SSV of the 2027 payment for 900,000 USD.
(ii) Exercise. SSV Labs will have to notify the SSV Foundation regarding the Conversion Option at least five (5) business days before the first scheduled batch of July 2027, by written notice from SSV Labs to the SSV Foundation.
(iii) Settlement. Occurs within thirty (30) days after the notice under (ii): the SSV Foundation shall pay 900,000 USD in USDC.
(iv) Balance. SSV converted under the Conversion Option is fully discharged on payment of the 900,000 USD, and nothing further is due in respect of it.
(v) Installments. If SSV Labs does not exercise the Conversion Option, the MC transfers the 1,700,000 SSV to the SSV Foundation in six (6) equal monthly installments of 283,333.33 SSV (the last amounting to 283,333.35 SSV), in the first scheduled batch of each month starting in July 2027, and the SSV Foundation transfers each installment to SSV Labs within twenty-one (21) days of receiving it. The installments are a payment schedule only.
The table below summarizes the above text for convenience, while the latter prevails in case of contradiction:
| Year | Compensation | Payment |
|---|---|---|
| 2025 | Paid under DIP-31 | Unchanged by this proposal; settled already |
| 2026 | 1,500,000 USDC | First scheduled batch of January 2027 |
| 2027 | 2,700,000 SSV | First scheduled batch of July 2027. 900,000 USD of this amount may be taken in USDC under the Conversion Option above. If it is not, that part is paid in six (6) monthly installments, starting in July 2027. |
Operational
If this proposal were to pass:
1. Amendment and extension. This proposal amends and extends DIP-31, as amended by DIP-53. The term is extended so that DIP-31 runs from January 1, 2025 to June 30th, 2027. The scope of the engagement is replaced by the roadmap and ongoing work set out above; and the payment schedule and sums are as set out in this proposal. All other provisions of DIP-31 remain in force so far as they are consistent with this proposal.
2. Term. The Grant Term runs from January 1, 2025 to June 30th, 2027. The efforts under this proposal run over the Extension Period, from June 30th, 2026 to June 30th, 2027.
3. Security over the indemnity-program funds. SSV Labs is granted a first-ranking security interest in the amount of 900,000 USD. The SSV Foundation may deploy the secured funds for yield generation through permitted venues; the security follows the funds into whatever form they take, so that 900,000 USD of value stands charged at all times. Yield, any value above that amount, and all other assets of the SSV Foundation are not charged and remain at the SSV Foundation’s free disposal. SSV Labs may apply the secured funds toward the 2027 payment described in the Finances section, and its recovery under the security is capped at 900,000 USD.
4. Execution of the security. The DAO authorizes and directs the SSV Foundation to negotiate, execute, and deliver a deed of fixed charge creating the security and any ancillary documents, and thereafter to take any and all steps required to give it effect, including transferring assets in the value of the 900,000 USD to the designated wallet, restricting its deployment to the permitted yield venues to be set out in the deed, maintaining the secured balance and the effectiveness of the charge. No further DAO approval is required for the SSV Foundation to do so.
5. Authorization. The DAO fully and irrevocably empowers, directs, and authorizes the SSV Foundation, on behalf of the DAO, to draft, execute, sign, and deliver a binding agreement, and any other documents it deems necessary and appropriate, to facilitate the efforts detailed in this proposal and their payment, and to create and perform the security and the Conversion Option set out in the Finances section.
6. Continuity. After June 30th, 2027, SSV Labs will retain the ability to provide these services uncompensated until such time as a new proposal is proposed.
