Batch Validator Depositor
Smart Contract Security Assessment
April 02, 2025
SUMMARY
ABSTRACT
Dedaub was commissioned by the Ethereum Foundation to perform a security audit of the Batch Validator Depositor by Attestant.io. No significant issues were identified.
BACKGROUND
The Batch Validator Depositor is based on the same implementation of the Abyss Finance protocol. It allows making up to 100 validator deposits conveniently in a single transaction to a predefined DepositContract.
SETTING & CAVEATS
This audit report mainly covers the contracts of the attestantio/batch-validator-depositor repository at commit e1ab97b0360f191fd8b50e2661b955192682dc98.
Two auditors worked on the codebase for 1 day on the following contracts:
- BatchValidatorDepositor.sol
- interfaces/
- IDepositContract.sol
As part of the audit, we also reviewed the fixes addressing the identified issues. These fixes were delivered in PR #1, commit 4b4c9d57126988cbde938e3a86dd57c4d8a128b5, and we have verified that they have been implemented correctly.
The audit’s main target is security threats, i.e., what the community understanding would likely call "hacking", rather than the regular use of the protocol. Functional correctness (i.e. issues in "regular use") is a secondary consideration. Typically it can only be covered if we are provided with unambiguous (i.e. full-detail) specifications of what is the expected, correct behavior. In terms of functional correctness, we often trusted the code’s calculations and interactions, in the absence of any other specification. Functional correctness relative to low-level calculations (including units, scaling and quantities returned from external protocols) is generally most effectively done through thorough testing rather than human auditing.
VULNERABILITIES & FUNCTIONAL ISSUES
This section details issues affecting the functionality of the contract. Dedaub generally categorizes issues according to the following severities, but may also take other considerations into account such as impact or difficulty in exploitation:
- User or system funds can be lost when third-party systems misbehave.
- DoS, under specific conditions.
- Part of the functionality becomes unusable due to a programming error.
- Breaking important system invariants but without apparent consequences.
- Buggy functionality for trusted users where a workaround exists.
- Security issues which may manifest when the system evolves.
Issue resolution includes “dismissed” or “acknowledged” but no action taken, by the client, or “resolved”, per the auditors.
CRITICAL SEVERITY
[No critical severity issues]
HIGH SEVERITY
[No high severity issues]
MEDIUM SEVERITY
[No medium severity issues]
LOW SEVERITY
Acknowledged
DepositContract checks would increase the gas cost of successful transactions by approximately 1%. Since the majority of transactions are expected to be successful, they prefer to avoid penalizing common cases and instead delegate these checks to the DepositContract. They also prefer not to enforce bounds on the deposit size (e.g., between 32 and 2,048 ETH), in order to maintain future flexibility, consistent with the approach taken in the DepositContract.The deposit function is the main entry point of the protocol. This contract was based on the abyss-eth2depositor/AbyssEth2Depositor.sol contract. One modification was that the Abyss implementation used a hardcoded collateral value of 32 ETH, while the current version allows for arbitrary collateral amounts per validator to be deposited in the DepositContract.
However, the 0x00000000219ab540356cBB839Cbe05303d7705Fa DepositContract on mainnet implements some restrictions on the allowed deposited amount of ETH per deposit, which are as follows:
DepositContract.sol::deposit:112// Check deposit amount
require(msg.value >= 1 ether, "DepositContract: deposit value too low");
require(msg.value % 1 gwei == 0,
"DepositContract: deposit value not multiple of gwei");
uint deposit_amount = msg.value / 1 gwei;
require(deposit_amount <= type(uint64).max,
"DepositContract: deposit value too high");
These validations could also be performed on the Batch Validator side to ensure that the forwarded collateral amounts conform to the DepositContract requirements, which was nevertheless unnecessary in the Abyss Finance implementation, as the collateral was fixed at 32 ETH.
When EIP-7251 is activated with the Electra upgrade, the maximum effective balance of a validator will increase to 2,048 ETH, while the minimum activation balance will remain at 32 ETH. The code could be extended to validate that collateral[i] is greater than 32 and less than 2,048 ETH. However, since the DepositContract allows any deposit size as long as it passes the required validations, these checks may be overly restrictive for the batch depositor's intended use.
OTHER / ADVISORY ISSUES
This section details issues that are not thought to directly affect the functionality of the project, but we recommend considering them.
The ReentrancyGuard contract is inherited but never used, which makes it redundant and able to be removed.
The nodesMinAmount and nodesMaxAmount constants are not used anywhere in the contract. However, the deposit function verifies that the nodesAmount requested to be deposited is inside the accepted range [1,100], but magic values are used for this comparison when the public constants could be used instead.
The DepositEvent(address from, uint256 nodesAmount) could include the totalCollateral value (msg.value), since in the current implementation, totalCollateral can be arbitrary and does not necessarily equal 32 ETH × nodesAmount, as it did in the Abyss implementation.
The code is compiled with Solidity ^0.8.0. For deployment, we recommend no floating pragmas but a specific version to be confident about the baseline guarantees offered by the compiler. Version 0.8.0, in particular, has some known bugs, which we do not believe affect the correctness of the contracts.
DISCLAIMER
The audited contracts have been analyzed using automated techniques and extensive human inspection in accordance with state-of-the-art practices as of the date of this report. The audit makes no statements or warranties on the security of the code. On its own, it cannot be considered a sufficient assessment of the correctness of the contract. While we have conducted an analysis to the best of our ability, it is our recommendation for high-value contracts to commission several independent audits, a public bug bounty program, as well as continuous security auditing and monitoring through Dedaub Security Suite.
ABOUT DEDAUB
Dedaub offers significant security expertise combined with cutting-edge program analysis technology to secure some of the most prominent protocols in DeFi. The founders, as well as many of Dedaub's auditors, have a strong academic research background together with a real-world hacker mentality to secure code. Protocol blockchain developers hire us for our foundational analysis tools and deep expertise in program analysis, reverse engineering, DeFi exploits, cryptography and financial mathematics.