) as you go. 3. Keep the internal per-item verdicts in the internal report; surface only confirmed findings here (each must have survived the Rule 5b validation gate). 4. Order findings by severity descending (Critical -> Informational). Zellic's convention of ordering by *importance/impact* rather than raw severity is an acceptable alternative — pick one and be consistent. CONVENTION — NO "SAFE TO DEPLOY" STAMP: Real firms do NOT certify code as "safe" or "guaranteed secure." This template MUST NOT contain a deploy blessing. Communicate readiness through: (a) the code-maturity narrative, (b) finding resolution status, and (c) explicit trust-model caveats. An audit is a point-in-time, scoped, non-exhaustive review — never a guarantee. This framing is enforced in the Disclaimer appendix. IP BOUNDARY: use only public-derivable firm conventions. Never reference or quote the proprietary knowledge base, and re-author all conventions in original wording. ================================================================================ --> # {Protocol / Client Name} — Security Audit Report | | | | --------------------- | ------------------------------------------------------ | | **Auditor** | auditor-skill v7.6 | | **Client** | {client / organization} | | **Protocol** | {protocol / product name} | | **Report Title** | {e.g. "Vault Program Security Assessment"} | | **Report Version** | {e.g. 1.0 — draft / 1.1 — final / 2.0 — post-fix} | | **Audit Window** | {YYYY-MM-DD → YYYY-MM-DD} | | **Report Published** | {YYYY-MM-DD} | | **Classification** | {Confidential — Client Only / Public / Draft} | ### Revision History | Version | Date | Description | Author | | ------- | ---------- | ------------------------------------------------- | ----------- | | 1.0 | {date} | Initial draft delivered | {name} | | 1.1 | {date} | Client comments incorporated | {name} | | 2.0 | {date} | Fix review; statuses + fix commits added | {name} | --- ## Table of Contents 1. [Executive Summary](#1-executive-summary) - [1.1 Findings Summary by Severity](#11-findings-summary-by-severity) - [1.2 Finding Lifecycle](#12-finding-lifecycle) - [1.3 Security Posture & Codebase Maturity](#13-security-posture--codebase-maturity) - [1.4 Key Takeaways](#14-key-takeaways) 2. [Scope & Engagement](#2-scope--engagement) - [2.1 Engagement Envelope](#21-engagement-envelope) - [2.2 Repository & Commits](#22-repository--commits) - [2.3 In Scope](#23-in-scope) - [2.4 Out of Scope](#24-out-of-scope) 3. [Methodology](#3-methodology) - [3.1 Assessment Goals](#31-assessment-goals) - [3.2 Approach](#32-approach) - [3.3 Phases Executed](#33-phases-executed) - [3.4 Human-in-the-Loop vs. Automated](#34-human-in-the-loop-vs-automated) - [3.5 Coverage & Limitations](#35-coverage--limitations) 4. [System Overview](#4-system-overview) - [4.1 Protocol Description](#41-protocol-description) - [4.2 Account / PDA Model](#42-account--pda-model) - [4.3 Instruction Inventory](#43-instruction-inventory) - [4.4 Trust Model & Actors](#44-trust-model--actors) - [4.5 Key Invariants](#45-key-invariants) - [4.6 Assumptions & Simplifications](#46-assumptions--simplifications) - [4.7 Systemic / Thematic Risks](#47-systemic--thematic-risks) 5. [Severity Classification](#5-severity-classification) - [5.1 Severity Tiers](#51-severity-tiers) - [5.2 Impact × Likelihood Matrix](#52-impact--likelihood-matrix) 6. [Findings](#6-findings) - [6.1 Findings Summary Table](#61-findings-summary-table) - [6.2 Detailed Findings](#62-detailed-findings) 7. [Findings Summary Table](#7-findings-summary-table) 8. [Code Maturity Assessment](#8-code-maturity-assessment) 9. [Appendices](#9-appendices) - [9.1 Severity Rating Definitions](#91-severity-rating-definitions) - [9.2 Status Vocabulary](#92-status-vocabulary) - [9.3 Tools & Versions](#93-tools--versions) - [9.4 Disclaimer](#94-disclaimer) --- ## 1. Executive Summary {auditor-skill was engaged by {client} to perform a security assessment of the {protocol} {program/codebase}. The review covered {N} program(s) / {LoC} lines over {duration}. The assessment identified {X} findings: {n} Critical, {n} High, {n} Medium, {n} Low, and {n} Informational. {One sentence on the dominant theme, e.g. "The core accounting logic is sound; findings cluster around access-control hardening and input validation."}} ### 1.1 Findings Summary by Severity | Severity | Count | Resolved | Acknowledged | Open | | ------------------- | :---: | :------: | :----------: | :--: | | 🔴 Critical | {n} | {n} | {n} | {n} | | 🟠 High | {n} | {n} | {n} | {n} | | 🟡 Medium | {n} | {n} | {n} | {n} | | 🔵 Low | {n} | {n} | {n} | {n} | | ⚪ Informational | {n} | {n} | {n} | {n} | | **Total** | **{N}** | **{n}** | **{n}** | **{n}** | ### 1.2 Finding Lifecycle | Severity | Discovered | Confirmed | Resolved | Acknowledged | Open | | ------------------- | :--------: | :-------: | :------: | :----------: | :--: | | 🔴 Critical | {n} | {n} | {n} | {n} | {n} | | 🟠 High | {n} | {n} | {n} | {n} | {n} | | 🟡 Medium | {n} | {n} | {n} | {n} | {n} | | 🔵 Low | {n} | {n} | {n} | {n} | {n} | | ⚪ Informational | {n} | {n} | {n} | {n} | {n} | | **Total** | **{N}** | **{N}** | **{n}** | **{n}** | **{n}** | ### 1.3 Security Posture & Codebase Maturity {maturity + resolution + trust-model narrative} ### 1.4 Key Takeaways - {e.g. "Critical AUD-01 (permissionless vault drain) has been fixed in {commit}."} - {e.g. "The program's upgrade authority is a single EOA — recommend a multisig + timelock before mainnet."} - {e.g. "Test coverage is strong for happy paths but thin on adversarial cases; property tests recommended."} - {...} --- ## 2. Scope & Engagement ### 2.1 Engagement Envelope | | | | -------------------------- | ------------------------------------------------- | | **Audited Commit** | `{full 40-char SHA}` | | **Remediation Commit(s)** | `{SHA}` {, `{SHA}` …} | | **Scope Size** | {LoC in scope} | | **Effort** | {e.g. ~X person-days / N agents / team of M} | | **Team / Agents** | {e.g. auditor-skill agent fleet: / named reviewers} | | **Scope vs. Budget Note** | {Honest note. E.g. "Scope came in at {LoC}, above the {budget} LoC envelope for this tier; {which surfaces got full depth vs. lighter passes}." or "Code was within budget; full depth across all in-scope files." or "Program X was delivered as a compiled artifact only — see §2.4."} | ### 2.2 Repository & Commits | | | | ---------------------------- | ------------------------------------------------- | | **Repository** | {https://github.com/org/repo} | | **Branch** | {branch reviewed} | | **Review Start Commit** | `{full 40-char SHA}` | | **Fix-Review End Commit** | `{full 40-char SHA}` | | **Lines of Code (in scope)** | {LoC} | | **Audit Window** | {e.g. 2026-06-15 → 2026-06-26 (2 weeks)} | | **Report Published** | {YYYY-MM-DD} | ### 2.3 In Scope | Component | Path | Language | Notes | | --------- | ---- | -------- | ----- | | {Program name} | `programs/{name}/src/` | Rust (Anchor {version}) | {on-chain program} | | {Off-chain service} | `apps/{name}/src/` | TypeScript | {if in scope} | | {...} | {...} | {...} | {...} | ### 2.4 Out of Scope - {e.g. Third-party programs invoked via CPI (SPL Token, Jupiter) — assumed correct.} - {e.g. Off-chain keeper / crank infrastructure not included in the repository.} - {e.g. Front-end / client application (unless separately listed as in scope).} - {e.g. Deployment process, key custody, and operational security (see Disclaimer).} - {e.g. Economic model / tokenomics design beyond on-chain code correctness.} - {e.g. Program X, delivered as a compiled artifact only — source not provided, could not be reviewed.} - {Any code outside the commits in §2.2.} --- ## 3. Methodology The assessment combined **manual, line-by-line human-in-the-loop review** with **automated tooling**. Manual review is the primary method; tooling is used to widen coverage and catch mechanical issues. ### 3.1 Assessment Goals The review was organized around answering the following questions for the in-scope code: - **Fund safety** — Can assets be withdrawn, transferred, or minted without proper authorization? Can a permissionless caller move another party's funds? - **Arithmetic integrity** — Can any calculation overflow, underflow, truncate, or divide by zero to corrupt balances, shares, or accounting? - **Account validation** — Can required account checks (owner, signer, PDA derivation, mint, mutability, rent) be bypassed or confused (substitution / type-confusion)? - **Access control** — Are privileged operations correctly gated? Can roles be escalated or impersonated? - **State-machine soundness** — Can the protocol be driven into an invalid or stuck state, or can steps be reordered/skipped to an attacker's benefit? - **CPI & composability** — Are cross-program calls made to validated targets, and is state correctly reloaded after them? Can an attacker supply a malicious callee? - **Denial of service** — Can a critical path be cheaply blocked, bricked, or made economically unusable? - **Economic / incentive** — Within code scope, can rounding, ordering, or precision be exploited for value extraction (e.g. first-depositor, donation, sandwich-on-chain)? - {Additional protocol-specific goals, e.g. "Are oracle staleness and confidence bounds enforced?" / "Is the liquidation path fair and non-gameable?"} ### 3.2 Approach - **Manual review** — every in-scope instruction/handler read in full, with context reconstruction before any verdict (purpose, invariants, assumptions, external-interaction risks per function). Findings are gated for reachability and impact before being reported (over-reporting is actively suppressed). - **Automated analysis** — {list what was actually run, e.g.:} - Static analysis / SAST: {e.g. `cargo clippy`, `semgrep`, custom lints} - Dependency / supply-chain: {e.g. `cargo audit`, `npm audit`} - {Fuzzing / property tests: `cargo-fuzz`, `proptest`, `trident` — if used} - {Formal verification: {tool} — if used, else state "not applied in this engagement"} ### 3.3 Phases Executed | Phase | Focus | | ----- | ----- | | Scope declaration & discovery | Enumerate languages, programs, entry points | | Context reconstruction | Per-function purpose, invariants, assumptions | | On-chain program review | Account validation, access control, arithmetic, CPI/PDA, state machine, economic logic | | Off-chain review | {TypeScript / backend / frontend — if in scope} | | DevOps & supply chain | Dependencies, secrets, deployment config | | Verification & monitoring | Test/fuzz quality, logging, incident response | | Known-vector sweep | Curated Solana attack-vector checklist | | Code maturity assessment | 9-category engineering-quality scorecard | ### 3.4 Human-in-the-Loop vs. Automated {All reported findings were manually verified against the source; automated tool output was triaged and confirmed by review before inclusion. Findings that could not be shown reachable and impactful were downgraded or excluded rather than reported speculatively.} ### 3.5 Coverage & Limitations - **Depth** — {Which components got full line-by-line review vs. which got a lighter/targeted pass, and why.} - **Dynamic vs. static** — {What was exercised at runtime (existing tests, new PoCs, fuzzing, mainnet-fork simulation) vs. reasoned about statically.} - **Tool limitations** — Automated tooling is a supplement, not a guarantee. Static analyzers produce false negatives and cannot reason about all cross-instruction or economic properties; fuzzing and property tests explore a bounded input space; a green test suite demonstrates correct behavior only on the paths it exercises. Absence of a finding in any area is **not** proof that no issue exists there. - **Blockers** — {Anything that constrained coverage: code delivered late, portions unbuildable, closed-source components, or the engagement time box.} - **Execution mode** — {isolated: | native: target-controlled code (builds, tests, PoCs) ran on the auditor's machine — steps: …} (OUTPUT-RULES Rule 11a). - **Outside services** — {one line per tool → service → what was sent | none} (OUTPUT-RULES Rule 11b). --- ## 4. System Overview ### 4.1 Protocol Description {2-5 sentences describing what the protocol does and its core mechanism.} ### 4.2 Account / PDA Model | Account | PDA Seeds | Purpose | Key Fields | | ------- | --------- | ------- | ---------- | | {Vault} | `["vault", authority]` | {holds funds} | {authority, bump, balance} | | {...} | {...} | {...} | {...} | ### 4.3 Instruction Inventory | Instruction | Purpose | Signer / Authority | Accounts Touched | Notes | | ----------- | ------- | ------------------ | ---------------- | ----- | | `{initialize}` | {create config/state} | {admin} | {config, payer, system} | {one-time; init guard} | | `{deposit}` | {add funds} | {user (permissionless)} | {vault, user_ata, vault_ata} | {checked math} | | `{withdraw}` | {remove funds} | {vault authority} | {vault, vault_ata, dest_ata} | {PDA-signed CPI} | | `{...}` | {...} | {...} | {...} | {...} | ### 4.4 Trust Model & Actors | Actor | Privileges | Trust Assumption | | ----- | ---------- | ---------------- | | {Admin / upgrade authority} | {upgrade program, set params} | {assumed honest & key-secure} | | {Manager} | {...} | {...} | | {User / depositor} | {deposit, withdraw own funds} | {untrusted — permissionless} | | {Oracle / external program} | {supplies price} | {assumed accurate & live} | ### 4.5 Key Invariants | ID | Invariant | Verification Status | | -- | --------- | ------------------- | | INV-1 | {e.g. `total_shares == shares_mint.supply` at all times.} | {Manually verified / Property-tested (`proptest: shares_conserve`) / Unproven} | | INV-2 | {e.g. Sum of all position balances equals vault token balance.} | {...} | | INV-3 | {e.g. Only the recorded authority can move funds out of a vault.} | {...} | | {...} | {...} | {...} | ### 4.6 Assumptions & Simplifications The findings, severities, and residual-risk conclusions in this report are conditioned on the following assumptions. Where an assumption does not hold in production, the associated conclusions must be revisited. - **Trusted authorities** — {e.g. The upgrade authority / admin multisig is honest, uncompromised, and operated per its stated policy; a compromise of this key is out of the threat model and would invalidate the access-control conclusions.} - **Oracle / external data** — {e.g. The configured price oracle reports accurate, timely values within its documented confidence bounds; oracle manipulation and prolonged staleness beyond the enforced bounds are assumed out of scope.} - **Trusted external programs** — {e.g. CPIs to SPL Token / {program} behave per their published specification and are not themselves malicious or backdoored.} - **Model simplifications** — {e.g. Cross-instruction MEV ordering was reasoned about qualitatively rather than simulated exhaustively; {other simplification}.} - **Deployment configuration** — {e.g. Program is deployed with the reviewed parameters and the upgrade authority set as described; a different configuration changes the analysis.} - {...} > The judgment that any acknowledged or risk-accepted findings below are tolerable > **depends on the assumptions above**. This is not a certification of safety (see > §9.4). ### 4.7 Systemic / Thematic Risks - **Centralization / privileged control** — {Which powers are concentrated in one key or role (mint, upgrade, pause, param-setting, fund movement), and what a compromise or misuse would enable. Note whether a multisig/timelock mitigates.} - **Authority structure** — {How authorities are assigned, rotated, and revoked; single points of failure; whether authority handoff is safe.} - **Ordering / synchronization** — {Sensitivity to transaction/instruction ordering, crank/keeper timing, or interleaving; where a race or stale read could bite.} - **Indirect / transitive CPI risk** — {Exposure inherited from programs this code calls (or that call it), including composability assumptions that hold today but could break if a dependency upgrades.} - {Other cross-cutting theme, e.g. upgrade-migration risk, data-availability assumptions, economic reflexivity.} --- ## 5. Severity Classification Each finding is assessed on two axes — **Impact** (how bad the outcome is) and **Likelihood** (how reachable/probable the exploit is, given the preconditions an attacker must satisfy). The headline **Severity** is derived from the combination via the matrix in §5.2; it is not assigned by feel. ### 5.1 Severity Tiers | Severity | Definition | | ------------------- | ---------- | | 🔴 **Critical** | Direct, permissionless loss of funds or complete protocol compromise — exploitable by any caller with no special privilege and minimal preconditions. Must be fixed before deployment. | | 🟠 **High** | Loss of funds or equivalent damage that requires attacker-achievable preconditions (a specific but reachable state, a modest capital outlay, or a race). Must be fixed before release. | | 🟡 **Medium** | Conditional or amplified impact — state corruption, economic manipulation of limited scope, or denial-of-service on a critical path. Should be fixed. | | 🔵 **Low** | Best-practice deviation or defense-in-depth gap with no realistic path to fund loss under the current design. Recommended to address. | | ⚪ **Informational** | Code quality, documentation, gas/CU, or hardening suggestions with no direct security impact. Optional. | ### 5.2 Impact × Likelihood Matrix Rate **Impact** and **Likelihood** independently, then read the headline severity from the cell: | Impact ↓ / Likelihood → | **High** | **Medium** | **Low** | | ----------------------- | :------: | :--------: | :-----: | | **High** | 🔴 Critical | 🟠 High | 🟡 Medium | | **Medium** | 🟠 High | 🟡 Medium | 🔵 Low | | **Low** | 🟡 Medium | 🔵 Low | ⚪ Informational | > The auditor's internal 1–10 numeric severity maps onto these five tiers as > **10–9 = Critical, 8–7 = High, 6–5 = Medium, 4–3 = Low, 2–1 = Informational**. > A privilege requirement lowers the Likelihood axis, which caps the derived > severity accordingly. --- ## 6. Findings ### 6.1 Findings Summary Table | ID | Title | Severity | Status | | ------ | ----- | -------- | ------ | | AUD-01 | {title} | 🔴 Critical | {Fixed} | | AUD-02 | {title} | 🟠 High | {Acknowledged} | | AUD-03 | {title} | 🟡 Medium | {Open} | | {...} | {...} | {...} | {...} | --- ### 6.2 Detailed Findings #### AUD-01 — Missing owner check allows draining any vault | Field | Value | | -------------- | ----------------------------------------------------------- | | **Severity** | 🔴 Critical (internal: 10) | | **Impact** | High — total loss of all deposited funds | | **Likelihood** | High — permissionless, no special state required | | **Status** | Fixed | | **Location** | [`programs/vault/src/instructions/withdraw.rs#L42`](https://github.com/org/repo/blob/{reviewSHA}/programs/vault/src/instructions/withdraw.rs#L42) @ `{reviewSHA}` | | **Category** | Access Control / Account Validation | **Description** The `withdraw` instruction reads the destination token account from `ctx.accounts.vault_token_account` but never constrains its `authority` to the signing user, nor verifies the `vault` PDA owns it. The account is typed `UncheckedAccount` with a `/// CHECK:` comment that does not perform a real check. As a result the `vault` seeds are derived from a caller-supplied `authority` argument rather than the signer, so any caller can pass another user's vault. **Impact** Any permissionless caller can construct a transaction that withdraws the full balance of an arbitrary victim vault to an attacker-controlled token account, resulting in complete loss of all deposited funds across every vault. **Exploit Scenario** 1. Alice deposits 100,000 USDC; her vault PDA is derived from her authority key. 2. Eve, an unrelated account with no deposit, crafts a `withdraw` transaction passing Alice's authority as the `authority` argument and her own ATA as the destination, signing only as herself. 3. Because the vault PDA is derived from the *argument* (not Eve's signer) and no check ties `vault_token_account` to the vault, the transfer is authorized. 4. Eve receives Alice's 100,000 USDC. Repeating across every vault drains the entire program TVL in a sequence of permissionless transactions. **Proof of Concept / Reachability** ```rust // Attacker passes victim_authority as the `authority` arg; signs as themselves. // Because the vault PDA is derived from the arg (not the signer) and no owner // check ties vault_token_account to the vault, the transfer succeeds. let (victim_vault, _) = Pubkey::find_program_address( &[b"vault", victim_authority.as_ref()], &program_id); // withdraw(ctx, amount = victim_vault.balance) -> funds land in attacker ATA ``` > *Listing 1 — `withdraw` invoked against a victim vault (review commit `{reviewSHA}`).* **Recommendation** *Short term* — Derive the `vault` PDA from the **signer** (`authority.key()`), add `has_one = authority`, and constrain the token account so it must belong to the vault: ```rust #[account(mut, seeds = [b"vault", authority.key().as_ref()], bump = vault.bump, has_one = authority)] pub vault: Account<'info, Vault>, #[account(mut, token::authority = vault, token::mint = mint)] pub vault_token_account: InterfaceAccount<'info, TokenAccount>, pub authority: Signer<'info>, ``` > *Listing 2 — recommended constraints.* *Long term* — Audit every handler for the same "derive-from-argument" pattern and adopt a convention that PDA seeds are always derived from signed accounts; add a negative test asserting a non-owner cannot withdraw. **Remediation** | | | | ------------------------ | ------------------------------------------------- | | **Fix Commit / PR** | [`abc1234`](https://github.com/org/repo/commit/abc1234) (PR #128) | | **Client Response** | {Client}: "Confirmed and patched; seeds now derive from the signer and the token account is constrained to the vault authority." | | **Auditor Verification** | We re-tested against `abc1234` and confirmed the non-owner withdrawal PoC now fails at account validation; the fix fully resolves the issue. | --- #### AUD-{NN} — {Finding Title} | Field | Value | | -------------- | ----------------------------------------------------------- | | **Severity** | {🔴 Critical / 🟠 High / 🟡 Medium / 🔵 Low / ⚪ Informational} (internal: {1-10}) | | **Impact** | {High / Medium / Low} — {one-line consequence} | | **Likelihood** | {High / Medium / Low} — {one-line on preconditions} | | **Status** | {Fixed / Partially Fixed / Acknowledged / Risk-Accepted / Disputed / Open} | | **Location** | [`{path/file.rs#L42}`]({repo}/blob/{reviewSHA}/{path/file.rs}#L42) @ `{reviewSHA}` {(+ additional locations if the same root cause recurs)} | | **Category** | {e.g. Arithmetic / Access Control / CPI / State Machine / DoS} | **Description** {...} **Impact** {...} **Exploit Scenario** 1. {Alice … } 2. {Eve … } 3. {… resulting in {quantified outcome}.} **Proof of Concept / Reachability** ``` {PoC code or reachability argument} ``` > *Listing N — {caption} (review commit `{reviewSHA}`).* **Recommendation** *Short term* — {immediate patch} ``` {recommended fix} ``` *Long term* — {systemic hardening / class-level prevention} **Remediation** | | | | ------------------------ | ------------------------------------------------- | | **Fix Commit / PR** | {`{SHA}` / PR #N, permalinked, or "—"} | | **Client Response** | {"{Client}: their attributed rationale / position."} | | **Auditor Verification** | {"We re-tested against `{SHA}` and confirmed …" / "Client states fixed; not re-verified because …" / "Pending — finding Open."} | --- ## 7. Findings Summary Table | ID | Title | Severity | Impact | Likelihood | Status | Location | | ------ | ----- | -------- | ------ | ---------- | ------ | -------- | | AUD-01 | {title} | 🔴 Critical | High | High | {Fixed} | `{file:line}` | | AUD-02 | {title} | 🟠 High | High | Medium | {Acknowledged} | `{file:line}` | | {...} | {...} | {...} | {...} | {...} | {...} | {...} | --- ## 8. Code Maturity Assessment Each category is rated **0–4**: 0 = absent · 1 = ad-hoc · 2 = partial · 3 = good · 4 = strong (weakest-link scoring). The **FIR** column flags "Further Investigation Required" — a coverage gap distinct from a low score. | # | Category | Score (0–4) | FIR? | Evidence (file:line / artifact) | Gap to Next Level | | - | -------- | :---------: | :--: | ------------------------------- | ----------------- | | 1 | Access Controls | {0-4} | {yes/no} | {...} | {...} | | 2 | Arithmetic | {0-4} | {yes/no} | {...} | {...} | | 3 | Account & Type Safety | {0-4} | {yes/no} | {...} | {...} | | 4 | Input Validation | {0-4} | {yes/no} | {...} | {...} | | 5 | Testing | {0-4} | {yes/no} | {...} | {...} | | 6 | Fuzzing & Property Tests | {0-4} | {yes/no} | {...} | {...} | | 7 | Error Handling & DoS Resilience | {0-4} | {yes/no} | {...} | {...} | | 8 | Upgradeability & Governance | {0-4} | {yes/no} | {...} | {...} | | 9 | Monitoring & Incident Response | {0-4} | {yes/no} | {...} | {...} | | | **Overall Maturity** | **{X.X} / 4.0** | | | | --- ## 9. Appendices ### 9.1 Severity Rating Definitions - **🔴 Critical** — Direct, permissionless fund loss / total compromise; minimal preconditions. - **🟠 High** — Fund loss under attacker-achievable preconditions. - **🟡 Medium** — Amplified/conditional impact, or DoS on a critical path. - **🔵 Low** — Best-practice / defense-in-depth gap; no realistic fund loss. - **⚪ Informational** — Quality, documentation, or hardening; no direct security impact. Severity is derived from the **Impact × Likelihood** matrix in §5.2, not asserted. ### 9.2 Status Vocabulary - **Fixed** — Client remediated the issue; the auditor re-reviewed the fix commit and independently confirmed the finding is resolved. - **Partially Fixed** — The remediation addresses part of the issue (or one of several locations) but leaves residual risk; the remaining exposure is described in the finding's Auditor Verification. - **Acknowledged** — Client agrees the finding is valid; a fix is planned/tracked but is not yet present in the reviewed code. - **Risk-Accepted** — Client agrees the finding is valid but has chosen not to fix it, accepting the risk; their stated rationale is recorded (attributed) in the Client Response. - **Disputed** — Client disagrees that the finding is valid or applicable; both the client's position and the auditor's assessment are recorded so the reader can judge. (The auditor does not silently drop a disputed finding.) - **Open** — Not yet triaged by the client (typical in a draft); no client position recorded. ### 9.3 Tools & Versions ``` auditor-skill: v6.0 solana-cli: {version} anchor-cli: {version} rustc / cargo: {version} node / npm: {version} cargo-audit: {version or "n/a"} {other SAST / fuzz / FV tools}: {version or "n/a"} ``` ### 9.4 Disclaimer This report reflects a **point-in-time** security assessment of the code at the commit(s) identified in §2. It is **scoped and non-exhaustive**: only the components listed as in scope were reviewed, and the absence of findings in any area is not a proof that no issues exist there. Security assessment is a best-effort activity; **no audit can guarantee** that a codebase is free of vulnerabilities, and this report does not constitute such a guarantee, nor any warranty, nor financial, investment, or legal advice. **Limits of testing and tooling.** The review combined manual analysis with automated tools, each of which has inherent limits: static analysis produces false negatives and cannot reason about all cross-instruction or economic properties; fuzzing and property testing explore only a bounded input space; and a passing test suite demonstrates correct behavior on the exercised paths only, never the absence of defects elsewhere. Dynamic verification was performed only where noted in §3.5. **Assumptions.** The findings, their severities, and the residual-risk conclusions are **conditioned on the trust assumptions and model simplifications stated in §4.6** (trusted authorities, oracle behavior, trusted external programs, deployment configuration). Where any such assumption does not hold in production, the corresponding conclusions do not hold and the affected surface should be re-reviewed. The assessment evaluates **the source code only**. Under a shared-responsibility model, matters outside the code remain the responsibility of the deploying party, including but not limited to: private-key custody and operational security, the integrity of the deployment and upgrade process, the configuration of upgrade authorities / multisigs / timelocks, run-time monitoring and incident response, and the behavior of third-party programs and off-chain infrastructure that this code depends on. Any material change to the code, dependencies, deployment configuration, trust model, or economic parameters after the reviewed commit **invalidates the conclusions herein for the affected surface**; a re-review is recommended before such changes reach production. This report does **not** certify the code as "safe to deploy" — readiness is communicated through the code-maturity narrative (§8), finding resolution status (§1), and the trust-model caveats above, never through a blessing. The findings and their statuses describe the state of the code as of the publication date and are provided **as-is**.