
Loading...
Loading
Loading...
LoadingLoading audit report...

WalletGuard.ai, powered by Gestalt Labs
Findings selected for deep verification. Where possible we generated a Solidity proof-of-concept and executed it against a forked mainnet.
src/HypoVault.solLines: 1-1The analyzed contract is a vault system consisting of HypoVault and PanopticVaultAccountant, implementing an epoch-based deposit and withdrawal queue with NAV-driven share pricing and a performance fee mechanism. The analysis identified 1 critical, 5 high, 5 medium, 6 low, and 5 informational findings. The single most dangerous pattern is the manager's unrestricted ability to make arbitrary external calls via the manage() function, which enables complete drainage of all vault assets including funds reserved for pending user withdrawals. The contract in its current form is unsafe for permissionless deployment; its security depends entirely on the trustworthiness and operational integrity of the manager role.
A single address called the 'manager' can instruct the vault to send any assets anywhere, including all funds deposited by users and all funds reserved for pending withdrawals. There is no whitelist, no time delay, and no way for users to exit before this happens. A compromised or malicious manager can empty the vault completely in a single transaction.
If the vault suffers investment losses, a key arithmetic operation in the deposit and withdrawal processing functions will fail and revert. Once this happens, no deposits can be finalized and no withdrawals can be processed, permanently trapping all user funds in the vault with no recovery path.
The manager controls both the prices used to calculate the vault's net asset value and the ability to move assets in and out of the vault at will. By temporarily removing assets before processing withdrawals and then returning them afterward, the manager can systematically pay users less than they are owed when they withdraw.
3 centralization points identified
The manage() function is an intentional design feature granting the manager broad operational authority; the risk arises from the scope of trust placed in the manager role rather than a coding defect. Per scope template guidance, admin capabilities are reported as centralization notes. The critical severity is preserved because the impact (total fund loss) is material and buyers must know about it.
manage()Single-step ownership transfer is a well-known operational risk for admin key management; its impact is limited to accidental misconfiguration rather than an externally triggerable exploit.
setManager()The cancel functions are intentionally restricted to the manager role; the risk is a trust and design choice rather than a coding defect.
cancelDeposit()The manager first uses the manage() arbitrary call capability to temporarily reduce the vault's on-chain asset balance by sending assets to a controlled address. The manager then calls fulfillWithdrawals, passing managerInput prices at the maximum allowed negative deviation from the TWAP (permitted by the TWAP deviation check). The resulting NAV is doubly depressed: once by the reduced actual balance and once by the adversarially chosen price inputs. Withdrawers receive fewer assets than their shares are worth. The manager then uses manage() again to recover the temporarily removed assets. This combines the unrestricted manage() finding with the manager price manipulation finding to extract value from withdrawers across every epoch.
If the vault sustains losses through its Panoptic positions such that NAV falls below the sum of pending deposit assets and reserved withdrawal assets, both fulfillDeposits and fulfillWithdrawals will revert due to unsigned integer underflow. This is reinforced by two independent findings describing the same underflow from different analytical perspectives. Once bricked, the manager cannot use cancelWithdrawal or cancelDeposit to unblock users without returning their funds, but the fulfillment path itself is permanently unavailable. Users with queued positions have no self-service exit.
The poolExposure1 premium calculation reversal (long minus short instead of short minus long) causes the token1 NAV component to be systematically misstated. Because the manager also supplies pool prices without array-length validation, a manager can provide a malformed managerInput that avoids the index that would expose the reversed calculation, or exploit the misstated NAV in concert with adversarially chosen prices within the TWAP deviation band to further skew share issuance prices. The combination means the NAV error can be directionally amplified by a sophisticated actor.
| Agent | Status | Findings | Severity | Confidence | Duration | Coverage |
|---|---|---|---|---|---|---|
| reentrancy | success | 8 | 2L | 74% | 1.6m | Cross-function reentrancy in deposit/withdrawal flows, ERC-20 transfer callback reentrancy (SafeTransferLib usage), Check-Effects-Interactions ordering in executeDeposit, executeWithdrawal, requestWithdrawal, Access control on manager functions (manage, fulfillDeposits, fulfillWithdrawals), NAV manipulation via manager-controlled input to computeNAV, Division by zero in epoch state calculations, Integer overflow/underflow in epoch accounting, Share price manipulation via initial totalSupply, Rounding/precision loss in pro-rata calculations, Read-only reentrancy in PanopticVaultAccountant.computeNAV, Arbitrary external call risks in manage(), ERC-777 callback risks (SafeTransferLib usage mitigates), Flash loan attack surface, Cross-contract state sharing between HypoVault and PanopticVaultAccountant, Epoch rollover logic correctness, userBasis tracking correctness in transfers |
| access control | success | 9 | 1H2M1L | 77% | 1.3m | Access control on all external/public functions, Manager privilege abuse via manage() arbitrary call, Signature verification and authentication patterns, Deposit and withdrawal epoch accounting logic, Basis (cost basis) tracking for performance fees, Share minting and burning via _mintVirtual/_burnVirtual, NAV computation in PanopticVaultAccountant, Oracle price manipulation and TWAP validation, Integer overflow/underflow in unchecked blocks, Reentrancy via SafeTransferLib usage, Initializer and constructor security, Ownership transfer patterns, Division by zero scenarios, Precision loss in mulDiv calculations, reservedWithdrawalAssets accounting integrity, Cross-epoch rollover logic for partial fulfillments, Transfer and transferFrom basis tracking |
| economic | success | 9 | 1H1M | 75% | 1.5m | Flash loan attack vectors on NAV computation and share pricing, Oracle manipulation via TWAP windows and manager-provided prices in PanopticVaultAccountant, Share price manipulation via deposit/withdrawal mechanics, Reentrancy in requestDeposit, requestWithdrawal, executeDeposit, executeWithdrawal, Integer overflow/underflow in basis calculations, NAV subtraction, epoch state, Access control on manager functions including unrestricted manage(), Division by zero in executeDeposit and requestWithdrawal, ERC20 compliance including totalSupply invariant, Performance fee calculation correctness and evasion vectors, Epoch state machine transitions and edge cases, Basis tracking precision loss in _transferBasis, Chainlink/TWAP oracle staleness checks in PanopticVaultAccountant, Withdrawal queue manipulation and remainder handling, NAV underflow in fulfillDeposits/fulfillWithdrawals |
| logic validation | success | 10 | 2M2L | 78% | 1.7m | Input validation on computeNAV parameters (array lengths, pool hash validation), Arithmetic safety in NAV calculation and share price computation, Deposit/withdrawal epoch state machine and transition logic, Performance fee calculation correctness, Manager privilege scope and potential abuse via manage(), Share transfer with basis tracking correctness, Integer overflow in unchecked blocks in computeNAV, reservedWithdrawalAssets accounting integrity, executeDeposit and executeWithdrawal idempotency and zero-division risks, underlyingTokens array bounds and deduplication logic, Pool exposure calculation symmetry (premium directions), NAV computation formula correctness including the +1 bias |
| code quality | success | 13 | 74% | 2.3m | ERC-20 conformance (totalSupply, balanceOf, transfer, transferFrom), Reentrancy in deposit/withdrawal flows, Access control on manager functions, Integer overflow/underflow in epoch accounting, uint128 downcast truncation, Division by zero in withdrawal execution, NAV computation correctness in PanopticVaultAccountant, Basis tracking for performance fees, Epoch state consistency across deposit/withdrawal fulfillment, Arbitrary call safety in manage() functions, Oracle price validation logic, Pool position accounting correctness, Cross-function reentrancy via SafeTransfer callbacks, Unchecked arithmetic in computeNAV | |
| compiler bugs | success | 6 | 72% | 1.3m | Deposit and withdrawal epoch state machine correctness, Performance fee calculation and bypass vectors, Manager privilege abuse via manage() function, NAV computation and oracle price manipulation bounds, Basis accounting for shares (transfer, mint, burn), Integer overflow/underflow in arithmetic operations, Access control on privileged functions, Reentrancy in deposit/withdrawal flows (SafeTransferLib used, no ETH callbacks for ERC20), Compiler bug patterns (pragma ^0.8.28 - outside all affected ranges), Virtual mint/burn vs totalSupply accounting consistency, reservedWithdrawalAssets invariant enforcement, Epoch rollover logic for partial fulfillments | |
| assembly safety | success | 9 | 1C1H1M1L | 83% | 1.4m | Full codepoint scan for non-ASCII characters, RTLO (U+202E), zero-width joiners (U+200D/U+200B/U+200C), and Cyrillic homoglyphs in all identifiers, comments, and string literals, Assembly block presence and safety (none found), Reentrancy in requestDeposit, requestWithdrawal, executeDeposit, executeWithdrawal, fulfillDeposits, fulfillWithdrawals, Access control on manager, owner, and vault-locked patterns, Integer overflow/underflow in epoch state arithmetic, Division-by-zero conditions in executeWithdrawal and requestWithdrawal, Share price manipulation via manager-controlled NAV input, Performance fee calculation correctness across partial fulfillments, Transfer/transferFrom basis accounting correctness, cancelDeposit/cancelWithdrawal manager privilege abuse, manage() arbitrary call vulnerability, ERC20 compliance (ERC20Minimal base), Epoch carry-forward logic for partial deposits and withdrawals, reservedWithdrawalAssets accounting correctness, PanopticVaultAccountant oracle deviation checks, vaultPools hash integrity checks |
| l2 specific | success | 10 | 1H1M1L | 77% | 1.6m | Reentrancy in deposit/withdrawal flows (SafeTransferLib usage, state updates before transfers), Access control on manager, owner, and public functions, NAV computation correctness and oracle manipulation vectors, Integer overflow/underflow in epoch accounting, Share price manipulation via phantom totalSupply, Performance fee calculation and fee wallet handling, Deposit/withdrawal rollover accounting correctness, Cross-epoch state consistency, Basis tracking arithmetic precision, Manager arbitrary call power (manage functions), L2-specific patterns (no L2 imports detected, Chain ID 1 mainnet deployment) |
This automated audit has inherent limitations. The following areas are not covered.
This report is an automated point-in-time assessment and does not guarantee protection against all possible attacks. It does not cover off-chain components, economic modeling, or business logic correctness unless explicitly noted. Changes to the contract after the audit commit are not reviewed. This is not financial or legal advice. WalletGuard, powered by Gestalt Labs, provides this analysis as-is with no warranty of completeness.
[](https://walletguard.ai/audit/6cb5012a-dc5c-4eb2-b752-08beb4698418)
<a href="https://walletguard.ai/audit/6cb5012a-dc5c-4eb2-b752-08beb4698418"> <img src="https://walletguard.ai/api/badge/6cb5012a-dc5c-4eb2-b752-08beb4698418" alt="WalletGuard Audit Badge" /> </a>