> ## Documentation Index
> Fetch the complete documentation index at: https://docs.berafarm.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Security Audit

> BeraFarm v1 smart contracts have been independently audited. Read the full security review, findings, and resolutions.

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.

<Note>
  All findings from the audit have been **resolved** before launch deployments. No Critical findings were identified.
</Note>

## Report summary

<CardGroup cols={2}>
  <Card title="Protocol" icon="shield-halved">
    BeraFarm - v1
  </Card>

  <Card title="Chain" icon="link">
    Berachain (chainId 80094)
  </Card>

  <Card title="Compiler" icon="code">
    Solidity 0.8.30
  </Card>

  <Card title="Proxy Pattern" icon="layer-group">
    ERC-1967 / UUPS (OpenZeppelin Upgradeable 4.7.3)
  </Card>

  <Card title="Audit Type" icon="magnifying-glass">
    Manual, function-by-function review with cross-contract tracing
  </Card>

  <Card title="Report Status" icon="circle-check">
    Final, consolidated
  </Card>
</CardGroup>

**Audit date:** 2026-09-12<br />**Re-audit date:** 2026-09-15<br />**Commit audited:** `5e705df1d0c53a600ff32f6d830678a62a9ed857`

## Download the full report

<Card title="BeraFarm v1 Security Audit Report" icon="file-pdf" horizontal href="https://drive.google.com/file/d/1Sqz52LdjUt7GQ2wZjqY7KCH1ShsRpShh/view?usp=sharing">
  Download the complete audit report (PDF)
</Card>

## 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**.

| ID   | Title                                                                      | Severity | Status   |
| ---- | -------------------------------------------------------------------------- | -------- | -------- |
| H-01 | Empty-Vault NAV Baseline (double-charged shortfall / misattributed profit) | High     | Resolved |
| H-02 | Strategy pause state reset on removal re-opens fund flows                  | High     | Resolved |
| M-01 | Zero-TVL deposit with paused strategies under-invests and mis-credits      | Medium   | 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

<AccordionGroup>
  <Accordion title="H-01 — Empty-Vault NAV Baseline Bug (Double Charging Shortfall)" icon="triangle-exclamation">
    **Severity:** High  |  **Status:** Resolved

    Both 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.
  </Accordion>

  <Accordion title="H-02 — Strategy Pause State Reset on Removal Re-Opens Fund Flows" icon="triangle-exclamation">
    **Severity:** High  |  **Status:** Resolved

    `ProtocolRegistry.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.
  </Accordion>

  <Accordion title="M-01 — Zero-TVL Deposit with Paused Strategies Under-Invests and Mis-Credits" icon="circle-exclamation">
    **Severity:** Medium  |  **Status:** Resolved

    In 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.
  </Accordion>
</AccordionGroup>

## 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).

<Tip>
  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.
</Tip>

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