Development of SSV.NETWORK Data & Information Aggregator Kepler

Proposals Grants
1

Background

With the official announcement of the launch of the Kiln public testnet by the Ethereum Foundation, the “merge” of Ethereum from PoW to PoS is one step closer to becoming a reality. Our team firmly believes that after the merge of Ethereum, we will face a brand-new public chain pattern and Ethereum will become the world settlement layer and ssv.network will be the decentralized staking infrastructure protocol of Ethereum. It is an indispensable part of the merged territory, and it must have great development opportunities. In this regard, according to our participation in the test network, as a validator, operator, and participant in the development of test network tools, we found the following pain points:

  • There is not enough in-depth understanding of the role of ssv.network in the market when Ethereum turns to POS, and the information is not concentrated enough, which will indirectly lead to the loss of new users.
  • Most users do not know the specific development trend of ssv.network.
  • Most users don’t know how to select operators, and they don’t have information about operators’ operation data, such as history records, operator team information, contact information, etc.
  • In the testnet, the participation threshold of the validator is too high and the process is complicated.
  • The network status data is not clear, such as the current network operator certification record, the number of new operators or validators, the proportion of new ones, and the proportion of staking in the whole network.

Therefore, there are the following proposals.

Approach

Overview

In the process of becoming an operator, we have compiled a reward query tool and a reward ranking tool for the test network to help the validator generate a validator key tool and help ssv.network further expands the marginal market. Therefore, we propose a data information aggregator Kepler. Based on the original tools, To provide users, operators, and validators with services of data analysis, information aggregation, and simple tools, Kepler’s vision is to become a data information provider of ssv.network, which mainly has three data information levels:

  • Beta 1.1: The real-time network status of SSV. Network, including the change curve of validator, operator and transaction volume of the whole network, the false proof, the global distribution of operators, the distribution of operators who do not meet the score, SSV rich list and a large amount of money transfer, etc., which we will show in the form of charts.
  • Beta 1.2: Comprehensive ranking of operators’ health. We will use a high-quality model to provide users with the ranking of operators’ health through modeling and analysis, aiming at transparent operators’ performance and allowing users to make better choices, including but not limited to social media quality, number of validators, node performance score, team influence, participation time, etc.
  • Beta 1.3: Information aggregation page in English and Chinese. Our crawler scans the related articles of ssv.network in the whole network, and brings the most complete and up-to-date information map to users through algorithm and manual audit. The main purpose of this part is to help users screen information, and quickly understand the development of ssv.network, and join the ssv.network ecosystem. Affiliate: Hellman team will publish ssv.network network health report from time to time.
  • Beta 1.4: Utility tools and revenue query tools. At present, according to the V1 test network, we have provided revenue inquiry tools and tools for generating validator keys. We will provide users with simpler testing tools and revenue calculation tools (based on community feedback) according to the situation of the V2 test network, so as to lower the threshold of users and make it easier for validators to participate in the network. At the same time, with SSV.On the main NETWORK line, we will also provide two sets of data of the test network and the main network.

V1: Wait for the SSV main network to come online before planning.

Kepler target

To sum up, Kepler mainly serves three kinds of people:

  • Users. We provide a visual network health data panel for users interested in ssv.network, so that users can know the network status in time.
  • Validators. In addition to the network data, we provide the validator with an operator ranking, revenue query, test network tool, etc., so that the validator can quickly participate in the network and select the most suitable and stable node.
  • Operators. Query operator database information, quickly locate operator ranking and health information, facilitate operator comparison, improve operation and maintenance technology, and provide a more stable environment for ssv.network.

Kepler Project Plan (June-October 2022)

Kepler’s goal is to retain every user, so that everyone can easily become a validator, and assist the ssv.network test network to proceed smoothly. On this basis, it provides a network health measurement index for operators and users.

The first stage (Beta 1.1, June-July 2022):

  • Product planning: module planning, and UI design;
  • Type of data: network performance data, validator and operator data, error-proof data, SSV rich list data, etc. (The technical framework includes front-end and back-end services, scheduled tasks, database, message queue, and cache);
  • Visual display of historical data: network and operator health data.
  • The technical framework includes front-end service, back-end service, scheduled task, database, message queue and cache.
  • Grab the relevant data of operator, validator, and SSV for aggregation calculation and develop relevant interfaces.
  • Implement the front-end corresponding page and connect with the back-end.

The second stage (Beta 1.2, August-September 2022):

  • Operator database collection: social media, number of validators, node performance score, goodwill, false proof, participation time, etc.;
  • Multi-dimensional stage operation score ranking.
  • Add related tables to realize the management background and enter data into the database through the management background.
  • Add related interfaces and sort them.
  • Add related front-end pages and interface with back-end.

The third stage (Beta 1.3, October 2022):

  • Collection and selection of Chinese and English materials: entry-level, technical section, operator section, validator section, etc.
  • The realization of content capture.
  • Add related tables to realize the management background and enter data into the database through the management background.
  • Add related interfaces and implement filtering and searching functions.
  • Add related front-end pages and interface with back-end.

Beta 1.4, as an affiliated version, goes online from time to time according to the situation of V2. Contents included in Beta 1.4:

  • V2 testnet income;
  • Simple tools.

However, this part can only be introduced according to V2 rules and market conditions.

Grant Breakdown

For the above planning, we need management, product managers, designers, and frontend and backend technicians, and the total development cost is USD 90,000. Stable currency or SSV can be accepted. The form of payment is mainly divided into three stages (it would be better if 50% advance payment can be made in advance for each stage).

Time and Compensation evaluation of functions

image
image965×157 25.2 KB

V1 applies for funding independently according to the online situation of the SSV main network.

Mainnet release notes

  • If there is little difference between the mainnet and the V2 architecture, we will automatically upgrade to ensure that Kepler can transition to the mainnet smoothly;
  • If the architecture is very different compared with V2, we need to apply for a grant again to support our development work.

All in all, we will try to ensure that Kepler is adaptable to the mainnet.

Team

Hellman is a Web 3 research institute focusing on Dao, NFT, ETH, and layer 2, and is actively involved in POS projects. Hellman has participated in pools and research such as Filecoin and Swarm, and has rich experience in PoW and PoS pools. And now we are actively involved in the ssv.network project.

Building Kepler is our beginning, it doesn’t mean the end. At the same time, we are also planning the staking pool. Once we have determined it, we will first tell the community so that more people can use the services of SSV.

Core member

MMT

6 years of experience in network operations and maintenance. Used to work at Hello Bike Inc., Eleme Inc. and Wind Information Co., Ltd. Proficient in Python and Data mining & analysis

Jack

Back-end engineer with more than 3 years of blockchain development expertise and server operation. Familiar with the technical architecture of the mainstream chains

Tony

Marketing and research analyst, used to work at BTCchina. Capable of conducting extensive research in the blockchain and token economy

Twitter : https://twitter.com/HellmanResearch

Website: https://hellman.team

V1 Tool: https://rewards-ssv.hellman.team

Our V1 node:

https://explorer.ssv.network/operators/e4edcb950ee9f4a4f89dde5e9b74b615c04f21f204884bc53ffe2bebbcea4b93

If you have any questions or doubts, you can contact us ( MMT | Hellman#8361 ).

3 Likes
2

Great initiative!

I think data transparency is crucial and should be developed to a much greater extend than we have today.
I’d love to see your vision + wire frame design + specific statistics as a pre-curser for beta 1.1, that will give the grant committee and community a much clearer sense of what you envision for this.
That can be done as after the grant proposal as kind of the first step.

3

Thank you very much, Beta1.1 mainly considers the health data of the network; Beta1.2 mainly considers the role data of the network, such as OP.

4

Could you detail more the grant payment you request?

5

Our vision: to become the data & information aggregator of SSV. We want every new user to know all the information about SSV, network status and OP status through Kepler.

Preliminary prototype manuscript:

image
image925×631 93.1 KB

image
image863×614 60.8 KB

Data includes but is not limited to the above.

1 Like
6

Of course, we can divide it into three stages: Beta1.1 ($30,000), Beta1.2 ($40,000) and Beta1.3 ($20,000).

Payment schedule: We’d like to be able to give us 50% of the startup grant at the beginning of each stage; after this stage is over and launches the community, we will be paid for the remainder of the stage.

Payment type: SSV or stablecoin.

1 Like
7

Unless there are specific considerations I think the approach the DAO should take is grant payment for execution (no upfront payment).
I’ll let @fod write down his thoughts as he will be leading the grant committee

8

This looks really good, I think this will help the community make a decision!

2 Likes
9

I don’t think we should accept proposals where the grant payments are made 100% upfront, and I think requests for any upfront payments should be seen as unfavorable compared to those that are willing to complete each task first. But I do understand that partial payments are often necessary to pay developers to begin the work, and if this is the case, then I’m fine with this arrangement. They should just be aware that requiring more payment upfront makes their proposal less competitive and might come with a greater need to track the team’s progress (updates, demos, etc.).

I also think we can relax this slightly as we develop relationships with different teams. In general, I view all of this as a function of how much trust we have in the given team. There’s a big difference between a company like Consensys and a small team of developers that doesn’t have an extensive portfolio of successes or a reputation to protect. I view Hellman as closer to the later, but they are not starting from zero— they have been great members of the community and high-performing verified operators, and they took the initiative to create a few very helpful tools for the testnet.

With that said, in regards to this proposal specifically, I think $90k is a large request, and I think we should be selective for jobs of this size. But I think asking for $15k (50% of the first payment) upfront is reasonable to balance risk for both parties involved, with the expectation that the work must be of high quality for additional payments to be released. If we want to be more conservative (especially for new teams that want to prove themselves), then I think it would also be reasonable to ask for the completion of a first (small) task before any payment, then maybe allow for 50% of the subsequent payments to be made upfront.

However, I would prefer to wait before moving forward with this proposal. I think we should pass the grant program first, and we should make sure we are advertising our needs widely to encourage other teams to compete for grants, especially for tasks like building an explorer, where we only plan to issue one or two grants. I do think this is a great proposal though! Thanks for creating a design prototype and explaining your vision thoroughly.

5 Likes
10

Update: We are delaying all plans by one month, starting in June.