# Security assessment report

**Client:** <!-- legal name -->
**Protocol / product:** <!-- name -->
**Engagement:** <!-- smart contract audit / Rust audit / penetration test / retainer -->
**Report version:** 1.0 (draft | final)
**Date:** <!-- YYYY-MM-DD -->
**Prepared by:** Andrei Dodu, Dodu Security
**Classification:** Confidential. Distribution limited to the client and its advisers.

---

## 1. Executive summary

- **Scope:** <!-- N repositories, N contracts, commit SHA, lines of code -->
- **Window:** <!-- review dates -->
- **Result:** <!-- C x, H x, M x, L x, I x -->
- **Overall assessment:** <!-- no blocking issues / issues found, fixable before launch / material risk -->
- **Top risks:**
  1. <!-- finding id, one line, why it matters -->
  2. <!-- ... -->
  3. <!-- ... -->

## 2. Scope and assumptions

### 2.1 In scope

| Repository | Commit | Paths | Language |
|---|---|---|---|
| | | | |

### 2.2 Out of scope

<!-- Frontend, deployment scripts, third-party contracts, economic parameters, operational
security, key management, off-chain infrastructure. Be explicit. -->

### 2.3 Assumptions

<!-- Trusted roles, external contracts, oracle behavior, token behavior, chain assumptions,
admin honesty. A finding is only valid while its assumptions hold. -->

### 2.4 Methodology

<!-- Manual review, threat model, invariant list, stateful fuzzing, static analysis, PoC.
Name the tools and versions. Say what was not done. -->

## 3. Severity classification

Severity is impact times likelihood. Impact is the technical, economic and reputational damage
of a successful attack. Likelihood is the chance that the issue is discovered and exploited.

| | Impact: High | Impact: Medium | Impact: Low |
|---|---|---|---|
| **Likelihood: High** | Critical | High | Medium |
| **Likelihood: Medium** | High | Medium | Low |
| **Likelihood: Low** | Medium | Low | Low |

| Severity | Meaning |
|---|---|
| **Critical** | Direct loss or lock of funds, or takeover of the protocol, with no special precondition. Do not deploy. |
| **High** | Material loss or broken invariant with a realistic precondition, or a privileged path likely to be misused. Fix before deployment. |
| **Medium** | Limited loss, degraded liveness, or a weakness that becomes High when combined with another issue. Fix before deployment where possible. |
| **Low** | Minor risk, defense in depth, or a correctness issue with no direct loss. Fix in the next release. |
| **Informational** | Quality, documentation, gas, or a note that does not affect security. No action required. |

## 4. Findings summary

| ID | Title | Severity | Status |
|---|---|---|---|
| C-01 | | Critical | |
| H-01 | | High | |
| M-01 | | Medium | |
| L-01 | | Low | |
| I-01 | | Informational | |

Status values: **Open**, **Fixed**, **Partially fixed**, **Acknowledged**, **Won't fix**.
Status is verified against the fix commit, not taken from the client's word.

## 5. Detailed findings

### [H-01] Title in one line, naming the mechanism

| | |
|---|---|
| **Severity** | High (Impact: High, Likelihood: Medium) |
| **Location** | `src/Vault.sol:142`, `Vault.deposit()` |
| **Status** | Open |
| **Affected commit** | `0000000` |

**Description**

<!-- What the code does, in the reviewer's words. Quote the smallest code fragment that
shows the problem. No more than ~15 lines. -->

**Impact**

<!-- What an attacker gains, concretely: which funds, whose, how much, under what
precondition. If the impact depends on liquidity or a parameter, state the number. -->

**Proof of concept**

<!-- Numbered steps or a Foundry test. The PoC must run against the commit under review.
For a web finding: the exact request and response. For an economic finding: the math. -->

1.
2.
3.

**Recommendation**

<!-- The fix at the level of the invariant, not only the line. Include a code sketch where
it removes ambiguity. If several fixes work, say which one you recommend and why. -->

**Client response**

<!-- Filled in by the client, or "No response received". -->

**Verification**

<!-- Filled in during fix review: the commit checked, the test re-run, and the result:
fixed / partially fixed / still open. -->

## 6. Fix review

| ID | Fix commit | Verified | Note |
|---|---|---|---|
| H-01 | | Yes / No / Partial | |

## 7. Coverage statement

<!-- What was reviewed, what was not, and how much time was spent. Example: "Reviewed 2,140
lines across 14 contracts at commit abc1234. Not reviewed: deployment scripts, the frontend,
the off-chain keeper. Time-boxed to 6 reviewer-days." -->

## 8. Appendix

### 8.1 Tooling

<!-- Foundry, Slither, Echidna, Halmos, custom scripts, versions. -->

### 8.2 Glossary

<!-- Only terms the client may not know. Optional. -->

### 8.3 Disclosure

<!-- Whether the findings may be published, when, and in what form. Default: the client
decides; the reviewer publishes only with written consent, and never before the fix is live. -->

---

*This report is a point-in-time assessment. It does not guarantee the absence of
vulnerabilities, and it does not replace monitoring, incident response, or a bug-bounty
program. Findings are valid for the commit under review; later changes invalidate the
assessment unless re-reviewed.*

---

*Template from Dodu Security. Free to use and adapt; attribution is welcome but not required.
Version 1.0, October 2026.*