Omniscia Stakewise Audit
ETH Staking V Implementation Security Audit
We were tasked with performing an audit on the Stakewise V2 codebase, a liquid non-custodial ETH2 staking implementation which is deployed and actively managed under a proxy pattern. The particular areas of focus for the audit were the fixes applied to the recently discovered ETH2-specific vulnerability that affected the Rocket Pool, Lido and Stakewise's own code as well as the overall security of the liquid staking scheme.
To achieve a satisfactory level of coverage, we utilized a zero-assumption approach when auditing the codebase to assess whether appropriate access controls and input sanitizations were applied in the various workflows supported by the system. For documentation, we relied on the explicitness of the code and in-line documentation present at each contract's respective interface as the documentation of the Stakewise website references the V1 implementation.
Over the course of the audit, we were able to pinpoint certain misbehaviours as well as fringe cases that appeared unaccounted for and should be remediated to ensure the system achieves a higher level of security. In addition to the edge cases we included as findings, we assessed the logic paths of other commonly-vulnerable malicious inputs such as transfers-to-self which were permitted by the system but did not result in any misbehaviour as the system performs each account's action atomically.
In order to properly validate the fix applied by Stakewise for the ETH2-specific vulnerability, we resorted to the documentation of ETH2, potential solutions that were included in DAO discussions of other projects, and our own understanding of the issue as the implications of this vulnerability are significant. In simple terms, the vulnerability arises in the way ETH2 locks the withdrawal credentials to a particular set that is specified during the first minimum valid deposit equivalent to 1 ETH, thus allowing a race condition to arise whereby a user specifies a different withdrawal credential than the one that the Stakewise protocol is meant to specify and causing staked funds that would have been redirected to the protocol to instead be siphoned out by the attacker, inclusive of the stake necessary to become a node operator.
The fix Stakewise has decided to apply is to rely on the oracle members of the Oracles contract to manage the lifetime cycle of a node operator instead. This puts the onus of an honest operator's submission to the protocol oracles as they are responsible for validating both the depositData of an operator as well as the accuracy of the withdrawal credential they provide. To deal with potentially rogue operators, a slashing mechanism was implemented that donates the 1 ETH required for the initialization of an operator's status to the pool of the protocol itself.
A severe misbehaviour we identified in the contracts was with regards to the staleness of the reward per token within the RewardEthToken implementation that could permit a zero-balance user to claim a huge delta in the reward-per-token rate should they remain with a zero-balance over a long period. Vulnerabilities aside, the codebase overall is of a very high standard and all the best security principles have been followed when it comes to the upgrade-ability component of the system. Namely, of the contracts in scope the following three contracts are meant to be newly deployed (Oracles, Roles, PoolValidators) whereas the rest are meant to replace the existing deployed implementations in the Stakewise network.
We should note that several optimizations are capable of being applied to the system beyond the ones we have explicitly identified within the report. As an example, the codebase makes no use of the immutable keyword which is proxy-compliant as it affects the bytecode rather than storage of a contract and would significantly reduce read-access gas costs in a lot of areas, such as the canonical ETH2 deposit contract. Additionally, the codebase makes certain assumptions as to the reader's aptitude in understanding the codebase and contains little to no comments in areas where it should, such as the (66.66~%, 100%] consortium level applied for Oracles votes or the fractional maximum pending operator threshold which results in a [0,1) active to pending validator ratio for permitting instant token mints.
During the audit, we filtered and validated a total of 9 findings utilizing static analysis tools as well as identified a total of 26 findings during the manual review of the codebase. We strongly recommend that any minor severity or higher findings are dealt with promptly prior to the project's launch as they introduce potential misbehaviours of the system as well as exploits.
The list below covers each segment of the audit in depth and links to the respective chapter of the report: