[DIP-24] SSV Labs Core Development Team Grant

Proposals Grants
1

Proposal Summary

This proposal outlines the achievements of ssvlabs performed in the past, as well as, the required maintenance and potential improvements that might come down the line if the proposal were to be approved. Also, the proposals requests from the ssv.network DAO 6.000.000 USD denominated in SSV for these efforts over a period of ending with 2024 EOY.

These development efforts require a team of about 60 employees, including developers, Product Managers, and designers. It will further require Cloud services for hosting, testing and production environments, DevOps services, and audits of the smart contracts by a reliable third party. This is far from a comprehensive list of expected costs that SSV Labs bears. Still, the Core Dev is willing to bear a substantial part of the costs for the benefit of the project and the community, as done by other members of the SSV community.

Motivation

Ssvlabs has been at the forefront of development of the ssv.network protocol for the past couple of years. In so doing, as one of the many ssv.network contributors it has managed to bring substantial changes, optimizations and groundbreaking features to both DVT and the ssv.network protocol.

Today, ssvlabs would like to continue its work on the ssv.network protocol with a longer time frame commitment to the ssv.network DAO and ssv.network protocol with a roadmap of improvements that will position the ssv.network at the forefront of retail, commercial and institutional staking and restaking industries.

Proposal particulars

  1. Achievements
    1. Continuous work
      1. Ongoing Infrastructure Support and Maintenance
    2. SSV Smart Contracts
      1. Batch Operations Implementation (DIP-15)
        1. Context
        2. Technical details
        3. Commit Reference
      2. Scaling Permissioned Operators (DIP-19)
        1. Context
        2. Technical details
        3. Commit Reference
      3. Pectra Readiness
        1. Context
        2. Technical details
        3. Commit Reference
    3. Continuous Documentation Updates
      1. Context
      2. Technical details
      3. Commit Reference
    4. Audits
      1. Batch Operations Upgrade Audit
      2. Audit Process
      3. Audit Report
  2. Potential improvements
    1. Alan Fork (SIP-13)
      1. Objective
      2. Key Changes
        1. Specification Update
        2. Networking Enhancements
        3. Node Software Update
        4. Web and Explorer App
        5. Documentation
    2. Committee Consensus Upgrade
      1. Objective
      2. Technical Details
        1. Scaling Research
        2. Consensus Research
        3. New specifications
        4. New Network Topology
        5. Client Support
        6. Exporter Support
      3. Specific Upgrade
    3. Pectra Readiness
      1. Objective
      2. Key Changes
        1. Refactored Operator Fees and Staker Payments
        2. Refactored Cluster Liquidation Mechanism
        3. Webapp and Explorer Support
      3. Timeline
    4. SSV Tooling
      1. SSV-DKG Enhancements:
        1. Objective
        2. Technical details
          1. Researching Capability
          2. Resigning Capability
        3. Timeline
      2. SSV-SDK Development
        1. Objective
        2. Technical details
          1. Optimizations
          2. Compatibility Updates
        3. Timeline
    5. Incentivized Mainnet Program
      1. Objective
      2. Technical details
        1. Research Focus
        2. Design Implementation
      3. Timeline
    6. Second Client Development
      1. Objective
      2. Timeline
    7. Audits
      1. SSV Spec (Committee Consensus Upgrade)
        1. Objective
        2. Audit Scope
      2. SSV Node(Committee Consensus Upgrade)
        1. Objective
        2. Audit Scope
      3. SSV Smart Contracts (Pectra Upgrade)
        1. Objective
        2. Audit Scope
      4. SSV-DKG (Resharing & Resigning Upgrade)
        1. Objective
        2. Audit Scope
  3. Budget

Achievements

  1. Continuous Work
    1. Ongoing Infrastructure Support and Maintenance:
      1. As the SSV Network scales, the demands for technical support and infrastructure maintenance increase proportionally. The SSV Labs engineering team is actively engaged in providing technical assistance to various teams building on the SSV protocol. This includes resolving critical issues, optimizing network performance, and ensuring the reliability of validator operations. As the network’s user base expands, this support becomes increasingly complex, requiring constant vigilance and proactive troubleshooting to maintain system stability.
  2. SSV Smart Contracts
    1. Batch Operations Implementation (DIP-15):
      1. Context: With the scaling of the SSV Network, the inefficiencies in handling individual validator registrations and updates became apparent. The network’s growth necessitated a more efficient method to perform multiple operations within a single transaction to mitigate gas costs and improve transaction throughput.
      2. Technical Details: The “Batch Operations” upgrade, formalized under DIP-15, introduced a batch processing capability into the SSV smart contracts. This modification allows for the registration of multiple validators and execution of other repetitive contract functions within a single transaction. This is achieved by optimizing the contract’s internal loops and leveraging Ethereum’s native gas efficiency strategies to reduce the computational overhead. For instance, the new batchRegisterValidators function replaces individual registerValidator calls, cutting down the total gas required per operation by aggregating storage and execution costs.
      3. Commit Reference: The core changes were integrated into the main contract codebase in acommit related to DIP-15 (replace with actual commit hash upon availability), where the implementation details of batch processing are thoroughly documented.
    2. Scaling Permissioned Operators (DIP-19):
      1. Context: The increasing number of validators managed by individual operators exposed the need for a more sophisticated mechanism to manage these validators efficiently. The traditional approach of manually updating each validator’s status became untenable as operator scales increased.
      2. Technical Details: The enhancements introduced under DIP-19 address the need for scaling the management of permissioned operators. This update implemented bulk operations for managing validator groups and introduced address whitelisting capabilities. The bulkWhitelistOperators function allows multiple operators to be whitelisted or managed within a single transaction, significantly reducing the operational complexity for large-scale validator operations. Additionally, the upgrade optimized contract logic to handle concurrent validator operations, ensuring that the system can manage large-scale validator onboarding without bottlenecks.
      3. Commit Reference: The commit related to DIP-19 (replace with actual commit hash upon availability) details the technical implementation, including the modified contract functions and the associated gas optimizations.
    3. Pectra Readiness:
      1. Context: The upcoming Pectra upgrade, which increases the max effective balance per validator to 2048 ETH, necessitates changes in the SSV Network’s smart contracts and node operations. This shift requires dynamic fee structures that are proportionate to the amount of ETH staked rather than fixed at 32 ETH increments.
      2. Technical Details: The preparation for Pectra involves refactoring the contract’s fee calculation mechanisms to support dynamic scaling. The smart contracts will be updated to compute fees based on the actual ETH staked by each validator, ensuring that the costs remain proportionate and fair across varying stake amounts. This involves modifying the calculateValidatorFee function to accept variable inputs corresponding to the staked amount and adjusting the node’s logic to handle these dynamic fees without additional latency.
      3. Commit Reference: The ongoing development for Pectra readiness can be tracked in dedicated branches or via specific issues within the SSV Network repository.
  3. Continuous Documentation Updates:
    1. Context: As the SSV Network evolves, keeping the documentation up-to-date with the latest features, APIs, and system architecture is a continuous task. Accurate and detailed documentation is essential for developers and operators to understand and correctly implement network functionalities.
    2. Technical Details: Documentation updates include comprehensive changes to API references, contract interaction guides, and architecture overviews. For instance, theREADME.md file is frequently updated to reflect new contract methods and deployment procedures. Additionally, detailed architectural diagrams are maintained to illustrate the interplay between various network components, which is crucial for onboarding new developers and ensuring that integrations are done correctly.
    3. Commit Reference: Documentation-related changes can be reviewed in the documentation commits, which highlight the incremental updates as new features are added to the network.
  4. Audits
    1. Batch Operations Upgrade Audit:
      1. Technical Context: The introduction of batch processing capabilities required a rigorous security audit to ensure that the aggregation of operations does not introduce new vulnerabilities, such as reentrancy attacks or excessive gas usage that could lead to denial-of-service scenarios.
      2. Audit Process: The smart contracts underwent a comprehensive audit by an external security firm to validate the integrity of the batch operations. The audit focused on ensuring that the new batch functions adhered to best practices in smart contract security, including proper state management, access control, and gas efficiency.
      3. Audit Report: The audit findings and recommendations were compiled into a detailed report, which is accessible via the SSV Network’s audit documentation.
    2. Scaling Permissioned Operators Audit:
      1. Technical Context: Scaling the permissioned operators involved adding complex management features that needed to be thoroughly tested for security risks. Bulk operations, in particular, were scrutinized for potential vulnerabilities that could be exploited if not properly secured.
      2. Audit Process: The audit process involved stress testing the bulk management functions under various conditions to ensure that they could handle large-scale operations without compromising the network’s security. Special attention was given to the handling of concurrent transactions and ensuring that the whitelisting mechanisms could not be bypassed.
      3. Audit Report: The audit results were documented and shared with the development community, ensuring transparency and providing a roadmap for any necessary follow-up actions. The detailed audit report is available alongside other security documentation (Node | Smart Contract).
    3. SSV-DKG Release Version Audit:
      1. Technical Context: The SSV-DKG (Distributed Key Generation) is a critical component for secure, decentralized validator key management. As it moved towards a release version, it was essential to ensure that the implementation was robust and free from critical vulnerabilities.
      2. Audit Process: The audit for the SSV-DKG focused on cryptographic security, ensuring that the key generation process was truly decentralized and resistant to tampering. The audit also included performance testing to verify that the DKG could operate efficiently under the expected network load.
      3. Audit Report: The final audit report for the SSV-DKG is published in the repository, ensuring that all aspects of the release version have been vetted and validated by external security experts.
  5. SSV Tooling
    1. SSV-Subgraph Implementation:
      1. Technical Context: Efficient data retrieval is critical for applications built on the SSV Network, particularly for operations that require real-time cluster state information. The SSV-Subgraph was developed to index and provide fast access to this data.
      2. Technical Details: The SSV-Subgraph leverages The Graph Protocol to create an indexed version of the blockchain data relevant to SSV’s operations. By using GraphQL queries, developers can retrieve validator cluster data, such as validator statuses, operator performance, and cluster configurations, with minimal latency. This tooling is essential for building scalable applications on the SSV Network, as it offloads the data retrieval burden from the Ethereum network to a more efficient querying layer.
      3. Commit Reference: The development and deployment of the SSV-Subgraph are documented in the SSV Network repository, with specific implementation details and optimizations highlighted in recent commits.
    2. Redesigned Web App:
      1. Technical Context: The increasing reliance on the SSV Network’s web application by projects such as Lido’s SimpleDVT necessitated a comprehensive overhaul of both the front-end and back-end systems. This redesign aimed to improve scalability, user experience, and integration capabilities.
      2. Technical Details: The new web app was built using modern web development frameworks to enhance performance and scalability. The back-end was re-architected to support more complex interactions with the SSV Network, including real-time data updates and expanded API support for third-party integrations. The front-end was designed with a focus on UX/UI improvements, ensuring that the application can handle increased traffic and provide a seamless user experience for operators and developers.
      3. Commit Reference: The web app redesign commits document the incremental development process, detailing both the technical underpinnings of the new architecture and the design considerations that guided the overhaul.
    3. Lido SimpleDVT Integration
      1. Technical Overview: The Lido SimpleDVT project represents a significant integration effort between the Lido DAO and the SSV Network, aiming to deploy approximately 7,000 validators onto the SSV infrastructure. This integration is strategically important as it leverages SSV’s decentralized validator technology to enhance Lido’s staking services.
      2. Development Details:
        1. Developer Relations: A dedicated developer relations team facilitated the integration by ensuring close collaboration between Lido and SSV developers. This included aligning on technical requirements, resolving integration challenges, and providing ongoing support throughout the development process.
        2. Testnets: Multiple testnets were deployed to validate the integration, simulating mainnet conditions to ensure that the SSV-DKG client, validator management tools, and staking contracts performed reliably under load. These testnets were critical for identifying and mitigating potential issues before moving to mainnet.
        3. DKG Client Implementation: The DKG client was a focal point of the integration, enabling decentralized management of validator keys. The client was designed to be robust and secure, ensuring that validator keys remain safe even in the event of node failures or malicious activity.
        4. Documentation and Compliance: Extensive documentation was developed to support the integration, covering everything from deployment guides to API references and compliance requirements. This documentation ensures that all stakeholders can fully understand and implement the necessary changes to support the integration.
        5. Commit Reference: The technical progress and milestones of the Lido SimpleDVT integration can be traced through relevant commits and pull requests within the SSV Network’s repository, offering detailed insights into the technical challenges and solutions developed during the project.

This technical breakdown provides a more in-depth and detailed view of the ongoing developments and updates within the SSV Network, highlighting the specific technical implementations, optimizations, and audit processes that ensure the network’s robustness and scalability.

Potential improvements

  1. Alan Fork (SIP-13)
    1. Objective: The Alan Fork represents a significant protocol upgrade, as outlined in SIP-13. Its primary goal is to enhance the network’s scalability and efficiency, enabling the SSV Network to support up to 200,000 validators while simultaneously reducing the computational and resource demands on individual nodes.
    2. Key Changes:
      1. Specification Update: The core protocol specifications were revised to accommodate the increased validator capacity and optimize resource usage. This included adjustments to validator registration, consensus algorithms, and the introduction of more efficient data handling mechanisms.
      2. Networking Enhancements: Network layer optimizations were implemented to support higher throughput and reduce latency. The new network topology allows for more efficient communication between nodes, ensuring that the increased validator count does not negatively impact performance.
      3. Node Software Update: The SSV node software was extensively modified to handle the increased load. This involved rewriting key components such as the consensus engine and state management to reduce memory and CPU usage. The new node software also supports dynamic scaling, allowing it to adapt to varying network conditions.
      4. Web and Explorer App: The user interfaces for both the web app and the explorer were updated to reflect the changes brought by the Alan Fork. This included the addition of new monitoring tools, enhanced validator management features, and improved data visualization to handle the larger volume of validators.
      5. Documentation: Comprehensive documentation updates were necessary to guide developers and operators through the changes introduced by the Alan Fork. This includes new API references, updated deployment guides, and detailed explanations of the new consensus mechanisms.
    3. Timeline: October 2024
  2. Committee Consensus Upgrade
    1. Objective:
      1. The Committee Consensus upgrade is designed to scale the SSV node’s performance to support the growing network, particularly in the context of the increased validator capacity introduced by the Alan Fork.
    2. Technical Details:
      1. Scaling Research: In-depth research was conducted to identify bottlenecks in the existing consensus mechanism. This led to the development of new algorithms and protocols designed to improve the scalability and resilience of the SSV Network.
      2. Consensus Research: The upgrade involved the refinement of consensus algorithms to support larger committees without compromising on security or performance. This included optimizing the BFT (Byzantine Fault Tolerance) mechanisms and improving the efficiency of consensus rounds.
      3. New Specifications: The technical specifications for the SSV protocol were updated to incorporate the findings from the scaling and consensus research. These specifications detail the new consensus procedures, network topologies, and validator management protocols.
      4. New Network Topology: A more scalable and fault-tolerant network topology was introduced. This new topology allows for better load distribution among nodes and reduces the risk of network congestion as the number of validators grows.
      5. Client Support: All SSV clients were updated to support the new consensus model. This included extensive testing to ensure compatibility and performance across different environments and configurations.
      6. Exporter Support: Enhancements were made to the metrics exporter to track and report on the performance of the new consensus mechanisms. This allows operators to monitor the health and efficiency of their nodes in real-time.
    3. Specific Upgrades:
      1. Increased Validator Cap: The maximum number of validators per operator will be increased from 500 to 1,000, providing greater flexibility and scalability for large-scale staking operations.
    4. Timeline: Q4 2024
  3. Pectra Readiness
    1. Objective:
      1. The Pectra readiness update prepares the SSV Network for compatibility with the upcoming Ethereum “Pectra” hard fork (EIP-7600). This fork introduces significant changes, including an increase in the maximum effective balance for validators, which requires corresponding updates to SSV’s systems.
    2. Key Changes:
      1. Refactored Operator Fees and Staker Payments: The mechanism for calculating and distributing operator fees was restructured to accommodate the dynamic changes in validator balances. This ensures that fees remain fair and proportionate, even with the new balance limits.
      2. Refactored Cluster Liquidation Mechanism: The cluster liquidation process was updated to account for the changes in validator balances, ensuring that liquidations occur smoothly and in accordance with the new protocol rules.
      3. Webapp and Explorer Support: Both the webapp and the explorer were updated to handle the changes brought by the Pectra upgrade. This included modifying the interfaces to display the new validator balance limits and updating the backend logic to support the new fee and liquidation mechanisms.
    3. Timeline: No later than one quarter after the Pectra hard fork (EIP-7600) occurs.
  4. SSV Tooling
    1. SSV-DKG Enhancements:
      1. Objective: Continue advancing the Distributed Key Generation (DKG) protocol by adding resharing and resigning capabilities, which are critical for improving user experience and enhancing the security of the DKG process.
      2. Technical Details:
        1. Resharing Capability: This feature allows for the redistribution of validator key shares without requiring a full reinitialization of the DKG process. It ensures that validators can adjust their key shares dynamically in response to changes in the network or validator group composition.
        2. Resigning Capability: This feature enables validators to securely resign from their positions within a validator group without compromising the overall security of the group’s keys. It builds on the existing zero-coordination protocol, ensuring that the resignation process is both secure and efficient.
      3. Timeline: Q4 2024
  5. SSV-SDK Development:
    1. Objective: Consolidate all SSV-related tools into a unified Software Development Kit (SDK) that is available in multiple programming languages. This project is expected to continue into 2025 and beyond.
    2. Technical Details: The SDK will integrate various standalone tools, providing a cohesive library that simplifies the development of applications on the SSV Network. It will include bindings for popular languages such as JavaScript, Python, and Rust, making it accessible to a broad range of developers. The SDK will also offer extensive documentation and example code to facilitate easy adoption.
    3. Timeline: Continuous work starting from Q4 2024.
  6. Webapp & Explorer
    1. Objective:
      1. Ensure continuous maintenance and development of the SSV webapp and explorer to optimize performance and maintain compatibility with upcoming protocol changes.
    2. Technical Details:
      1. Optimizations: Regular performance optimizations are applied to both the webapp and explorer, including improvements to data retrieval times, UI responsiveness, and scalability to handle an increasing number of validators.
      2. Compatibility Updates: As new protocol features are introduced (such as those from the Alan Fork, Committee Consensus, and Pectra updates), the webapp and explorer are continuously updated to support these features. This includes backend updates, API adjustments, and UI changes to ensure seamless integration of new functionalities.
    3. Timeline: Continuous work.
  7. Incentivized Mainnet Program
    1. Objective:
      1. Conduct research and development to design a revised incentivized mainnet program that ensures the continued operation and engagement of the SSV Network community beyond the program’s current conclusion in 2025.
    2. Technical Details:
      1. Research Focus: The research focuses on sustainable incentive models that can maintain validator participation and network security. This includes exploring new reward structures, performance-based incentives, and community-driven governance mechanisms.
      2. Design Implementation: The new program design will be implemented in phases, with ongoing testing and adjustments based on community feedback and network performance metrics.
    3. Timeline: Proposal estimated to be provided by EOY.
  8. Second Client Development:
    1. Objective:
      1. Support the ssv.network DAO in shaping of requirements for a second client implementation. If the ssv.network DAO is happy with the outcome of such requirements and finds an implementation team for the second client, then ssvlabs will support the implementation team in whatever they might need to build and implement a performant and robust second client for the ssv.network protocol. This will be a considerable effort requiring multiple teams within ssvlabs to work with such an implementation team for months if not years.
    2. Timeline: Continuous from the DAOs decision to pursue this improvement to a production ready second client.
  9. Audits
    1. SSV Spec (Committee Consensus Upgrade):
      1. Objective: Ensure the robustness and security of the new Committee Consensus specifications through a comprehensive audit process.
      2. Audit Scope: The audit will cover the updated consensus mechanisms, network topology changes, and any new protocols introduced. The goal is to identify potential vulnerabilities and optimize performance before full deployment.
    2. SSV Node (Committee Consensus Upgrade):
      1. Objective: Verify the integrity and efficiency of the SSV node software following the Committee Consensus upgrade.
      2. Audit Scope: This audit will focus on the implementation of the new consensus algorithms, memory and CPU optimizations, and the ability of the node software to handle the increased validator load. The audit will include stress testing and performance benchmarking.
    3. SSV Smart Contracts (Pectra Upgrade):
      1. Objective: Ensure that the smart contract changes required for the Pectra upgrade are secure and function as intended.
      2. Audit Scope: The audit will evaluate the modifications to the operator fee structures, staker payment mechanisms, and cluster liquidation processes. It will also assess the compatibility of these changes with the upcoming Ethereum Pectra hard fork.
    4. SSV-DKG (Resharing & Resigning Upgrade):
      1. Objective: Validate the security and functionality of the new resharing and resigning features in the SSV-DKG protocol.
      2. Audit Scope: This audit will examine the cryptographic security of the resharing and resigning processes, ensuring that they do not introduce vulnerabilities into the DKG system. The audit will also assess the user experience improvements these features are designed to provide.

Budget

As ssvlabs has requested in the past, the total compensation for the Achievements, as well as, Potential improvements is 6.000.000 USD denominated in SSV, based on a 30-day moving average calculated on the 1st of the month in which the payment is executed. All funds shall be sent to 0x935Cea9196a22E59934Aa036143dEDA0e482f3E4. This compensation is to be paid out by the ssv.network DAO Multi-Sig Committee in the following schedule:

1 Like
2

I highly recognize the contributions of SSV Lab, especially the development of the Batch operation feature, which I believe is a catalyst for DVT. I also fully understand the funding required for team development, particularly since I am in the software industry as well. Therefore, I have great confidence in this proposal; it is a necessary expenditure to support SSV’s future. However, I feel that this proposal lacks one aspect: what funding sources SSV DAO will use to support this expenditure, especially considering that the current income from the SSV protocol is limited and that there are also constraints on the funds available in the DAO treasury.

1 Like
3

This is an excellent question. The DAO will soon present its budget for the next couple of years and also present ways to fund the project with all perspectives in mind. It would have been ideal to have this ready side-by-side, but it took the working group a bit more time than expected. Stay tuned…

Also, I don’t have the exact numbers with me, but I think that the current treasury can satisfy the claim. The working group, along with the MoC, will certainly have a look and provide guidance before this goes to snapshot.

Thank you very much!

1 Like
4

This is definitely good news. As SSV enters the mainnet and the DVT process gradually advances, a healthy economic cycle becomes very important for future development. Thank you.

2 Likes
5

No doubt that the need for continuous improvement of the software is paramount. The protocol’s existence depends on it. And the labs team has done an absolutely outstanding job with it. All of that said, I think it would be a good practice to have a slightly deeper budget detail so that the DAO has some understanding of how the total budget was developed. What portion is retroactive and what is forward looking? How long is this funding expected to sustain the development team? Is there a basic work-up to the amount, or perhaps estimated dev hours or something that can be fairly evaluated to understand where the number is coming from?

I’m a supporter but I feel some of this information would be helpful to make an informed decision.

3 Likes
6

Big thanks to the SSV Labs team for all the hard work and to Ben Affleck for this proposal!

After using SSV Network for the past three months, I really see the effort that goes into keeping it running smoothly.

I agree with @Hackworth and @Yuting about needing more details on the financials. Excited to see the budget plans for the next few years!

3 Likes
7

Thanks for all the details Ben glad to see SSV Lab putting so much effort on the table. I am curious about a couple of things.

  • How was the $6m calculated? Are there any breakdown of expected costs viewable by the community?
  • Is there a specific strategy in place for how the tokens are going to be sold to minimise market volatility?
2 Likes
8

No more ssv token inflation please! You should increase ssv token value to get fund(so that you can sell your current ssv token for more fund to do things you want to do ) instead of mint new ssv token!!!

1 Like
9

I see that this has moved to a vote on snapshot, but it appears to me that there are questions here that are still outstanding.

3 Likes
10

@Hackworth @LemmaGov @AXBLOX

Thank you very much for your thorough questions, which I tried to get answers to in the background. While the 7-day period has started on snapshot, there is still time to ask questions, vote no, or abstain from the vote.

What portion is retroactive and what is forward looking? How long is this funding expected to sustain the development team?

A: According to the proposal, this is retroactive compensation for 2024. The milestone structure has been updated to accommodate the DAO (see the budget section). Overall, SSV Labs is expected to continue the work according to the ‘Potential Improvement’ section and ask for another retroactive grant sometime in 2025, which the DAO needs to benchmark against the actual achievements.

Is there a basic work-up to the amount, or perhaps estimated dev hours or something that can be fairly evaluated to understand where the number is coming from?

How was the $6m calculated? Are there any breakdown of expected costs viewable by the community?

A: The proposal summary section has been updated to give some rational. The 6M only represents a fraction of the actual expenses, and the number of personnel has grown over the last year, and so has TVL. To give some history, this has been debated already during SSV x Blox grant proposal [Core Development Team Grant]. The ’ Suggested Grant for the Core Dev for these Services’ section has kind of a breakdown. The proposer hopes that this, together with the updated summary, is enough rationale for the number. With the achievements in mind, do the numbers make sense?

Is there a specific strategy in place for how the tokens are going to be sold to minimise market volatility?

A: No. The DAO has not enforced any lock-up or vesting period for grantees thus far. This not only applies for SSV Labs, but for all grantees of the SSV DAO grants program. It has not been debated if this is a need for the DAO. Since the success of the project, the token and the grantee are interconnected for obvious reasons, one can imagine that this is treated with care.
Also, I’d like to highlight the reports from market makers showing high trading volume on commen exchanges. Although the asked numbers are high relative to the DAO’s Budget, they are low compared to the daily trading volume of the SSV token.

2 Likes
11

:vertical_traffic_light: Voting is now open!

ssv.network Proposal: [DIP-24] SSV Labs Core Development Team Grant (snapshot.org)

1 Like
12

@BenAffleck, hello! I believe I have found a typo (both here and in the Snapshot). It should be 2024 rather than 2025, as soon as the program was revisioned till December 2024 ([DIP-18] Incentivized Mainnet Program - Revision).

1 Like
13

Hello @irina-everstake! Good catch. I leave it here for the record. Thank you very much for pointing this out.

15

The numbers make sense. Thanks for the context.

1 Like