Summary
100% of all REPORTED Findings have been addressed
- 0Solved
- 4Acknowledged
- 12Risk Accepted
- 16All Findings
- Critical0
- High1
- 1Risk A.
- Medium1
- 1Risk A.
- Low10
- 10Risk A.
- Informational4
- 4Ack.
Introduction#
Halborn was engaged to conduct a security assessment of the Ern protocol. The assessment was performed from February 16th, 2026 to February 17th, 2026. Commit hashes and additional details reviewed during the engagement are documented in the Scope section of this report.
The Ern protocol implements a yield aggregation and reward distribution system that allows users to deposit assets into Aave, accrue yield through aTokens, and periodically convert the generated yield into reward tokens via decentralized exchanges. The design uses non-transferable vault shares, configurable harvest conditions, and role-based controls, along with lock and fee mechanisms, to manage reward distribution and enforce protocol economics.
Assessment Summary#
A full-time security engineer from Halborn conducted a targeted security review of the Ern protocol. The assessment was performed by a blockchain and smart contract security specialist with expertise in DeFi yield strategies, tokenized vault designs, and reward distribution mechanisms.
The purpose of the assessment was to:
Identify potential security, economic, and design issues within the Ern smart contracts.
Verify that deposit, withdrawal, harvesting, and reward distribution workflows operate as intended under various market and usage scenarios.
In summary, Halborn identified some improvements to reduce the likelihood and impact of risks, which were addressed by the Ern team. The main recommendations included:
Withdrawal fees protect reward distribution against front-running so late depositors cannot capture yield they did not generate.Implement atomic allocation updates or a claim pause mechanism off chain so users cannot front-run allocation reductions to claim full rewards.
Scope#
Findings Overview#
# | Title | Severity | Score | Status |
|---|---|---|---|---|
HAL-01 | Users Can Front-Run Harvest to Capture Disproportionate Rewards | High | 7.5 | Risk Accepted02/19/2026 |
HAL-02 | Users Can Front-Run Allocation Reductions to Claim Full Rewards | Medium | 5.0 | Risk Accepted02/19/2026 |
HAL-03 | Harvest Can Be Triggered Even When Time or Yield Conditions Are Not Fully Met | Low | 3.4 | Risk Accepted02/19/2026 |
HAL-04 | Missing Input Validation in Constructor Can Cause Silent Deployment Failures | Low | 3.1 | Risk Accepted02/19/2026 |
HAL-05 | Additional Deposits Reset Lock and Extend Withdrawal Penalty for Existing Funds | Low | 2.5 | Risk Accepted02/19/2026 |
HAL-06 | Harvest Logic Breaks When Reward Token Is the Same as the Underlying Token | Low | 2.5 | Risk Accepted02/19/2026 |
HAL-07 | Allocation Reduction Function Silently Ignores Increases Instead of Rejecting Them | Low | 2.5 | Risk Accepted02/23/2026 |
HAL-08 | Unused Harvest Cooldown Variable and Error Increase Unnecessary Complexity | Low | 2.5 | Risk Accepted02/19/2026 |
HAL-09 | Single-Step Ownership Transfer Increases Risk of Irrecoverable Admin Control Loss | Low | 2.5 | Risk Accepted02/23/2026 |
HAL-10 | Configuration Setters Allow Redundant State Updates Without Change | Low | 2.5 | Risk Accepted02/23/2026 |
HAL-11 | Allocation Management Functions Ignore Pause State | Low | 2.5 | Risk Accepted02/23/2026 |
HAL-12 | Unbounded Loops Can Cause Transactions to Run Out of Gas | Low | 2.5 | Risk Accepted02/23/2026 |
HAL-13 | Unused Insufficient Allowance Error Increases Contract Complexity | Informational | 1.7 | Acknowledged02/23/2026 |
HAL-14 | View Functions Do Not Validate User Address Inputs | Informational | 1.7 | Acknowledged02/23/2026 |
HAL-15 | Repeated Mapping Access in Reward Processing Increases Gas Costs | Informational | 1.7 | Acknowledged02/23/2026 |
HAL-16 | Rewards Depend on Manual Harvest Calls and May Never Be Distributed | Informational | 0.7 | Acknowledged02/19/2026 |
Disclaimer#
Halborn strongly recommends conducting a follow-up assessment of the project either within six months or immediately following any material changes to the codebase, whichever comes first. This approach is crucial for maintaining the project’s integrity and addressing potential vulnerabilities introduced by code modifications.
