## Introduction
After undergoing comprehensive audits, internal assessments, and incorporating valuable feedback from our developer community, we are excited to present the release candidate version of our smart contracts. This version marks a pivotal step in our journey, and I’m very happy to announce that this is the version we are taking to mainnet.

## Overview
This release is centered around two major updates:

1. **ERC-2535 Diamond Standard Inspiration**: We have made significant enhancements to our smart contracts by drawing upon the [ERC-2535 Diamond Standard](https://eips.ethereum.org/EIPS/eip-2535). This move has empowered us to weave greater modularity, scalability, and gas efficiency into our contracts. It lays out a systematic blueprint for structuring contract code and data, thereby equipping our contracts with the ability to be upgraded and extended after deployment. Rather than full compliance with the standard, we've simplified its implementation to render it more accessible to the community. This adaptation significantly enhances the adaptability and longevity of our contracts, ensuring we can keep providing a strong and resilient network as our ecosystem expands.

2. **Frontrunning & Replay Attack Mitigation**: We have implemented a crucial security measure to protect users against [shares theft](https://github.com/bloxapp/SIPs/blob/re-registering-attack-protection/sips/re_registering_attack_protection.md) in the network, which could result by frontrunning or re-registering removed validator shares. To counter this, we’ve updated the shares used in validator registration to a new shares data that now also includes a signature of the validator key to ensure that only the legitimate owner of the validator could ever register it with the network.

:::warning
These updates have led to breaking changes to previous integrations, which requires adjustments in order to be compatible with the next testnet and imminent mainnet launch.
:::

## Breaking Changes
The breaking changes are mainly centered around validator registrations to the network:

### SSV Keys
The SSV Keys tool, which previously only generated shares, now also uses the validator key to sign the validator’s owner address and his registration nonce. The shares and the signature are constructed as **sharesData**, which replaces the previous **shares** parameter used during validator registrations.

To construct the new signature, the SSV Keys tool requires as input two additional parameters:
* `owner-address` - the cluster owner address (in the SSV contract).
* `owner-nonce` - a sequence number that represents the number of validators an owner-address has registered to the SSV network (registration nonce), obtained using the new SSV Scanner tool (outlined below).

### SSV Scanner
The SSV Scanner (previously Cluster Scanner) is a new tool that enables users to retrieve events data from the SSV network contract - **cluster snapshots** and **registration nonces**.

Other than obtaining cluster objects, users can use its additional use case to retrieve registration nonces of an owner-address - the new input requirement for the SSV Keys tool.

Please note that the registration nonce increments after each validator registration and does not decrease when a validator is removed.

### Cluster Object
As part of the optimizations we’ve implemented for gas efficiency, the cluster object has been updated to a new struct (order of parameters have changed):

struct Cluster {
     /// @dev The number of validators in the cluster
     uint32 validatorCount;
     /// @dev The index of network fees related to this cluster
     uint64 networkFeeIndex;
     /// @dev The last index calculated for the cluster
     uint64 index;
     /// @dev Flag indicating whether the cluster is active
    bool active;
    /// @dev The balance of the cluster
    uint256 balance;
}

With this change, the updated default state for new clusters is **{0,0,0,true,0}**.

## Validator Registration Workflow
With the breaking changes, the procedure to register validators to the network has now changed. If previously users could use the SSV Keys tool independently, now one would have to use the new SSV Scanner tool to obtain their registration nonce as a prerequisite:


## Jato v2 Testnet
The new contracts are deployed to the new Jato v2 testnet, which is a **closed** testnet.
To participate, you must whitelist the Ethereum address (owner address) which will be used to register your operators or validators to the network (applies to both webapp and smart contracts).

For access, please fill out this [form](https://forms.monday.com/forms/9c6210831e15c5265666ce43975bb01a) - you will receive an email confirmation once your address has been whitelisted.

## Resources
* [Gitbook v4](https://ssv-network.gitbook.io/docs-v4/)
* Contracts
* [Addresses](https://ssv-network.gitbook.io/docs-v4/#goerli-testnet-v4)
* [Github](https://github.com/bloxapp/ssv-network/tree/main/contracts)
* [ABI](https://github.com/bloxapp/ssv-network/tree/contract-abi/docs/testnet/v1.0.0/abi)
* Tools
* [SSV Keys](https://ssv-network.gitbook.io/docs-v4/tools/ssv-keys)
* [SSV Scanner](https://ssv-network.gitbook.io/docs-v4/tools/ssv-scanner)
* [SSV API v4](https://api.ssv.network/documentation/#/v4)
* Guides
* [Run a Distributed Validator v4](https://ssv-network.gitbook.io/docs-v4/get-started/run-a-distributed-validator)