SSV.network
Summary
The ssv.network is a decentralized protocol that facilitates the distributed operation of an Ethereum validator by employing a Distributed Validator Technology (DVT) approach. This method divides the validator key among various non-trusting nodes operated by different entities. The key is fragmented, encrypted, and distributed among these operators to execute validator tasks. To manage their validators, the validator owners compensate their chosen operators with SSV tokens as operating fees, while paying a network fee to the DAO. The SSV token functions as a reciprocal reward system between validators and operators, and also serves as the payment token for the SSV network. The audit focused on the smart contracts responsible for facilitating a registry for validators and operators and the distribution of SSV token payments between them. The following were identified as key areas of concern, but not limited to: - Liquidation: This refers to the risk of clusters being liquidated incorrectly, which could lead to a loss of funds for the validators. - Insolvency: This risk involves the possibility of clusters being insolvent, which could lead to operators being unable to withdraw. - Accounting: The contracts must accurately account for operators' and clusters' balances when taking snapshots. - Permission: The contracts must restrict non-permissioned operations to prevent unauthorized changes to the registry or payment distribution. - Event data: The contracts must emit correct values in events that are used by off-chain components. <br> During the audit, we identified several medium-severity issues that require attention. The first issue relates to the liquidation delay, which can result in an insufficient balance of the SSV token in the `SSVNetwork` contract, preventing operators from being able to withdraw their earnings and causing the cluster to remain insolvent even upon reactivation. The second issue concerns the `withdraw()` function, which allows the cluster owner to withdraw funds from the cluster balance. However, the liquidation check is done before the withdrawal amount is subtracted from the cluster balance, making it possible for a cluster owner to withdraw funds that could cause the cluster to become liquidatable. Finally, the third issue is related to the registration of identical operators for a validator, as the `registerValidator()` function checks that the operator IDs are sorted in ascending order but does not verify whether there are any duplicate operator IDs. Additionally, to enhance the codebase, we recommend refactoring redundant checks and documenting the code more comprehensively. For instance, the `registerValidator()` function is responsible for adding a new validator and registering a new cluster, which makes the function complex. We recommend that the client considers breaking such functions down into smaller, more specialized functions that handle specific tasks. This approach improves the code's readability, maintainability, and testability. We recommend that the client addresses and/or considers all the findings highlighted in this report. **Fix Review**: Following the initial audit, the SSV team updated the codebase to include fixes for issues and redesigned the codebase's architecture that utilizes the Diamond Storage Pattern for upgradeable module contracts. Through the use of `delegatecall`, the `SSVNetwork` contract performs state changes through the execution of code within the module contracts (`SSVClusters`, `SSVDAO`, `SSVOperators`, and `SSVViews`). During the fix review, the client identified and addressed a critical front-running vulnerability related to validator registration. We reviewed the fix and believe that the front-running risk, affecting both validators' and operators' registrations, is still possible and the issue is documented in SSV-18. We also updated existing issues SSV-9 and SSV-13 and included additional issues SSV-19 to SSV-25 and best practices identified during the fix review. **Fix Review 2**: The client resolved issues SSV-18 to SSV-25 by implementing fixes, mitigating, or acknowledging them. Although SSV-18 is acknowledged, the client provided the explanation that additional validation will be performed by the nodes off-chain to mitigate slashable events.
Issues (25)
Low | Medium | High | Critical | Total | |
|---|---|---|---|---|---|
Not fixed | 17 | 2 | - | - | 19 |
Fixed | 3 | 3 | - | - | 6 |
| Total | 20 | 5 | 0 | 0 | 25 |