Origin Protocol
Compounding Staking

Covered the Compounding Staking Strategy's validator lifecycle management, SSV-based distributed validation, and Merkle-proof balance verification.

report id

0645

1 Executive Summary

This document presents the results of a security review conducted by Nethermind Security for Origin Protocol's Compounding Staking Strategy. Origin Protocol's Compounding Staking Strategy is a system for natively staking ETH on the Beacon Chain, designed to operate efficiently within the post-Pectra upgrade environment by minimizing the number of validators required and thus reducing operational overhead.

The strategy leverages the SSV Network for distributed validator operations and ensures the integrity of its accounting through on-chain cryptographic verification of Beacon Chain state using Merkle proofs, forgoing reliance on external data feeds. A privileged Registrator role is responsible for managing the validator lifecycle, which incorporates a secure, two-phase staking process to mitigate deposit front-running attacks. This lifecycle includes the initial deposit, on-chain credential verification, balance top-ups to leverage the increased maximum effective balance, and eventual validator exit and removal from the network.

The audit comprises 1313 lines of Solidity code.

The audit was performed using (a) manual analysis of the codebase, and (b) automated analysis tools.

Audit assessment
Audit Type	Security Review
Initial Report	October 10, 2025
Final Report	October 16, 2025
Initial Commit	`0528675dcc`
Final Commit	`3e790c1dd9`
Documentation Assessment	High
Test Suite Assessment	High

Total findings: 1
Fixed: 1
Acknowledged: 0
Mitigated: 0
Unresolved: 0

Findings by severity

Critical0
High0
Medium0
Low0
Informational1
Best Practices0

2 Audited Files

#	Contract	LoC	Comments	Ratio	Blank	Total
1	`contracts/beacon/Merkle.sol`	85	53	62.4%	5	143
2	`contracts/beacon/PartialWithdrawal.sol`	22	16	72.7%	7	45
3	`contracts/beacon/BeaconProofs.sol`	115	62	53.9%	10	187
4	`contracts/beacon/Endian.sol`	35	18	51.4%	3	56
5	`contracts/beacon/BeaconRoots.sol`	16	15	93.8%	3	34
6	`contracts/beacon/BeaconProofsLib.sol`	250	143	57.2%	37	430
7	`contracts/strategies/NativeStaking/CompoundingStakingView.sol`	61	13	21.3%	8	82
8	`contracts/strategies/NativeStaking/CompoundingStakingSSVStrategy.sol`	120	71	59.2%	32	223
9	`contracts/strategies/NativeStaking/CompoundingValidatorManager.sol`	609	540	88.7%	131	1280
	Total	1313	931	70.9%	236	2480

3 Summary of Issues

#	Finding	Severity	Update
1	Off-by-one error prevents reaching `MAX_VERIFIED_VALIDATORS` limit	Info	Fixed

4 System Overview

The Origin Protocol's Compounding Staking Strategy is a system for natively staking ETH on the Beacon Chain, designed to operate efficiently within the post-Pectra upgrade environment. By leveraging the increased maximum effective balance for validators, the strategy aims to minimize the number of validators required, thereby reducing operational overhead. The system utilizes the SSV Network for distributed validator operations and relies on on-chain verification of Beacon Chain state through Merkle proofs to ensure the integrity of its accounting.

4.1 Fund Deposit and Withdrawal

The primary entry point for capital is the CompoundingStakingSSVStrategy contract, which receives Wrapped ETH (WETH) from the main Origin Protocol Vault. Unlike strategies that immediately deploy assets, this contract holds the deposited WETH until it is actively used for staking.

Deposits: When the Vault calls the deposit or depositAll functions, the strategy contract receives WETH. It updates an internal accounting variable, depositedWethAccountedFor, to track the amount of WETH that is available for staking but has not yet been deployed to a validator.
Withdrawals: Users initiate withdrawals through the Vault, which in turn calls the withdraw or withdrawAll function on the strategy. The strategy fulfills the request by transferring its WETH balance. Any native ETH held by the contract, accumulated from validator exits or execution layer rewards, is first converted to WETH to satisfy the withdrawal demand.

4.2 Validator Lifecycle Management

The management of validators from creation to retirement is handled by a privileged account known as the Registrator. This role is responsible for executing the key state transitions in a validator's lifecycle.

Registration: The lifecycle begins when the Registrator calls registerSsvValidator, providing a validator's public key and the operator details for the SSV Network. This action transitions the validator's state from NON_REGISTERED to REGISTERED.
Initial Staking and Security: To protect against deposit front-running attacks, the protocol employs a two-phase staking process. The Registrator first stakes a minimal 1 ETH deposit, moving the validator to the STAKED state. Crucially, before any further capital is committed, the validator's withdrawal credentials must be proven correct via a successful on-chain call to the verifyValidator function. This verification ensures that funds are staked to a validator controlled by the strategy. To further minimize risk, the system only permits one unverified validator to exist at any given time, serializing the onboarding process.
Verification and Top-Up: Once a validator's credentials are confirmed, its state becomes VERIFIED. The Registrator can then call stakeEth to deposit additional funds. This can be done to meet the 32 ETH activation threshold or to top up the validator's balance further, taking advantage of the increased maximum effective balance post-Pectra. The validator's state is updated to ACTIVE once its balance is confirmed to be above the activation threshold during a subsequent balance verification process.
Withdrawal, Exit, and Removal: The Registrator can initiate withdrawals by calling validatorWithdrawal. Providing a specific amount triggers a partial withdrawal of excess balance. Providing a zero amount initiates a full validator exit, moving its state to EXITING. After a full exit is complete and the validator's balance is verified to be zero, its state becomes EXITED. Finally, the Registrator calls removeSsvValidator to decommission it from the SSV network, marking its final state as REMOVED.

4.3 On-Chain State Verification via Beacon Proofs

The protocol ensures the integrity of its accounting by forgoing reliance on off-chain data feeds. Instead, it employs a permissionless system of on-chain cryptographic verification using Merkle proofs. The EIP-4788 Beacon Block Roots oracle serves as the on-chain source of truth, providing the necessary state roots against which these proofs are validated.

Anyone can call the verification functions, but they are expected to be run by an off-chain keeper that generates the necessary proofs.

verifyValidator: As part of the lifecycle, this function verifies a new validator's public key and, crucially, its withdrawal credentials against the Beacon Chain state. This step is mandatory before significant capital is deposited.
verifyDeposit: This function is used to prove that a pending deposit has been successfully processed by the Beacon Chain. This transitions the value of the deposit from being "pending" to being part of a validator's balance in the protocol's internal accounting.
verifyBalances: This function verifies the current ETH balance of every active validator against a specific Beacon Chain state root. It is the primary mechanism through which the protocol recognizes consensus layer rewards that have compounded on the validators' balances.

4.4 Balance and Rewards Accounting

The strategy's total value is composed of multiple components: idle WETH and ETH in the contract, ETH in pending deposits, and ETH held in validators on the Beacon Chain. A periodic two-step process ensures this value is accurately accounted for on-chain.

Consensus layer rewards are automatically compounded into the validator balances on the Beacon Chain. Execution layer rewards, such as MEV and priority fees, are sent directly to the strategy contract as native ETH.

Snapshot: The process begins with a call to snapBalances. This function records a snapshot of the strategy contract's current native ETH balance and the corresponding parent Beacon Chain block root.
Verification: Following the snapshot, an off-chain keeper provides proofs to the verifyBalances function. This function verifies the balance of every active validator and confirms that all pending deposits are still in the queue for the snapped block root. Upon successful verification, the protocol sums the snapped ETH balance, the total value of all pending deposits, and the total verified validator balances. This sum is stored in lastVerifiedEthBalance, which serves as the canonical, on-chain record of the strategy's total assets under management.

5 Risk Rating Methodology

The risk rating methodology used by Nethermind Security follows the principles established by the OWASP Foundation. The severity of each finding is determined by two factors: Likelihood and Impact.

Likelihood measures how likely the finding is to be uncovered and exploited by an attacker. This factor will be one of the following values:

High: the issue is trivial to exploit and has no specific conditions that need to be met;
Medium: the issue is moderately complex and may have some conditions that need to be met;
Low: the issue is very complex and requires very specific conditions to be met.

When defining the likelihood of a finding, other factors are also considered. These can include but are not limited to motive, opportunity, exploit accessibility, ease of discovery, and ease of exploit.

Impact is a measure of the damage that may be caused if an attacker exploits the finding. This factor will be one of the following values:

High: the issue can cause significant damage, such as loss of funds or the protocol entering an unrecoverable state;
Medium: the issue can cause moderate damage, such as impacts that only affect a small group of users or only a particular part of the protocol;
Low: the issue can cause little to no damage, such as bugs that are easily recoverable or cause unexpected interactions that cause minor inconveniences.

When defining the impact of a finding, other factors are also considered. These can include but are not limited to data and state integrity, loss of availability, financial loss, and reputation damage. After defining the likelihood and impact of an issue, the severity is determined according to the table below.

Impact / Likelihood	Low	Medium	High
High	Medium	High	Critical
Medium	Low	Medium	High
Low	Info / Best Practices	Low	Medium
Undetermined	Undetermined	Undetermined	Undetermined

To address issues that do not fit a High, Medium or Low severity, Nethermind Security also uses three more finding severities: Informational, Best Practices, and Undetermined.

Informational findings do not pose any risk to the application, but they carry some information that the audit team intends to pass to the client formally;
Best Practice findings are used when some piece of code does not conform with smart contract development best practices;
Undetermined findings are used when we cannot predict the impact or likelihood of the issue.

6 Issues

6.1 Off-by-one error prevents reaching `MAX_VERIFIED_VALIDATORS` limit

File	Fix commit	Type	Status
`contracts/strategies/NativeStaking/CompoundingValidatorManager.sol`	PR #2683	Info	Fixed

The stakeEth(...) function is used to perform the initial 1 ETH deposit for a new validator that is in the REGISTERED state. The contract defines a constant MAX_VERIFIED_VALIDATORS set to 48, which is intended to be the maximum number of validators the system can manage.

However, the check to enforce this limit contains an off-by-one error. The require statement uses a strict less-than ( <) operator, which prevents the number of validators from reaching the intended maximum.

function stakeEth(...) external onlyRegistrator whenNotPaused {
    // ...
    bytes32 pubKeyHash = _hashPubKey(validatorStakeData.pubkey);
    ValidatorState currentState = validator[pubKeyHash].state;
    // ...
    if (currentState == ValidatorState.REGISTERED) {
        // ...
        // Limits the number of validator balance proofs to verifyBalances
        // @audit-issue This check should use `<=` to allow exactly 48 validators.
        require(
            verifiedValidators.length + 1 < MAX_VERIFIED_VALIDATORS,
            "Max validators"
        );

        // ...
        firstDeposit = true;
        validator[pubKeyHash].state = ValidatorState.STAKED;
    }
    // ...
}

When there are 47 validators in the verifiedValidators array, verifiedValidators.length is 47. The check evaluates to 47 + 1 < 48, which is 48 < 48. This condition is false, causing the transaction to revert. As a result, it is impossible to stake for the 48th validator, effectively limiting the system to a maximum of 47 validators instead of the intended 48.

Recommendation

Consider changing the strict inequality operator (<) to a less-than-or-equal-to operator (<=). This will ensure that the number of verified validators can reach the MAX_VERIFIED_VALIDATORS limit.

7 Documentation Evaluation

Software documentation refers to the written or visual information that describes the functionality, architecture, design, and implementation of software. It provides a comprehensive overview of the software system and helps users, developers, and stakeholders understand how the software works, how to use it, and how to maintain it. Software documentation can take different forms, such as user manuals, system manuals, technical specifications, requirements documents, design documents, and code comments. Software documentation is critical in software development, enabling effective communication between developers, testers, users, and other stakeholders. It helps to ensure that everyone involved in the development process has a shared understanding of the software system and its functionality. Moreover, software documentation can improve software maintenance by providing a clear and complete understanding of the software system, making it easier for developers to maintain, modify, and update the software over time. Smart contracts can use various types of software documentation. Some of the most common types include:

Technical whitepaper: A technical whitepaper is a comprehensive document describing the smart contract’s design and technical details. It includes information about the purpose of the contract, its architecture, its components, and how they interact with each other;
User manual: A user manual is a document that provides information about how to use the smart contract. It includes step-by-step instructions on how to perform various tasks and explains the different features and functionalities of the contract;
Code documentation: Code documentation is a document that provides details about the code of the smart contract. It includes information about the functions, variables, and classes used in the code, as well as explanations of how they work;
API documentation: API documentation is a document that provides information about the API (Application Programming Interface) of the smart contract. It includes details about the methods, parameters, and responses that can be used to interact with the contract;
Testing documentation: Testing documentation is a document that provides information about how the smart contract was tested. It includes details about the test cases that were used, the results of the tests, and any issues that were identified during testing;
Audit documentation: Audit documentation includes reports, notes, and other materials related to the security audit of the smart contract. This type of documentation is critical in ensuring that the smart contract is secure and free from vulnerabilities.

These types of documentation are essential for smart contract development and maintenance. They help ensure that the contract is properly designed, implemented, and tested, and they provide a reference for developers who need to modify or maintain the contract in the future.

8 Remarks & Test Suite

The Origin Protocol's Compounding Staking Strategy is exceptionally well-documented. The codebase is thoroughly commented, featuring detailed NatSpec documentation for every function. Extensive inline comments clarify the rationale behind specific implementations and thoroughly address potential edge cases. This high level of detail, combined with clear and consistent naming conventions for variables and functions, makes the codebase easy to follow and understand, despite its inherent complexity. Throughout the engagement, the Origin Protocol team was highly responsive, readily available for calls, and provided clear and comprehensive answers to all questions raised by the Nethermind Security auditors.

All the relevant issues raised by the AuditAgent have been incorporated into this report. The AuditAgent is an AI-powered smart contract auditing tool that analyses code, detects vulnerabilities, and provides actionable fixes. It accelerates the security analysis process, complementing human expertise with advanced AI models to deliver efficient and comprehensive smart contract audits. Available at https://app.auditagent.nethermind.io.

Test suite

189Tests passed

1Failed

The complete test output is in the full report.

General advisory to clients

As auditors, we recommend that any changes or updates made to the audited codebase undergo a re-audit or security review to address potential vulnerabilities or risks introduced by the modifications. By conducting a re-audit or security review of the modified codebase, you can significantly enhance the overall security of your system and reduce the likelihood of exploitation. However, we do not possess the authority or right to impose obligations or restrictions on our clients regarding codebase updates, modifications, or subsequent audits. Accordingly, the decision to seek a re-audit or security review lies solely with you.

Disclaimer

This report is based on the scope of materials and documentation provided by you to Nethermind in order that Nethermind could conduct the security review outlined in 1. Executive Summary and 2. Audited Files. The results set out in this report may not be complete nor inclusive of all vulnerabilities. Nethermind has provided the review and this report on an as-is, where-is, and as-available basis. You agree that your access and/or use, including but not limited to any associated services, products, protocols, platforms, content, and materials, will be at your sole risk. Blockchain technology remains under development and is subject to unknown risks and flaws. The review does not extend to the compiler layer, or any other areas beyond the programming language, or other programming aspects that could present security risks. This report does not indicate the endorsement of any particular project or team, nor guarantee its security. No third party should rely on this report in any way, including for the purpose of making any decisions to buy or sell a product, service or any other asset. To the fullest extent permitted by law, Nethermind disclaims any liability in connection with this report, its content, and any related services and products and your use thereof, including, without limitation, the implied warranties of merchantability, fitness for a particular purpose, and non-infringement. Nethermind does not warrant, endorse, guarantee, or assume responsibility for any product or service advertised or offered by a third party through the product, any open source or third-party software, code, libraries, materials, or information linked to, called by, referenced by or accessible through the report, its content, and the related services and products, any hyperlinked websites, any websites or mobile applications appearing on any advertising, and Nethermind will not be a party to or in any way be responsible for monitoring any transaction between you and any third-party providers of products or services. As with the purchase or use of a product or service through any medium or in any environment, you should use your best judgment and exercise caution where appropriate. FOR AVOIDANCE OF DOUBT, THE REPORT, ITS CONTENT, ACCESS, AND/OR USAGE THEREOF, INCLUDING ANY ASSOCIATED SERVICES OR MATERIALS, SHALL NOT BE CONSIDERED OR RELIED UPON AS ANY FORM OF FINANCIAL, INVESTMENT, TAX, LEGAL, REGULATORY, OR OTHER ADVICE.

Origin ProtocolCompounding Staking

1

Executive Summary

2

Audited Files

3

Summary of Issues

4

System Overview

4.1 Fund Deposit and Withdrawal

4.2 Validator Lifecycle Management

4.3 On-Chain State Verification via Beacon Proofs

4.4 Balance and Rewards Accounting

5

Risk Rating Methodology

6

Issues

6.1 Off-by-one error prevents reaching MAX_VERIFIED_VALIDATORS limit

7

Documentation Evaluation

8

Remarks & Test Suite

Origin Protocol
Compounding Staking

6.1 Off-by-one error prevents reaching `MAX_VERIFIED_VALIDATORS` limit