Smart Contract Assessment - Ern


Prepared by:

Halborn Logo

HALBORN

Last Updated 02/27/2026

Date of Engagement: February 16th, 2026 - February 17th, 2026

Summary

100% of all REPORTED Findings have been addressed

All findings

16

Critical

0

High

1

Medium

1

Low

10

Informational

4


1. 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.

2. 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.


3. SCOPE

REPOSITORY
(a) Repository: app
(b) Assessed Commit ID: 32275c7
(c) Items in scope:
  • contracts/src/Ern.sol
  • contracts/src/RewardsDistributor.sol
Out-of-Scope: Third party dependencies and economic attacks.
Out-of-Scope: New features/implementations after the remediation commit IDs.

4. Findings Overview

Security analysisRisk levelRemediation
Users Can Front-Run Harvest to Capture Disproportionate RewardsHighRisk Accepted - 02/19/2026
Users Can Front-Run Allocation Reductions to Claim Full RewardsMediumRisk Accepted - 02/19/2026
Harvest Can Be Triggered Even When Time or Yield Conditions Are Not Fully MetLowRisk Accepted - 02/19/2026
Missing Input Validation in Constructor Can Cause Silent Deployment FailuresLowRisk Accepted - 02/19/2026
Additional Deposits Reset Lock and Extend Withdrawal Penalty for Existing FundsLowRisk Accepted - 02/19/2026
Harvest Logic Breaks When Reward Token Is the Same as the Underlying TokenLowRisk Accepted - 02/19/2026
Allocation Reduction Function Silently Ignores Increases Instead of Rejecting ThemLowRisk Accepted - 02/23/2026
Unused Harvest Cooldown Variable and Error Increase Unnecessary ComplexityLowRisk Accepted - 02/19/2026
Single-Step Ownership Transfer Increases Risk of Irrecoverable Admin Control LossLowRisk Accepted - 02/23/2026
Configuration Setters Allow Redundant State Updates Without ChangeLowRisk Accepted - 02/23/2026
Allocation Management Functions Ignore Pause StateLowRisk Accepted - 02/23/2026
Unbounded Loops Can Cause Transactions to Run Out of GasLowRisk Accepted - 02/23/2026
Unused Insufficient Allowance Error Increases Contract ComplexityInformationalAcknowledged - 02/23/2026
View Functions Do Not Validate User Address InputsInformationalAcknowledged - 02/23/2026
Repeated Mapping Access in Reward Processing Increases Gas CostsInformationalAcknowledged - 02/23/2026
Rewards Depend on Manual Harvest Calls and May Never Be DistributedInformationalAcknowledged - 02/19/2026

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.

// Download the full report

Smart Contract Assessment

* Use Google Chrome for best results

** Check "Background Graphics" in the print settings if needed