Staking Router Module Proposal: Simple DVT

Proposals
42

This is an update regarding the Easy Track motion that has just gone live via the Simple DVT Module Committee that would add the 12 SSV Cohort 1 clusters to the Simple DVT Node Operator Registry on mainnet.

In addition to signed messages confirming each participant’s agreement to the Operating Rules of the Simple DVT Module for Lido x SSV Node Operators, the following link contains sheets showing Cluster Manager Addresses, Wrappers, and 0xSplits addresses well as all of the participant Individual Manager and Individual Reward Addresses tied to each cluster: https://docs.google.com/spreadsheets/d/1Y7v35jVzdRxFnuOxK6Zz1K4AldcCSowgQQPb4HiOmdU/edit?usp=sharing

If this motion passes, it is expected a subsequent set of motions will be created over the next two weeks to raise the key limits of these SSV Simple DVT clusters to 5 validators. Once validators are deposited to, a monitoring period will be in place to assess cluster performance, and an update will be made in this thread to share the results of the first 30 days.

It is expected that if this performance is comparable to other mainnet operators, a proposal will be made to begin the process of adding clusters from Cohort 2 to mainnet and potentially raise key limits for the existing clusters.

9 Likes
43

The NOM contributor workstream on behalf of the Lido Node Operator Subgovernance Group (LNOSG) would like to provide an update regarding the Obol Cohort 2 Simple DVT mainnet participants.

The proposal for both Obol Cohort 1 and Cohort 2 passed the DAO discussion period in February. During the first step of the Cohort 2 onboarding stage, one participant, ryssroad, a member of Cluster 20 (aka Lido x Obol Tranquil Turtle) has failed to respond within their cluster thread to complete the required address verification steps despite multiple attempts of contact.

As a result, the LNOSG has discussed the situation and would like to propose adding the P-OPS team as a replacement to the Tranquil Turtle cluster. The P-OPS team has participated in multiple Lido DVT testnets and demonstrated their ability to run a performant Obol node and remain responsive. In addition, they have already been approved to participate in Lido x Obol Cluster 26 where all preliminary steps have been successfully completed.

P-OPS would run infrastructure from the same region as other participants of the Tranquil Turtle cluster and use the same set of relays. Given this, the team should be able to quickly onboard.

The changes can be seen in the following spreadsheet: Proposed Lido x Obol SDVT Clusters - Google Sheets

The Updated Proposal (17.6.24) sheet includes the updated participant proposals, the Participant Updates sheet shows the change of participants per cluster, and the Original Proposal sheet shows the clusters proposed on February 22.

A week discussion period is now open for the DAO to consider the change, whereafter if no additional changes are sought the P-OPS team will officially be part of the Tranquil Turtle cluster.

2 Likes
44

The Simple DVT Module Committee has started an Easy Track motion that is currently active that would add the 14 Obol Cohort 2 clusters to the Simple DVT Node Operator Registry on mainnet.

In addition to signed messages confirming each participant’s agreement to the Operating Rules of the Simple DVT Module for Lido x Obol Node Operators, the following link contains sheets showing Cluster Manager Addresses, Obol Wrappers, and 0xSplits addresses well as all of the participant Individual Manager and Individual Reward Addresses tied to each cluster: Public Master Address Form (Obol Mainnet) - Google Sheets

If this motion passes, it is expected a subsequent set of motions will be created over the next 10 days to raise the key limits of these Cohort 2 Obol Simple DVT clusters to 5 validators. Once validators are deposited to, a monitoring period will be in place to assess cluster performance, and an update will be made in this thread to share the results of the first 30 days.

It is expected that if this performance is comparable to other mainnet operators, a proposal will be made to begin the process of raising key limits for the Cohort 2 clusters.

4 Likes
45

Incident Report in Cluster Lido x Obol: Vivacious Viper

Introduction:
Hello, my name is Anton, and this report aims to detail the critical incident that occurred during the DKG setup process within our cluster, outline the sequence of errors, and discuss the corrective measures I will implement to prevent such issues in the future.

Description of the Incident:
The incident occurred during a coordinated effort by the team to launch the DKG. An error message ‘cause keys/files exist already’ appeared, prompting an immediate check within the team to ensure all validator keys and related files were correctly created and in place. Upon reviewing my setup, everything appeared to be in order, yet a subsequent error indicated an issue with the encryption key being incorrect.

Immediate Actions Taken:
In an attempt to resolve the encryption key error, I consulted ChatGPT for assistance on modifying the key. Despite following suggested changes, the error persisted. Under the pressure of resolving the issue promptly and the fatigue from recent travel, I made the decision to generate a new key and delete the old one. This action led to the irreversible loss of the original key, causing a delay and potential security concerns for the DKG setup process.

Impact of the Incident:
The deletion of the original key not only delayed the DKG setup but also posed a risk to the integrity and security of the system, if it had not been discovered. This incident likely caused inconvenience and raised concerns among the team and stakeholders involved.

Corrective Actions and Preventative Measures:

  1. Enhanced Verification: Before making any changes to critical components such as encryption keys, a verification process will be established to double-check the alignment with system requirements. This step will ensure that modifications are necessary and correctly implemented.
  2. Rest Protocol: Recognizing the role that fatigue played in this incident, a mandatory rest period will be instituted after extensive travel before engaging in critical system operations.
  3. Backup and Recovery Protocols: Our backup procedures will be strengthened to ensure that multiple copies of essential keys are securely maintained and accessible before any modification or deletion is attempted. Additionally, backups will be performed after every significant procedural step to secure our data further and ensure continuity.
  4. Team Communication and Error Handling: Improve communication within the team to ensure that all members are immediately aware of errors and the steps required to rectify them. This will include detailed checks and verifications whenever an error related to setup or existing files is encountered.

Conclusion:
I sincerely apologize for the oversight and the resultant complications it may have caused. My commitment to learning from this mistake is firm, and I am dedicated to implementing these measures to enhance our operational protocols, ensuring our system’s robustness and reliability.

This draft of the report aims to comprehensively address the incident, the steps taken, and the future measures to mitigate such risks, providing a clear and structured response to the situation. maintained and readily accessible before any modification or deletion is attempted. Additionally, backups will be performed after every significant procedural step to secure our data further and ensure continuity.
Team Communication and Error Handling: Improve communication within the team to ensure that all members are immediately aware of errors and the steps required to rectify them. This will include detailed checks and verifications whenever an error related to setup or existing files is encountered.

4 Likes
46

Thank you for the public communications and transparency regarding the incident Anton.

The Vivacious Viper Cluster members discussed the situation amongst themselves in addition to a conversation that took place amongst the Lido Node Operator Subgovernance Group. Both groups have agreed that given the transparency on Anton’s side as well as the proposed corrective actions and preventative measures that he should continue to participate as a member of the cluster.

I believe that if the above corrective actions and preventative measures are followed, the Vivacious Viper cluster will move forward without issue.

Looking forward to seeing your group’s validators online in the coming weeks!

6 Likes
47

Hello everyone, I am Massimo, Developer Relations from the SSV Labs team.
I wanted to provide an update regarding the work SSV core team has been doing on the smart contract.

Permissioned Operator whitelisting smart contract upgrade live on Holesky

This release has undergone an official audit.

Edit: updated audit link

Main Changes

You can expect this update to be deployed on mainnet in the upcoming weeks, pending on the audit report and multi-sig update. If required, make sure to make adjustments in advance.

:warning: Official version release :warning:

An officially tagged version of the contract has not been created on the ssvlabs GitHub repository, but it will be generated before the upgrade is deployed to Mainnet. Please monitor the Releases page to stay up to date.

5 Likes
48

The Simple DVT Module Committee has started two Easy Track motions 1. that will raise the key limit for Cohort 1 Obol Clusters to 40 validators, and 2. that will raise the key limit for a portion of the SSV Cohort 1 validators to 5 validators (another ET is expected in the coming days for the final two clusters).

The Obol Cohort 1 limit increase follows the performance report discussed here, with another performance report expected to follow in the coming weeks.

When the next two clusters in SSV Cohort 1 have their key limits raised and validators deposited to, the initial 30 day performance monitoring period for SSV clusters will begin with a performance report to follow. If the performance is comparable to the overall validator set, a proposal will be made to raise the key limits and begin the onboarding of SSV Cohort 2.

4 Likes
49

The NOM contributor workstream on behalf of the Lido Node Operator Subgovernance Group (LNOSG) would like to provide an update regarding the results of the Simple DVT Super Cluster participant evaluations that took place on July 16th, 2024. This evaluation meeting follows the Snapshot vote for the Expansion of the Simple DVT Module. Information about the Simple DVT Module is available here.

As mentioned in the Simple DVT Module Proposal, in order to broaden the scope of operator categorization of Node Operators utilizing the Lido protocol, a classification of “Advanced Node Operators” was suggested. For clarity, three different classifications of Node Operators now exist in the operator groupings:

  1. Curated Node Operators (CNOs) - Professional Node Operator teams that are members of the Lido on Ethereum Curated Module.
  2. Advanced Node Operators (ANOs) - Professional Node Operators, Solo Stakers, and Community stakers that have demonstrated the ability to run performant nodes and remain responsive via Simple DVT testnets and mainnet. Any Simple DVT Cluster that runs more than 100 validators must consist of 50% Advanced Node Operators.
  3. Solo (or Independent) & Community Stakers - non-professional Node Operators participating in running Ethereum validators. Solo stakers run validators & DVT nodes alone, while Community Stakers are groups working together.

Super Cluster Participant Evaluation

A discussion was had to suggest which participants should be part of the 5 Obol and 5 SSV Super Simple-DVT Clusters. In addition, a list of backup operators were identified in the event participants from the proposed list (should it be accepted) cannot move forward. Additionally, the proposal is that all of the identified operators will be classified as Advanced Node Operators unless they are already considered a Curated Node Operator. Additional Advanced Node Operators are expected to be proposed in the future.

A total of 230 participants were assessed for inclusion, all of which have already been accepted to proceed to mainnet Simple DVT across Lido clusters with Obol and SSV Network.

Given the relatively larger number of validators expected to be run by Super Clusters (maximum of 500), the LNOSG opined that a higher percentage of professional Node Operators should be included, however solo and community stakers were also considered.

1262×627 68 KB

1238×637 61.6 KB

Evaluation Results

During the evaluation discussion, the LNOSG together with mainnet and testnet coordinators from the Lido DAO NOM Workstream, Obol, and SSV Network teams suggested 70 unique participants across 10 clusters with a 5/7 threshold configuration be onboarded to mainnet Obol and SSV Super clusters in the Simple DVT Module. The proposed participants include 7 solo / community stakers in addition to 63 professional node operators, including some CNOs. In addition to the cluster proposal, an additional 28 participants are being proposed for the backup list. All of the aforementioned participants that are not CNOs would be classified as Advanced Node Operators.

All of the candidates proposed by the LNOSG were considered to have shown strong performance, responsiveness, and reliability over the course of both testnets and during mainnet onboarding application assessments. The proposed clusters would balance client and geographic diversity to promote infrastructure resilience.

The proposed participants have been asked to confirm their desire to join the Simple DVT Operator Set via a Super Cluster. In case they do not reply affirmatively in a timely manner, or for some other reason cannot participate, the LNOSG will make an adjustment to the proposed list and share an update in this thread.

During the final meeting on July 17th, 2024, the LNOSG suggested to propose the following participants and cluster-makeups for inclusion into the Lido Simple DVT Module Ethereum protocol:

Proposed Lido Super Clusters

The full PDF with summary statistics and the LNOSG meeting recordings of the introduction, final conclusion and cluster proposal can be found in the public drive below. Due to the privileged/confidential nature of some of the information provided in some of the applications, the portion of the call where cluster makeups were discussed in detail was not recorded.

https://drive.google.com/drive/folders/1xU1BgmivCfcmI3n9WRCeZZL0q62C7BNE

All participants have been emailed notifying them of the proposal and are welcome to reach out via email to [email protected] for further clarification.

Path to Mainnet

If there are no objections or changes requested to the proposed list of participants by the DAO, onboarding will begin in the coming weeks.

Super Clusters will start with 50 depositable keys after they have been onboarded to the Simple DVT Module. After an initial 14 day monitoring period, a performance report will be presented to the DAO. If the performance is comparable to other mainnet operators, a proposal will be made to raise the key limits of the clusters to 200. Once those validators are deposited to and active for 14 days, another performance report will be presented with a potential proposal to raise limits to 500 validators.

DAO Discussion Period

A 7 day discussion period is now open for the DAO to discuss the proposed participants for the Super Clusters within the Simple DVT module.

Should the DAO disagree with any of the proposed applicants, request additional information, or otherwise request additional input for the onboarding, the LNOSG will reconvene to propose a next course of action.

If after 7 days, no major changes are required by the DAO, the Simple DVT coordinators from the Lido DAO NOM Workstream, Obol, and SSV Network will begin the coordination process with cluster participants.

Next Steps

If no adjustments are required after the week discussion period, the Super Clusters will soon be added to coordination threads and begin the process of verifying addresses and setting up cluster multisigs. The Lido Simple DVT Module Committee will propose their entries in the Simple DVT Node Operator Registry via Easy Track, and clusters will submit keys to the Lido Simple DVT Module once they are deemed to be ready for deposits.

An update will be posted to the research forums before validator key limits are raised for any clusters.

6 Likes
50

As mentioned here, the Easy Track motion to start raising key limits for Obol Cohort 2 clusters has started here: Lido Easy Track.

An additional Easy Track motion is expected to begin in the next few days for the remaining 4 clusters. Once both of these Easy Track motions are complete, the 26 Obol Clusters approved for onboarding so far will be eligible to run validators via the protocol.

A performance report will be shared 30 days after the Cohort 2 Validators have been fully activated.

1 Like
51

The NOM contributor workstream on behalf of the Lido Node Operator Subgovernance Group (LNOSG) would like to provide an update regarding the proposed SSV Super Cluster 3.

The Gateway.FM AS team has decided to withdraw from their participation spot. After discussion with the LNOSG, it was suggested that one of the the backup Node Operators for SSV, Cryptonative Systems, should replace Gateway in the cluster. Like Gateway, Cryptonative Systems will run infrastructure in the Europe region, has a range of EL and CL clients they can support, and provides additional hosting diversity to the cluster.

The discussion period for this cluster will be extended to a week from the time of this post, however given that Cryptonative Systems is already being proposed as a backup Advanced Node Operator, the cluster will begin optimistic onboarding with them filling in as a replacement for Gateway this week.

3 Likes
52

Summary

This update serves as the second performance report for the 12 Lido x Obol Cohort 1 clusters active on mainnet via the Simple DVT Module. Given an increase in performance across all metrics, it is proposed that the key limits for Obol Cohort 1 are raised to 80 validators in a phased approach.

Performance Analysis

Obol Cohort 1 validator performance has continued to be tracked and monitored since the May 2nd activation date. As a reminder, over the course of the initial monitoring period of May 2nd to June 6th, Average Uptime across clusters stood was 99.95%, the Average Validator Effectiveness was 96.48%, and the Block Proposal Success Rate stood at 73.68%, with 14 proposed blocks and 5 missed blocks (though from May 7 - June 6th the Block Proposal Success Rate was 100% as explained in the prior report).

Since that time, the number of validator keys has been increased to 40 per cluster from 5 in the first period (a total of 480) and there has been an improvement across all metrics: with Average Uptime now at 99.96%, Average Validator Effectiveness of 96.91%, and a Block Proposal Success Rate of 86.76%. Importantly, Average Validator Effectiveness continues to outperform the 30 day Network Performance as per Rated of 96.32%.

For a detailed overview of cluster level metrics & the list of validator keys, see the analysis: Obol Cohort 1 Performance Metrics - Google Sheets

Proposed Next Steps

Given the strong results, it is proposed that the key limits for Lido x Obol Cohort 1 clusters be raised to a maximum of 80 validators each until the next performance monitoring period (which will end no earlier than 37 days after the publication date of this update), in a phased approach of raising the key limits to 60, followed by an additional raise to 80 after the initial 20 additional keys have been deposited to and observed to activate without issues.

The relevant Easy Track motions for these key limit raises would be communicated in this thread and would follow the default approach of being veteoable by LDO holders over a 72 hour period.

In the coming weeks, performance updates will be shared for SSV Cohort 1 and Obol Cohort 2.

This begins a 7 day discussion period for the DAO to consider the performance report and proposal to raise key limits to 80 validators in a phased approach for Obol Cohort 1.

7 Likes
53

The NOM contributor workstream on behalf of the Lido Node Operator Subgovernance Group (LNOSG) would like to provide an update regarding the Lido x Obol Cohort 2 Cluster Vivacious Viper.

Due to a misconfiguration error followed by an issue trying to restore his Obol node from a backup, the participant Anton_Duzhenko has decided to withdraw from participation in the Simple DVT Module.

After discussion with the LNOSG, it was suggested that one of the backup Advanced Node Operators for Obol, Anonstake, should replace Anton in the cluster. Like Anton, Anonstake will run infrastructure in the Europe region and has a range of EL and CL clients they can support within the cluster.

As the cluster has 5 active validators, an Easy Track motion will be created by the Simple DVT Module Committee to set the targetLimit of the cluster to 0 validators so that this cluster is prioritized for exits.

Once this process is completed, the existing submitted (but undeposited) keys will be removed from the Simple DVT registry, Anonstake will be cycled into the cluster, and the cluster rewards address will be updated. This will be followed by a new DKG and key submission period for the cluster.

Anonstake was already proposed as one of the backup Advanced Node Operators in the July 18th proposal. An updated list of cluster participants with Anonstake replacing Anton is available to view here: Proposed Lido x Obol SDVT Clusters - Google Sheets

A discussion period is now open for a week for the community members to consider the replacement and raise any questions or concerns.

1 Like
54

This is notice that an Easy Track motion has now been started to create the 5 Lido x Obol Super Cluster entries via the Simple DVT Node Operator registry: Lido Easy Track

In addition to signed messages confirming each participant’s agreement to the Super Cluster Operating Rules of the Simple DVT Module for Lido x Obol Node Operators, the following link contains sheets showing Cluster Manager Addresses, Obol Wrappers, and 0xSplits addresses well as all of the participant Individual Manager and Individual Reward Addresses tied to each cluster: Public Master Address Form (Obol Mainnet) - Google Sheets

If this motion passes, it is expected a subsequent set of motions will be created to raise the key limits of these clusters.

Another motion is expected in the coming days to create the entries for the 5 Lido x SSV Super Clusters as well.

9 Likes
55

As mentioned in the prior comment, the Easy Track for the creation of the 5 Lido x SSV Super Clusters has now been started: Lido Easy Track

The following link contains the signed messages confirming each participant’s agreement to the Super Cluster Operating Rules of the Simple DVT Module for Lido x SSV Node Operators, the list of Cluster Manager Addresses, Wrapper contracts, and 0xSplits addresses, and each participant’s Individual Manager and Individual Reward Addresses: Public Master Address Form (SSV Mainnet) - Google Sheets

If this motion passes, it is expected a subsequent set of motions will be created to raise the key limits of these clusters in the coming week.

4 Likes
56

Summary

This update serves as the first performance report for the 12 Lido x SSV Cohort 1 clusters active on mainnet via the Simple DVT Module. Given very strong performance results, it is proposed that the key limits for SSV Cohort 1 are raised to 40 validators in a phased approach, and the key limits for SSV Cohort 2 are raised to 5 validators once they have completed onboarding.

Performance Analysis

The performance monitoring period for Lido x SSV Cohort 1 began on July 20th, the day that all 12 clusters had active validators.

During this time, as per Rated, average uptime across clusters stands at 99.97%, aggregate Block Proposal Success Rate of 100%, and Average Validator Effectiveness is 97.46%. This compares to the 30 day overall Ethereum validator set performance with an average Validator Effectiveness of 96.71%.

For a detailed overview of cluster level metrics & the list of validator keys, see the analysis: https://docs.google.com/spreadsheets/d/1yFlORj_r29HOw5Cn6HOIBSZzJpBNjUyzk1BrXFbAwb0/edit?usp=sharing

Proposed Next Steps

It is proposed that the key limits for Lido x SSV Cohort 1 clusters be raised to a maximum of 40 validators each until the next performance monitoring period (which will end no earlier than 37 days after the publication date of this update), in a phased approach of raising the key limits to 20, followed by an additional raise to 40 after the initial 15 additional keys have been deposited to and observed to activate without issues.

It is also proposed that the key limits for the Lido x SSV Cohort 2 clusters are raised to 5 validators each, with a performance monitoring period and follow up performance report to be shared no earlier than 30 days after the keys are deposited to.

The relevant Easy Track motions for these key limit raises would be communicated in this thread and would follow the default approach of being veteoable by LDO holders over a 72 hour period.

This begins a 7 day discussion period for the DAO to consider the performance report and proposal to raise key limits to 40 validators in a phased approach for SSV Cohort 1, and raise key limits to the 5 initial validators for SSV Cohort 2.

6 Likes
57

This is notification that two Easy Track motions are currently pending, the first to raise key limits to 10 for the 5 Obol Super Clusters, and the 2nd to increase key limits to 20 for the 12 SSV Cohort 1 clusters.

This follows prior notification of the respective creation of Obol SC Node Operator entries and the SSV Cohort 1 performance report. A motion to increase key limits for SSV Super clusters is also expected to be created in the coming days.

Key limits are expected to quickly be increased to 50 validators after the initial validators activate for both Obol and SSV Super Clusters, after which a 14 day performance report will be presented as discussed in the Simple DVT Expansion proposal.

4 Likes
58

A new Easy Track has been created to update the Reward Address of the Lido x SSV Cohort 2 Cluster Quiet Quetzal. This is the result of an update needed to the original address of one of the operators within the cluster.

As Cohort 2 is still in the onboarding process and has not yet activated validators, there will be no impact to cluster operations.

For the full list of addresses please see here: Public Master Address Form (SSV Mainnet) - Google Sheets

1 Like
59

Summary

This update serves as the first performance report for the 13 Lido x Obol Cohort 2 clusters active on mainnet via the Simple DVT Module. While Cohort 2 in total includes 14 clusters, due to the need to replace an operator in the Vivacious Viper cluster (discussed above) only 13 are included in this report.

Given solid performance results, it is proposed that the key limits for Obol Cohort 2 are raised to 40 validators in a phased approach.

Performance Analysis

The performance monitoring period for Lido x Obol Cohort 2 began on August 15th, the day that all 13 clusters had active validators.

During this time, as per Rated, average uptime across clusters stands at 99.98%, aggregate Block Proposal Success Rate at 76.92% (10/13 proposals), and Average Validator Effectiveness was 97.58%. This compares to the 30 day overall Ethereum validator set performance with an average Validator Effectiveness of 97.37%.

While the sample size for Block Proposals is low given the small number of validators, performance for the aggregate Cohort 2 Block Proposals were impacted by various configuration issues for certain Node Operators. Following an update to the LCDVN used by many Node Operators within the Cohort as well as confirmation from those using custom setups, the Block Proposal Success rate has been 100%.

For a detailed overview of cluster level metrics & the list of validator keys, see the analysis: Obol Cohort 2 Performance Metrics - Google Sheets

Proposed Next Steps

It is proposed that the key limits for Lido x Obol Cohort 2 clusters be raised to a maximum of 40 validators each until the next performance monitoring period (which will end no earlier than 37 days after the publication date of this update), in a phased approach of raising the key limits to 20, followed by an additional raise to 40 after the initial 15 additional keys have been deposited to and observed to activate without issues.

The relevant Easy Track motions for this key limit raise will be communicated in this thread and would follow the default approach of being veteoable by LDO holders over a 72 hour period.

This begins a 7 day discussion period for the DAO to consider the performance report and proposal to raise key limits to 40 validators in a phased approach for Obol Cohort 2.

6 Likes
60

Two new Easy Tracks have been created: the first to increase the key limit of the 5 Obol Super Clusters to 5 validators and the second to set target limit to 0 for the Vivacious Viper Cluster, which will allow for their depositable keys to receive deposits after the replacement process that was discussed above.

Another two Easy Tracks are expected in the coming days to raise the key limits for the SSV Super Clusters and Cohort 1.

3 Likes
61

Hello everyone, I am Massimo, Developer Relations from the SSV core team. I wanted to give you all a heads-up on our upcoming node upgrade. It’s a big one, will bring a lot of improvements, and as such, will require a network fork. Quick rundown:

:fork_and_knife: Alan Fork:

Named after Alan Turing, the pioneer of modern computing, this upgrade focuses on:

  • Committee-Based Consensus: Streamlines processes among operators to reduce redundancy and increase throughput.
  • Efficient Network Messaging: Targets up to a 90% reduction in the volume of network messages, fostering a more agile and responsive infrastructure.
  • It has undergone audit - the audit has been terminated, we are waiting on the delivery of the report. Going to publish results soon :tm:

:date: Implementation Timeline:

  • Testnet Launch: September 24th, 2024 - Release new version of the testnet. Node operators should update their software starting on this day.
  • Testnet Fork: October 8, 2024 - Final date for all updates to be completed for participation.
  • Mainnet Rollout: TBA. Will be scheduled based on testnet performance to ensure stability and effectiveness. Tentative date: October 20th
  • MainnetFork: TBA. Will be scheduled based on testnet performance to ensure stability and effectiveness, as well as any additional time to apply any necessary hypothetical changes, as well as to allow an effective mainnet rollout. Tentative date: October 28th

So, in short, we are releasing a node version, and giving everyone 2 weeks notice to upgrade. This is exclusively for testnet at the moment, as the upgrade for mainnet is scheduled after we have looked into the testnet data, and it’s all postive.
That being said, the tentative date for a mainnet release is around October 20th.

Given all of the above, I think we have healthy margins to respect the protocols you have in place for node upgrades and we have additional leeway, in our opinion. But I am writing here, as we’d love to hear yours.

I’ll be updating this post, or post a reply as soon as the audit final report is delivered to us.

4 Likes