Skip to main content
BeraFarm v1 has undergone a comprehensive independent security review. Every core protocol contract, the full strategy-adapter suite, and the supporting math and accounting libraries were examined function-by-function, with cross-contract tracing of every configuration value and fund-flow path.
All findings from the audit have been resolved before launch deployments. No Critical findings were identified.

​
Report summary

Protocol

BeraFarm - v1

Chain

Berachain (chainId 80094)

Compiler

Solidity 0.8.30

Proxy Pattern

ERC-1967 / UUPS (OpenZeppelin Upgradeable 4.7.3)

Audit Type

Manual, function-by-function review with cross-contract tracing

Report Status

Final, consolidated
Audit date: 2026-09-12
Re-audit date: 2026-09-15
Commit audited: 5e705df1d0c53a600ff32f6d830678a62a9ed857

​
Download the full report

BeraFarm v1 Security Audit Report

Download the complete audit report (PDF)

​
Scope

The engagement covered:
  • 14 core protocol contracts across main/, library/, and tokens/
  • 24 strategy-adapter files across 12 subfolders
  • Supporting math and accounting libraries
Out of scope: third-party protocols BeraFarm integrates with (Aave, Balancer/BeraHub, Dolomite, Kodiak, Pyth, Chronicle, Chainlink), off-chain infrastructure, deployment scripts, key custody, and front-end/API layers.

​
Findings summary

Three confirmed vulnerabilities were identified and all have been resolved. Status counts: 0 Open, 0 Acknowledged, 3 Fixed. All three findings concern NAV and accounting conservation or strategy pause-state handling. None require an untrusted attacker to hold privileged roles.

​
Severity methodology

Severity is derived from Impact and Likelihood, consistent with industry practice (Trail of Bits, OpenZeppelin, Consensys Diligence style matrices).
  • Critical: Direct loss of funds, complete protocol compromise, or irreversible fund lock reachable by any user.
  • High: Loss of funds or broken core invariant reachable by an attacker, or by governance following a documented safe procedure.
  • Medium: Fund mis-accounting, unfair value distribution, or availability degradation with a bounded, non-catastrophic impact.
  • Low: Best-practice deviations, hardening gaps, or issues requiring a privileged, self-inflicted misconfiguration with no legitimate trigger.

​
Detailed findings

Severity: High  |  Status: ResolvedBoth vault implementations track a NAV baseline in previousCurrentStrategyBalance. When all users fully exit but strategies or the manager continue to hold residual NAV (dust positions, donated rewards, idle currency), the baseline was clamped once and then frozen while the vault was empty. On the next deposit or sync, the entire gap between live NAV and stale baseline was treated as fresh profit or loss, which could double-charge a genuine withdrawal shortfall or misattribute residual profit to the first new depositor.Fix: Always sync the baseline (even at zero TVL), treat empty-vault updates as neutral, and define explicit ownership for residual NAV.
Severity: High  |  Status: ResolvedProtocolRegistry.removeProtocolStrategyAddress() disabled a strategy by overwriting its StrategyInfo struct and unconditionally hardcoded isPaused: false. The textbook incident-response order is to pause a compromised strategy first, then remove it. That correct sequence silently reversed the pause at the moment of removal, and StrategyManager deposit/withdraw loops gated inclusion solely on pause state, so subsequent flows would resume routing user funds into the removed adapter.Fix: Do not clear pause on removal (preserve or force isPaused = true) and add verifyProtocolStrategyAddress() as a defense-in-depth gate in StrategyManager.deposit() and withdraw() hot paths.
Severity: Medium  |  Status: ResolvedIn the zero-TVL allocation branch, StrategyManager.deposit() skipped paused strategies but kept their ratio share in ratioTotal. The full user amount was pulled, but only unpaused strategies received their proportional slice; the paused strategies’ share stayed as idle manager currency. The vault credited principal and minted receipt shares using only the invested portion, and the uninvested remainder was later recognized as NAV, distorting principal-vs-profit attribution.Fix: Renormalize allocation to unpaused strategies only (activeRatio / sumActiveRatio), or revert zero-TVL deposits when any strategy is paused.

​
System overview

BeraFarm v1 is a senior/junior tranche vault protocol. Users deposit into a shared currency pool split into a senior (lower-risk, fixed/compounding-rate) tranche and a junior (higher-risk, residual-yield) tranche. Deposited funds are allocated across pluggable strategy adapters that integrate with external lending and liquidity protocols. The design uses three distinct authority systems:
  1. OpenZeppelin OwnableUpgradeable controls UUPS upgrades and many global or adapter settings.
  2. AccessController (per vault, non-upgradeable) manages operational roles.
  3. ProtocolRegistry.rewardsClaimer is a privileged bot address used for investment synchronization and reward harvesting.

​
Conclusion

Every contract carrying logic, funds, or access control has been reviewed. The three confirmed findings have been resolved. The access-control model, fee math and timelock, Merkle reward accounting, and strategy-adapter guards were otherwise found sound. Remaining items are informational (hardening, dead code, off-chain projection accuracy).
For the complete report — including detailed findings with code locations, full contract and strategy-adapter coverage tables, ownership and privileged-role documentation, informational notes, and retracted candidates — download the PDF above.

​
Disclaimer

This audit is provided for informational purposes only and does not constitute a guarantee of security, an endorsement of the protocol, or a substitute for independent due diligence. Security audits are inherently limited by time, scope, and the information available at the time of review. No audit can guarantee the complete absence of vulnerabilities.