Security Audit Report

WalletGuard.ai, powered by Gestalt Labs

April 17, 2026

ID: c28b2392

0xa7bf...1918EVMBench: 2024-04-noyav1View audit historyEthereumLive TargetCritical Risk

Verified on BaseVerify externally Prompt 0xd29afd...

Apr 17, 2026, 05:52

Standard AuditModel: Claude Sonnet 4.6

What you got

Tier: Standard ($29)
Model: Sonnet
Specialists completed: 9 of 9

Risk Level: Critical Risk

Efficiency

0C7H12M11L

30 security | 1 code quality | 3 gas

7 High: across 4 files

In-Scope Security Score Guide

8.0 - 10.0Low Risk. No critical issues. Safe for interaction.

5.0 - 7.9Moderate Risk. Some issues found. Review before interacting.

1.0 - 4.9High/Critical Risk. Significant vulnerabilities detected.

Score is based on 34 findings from 10 specialist agents.

Exploit Analysis

Forge fork-validation ran but no findings met the threshold for PoC inclusion. See the per-finding "Forge validated" badges in the report below for individual results.

Executive Summary

The analyzed contract is a DeFi vault system (AccountingManager) implementing a queue-based deposit and withdrawal mechanism with ERC4626 inheritance, multi-connector TVL aggregation, flash loan support, and a multi-tier governance model. The analysis identified 2 critical, 8 high, 10 medium, 9 low, and 4 informational findings across 34 total deduplicated findings from 9 specialist agents. The single most dangerous pattern is the MorphoBlue TVL double-counting of borrow amounts as assets, which combined with a manipulable Uniswap V3 slot0 oracle creates a composable path to drain vault value from other depositors. The contract in its current state is unsafe for production use without remediation of the critical and high severity issues, particularly the access control logic inversion in onlyVaultMaintainer and the oracle manipulation surfaces.

Critical Highlights

criticalMorphoBlue _getPositionTVL Double-Counts Borrow Amount as Collateral

When the vault calculates its total value locked using MorphoBlue positions, it incorrectly adds the amount the vault has borrowed (which is a debt it owes) as if it were an asset it owns. This makes the vault appear far wealthier than it actually is. An attacker can exploit this by depositing when TVL is inflated to receive more shares than they deserve, then withdrawing at the true lower value, effectively stealing funds from other depositors.

criticalUniswap V3 slot0 Used for TVL in UNIv3Connector (_getPositionTVL)

The vault calculates the value of its Uniswap V3 positions using the current spot price, which can be instantly manipulated within a single transaction using a flash loan. An attacker can borrow a large amount, move the price to inflate or deflate the vault's apparent value, then deposit or withdraw at the manipulated price to extract value from honest depositors.

highonlyVaultMaintainer modifier uses AND logic instead of OR, making it always revert

A logic error in the access control modifier means that vault maintainers cannot perform essential administrative actions such as adding connectors, updating trusted tokens, or removing positions. Only an address that simultaneously holds both the maintainer role and the emergency role can call these functions, which is likely never the case in practice. This locks critical protocol administration indefinitely.

30 Security Findings | 1 Code Quality | 3 Gas Optimizations

high(7)

medium(12)

Decentralization

4 centralization points identified

Missing two-step ownership transfer in Ownable-based contracts

Single-step ownership transfer in NoyaFeeReceiver can result in permanent loss of administrative control if the new owner address is incorrect; this is a property the buyer should know.

constructor()

UniswapValueOracle TWAP Window Default of 1800 Seconds May Be Too Short

The period is maintainer-configurable with no lower bound, making it a privileged parameter that could be set to near-zero, effectively converting the TWAP to a spot price read.

setPeriod()

setDepositLimits allows setting zero limits which would brick all deposits

Setting deposit limits to zero requires a trusted maintainer action; this is an admin capability the buyer should be aware of, not an externally exploitable vulnerability.

setDepositLimits()

AccountingManager overrides standard ERC4626 functions with unconditional reverts

The ERC4626 non-compliance is intentional by design and does not create an exploit path, but it is a property integrators must know as it breaks composability with ERC4626-assuming protocols.

mint()

Attack Chain Analysis

Flash Loan Oracle Manipulation to Vault Draincritical

An attacker uses a flash loan (via BalancerFlashLoan, which has no access control on makeFlashLoan) to perform a large swap in a Uniswap V3 pool that the UNIv3Connector uses for TVL via slot0. The manipulated slot0 price inflates the reported TVL. In the same transaction window, the inflated TVL causes AccountingManager to issue more shares per unit of baseToken deposited. The attacker then deposits baseToken at the inflated share price, reverses the price manipulation, and withdraws shares at the true higher per-share value, extracting value from existing depositors. The deposit ordering bug (safeTransferFrom before limit checks) further reduces friction for large deposits.

Uniswap V3 slot0 Used for TVL in UNIv3Connector (_getPositionTVL)BalancerFlashLoan.receiveFlashLoan allows arbitrary connector calls with user-controlled calldataDeposit Occurs Before Limit Checks Allow Attacker to Lock Funds

MorphoBlue TVL Inflation to Share Price Arbitragecritical

The MorphoBlue connector adds borrow amounts as assets rather than liabilities, permanently inflating TVL for any vault with active MorphoBlue borrows. Combined with the Chainlink stale price issue (missing answeredInRound check), an attacker can time a deposit during a stale price period when the Chainlink oracle has not yet updated a round, causing the vault to use the inflated MorphoBlue TVL alongside a stale favorable price to compute share issuance. The attacker receives excess shares relative to contributed value, then redeems after prices normalize.

MorphoBlue _getPositionTVL Double-Counts Borrow Amount as CollateralChainlink latestRoundData() Missing answeredInRound >= roundId Check

Compromised Keeper Flash Loan Arbitrary Executioncritical

makeFlashLoan has no access control, allowing any caller to initiate a flash loan and set themselves as the caller state variable. The security of receiveFlashLoan rests entirely on the caller matching keeperContract. If the keeperContract address is updated through governance (which is accessible via the broken onlyVaultMaintainer modifier allowing emergency role bypass), a malicious keeper can call makeFlashLoan, and receiveFlashLoan will execute arbitrary calls on any destinationConnector addresses with borrowed funds and user-supplied calldata, draining connector assets.

BalancerFlashLoan.receiveFlashLoan allows arbitrary connector calls with user-controlled calldataBalancerFlashLoan.receiveFlashLoan only validates caller is vault but doesn't verify caller is the legitimate keeperContractonlyVaultMaintainer modifier uses AND logic instead of OR, making it always revert

Performance Fee Griefing via Oracle-Triggered TVL Resethigh

checkIfTVLHasDroped is publicly callable and resets performance fee state if current TVL is below stored profit. An attacker who can temporarily reduce TVL (e.g., via slot0 price manipulation on a Uniswap V3 connector position, or by exploiting the MorphoBlue borrow double-count being corrected by a market move) can call checkIfTVLHasDroped immediately before the 12-48 hour collection window closes, zeroing out preformanceFeeSharesWaitingForDistribution. This can be repeated indefinitely to permanently block fee collection.

checkIfTVLHasDroped is public and can be called by anyone to reset performance fee sharesUniswap V3 slot0 Used for TVL in UNIv3Connector (_getPositionTVL)collectPerformanceFees has a 12-48 hour collection window that can be missed, permanently losing performance fees

Agent Coverage

Agent	Status	Findings	Severity	Confidence	Duration	Coverage
reentrancy	success	6	1H2M1L	69%	1.3m	Classic reentrancy in deposit/withdraw/executeDeposit/executeWithdraw functions, Cross-function reentrancy between deposit queue and withdraw queue shared state, ERC-4626 deposit/withdraw ordering (shares minted before/after token transfer), Flash loan callback in BalancerFlashLoan.receiveFlashLoan, ReentrancyGuard usage and placement across all contracts, CEI pattern compliance in AccountingManager, sendTokensToTrustedAddress external calls, Registry modifier logic correctness, Fee collection functions (collectManagementFees, collectPerformanceFees, recordProfitForFee), retrieveTokensForWithdraw external calls to connectors, Read-only reentrancy via TVL()/totalAssets() view functions, Connector addLiquidity callback chain, Token transfer ordering in executeWithdraw loop
access control	success	7	1H2M1L	80%	1.3m	Access control modifiers in PositionRegistry (onlyVaultMaintainer, onlyVaultGoverner, onlyVaultMaintainerWithoutTimeLock), AccountingManager deposit/withdraw flow and limit checks ordering, Fee collection functions and authorization checks, BalancerFlashLoan receiveFlashLoan arbitrary call execution, sendTokensToTrustedAddress access control patterns, burnShares unrestricted access, ERC4626 standard override functions, Signature-based operations in Keepers multisig (nonce, deadline, replay protection), Initializer protection (no proxy pattern detected), Registry role administration and self-granting risks, Ownership patterns in NoyaFeeReceiver and Keepers, Flash loan guard patterns in BalancerFlashLoan, OmnichainLogic bridge transaction approval flow, Connector delegatecall patterns (none found), Withdraw queue state machine correctness, Event emission correctness in fulfillCurrentWithdrawGroup, TVL calculation ordering in deposit, Cross-function reentrancy with nonReentrant guards
economic	success	10	3H1M1L	87%	1.6m	Flash loan attack vectors in deposit/withdraw flow, Oracle manipulation - Chainlink staleness checks in ChainlinkOracleConnector, Oracle manipulation - Uniswap V3 slot0 usage in UNIv3Connector TVL, Oracle manipulation - spot reserve usage in Aerodrome/Camelot LP TVL, Oracle manipulation - UniswapValueOracle TWAP window, MEV/sandwich exposure in share calculation timing, Governance access control modifiers in PositionRegistry, Accounting logic in deposit() - ordering of checks vs transfers, Withdraw group lifecycle - calculateWithdrawShares accumulation, MorphoBlue TVL calculation correctness, Fee calculation precision in BalancerConnector, BalancerFlashLoan - caller authentication, ReentrancyGuard usage across accounting flows, Chainlink answeredInRound completeness check, WETH_Oracle mock - hardcoded values not relevant to production security, PrismaConnector, FraxConnector, SiloConnector TVL calculations, DolomiteConnector debt/collateral accounting, PendleConnector SY/PT/YT pricing via static router
logic validation	success	10	3L	76%	1.9m	Input validation and parameter bounds in AccountingManager deposit/withdraw/fee functions, Arithmetic safety in fee calculations, share price calculations, and TVL computations, State machine integrity for deposit/withdraw queue state transitions, Access control modifiers in Registry (onlyVaultMaintainer logic bug), Reentrancy protection via ReentrancyGuard usage, Flash loan security in BalancerFlashLoan, MorphoBlue TVL calculation correctness, Downcast safety in UniswapValueOracle, Unbounded loop analysis in TVLHelper, Deposit limit ordering and validation, fulfillCurrentWithdrawGroup event emission ordering, calculateWithdrawShares accumulation logic, retrieveTokensForWithdraw validation ordering, ERC4626 overrides to prevent standard deposit/withdraw/mint/redeem, abi.encodePacked usage for hash collision risks, Keepers multisig signature validation
code quality	success	18		86%	2.5m	ERC4626 compliance - deposit/withdraw/mint/redeem override behavior, Deposit queue ordering and fund transfer logic, Withdraw queue state machine correctness, Fee calculation logic (management, performance, withdrawal), TVL calculation across all connectors for underflow/overflow, Access control modifiers in Registry (onlyVaultMaintainer AND vs OR bug), Flash loan callback security in BalancerFlashLoan, Oracle price manipulation resistance, uint128 downcast safety in UniswapValueOracle, Reentrancy protection (nonReentrant guards present), Cross-connector TVL aggregation correctness, MorphoBlue TVL calculation (borrow+supply+collateral instead of supply-borrow+collateral), Deposit limit checks ordering relative to token transfer, Withdraw group state machine (calculateWithdrawShares, startCurrentWithdrawGroup, fulfillCurrentWithdrawGroup, executeWithdraw), Event emission correctness (WithdrawGroupFulfilled totalCBAmount = 0 bug), burnShares access control, retrieveTokensForWithdraw cumulative amount validation, Bridge transaction approval mechanism in OmnichainLogic, Keepers multisig signature validation, ChainlinkOracleConnector staleness check
compiler bugs	success	4		86%	49.4s	AccountingManager deposit/withdraw/execute flow and queue state management, Fee collection logic (management, performance, withdrawal fees), Access control modifiers in Registry and NoyaGovernanceBase, Registry.onlyVaultMaintainer modifier logic, fulfillCurrentWithdrawGroup event emission ordering, retrieveTokensForWithdraw validation logic, BalancerFlashLoan access control and callback validation, BaseConnector sendTokensToTrustedAddress trust model, Deposit limit checks ordering relative to token transfer, Compiler version (0.8.20 fixed - no legacy compiler bugs applicable), Reentrancy guards on state-modifying functions, ERC4626 standard compliance overrides
assembly safety	success	10	2H3M	84%	1.9m	Full codepoint-by-codepoint scan for non-ASCII characters, homoglyphs, zero-width characters, and RTLO characters - none found, All assembly{} blocks scanned - none found in this codebase (FullMath, TickMath, and library code contain assembly but none of the anti-patterns), AccountingManager deposit/withdraw queue logic and arithmetic, PositionRegistry access control modifiers (onlyVaultMaintainer bug identified), Fee calculation and collection logic (performance, management, withdrawal fees), Flash loan BalancerFlashLoan security model, fulfillCurrentWithdrawGroup state mutation ordering and event emission, retrieveTokensForWithdraw balance validation logic, executeDeposit control flow and error conditions, TVL calculation across connectors (Morpho, Compound, Aave), burnShares access control and pause bypass, Keepers multisig signature verification, Registry vault and position management, ERC4626 override functions, SwapAndBridgeHandler route verification
l2 specific	success	11	3M3L	82%	2.1m	AccountingManager deposit/withdraw queue logic and ordering, Fee calculation and distribution (management, performance, withdrawal), PositionRegistry access control modifiers, BalancerFlashLoan access control and flash loan flow, Keepers multi-sig signature verification, MorphoBlue TVL calculation, Chainlink oracle freshness checks, executeDeposit connector validation logic, calculateWithdrawShares accumulation logic, fulfillCurrentWithdrawGroup fulfillment conditions, Cross-chain L2 patterns (no L2-specific imports found in core contracts), ERC4626 override functions (correctly revert with NOT_ALLOWED), ReentrancyGuard usage across all state-changing functions, Token transfer safety (SafeERC20 used throughout), Registry vault maintainer/governance modifier logic, Performance fee time window constraints, Deposit limit checks ordering relative to token transfers
upgrade	success	9	3M2L	77%	2.0m	AccountingManager deposit/withdraw queue ordering and limit checks, Registry modifier logic (onlyVaultMaintainer AND vs OR condition), Fee collection mechanics (management fee, performance fee, withdraw fee), Flash loan implementation security in BalancerFlashLoan, Access control on sendTokensToTrustedAddress, WithdrawGroup state machine transitions, Event emission ordering relative to state changes, retrieveTokensForWithdraw cumulative over-retrieval, checkIfTVLHasDroped public access griefing vector, ERC4626 standard override correctness (mint/withdraw/redeem/deposit all revert), NoyaFeeReceiver withdrawal flow, PositionRegistry holding position management, BaseConnector token registry and liquidity management, Cross-connector token transfer security in sendTokensToTrustedAddress, Proxy pattern - no proxy pattern detected, not applicable, Storage collision - no proxy pattern, not applicable, Initialization risks - no upgradeable pattern, not applicable

Scope and Methodology

Target0xa7bf65ebbc8d5450deed9e5e18529f6822321918

ChainEthereum

Complexitymoderate

Analysis ModelClaude Sonnet 4.6

Specialist Agents10

Agent Types

reentrancyaccess controleconomiclogic validationcode qualitycompiler bugsassembly safetyl2 specificupgrade

Scope TemplateGeneral Smart Contract (auto-selected)

MethodologyAutomated multi-agent analysis. Each specialist agent independently reviews the contract source code for vulnerabilities in its domain. Findings are deduplicated, scored, and synthesized into this report.

Findings are gated by demonstrated exploit feasibility against the analyzed contract. Observations that describe accepted blockchain behavior, consensus-layer issues, or infeasible preconditions are excluded from scored findings. See scope policy.

Severity Classification

CriticalDirect loss of funds or complete protocol compromise. Exploitable with high likelihood. Requires immediate remediation.

HighSignificant risk to funds or protocol integrity. Conditionally exploitable or requires specific circumstances. Should be fixed before deployment.

MediumLimited or conditional impact. May require unlikely conditions to exploit. Should be addressed but not blocking.

LowMinor impact. Best practice deviations, minor inefficiencies. Fix when convenient.

InformationalNo direct security impact. Code quality observations, gas optimizations, style recommendations.

Limitations

This automated audit has inherent limitations. The following areas are not covered.

-Business logic correctness: The audit detects structural and pattern-level code issues but cannot verify whether the queue-based deposit and withdrawal lifecycle, share pricing model, and fee accrual logic correctly implement the intended economic design of the protocol.

-Off-chain component security: The security of keeper bot infrastructure, multi-sig key management for Keepers.execute signers, registry governance key custody, and the operational discipline of maintainers (e.g., timely collectPerformanceFees calls within the 12-48 hour window) cannot be assessed from on-chain code alone.

-Economic modeling: The viability of the TWAP oracle window (1800 seconds) against real liquidity depth in specific pools, whether the TVL-to-shares conversion remains economically sound under stress scenarios, and whether the 10-day management fee cap adequately incentivizes timely fee collection are outside the scope of static analysis.

-Cross-protocol composability risks: Interactions between this vault and external protocols (MorphoBlue, Aave, Compound, Balancer, Uniswap V3, Aerodrome, Camelot, Frax, Silo, Dolomite, Pendle, Prisma) beyond the TVL calculation interfaces analyzed here, including protocol-specific upgrade risks and governance actions in those protocols, are not fully evaluated.

-Governance social dynamics: The feasibility of governance attacks (bribery, vote-buying, hostile governance proposals) that could change keeperContract, vault maintainer, or registry roles to enable the exploit chains identified is a social and economic question that static analysis cannot answer.

-Prompt injection detection: The source code analyzed is untrusted user input. The system monitored for instructions embedded in findings or source code attempting to direct scope gate decisions. No such injections were detected in this scan, but the limitation of trusting agent-reported findings without re-reading raw source applies.