6.1 Shares are calculated before fee recomputation on mint, causing depositors to lose a portion of their assets
NullV1Pool charges its entry and exit fees on notional — the size of the bet a deposit represents — rather than on the deposit amount itself.
The fee is computed by one of two helpers, depending on the flow:
feeOnTotal — the caller handed over a fixed sum of collateral, so the fee has to be taken out of it;feeOnRawNotional — the caller asked for a fixed position size(shares), so the fee has to be added on top;
function feeOnTotal(uint256 assets, uint256 feeBasisPoints) internal pure returns (uint256) { return Math.mulDiv(assets, feeBasisPoints, feeBasisPoints + MAX_BASIS_POINTS, Math.Rounding.Ceil); }<br>function feeOnRawNotional(uint256 notional, uint256 assets, uint256 feeBasisPoints) internal pure returns (uint256) { if (notional == 0 || feeBasisPoints == 0) return 0; uint256 denom = assets * (feeBasisPoints + MAX_BASIS_POINTS); if (notional * feeBasisPoints >= denom) revert ErrorsLib.FeeExceedsAssets(); return Math.mulDiv(notional, assets * feeBasisPoints, denom - notional * feeBasisPoints, Math.Rounding.Ceil); }
The two functions are meant to be mirror implementations: feeOnRawNotional quotes the fee the user will pay, and feeOnTotal should pull exactly that same fee back out. This equivalence holds only if the fee rate stays constant regardless of deposit size
_notional places the depositor's own asset amount into the denominator:
function _notional(uint256 assets, bool depositing) private view returns (uint256) {
(, uint256 receiverAssets, uint256 payerAssets,,) = _market.state();
uint256 ownAssets =
(poolKind == NullV1PoolKind.Receiver ? receiverAssets : payerAssets) + (depositing ? assets : 0);
if (depositing && poolKind == NullV1PoolKind.Receiver) receiverAssets += assets;
uint256 settleableR = SettlementLib._settleableAssets(receiverAssets);
return ownAssets == 0 || settleableR == 0 || (depositing && SettlementLib._settleableAssets(payerAssets) == 0)
? 0
@==> : assets.mulDiv(settleableR, ownAssets);
}
As a result, a larger deposit enlarges the payer pool, which reduces the depositor's effective leverage, which in turn shrinks their fee ( fee = assets × settleableReceiver ÷ (payerPool + assets)) and vice versa.
The mint entry point is where this dependency is not handled correctly. mint first derives the fee from the net asset amount and passes the resulting gross amount to _deposit (step 1):
function previewDeposit(uint256 assets) public view override(IERC4626, ERC4626Upgradeable) returns (uint256) {
uint256 fee = Math.min(assets, feeOnTotal(_notional(assets, true), _market.entryFee()));
return super.previewDeposit(assets - fee);
}
function deposit(uint256 assets, address receiver) public virtual returns (uint256) {
// --SNIP
uint256 shares = previewDeposit(assets);
_deposit(_msgSender(), receiver, assets, shares);
return shares;
}
_deposit then recomputes the fee from the gross amount (step 2):
function _deposit(address caller, address receiver, uint256 assets, uint256 shares) internal virtual override {
// --SNIP
@==> uint256 fee = Math.min(assets, feeOnTotal(_notional(assets, true), _market.entryFee()));
IERC20(asset()).safeTransferFrom(caller, address(_market), assets);
_market.recordDeposit(assets, fee, poolKind);
_mint(receiver, shares);
emit Deposit(caller, receiver, assets, shares);
}
The fee is thus calculated twice, and the two calculations are expected to agree. In the mint flow, however, they do not, because each step computes the notional from a different amount:
previewMint (step 1) calculates the fee from the smaller, net amount, which corresponds to a higher notional ratio and therefore a higher fee rate. It quotes the user a gross amount to pay based on this fee;_deposit (step 2) discards that fee and recomputes it from the larger, gross amount, which corresponds to a lower fee rate (because of smaller notional) and therefore a smaller fee;
Because the fee actually charged is smaller than the one quoted when calculating the gross amount, more capital ends up in the pool than the minted shares were priced for. Critically, the share count is fixed in step 1 — before _deposit is called — and nothing subsequently adjusts it once the fee is recalculated from the gross amount. The resulting surplus capital sits in the payer pool with no shares attached to it, and is effectively distributed among all existing payer-shareholders. The depositor thereby loses a portion of the assets they paid in, without receiving any shares in return.
Consider the following example, which illustrates the issue: Pre-state: the payer pool holds 5,000 assets, the receiver pool holds 1,000,000 assets, and the entry fee is 0.25%.
- Bob wants a payer position worth
10,000 USDC. The notional for this position is 666,666, and the share count is fixed at this point. Bob calls mint, which calls previewMint to calculate the fee:;
- The fee quoted by
previewMint is 1,994.015. - The gross amount Bob must pay is
11,994.015.
- Bob pays
11,994.015 USDC against the shares requested, and this gross amount is passed to _deposit; _deposit recalculates the fee from this gross amount:;
- The notional of
11,994.015 is 705,778.076 - The recalculated fee is:
1,760.045
The fee actually taken ( 1,760.045) is therefore 233.97 USDC less than the fee originally quoted to Bob. The pool receives 10,233.97 USDC, but the shares minted for Bob remain fixed at the step-1 priced at 10,000 USDC. As a result, Bob effectively loses 233.97 USDC, since no shares back this amount — it is instead attributed to the existing payer-shareholders.
NOTE: Same issue exists in the withdraw flow.
Recommendation
Ensure the fee used to determine the minted share count and the fee actually recorded/transferred in _deposit are computed from the same basis. Concretely, either:
- Compute the fee once (e.g., in
mint/ previewMint) and pass it through to _deposit instead of recomputing it there from the gross amount, or; - Recompute the shares in
_deposit after the fee is finalised, so that the minted shares always match the fee actually charged;
6.2 _deposit does not revert on zero shares
When depositing into an underfunded pool, leverage is high, and the fee charged against the deposited assets can saturate to the full asset amount. As a result, a depositor can be charged a 100% fee on their assets:
function previewDeposit(uint256 assets) public view override(IERC4626, ERC4626Upgradeable) returns (uint256) {
uint256 fee = Math.min(assets, feeOnTotal(_notional(assets, true), _market.entryFee()));
return super.previewDeposit(assets - fee);
}
In this case, the shares minted for the depositor will be zero. The issue is that _deposit does not guard against this:
function _deposit(address caller, address receiver, uint256 assets, uint256 shares) internal virtual override {
if (NullV1Factory(_market.factory()).isDepositsPaused()) {
revert ErrorsLib.DepositsPaused();
}
_checkAllowed(caller, true);
_checkAllowed(receiver, true);
IERC20(asset()).safeTransferFrom(caller, address(_market), assets);
uint256 fee = Math.min(assets, feeOnTotal(_notional(assets, true), _market.entryFee()));
_market.recordDeposit(assets, fee, poolKind);
_mint(receiver, shares);
emit Deposit(caller, receiver, assets, shares);
}
This allows the depositor to pay a 100% fee while receiving zero shares, resulting in a loss of funds.
Recommendation
Add a check in _deposit that reverts if shares is zero.
6.3 deposit flow is cheaper than mint flow, causing protocol to lose portion of fees
Both payer and receiver pools charge entry fees against the notional, which is the leverage the deposit is making ( leverage = settleableReceiver / (payerPool + your deposit)). The higher the deposit is, the less the leverage is:
function _notional(uint256 assets, bool depositing) private view returns (uint256) {
(, uint256 receiverAssets, uint256 payerAssets,,) = _market.state();
uint256 ownAssets =
(poolKind == NullV1PoolKind.Receiver ? receiverAssets : payerAssets) + (depositing ? assets : 0);
if (depositing && poolKind == NullV1PoolKind.Receiver) receiverAssets += assets;
uint256 settleableR = SettlementLib._settleableAssets(receiverAssets);
return ownAssets == 0 || settleableR == 0 || (depositing && SettlementLib._settleableAssets(payerAssets) == 0)
? 0
@==> : assets.mulDiv(settleableR, ownAssets);
}
When making deposits into the pool, there are two flows: mint which spends the assets based on the requested shares, and deposit, which mints shares based on the requested assets. However, if we take a look at how both functions charge the fees: 1. previewMint:
function previewMint(uint256 shares) public view override(IERC4626, ERC4626Upgradeable) returns (uint256) {
uint256 assets = super.previewMint(shares);
return assets + feeOnRawNotional(_notional(assets, true), assets, _market.entryFee());
}
2. previewDeposit:
function previewDeposit(uint256 assets) public view override(IERC4626, ERC4626Upgradeable) returns (uint256) {
uint256 fee = Math.min(assets, feeOnTotal(_notional(assets, true), _market.entryFee()));
return super.previewDeposit(assets - fee);
}
previewMint calculates the leverage in _notional based on the net asset the user will deposit into the pool, while previewDeposit measures the leverage against a gross deposit that includes the fee that is about to be charged. That fee doesn't go into the pool, but still is included in the leverage calculation, which makes it less and thus gives higher shares. So, for depositing the same amount of assets, the deposit flow will be cheaper than mint flow, in which the former will charge fewer fees than the latter.
Consider the following example demonstrating the issue:
- Pre-state: The receiver pool has
1_000_000 assets and the payer pool has 5_000 assets; - mint flow:
- - To deposit a net amount of
10_000, you need spend 11_994,015555 and request shares of 100000000000000000000 - The fee charged:
11994015555 - Minted shares:
100000000000000000000
- deposit flow:
- amount spent:
11994015555 - The fee charged:
1760045072 - Minted shares:
102339704830000000000
So, through the deposit flow, the position's value has more 233,97 USDC than the mint flow, for the same spent amount.
Recommendation
Consider disabling one of the flows. It is tricky to fix the issue while keeping both flows given the notional logic.
6.4 Inconsistent reentrancy guard implementations across contracts
Reentrancy protection is implemented across the protocol to prevent untrusted external calls from re-entering state-modifying functions.
However, three distinct versions of reentrancy guards are used across the codebase rather than standardising on the custom NullV1ReentrancyGuard contract.
NullV1Market uses NullV1ReentrancyGuard;NullV1Factory uses ReentrancyGuard which is storage based;NullV1Router uses ReentrancyGuardTransient from OZ library;
This inconsistency creates architectural fragmentation and maintenance overhead across the codebase. Additionally, using persistent storage in NullV1Factory incurs higher execution gas costs than transient storage implementations.
Recommendation
Consider standardising all contracts across the project to use NullV1ReentrancyGuard as the single transient storage-based reentrancy guard implementation.
6.5 No mechanism to prevent deployment of new markets using whitelisted account, if compromised
In the NullV1Factory contract, the whitelistAdmin grants market creation privileges to specific addresses by calling the addToWhitelist(...) function. Whitelisted users can then call the createMarket(...) function to instantiate new markets with specific parameters, such as collateral tokens, oracle feeds, and funding rate models.
However, the NullV1Factory contract does not provide a removeFromWhitelist(...) function or any other mechanism to revoke an address's whitelisted status once it has been granted. While deposit functionality can be independently restricted using the setDepositsBlocked(...) function in the NullV1Pool contract via _checkAllowed(...), the createMarket(...) function relies solely on the isWhitelisted mapping without any secondary blocklist control.
function createMarket(...) external noDelegateCall nonReentrant returns (INullV1Market market) {
// ...
// @audit-issue The contract checks whitelist status, but there is no mechanism to revoke it.
if (!isWhitelisted[msg.sender]) {
revert ErrorsLib.NotAllowed(msg.sender);
}
// ...
}
This means that if a whitelisted address is compromised or should otherwise be restricted, the whitelistAdmin has no way to revoke its ability to create new markets. The compromised account can continue calling createMarket(...) indefinitely to deploy markets with arbitrary or malicious oracle parameters and funding rate models into the protocol.
Recommendation
Consider extending the existing blocklist check to also gate the createMarket(...) function.
