AI Advisory
Strategic guidance for secure AI adoption
Prepared by:
HALBORN
Last Updated 07/13/2026
Date of Engagement: June 23rd, 2026 - June 24th, 2026
100% of all REPORTED Findings have been addressed
All findings
12
Critical
0
High
0
Medium
4
Low
2
Informational
6
NUVA engaged Halborn to conduct a security assessment on their smart contracts beginning on June 23rd 2026 and ending on June 24th, 2026. The assessment scope was limited to the smart contracts provided to Halborn. Commit hashes and additional details are available in the Scope section of this report.
The reviewed contracts are a multi-hop ERC4626 vault system where NuvaVault is the outermost upgradeable vault, DedicatedVaultRouter orchestrates atomic three-hop deposits and manages asynchronous keeper-mediated redemptions, and RedemptionProxy is a disposable clone deployed per withdrawal request to unwind the vault stack and hold funds pending async settlement. Users deposit a base asset through three nested vaults in one transaction and redeem through a keeper-gated request/accept/sweep flow with a 7-day emergency self-rescue fallback. The underlying assetVault operates a two-step redemption model: requestRedeem() transfers the caller's shares into the vault and records a pending redemption, and an admin-gated completeRedeem() pulls the underlying asset from a separate redeemVault() and delivers it to the proxy, where the keeper sweeps it to the user.
Halborn was provided with 2 days for this engagement and assigned a full-time security engineer to assess the security of the smart contracts in scope. The assigned engineer possesses deep expertise in blockchain and smart contract security, including hands-on experience with multiple blockchain protocols.
The objective of this assessment is to:
Identify potential security vulnerabilities within the smart contracts.
Verify that the smart contract functionality operates as intended.
In summary, Halborn identified several areas for improvement to reduce the likelihood and impact of security risks, which were mostly addressed by the NUVA team. The main recommendations were:
Apply consistent balance-delta accounting in the sweep path to match the fee-on-transfer handling already implemented in the deposit path.
Introduce a user-callable cancellation function with a timeout that allows users to reclaim escrowed shares from pending redemption requests, preventing indefinite share lockup in the router if the keeper is unresponsive or delayed.
Move the proxy-to-user mapping cleanup inside the sweep execution branch so it only runs when a non-zero sweep was actually attempted, preventing premature deletion of valid unmatured redemptions.
Halborn performed a combination of manual review of the code and automated security testing to balance efficiency, timeliness, practicality, and accuracy in regard to the scope of the smart contract assessment. While manual testing is recommended to uncover flaws in logic, process, and implementation; automated testing techniques help enhance coverage of smart contracts and can quickly identify items that do not follow security best practices.
The following phases and associated tools were used throughout the term of the assessment:
Research into the architecture and purpose of the in-scope contracts.
Manual code review and walkthrough of the in-scope contracts.
Manual assessment of critical Solidity variables and functions to identify potential vulnerability classes.
Manual testing using custom scripts.
Static Analysis of security for scoped contract, and imported functions (Slither).
Local deployment and testing with (Foundry, Remix IDE).
| EXPLOITABILITY METRIC () | METRIC VALUE | NUMERICAL VALUE |
|---|---|---|
| Attack Origin (AO) | Arbitrary (AO:A) Specific (AO:S) | 1 0.2 |
| Attack Cost (AC) | Low (AC:L) Medium (AC:M) High (AC:H) | 1 0.67 0.33 |
| Attack Complexity (AX) | Low (AX:L) Medium (AX:M) High (AX:H) | 1 0.67 0.33 |
| IMPACT METRIC () | METRIC VALUE | NUMERICAL VALUE |
|---|---|---|
| Confidentiality (C) | None (C:N) Low (C:L) Medium (C:M) High (C:H) Critical (C:C) | 0 0.25 0.5 0.75 1 |
| Integrity (I) | None (I:N) Low (I:L) Medium (I:M) High (I:H) Critical (I:C) | 0 0.25 0.5 0.75 1 |
| Availability (A) | None (A:N) Low (A:L) Medium (A:M) High (A:H) Critical (A:C) | 0 0.25 0.5 0.75 1 |
| Deposit (D) | None (D:N) Low (D:L) Medium (D:M) High (D:H) Critical (D:C) | 0 0.25 0.5 0.75 1 |
| Yield (Y) | None (Y:N) Low (Y:L) Medium (Y:M) High (Y:H) Critical (Y:C) | 0 0.25 0.5 0.75 1 |
| SEVERITY COEFFICIENT () | COEFFICIENT VALUE | NUMERICAL VALUE |
|---|---|---|
| Reversibility () | None (R:N) Partial (R:P) Full (R:F) | 1 0.5 0.25 |
| Scope () | Changed (S:C) Unchanged (S:U) | 1.25 1 |
| Severity | Score Value Range |
|---|---|
| Critical | 9 - 10 |
| High | 7 - 8.9 |
| Medium | 4.5 - 6.9 |
| Low | 2 - 4.4 |
| Informational | 0 - 1.9 |
Critical
0
High
0
Medium
4
Low
2
Informational
6
| Security analysis | Risk level | Remediation Date |
|---|---|---|
| Inconsistent fee-on-transfer handling between deposit and redemption paths causes permanent DOS on keeper sweep | Medium | Solved - 06/30/2026 |
| Missing user-initiated cancellation for pending redemption requests allows permanent share lockup | Medium | Solved - 07/03/2026 |
| Premature mapping cleanup on zero-amount sweep permanently disables keeper sweep path for unfunded proxies | Medium | Risk Accepted - 06/30/2026 |
| Inability to cancel a pending async redemption leaves user funds unrecoverable when settlement stalls | Medium | Solved - 07/02/2026 |
| Hardcoded transfer recipient in all exit paths permanently locks funds when the recipient is blacklisted | Low | Risk Accepted - 06/30/2026 |
| Missing transaction deadline on deposit functions allows stale execution with outdated slippage parameters | Low | Risk Accepted - 06/30/2026 |
| Missing per-proxy failure isolation in batch sweep causes entire batch to revert on a single proxy failure | Informational | Solved - 06/29/2026 |
| Batch sweep event emits requested amounts instead of actual swept amounts, producing incorrect accounting records | Informational | Solved - 06/29/2026 |
| Default admin role never granted despite documentation claiming owner holds it | Informational | Solved - 07/01/2026 |
| Inaccurate storage gap comment omits a declared variable and misattributes a namespaced slot as linear | Informational | Solved - 06/30/2026 |
| Missing timelock on proxy implementation update allows immediate deployment of malicious clones | Informational | Partially Solved - 06/30/2026 |
| Stale slippage parameter in async redemption flow with no user update mechanism | Informational | Solved - 06/30/2026 |
//Medium
//Medium
//Medium
//Medium
//Low
//Low
//Informational
//Informational
//Informational
//Informational
//Informational
//Informational
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
