6.1 Rounding error in executeDeposit(...) may lead to state inconsistency and excessive share minting
The vault's deposit mechanism is spread across three functions: requestDeposit(...), where users queue their assets; fulfillDeposits(...), where the manager finalizes an epoch by specifying the total assets to be invested; and executeDeposit(...), where users claim their shares based on the fulfilled amount.
In the executeDeposit(...) function, the portion of a user's deposit that gets fulfilled ( userAssetsDeposited) is calculated pro-rata using Math.mulDiv(...). Any of the user's assets that are not fulfilled ( assetsRemaining) are carried over to the next deposit epoch.
function executeDeposit(address user, uint256 epoch) external {
if (epoch >= depositEpoch) revert EpochNotFulfilled();
uint256 queuedDepositAmount = queuedDeposit[user][epoch];
queuedDeposit[user][epoch] = 0;
DepositEpochState memory _depositEpochState = depositEpochState[epoch];
// @audit-issue Due to downward rounding, the sum of all `userAssetsDeposited`
// across all users will be less than `_depositEpochState.assetsFulfilled`.
uint256 userAssetsDeposited = Math.mulDiv(
queuedDepositAmount,
_depositEpochState.assetsFulfilled,
_depositEpochState.assetsDeposited
);
// ...
// @audit The unfulfilled portion of the deposit is carried over to the user's balance in the next epoch.
uint256 assetsRemaining = queuedDepositAmount - userAssetsDeposited;
if (assetsRemaining > 0) queuedDeposit[user][epoch + 1] += uint128(assetsRemaining);
// ...
}
The issue is that Math.mulDiv(...) rounds down. Consequently, the sum of all userAssetsDeposited across all depositors in an epoch will be slightly less than the total assetsFulfilled defined by the manager.
This dust is problematic because while the assetsRemaining for each user (including their share of the dust) is carried over to the next epoch in the queuedDeposit mapping, the global state is not updated correspondingly. In fulfillDeposits(...), the next epoch's total assetsDeposited is calculated simply as the total unfulfilled assets, without accounting for the accumulated user-level dust from the previous epoch's rounding errors.
function fulfillDeposits(...) external onlyManager {
// ...
// @audit The global remaining assets are calculated here.
uint256 assetsRemaining = epochState.assetsDeposited - assetsToFulfill;
// ...
currentEpoch++;
depositEpoch = uint128(currentEpoch);
// @audit The next epoch's global deposit amount is set. This value will be smaller than the
// sum of all users' queued deposits due to the rounding errors from the prior epoch.
depositEpochState[currentEpoch] = DepositEpochState({
assetsDeposited: uint128(assetsRemaining),
sharesReceived: 0,
assetsFulfilled: 0
});
// ...
}
This creates a state inconsistency where the sum of individual queued deposits for an epoch is greater than the globally tracked depositEpochState[epoch].assetsDeposited. This inconsistency can cause an excessive number of shares to be minted. In the subsequent epoch, the denominator for the pro-rata calculation ( _depositEpochState.assetsDeposited) will be smaller than the actual sum of queued assets (the numerator). This inflates the fulfillment ratio, causing more shares to be minted than are backed by assets and diluting the value of all existing shareholders in the vault.
Recommendation
Consider modifying the current design to avoid this or consistently monitor the state of vaults to act quickly before the accumulation of this dust can become a problem.
Resolution
The underlying cause is that partial deposit fulfillments round down per user, while the next epoch’s global deposited amount only carries forward the aggregate remainder. This creates a mismatch between user-level queued deposits and the global epoch denominator. That said, the practical impact is limited to dust-level drift in the underlying asset’s smallest unit. For assets like USDC, the maximum mismatch per partially fulfilled epoch is bounded by the number of depositors minus one base unit, making economically meaningful extraction infeasible on Ethereum mainnet absent an unrealistic number of sybil depositors. We therefore acknowledge the issue as a real accounting edge case, but do not view it as a credible loss-of-funds or protocol-bricking risk under expected operating conditions.
A concrete USDC example shows the scale. If three users each deposit 1 USDC and only 2 USDC is fulfilled, each user is credited 0.666666 USDC and rolls 0.333334 USDC. The true rollover total is 1.000002 USDC, while the vault globally records 1.000000 USDC, creating a mismatch of only 0.000002 USDC total. If the same cohort is fully processed on the next fulfillment, that dust offsets exactly across that same cohort. A transfer only appears if the shareholder set changes between the partial fulfillment and the later rollover settlement, such as if new users deposit in between.
The magnitude is extremely small in native asset units. For USDC, this example is 2 x 10-6 USDC, which is six orders of magnitude below 1 USDC. For WETH, an analogous two-unit mismatch would be 2 x 10-18 WETH, which is eighteen orders of magnitude below 1 WETH. More generally, the drift is bounded by the number of depositors minus one in base units, so the impact depends on the number of distinct depositor addresses in a partially fulfilled epoch, not on the raw share-unit count.
From an attack perspective, an attacker would need many distinct depositor addresses all participating in a partially fulfilled epoch in order to accumulate any measurable benefit, and even then the result would only be dust. If assuming the vault managers fulfill on a regular cadence, the expected small depositor count per epoch, and the fact that partial fulfillment only occurs when the cap is hit and is then resolved on the next cycle, such an attack is extremely unlikely and economically unprofitable on Ethereum mainnet.
6.2 Rounding error in share distribution leads to locked yield
In the vault's deposit lifecycle, the fulfillDeposits(...) function calculates the total number of new shares to be created for an epoch and increases the contract's totalSupply accordingly. Subsequently, depositors call the executeDeposit(...) function to mint their individual portion of these new shares.
A problem arises in the executeDeposit(...) function where individual share amounts are calculated. The calculation uses Math.mulDiv(...), which rounds down.
function executeDeposit(address user, uint256 epoch) external {
// ...
// @audit-issue The downward rounding here means the sum of shares received by all
// users can be less than the total shares allocated for the epoch.
uint256 sharesReceived = Math.mulDiv(
userAssetsDeposited,
_depositEpochState.sharesReceived,
_depositEpochState.assetsFulfilled == 0 ? 1 : _depositEpochState.assetsFulfilled
);
_mintVirtual(user, sharesReceived);
// ...
}
Due to this downward rounding, the sum of all shares minted to individual users throughout an epoch may be less than the total amount by which the totalSupply was increased in fulfillDeposits(...).
function fulfillDeposits(...) external onlyManager {
// ...
uint256 _totalSupply = totalSupply;
uint256 sharesReceived = Math.mulDiv(assetsToFulfill, _totalSupply, totalAssets);
// ...
// @audit The totalSupply is increased by the full calculated amount,
// before individual (rounded-down) shares are minted to users.
totalSupply = _totalSupply + sharesReceived;
emit DepositsFulfilled(currentEpoch - 1, assetsToFulfill, sharesReceived);
}
This creates a persistent discrepancy where the totalSupply is greater than the sum of all user balances. The resulting difference is a growing number of shares that are not owned by any address.
Since the vault's Net Asset Value (NAV) and any generated profits are divided across the entire totalSupply, these shares are entitled to a portion of the vault's assets. This portion becomes locked in the contract, as there is no owner who can claim or redeem these shares. The portion of locked funds will growth with every new deposit epoch, continuously eroding the returns for legitimate shareholders.
Recommendation
Consider implementing a mechanism to handle the rounding dust from the share calculation in executeDeposit(...). For example, the last user to execute their deposit in an epoch receives any remaining fractional shares, thus aligning the sum of minted balances with the increase in totalSupply.
Resolution
The vault increases total supply for the full batch at fulfillment time, while per-user share allocations during execution are rounded down. This can leave a very small number of unowned shares in the system, which slightly dilutes returns over time. In practice this is a dust-level effect and not realistically exploitable for meaningful value extraction. We acknowledge the issue, but view the impact as negligible.
6.3 Manager has exclusive control over deposit cancellations
When users deposit assets into the HypoVault via the requestDeposit(...) function, their tokens are immediately transferred to and held by the contract. These funds remain in a pending state until processed by the vault's manager.
The contract provides a cancelDeposit(...) function to return these pending assets to the user. However, this function includes an onlyManager modifier, making the manager the only entity with the authority to execute a cancellation.
// @audit Only the manager can cancel a deposit.
function cancelDeposit(address depositor) external onlyManager {
uint256 currentEpoch = depositEpoch;
uint256 queuedDepositAmount = queuedDeposit[depositor][currentEpoch];
queuedDeposit[depositor][currentEpoch] = 0;
depositEpochState[currentEpoch].assetsDeposited -= uint128(queuedDepositAmount);
SafeTransferLib.safeTransfer(underlyingToken, depositor, queuedDepositAmount);
emit DepositCancelled(depositor, queuedDepositAmount);
}
This design places complete control over pending deposits with the manager role. Users cannot unilaterally retrieve their funds after depositing them. The return of unfulfilled assets is contingent upon the manager's action, creating a strong trust assumption regarding the manager's liveness and integrity.
Recommendation
The current design centralizes control over pending user funds. For future consideration, the team might evaluate introducing a permissionless way for users to cancel their own deposits.
Resolution
Fixed in commit a00f26. Users can now cancel their own pending deposits via the permissionless cancelDeposit(...) path, so the trust/liveness concern identified in the audit has been addressed.
6.4 The decimals(...) function returns a misleading value of 0 for underlying tokens that do not implement it
The HypoVault contract implements the ERC20 standard, representing shares in the vault. Its decimals(...) function is designed to mirror the decimals of the underlyingToken to ensure consistency.
The current implementation uses a try...catch statement to fetch the decimals from the underlying token. If the call to underlyingToken.decimals() fails—for instance, if the token contract does not implement this function—the catch block returns 0.
function decimals() external view returns (uint8) {
try IERC20Metadata(underlyingToken).decimals() returns (uint8 _decimals) {
return _decimals;
// @audit-issue If the underlying token does not implement decimals(), this returns 0.
} catch {
return 0;
}
}
The decimals() function is an optional part of the ERC20 standard. While a return value of 0 is valid and indicates a non-divisible token.
Returning 0 when the function is not implemented is misleading and can cause integration issues.
Recommendation
Consider modifying the behavior for underlying tokens that do not implement the decimals() function. Instead of returning 0, a different approach could be to revert the transaction to make the incompatibility explicit or set the decimals during initialization.
Resolution
This behavior may be misleading for integrators or user interfaces interacting with non-standard ERC20 tokens, but it does not create an onchain loss-of-funds scenario. We acknowledge the issue as a compatibility/documentation concern rather than a material protocol risk.
