Nexus Mutual Cover Edit, Limit Orders and Staking Pool Fix Smart Contract Audit

</nav>
<article class="report">
<h1 id="introduction">Introduction</h1>
iosiro was commissioned by Nexus Mutual to perform a smart contract audit of changes to their protocol. Two auditors conducted the audit between 24 and 28 March 2025, using 10 audit days.
<h4 id="overview">Overview</h4>
During the audit, one high risk and one medium risk issue were found. The high risk issue could allow malicious users to cancel limit orders which they did not own, and the medium risk issue related to incorrect reward accounting when extending deposits.
In addition, several recommendations for code quality improvements were made.
<table class="findings-count">
<thead>
<tr>
<th> </th>
<th>Critical</th>
<th>High</th>
<th>Medium</th>
<th>Low</th>
<th>Informational</th>
</tr>
</thead>
<tbody>
<tr>
<td>Open</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
</tr>
<tr>
<td>Resolved</td>
<td>0</td>
<td>1</td>
<td>1</td>
<td>0</td>
<td>0</td>
</tr>
<tr>
<td>Closed</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
</tr>
</tbody>
</table>
<h4 id="scope">Scope</h4>
The assessment focused on source file listed below, with all other files considered out of scope. Any out-of-scope code interacting with the assessed code was presumed to operate correctly without introducing functional or security vulnerabilities.
<ul>
<li>Project name: smart-contracts</li>
<li>Initial audit commit: <a href="https://github.com/NexusMutual/smart-contracts/tree/2b95c13610cbabf19802174dec4653e178fc8394">2b95c13</a></li>
<li>Final review commit: <a href="https://github.com/NexusMutual/smart-contracts/tree/008edda3215e39fa82e83d2b8f34b376d1cd9f35">008edda</a></li>
<li>Files: Assessment.sol, AssessmentViewer.sol, IndividualClaims.sol, Cover.sol, CoverNFTDescriptor.sol, CoverProducts.sol, CoverViewer.sol, LimitOrders.sol, MemberRoles.sol, StakingPool.sol, StakingProducts.sol, StakingTypesLib.sol, TokenController.sol, NexusViewer.sol,</li>
</ul>
A specification is available in the <a href="#specification">Specification section</a> of this report.
<h1 id="disclaimer">Disclaimer</h1>
This report aims to provide an overview of the assessed smart contracts' risk exposure and a guide to improving their security posture by addressing identified issues. The audit, limited to specific source code at the time of review, sought to:
<ul>
<li>Identify potential security flaws.</li>
<li>Verify that the smart contracts' functionality aligns with their documentation.</li>
</ul>
Off-chain components, such as backend web application code, keeper functionality, and deployment scripts were explicitly not in-scope of this audit.
Given the unregulated nature and ease of cryptocurrency transfers, operations involving these assets face a high risk from cyber attacks. Maintaining the highest security level is crucial, necessitating a proactive and adaptive approach that accounts for the experimental and rapidly evolving nature of blockchain technology. To encourage secure code development, developers should:
<ul>
<li>Integrate security throughout the development lifecycle.</li>
<li>Employ defensive programming to mitigate the risks posed by unexpected events.</li>
<li>Adhere to current best practices wherever possible.</li>
</ul>
<h1 id="methodology">Methodology</h1>
The audit was conducted using the techniques described below.
<dl>
<dt>Code review</dt>
<dd>The source code was manually inspected to identify potential security flaws. Code review is a useful approach for detecting security flaws, discrepancies between the specification and implementation, design improvements, and high-risk areas of the system.</dd>
<dt>Dynamic analysis</dt>
<dd>The contracts were compiled, deployed, and tested in a test environment, both manually and through the test suite provided. Dynamic analysis was used to identify additional edge cases, confirm that the code was functional, and to validate the reported issues.</dd>
<dt>Automated analysis</dt>
<dd>Automated tooling was used to detect the presence of various types of security vulnerabilities. Static analysis results were reviewed manually and any false positives were removed. Any true positive results are included in this report.</dd>
</dl>
<h1 id="audit-findings">Audit findings</h1>
The table below provides an overview of the audit's findings. Detailed write-ups are provided below.
<table class="findings">
<thead>
<tr>
<th>ID</th>
<th>Issue</th>
<th>Risk</th>
<th>Status</th>
</tr>
</thead>
<tbody>
<tr>
<td><a href="#IO-NXM-CLS-001">IO-NXM-CLS-001</a></td>
<td>Insufficient order cancellation checks</td>
<td class="rating-high">High</td>
<td class="status-resolved">Resolved</td>
</tr>
<tr>
<td><a href="#IO-NXM-CLS-002">IO-NXM-CLS-002</a></td>
<td>Fee reward shares not incremented</td>
<td class="rating-medium">Medium</td>
<td class="status-resolved">Resolved</td>
</tr>
</tbody>
</table>
Each issue identified during the audit has been assigned a risk rating. The rating is determined based on the criteria outlined below.
<dl>
<dt>Critical risk</dt>
<dd>The issue could result in the theft of funds from the contract or its users.</dd>
<dt>High risk</dt>
<dd>The issue could result in the loss of funds for the contract owner or its users.</dd>
<dt>Medium risk</dt>
<dd>The issue resulted in the code being dysfunctional or the specification being implemented incorrectly.</dd>
<dt>Low risk</dt>
<dd>A design or best practice issue that could affect the ordinary functioning of the contract.</dd>
<dt>Informational</dt>
<dd>An improvement related to best practice or a suboptimal design pattern.</dd>
</dl>
In addition to a risk rating, each issue is assigned a status:
<dl>
<dt>Open</dt>
<dd>The issue remained present in the code as of the final commit reviewed and may still pose a risk.</dd>
<dt>Resolved</dt>
<dd>The issue was identified during the audit and has since been satisfactorily addressed, removing the risk it posed.</dd>
<dt>Closed</dt>
<dd>The issue was identified during the audit and acknowledged by the developers as an acceptable risk without actioning any change.</dd>
</dl>
<a name="IO-NXM-CLS-001"></a><h2 id="io-nxm-cls-001-insufficient-order-cancellation-checks" class="break-before">IO-NXM-CLS-001 Insufficient order cancellation checks</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-high">High</td>
<td class="status-resolved">Resolved</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/2b95c13610cbabf19802174dec4653e178fc8394/contracts/modules/cover/LimitOrders.sol#L131-L152">LimitOrders.sol#L131-L152</a></td>
</tr>
</tbody>
</table>
An attacker could cancel any order by calling <code>LimitOrders::cancelOrder()</code> with the <code>BuyCoverParams</code> and <code>ExecutionDetails</code> values of the target order, signed with the attacker's private key.
<h3 id="recommendation">Recommendation</h3>
This issue could be resolved by including the buyer/signer address in <code>ExecutionDetails</code> and checking the order signer against this address, in addition to the existing <code>msg.sender</code> check.
Additionally, in <code>LimitOrders::executeOrder()</code> a check should be added to ensure the recovered <code>buyer</code> address is the same as the proposed <code>ExecutionDetails::buyer</code> address.
These proposed changes are shown in the following diff:
<pre tabindex="0" class="chroma"><code>diff --git a/contracts/interfaces/ILimitOrders.sol b/contracts/interfaces/ILimitOrders.sol
index 3d3f311d..80507103 100644
--- a/contracts/interfaces/ILimitOrders.sol
+++ b/contracts/interfaces/ILimitOrders.sol
@@ -16,6 +16,7 @@ struct ExecutionDetails {
 uint256 renewableUntil;
 uint256 renewablePeriodBeforeExpiration;
 uint256 maxPremiumInAsset;
+ address buyer;
 }

 struct OrderDetails {
@@ -74,5 +75,6 @@ interface ILimitOrders {
 error OrderCannotBeRenewedYet();
 error OrderPriceNotMet();
 error NotOrderOwner();
+ error NotOrderSigner();
 error InvalidOwnerAddress();
 }
diff --git a/contracts/modules/cover/LimitOrders.sol b/contracts/modules/cover/LimitOrders.sol
index 4e88fee5..4923438b 100644
--- a/contracts/modules/cover/LimitOrders.sol
+++ b/contracts/modules/cover/LimitOrders.sol
@@ -38,7 +38,8 @@ contract LimitOrders is ILimitOrders, MasterAwareV2, EIP712 {
 "uint256 executableUntil,",
 "uint256 renewableUntil,",
 "uint256 renewablePeriodBeforeExpiration,",
- "uint256 maxPremiumInAsset)",
+ "uint256 maxPremiumInAsset,"
+ "address buyer)",
 // OrderDetails
 "OrderDetails(",
 "uint256 coverId,",
@@ -87,6 +88,7 @@ contract LimitOrders is ILimitOrders, MasterAwareV2, EIP712 {

 bytes32 orderId = getOrderId(params, executionDetails);
 address buyer = ECDSA.recover(orderId, signature);
+ require(buyer == executionDetails.buyer, NotOrderSigner());

 OrderStatus memory _orderStatus = orderStatus[orderId];
 bool isNewCover = _orderStatus.coverId == 0;
@@ -140,6 +142,7 @@ contract LimitOrders is ILimitOrders, MasterAwareV2, EIP712 {
 address signer = ECDSA.recover(orderId, signature);

 require(signer == msg.sender, NotOrderOwner());
+ require(signer == expirationDetails.buyer, NotOrderSigner());

 OrderStatus memory _orderStatus = orderStatus[orderId];

@@ -167,7 +170,8 @@ contract LimitOrders is ILimitOrders, MasterAwareV2, EIP712 {
 executionDetails.executableUntil,
 executionDetails.renewableUntil,
 executionDetails.renewablePeriodBeforeExpiration,
- executionDetails.maxPremiumInAsset
+ executionDetails.maxPremiumInAsset,
+ executionDetails.buyer
 )
 );
 // Hash the OrderDetails struct
</code></pre><h3 id="client-response">Client response</h3>
Fixed in <a href="https://github.com/NexusMutual/smart-contracts/pull/1352/commits/d09a3c3d116cd0d75079d6289783a5678a88726d">d09a3c3</a>.
<a name="IO-NXM-CLS-002"></a><h2 id="io-nxm-cls-002-fee-reward-shares-not-incremented" class="break-before">IO-NXM-CLS-002 Fee reward shares not incremented</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-medium">Medium</td>
<td class="status-resolved">Resolved</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/2b95c13610cbabf19802174dec4653e178fc8394/contracts/modules/staking/StakingPool.sol#L1116">StakingPool.sol#L1116</a></td>
</tr>
</tbody>
</table>
When extending a deposit with a top-up amount, the new fee reward shares are not added to the fee deposit's reward shares.
<h3 id="recommendation-1">Recommendation</h3>
When calculating <code>feeDeposit.rewardsShares</code>, <code>newFeeRewardsShares</code> should be added, as in the below diff:
<pre tabindex="0" class="chroma"><code>diff --git a/contracts/modules/staking/StakingPool.sol b/contracts/modules/staking/StakingPool.sol
index 36883c4e..98e560e1 100644
--- a/contracts/modules/staking/StakingPool.sol
+++ b/contracts/modules/staking/StakingPool.sol
@@ -1113,7 +1113,7 @@ contract StakingPool is IStakingPool, Multicall {
 uint newEarningsPerShare = _accNxmPerRewardsShare.uncheckedSub(feeDeposit.lastAccNxmPerRewardShare);
 feeDeposit.pendingRewards += (newEarningsPerShare * feeDeposit.rewardsShares / ONE_NXM).toUint96();
 }
- feeDeposit.rewardsShares += initialFeeRewardShares.toUint128();
+ feeDeposit.rewardsShares += (initialFeeRewardShares + newFeeRewardShares).toUint128();
 feeDeposit.lastAccNxmPerRewardShare = _accNxmPerRewardsShare.toUint96();
 deposits[0][targetTrancheId] = feeDeposit;
 }
</code></pre><h3 id="client-response-1">Client response</h3>
Fixed in <a href="https://github.com/NexusMutual/smart-contracts/pull/1351/commits/bd8b797a7c79ba580724725040cac5434ce2ac92">bd8b797</a>
<h1 id="code-quality-improvement-suggestions">Code quality improvement suggestions</h1>
Code improvement suggestions without security implications are listed below.
<table class="codequality">
<thead>
<tr>
<th>#</th>
<th>Location</th>
<th>Details</th>
</tr>
</thead>
<tbody>
<tr>
<td>1</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/2b95c13610cbabf19802174dec4653e178fc8394/contracts/modules/cover/LimitOrders.sol#L82">LimitOrders.sol#L82</a></td>
<td>The <code>payable</code> modifier can be removed from the <code>LimitOrders::executeOrder()</code> function as this function is not intended to receive ETH.</td>
</tr>
<tr>
<td>2</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/2b95c13610cbabf19802174dec4653e178fc8394/contracts/modules/cover/Cover.sol#L337">Cover.sol#L337</a></td>
<td>In <code>_requestDeallocation</code> the same result is calculated twice as <code>expiration</code> and <code>previousCoverExpiration</code>. The named return parameter <code>previousCoverExpiration</code> can be calculated earlier and used for the remainder of the function instead.</td>
</tr>
<tr>
<td>3</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/2b95c13610cbabf19802174dec4653e178fc8394/contracts/modules/cover/LimitOrders.sol#L105">LimitOrders.sol#L105</a></td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/2b95c13610cbabf19802174dec4653e178fc8394/contracts/modules/cover/LimitOrders.sol#L105">LimitOrders.sol#L105</a> could result in a panic revert if the user submits an order with a very large <code>renewablePeriodBeforeExpiration</code> value. This can be prevented by changing this statement to <code>coverData.start + coverData.period < block.timestamp + executionDetails.renewablePeriodBeforeExpiration</code></td>
</tr>
<tr>
<td>4</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/2b95c13610cbabf19802174dec4653e178fc8394/contracts/modules/cover/LimitOrders.sol#L223">LimitOrders.sol#L223</a></td>
<td>In <code>LimitOrders::_buyCoverEthPayment()</code> <code>settlementDetails.fee</code> should be checked to ensure it’s greater than zero before the call to <code>transferFrom()</code> on <a href="https://github.com/NexusMutual/smart-contracts/blob/2b95c13610cbabf19802174dec4653e178fc8394/contracts/modules/cover/LimitOrders.sol#L223">LimitOrders.sol#L223</a>, similar to the check on <a href="https://github.com/NexusMutual/smart-contracts/blob/2b95c13610cbabf19802174dec4653e178fc8394/contracts/modules/cover/LimitOrders.sol#L261">LimitOrders.sol#L261</a> in <code>LimitOrders::_buyCoverErc20Payment()</code></td>
</tr>
<tr>
<td>5</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/2b95c13610cbabf19802174dec4653e178fc8394/contracts/modules/cover/LimitOrders.sol#L111">LimitOrders.sol#L111</a></td>
<td>The require statement on <a href="https://github.com/NexusMutual/smart-contracts/blob/2b95c13610cbabf19802174dec4653e178fc8394/contracts/modules/cover/LimitOrders.sol#L111">LimitOrders.sol#L111</a> should be moved to earlier in the function, ideally after <code>_orderStatus</code> is retrieved from storage and before any external calls</td>
</tr>
<tr>
<td>6</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/2b95c13610cbabf19802174dec4653e178fc8394/contracts/modules/cover/LimitOrders.sol#L102-L107">LimitOrders.sol#L102-L107</a></td>
<td>The code block on <a href="https://github.com/NexusMutual/smart-contracts/blob/2b95c13610cbabf19802174dec4653e178fc8394/contracts/modules/cover/LimitOrders.sol#L102-L107">LimitOrders.sol#L102-L107</a> could be moved to the preceding else block as the conditions are the same and this would improve code readability</td>
</tr>
<tr>
<td>7</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/2b95c13610cbabf19802174dec4653e178fc8394/contracts/modules/cover/LimitOrders.sol#L234">LimitOrders.sol#L234</a></td>
<td>The return statement on <a href="https://github.com/NexusMutual/smart-contracts/blob/2b95c13610cbabf19802174dec4653e178fc8394/contracts/modules/cover/LimitOrders.sol#L234">LimitOrders.sol#L234</a> should be moved to after the if statement. The statement itself is not strictly necessary as the function uses a named return variable, <code>coverId</code>. If it is removed, the return statement on <a href="https://github.com/NexusMutual/smart-contracts/blob/2b95c13610cbabf19802174dec4653e178fc8394/contracts/modules/cover/LimitOrders.sol#L273">LimitOrders.sol#L273</a> should also be removed to maintain consistent code convention.</td>
</tr>
<tr>
<td>8</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/2b95c13610cbabf19802174dec4653e178fc8394/contracts/interfaces/IStakingPool.sol#L182">IStakingPool.sol#L182</a></td>
<td>Deallocated event parameter should be <code>allocationID</code> and not <code>productID</code></td>
</tr>
<tr>
<td>9</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/2b95c13610cbabf19802174dec4653e178fc8394/contracts/modules/cover/Cover.sol#L141">Cover.sol#L141</a></td>
<td><code>coverRefernce</code> → <code>coverReference</code></td>
</tr>
</tbody>
</table>
<h3 id="client-response-2">Client response</h3>
<ol>
<li>Fixed in <a href="https://github.com/NexusMutual/smart-contracts/pull/1352/commits/5f40d0769a2171ae60fbb88db1d484173914be4d">5f40d07</a>.</li>
<li>Fixed in <a href="https://github.com/NexusMutual/smart-contracts/pull/1353/commits/919ed3a06c558ba905cc8004ff7c0c7ef8f9c65e">919ed3a</a>.</li>
<li>Fixed in <a href="https://github.com/NexusMutual/smart-contracts/pull/1352/commits/5ae5e7e2ee75483a19430d6f79a3aa69934d3b13">5ae5e7e</a>.</li>
<li>Fixed in <a href="https://github.com/NexusMutual/smart-contracts/pull/1352/commits/62304eddc84364c8eb318e32b95db93f6caf1bf0">62304ed</a>.</li>
<li>Fixed in <a href="https://github.com/NexusMutual/smart-contracts/pull/1352/commits/37bf5bc0ffeee3006a1fea5ded6b77e56cb98e16">37bf5bc</a>.</li>
<li>Fixed in <a href="https://github.com/NexusMutual/smart-contracts/pull/1352/commits/82a52fc4dfbd7462dc3e3c7178a37cc88939c7fe">82a52fc</a>.</li>
<li>Fixed in <a href="https://github.com/NexusMutual/smart-contracts/pull/1352/commits/a94bc9cac95a8b23c3a3e04fe749142721f1470f">a94bc9c</a>.</li>
<li>Fixed in <a href="https://github.com/NexusMutual/smart-contracts/pull/1353/commits/47c80b38c7556f3bcb7e9c9573f8c1a64904b6a7">47c80b3</a>.</li>
<li>Fixed in <a href="https://github.com/NexusMutual/smart-contracts/commit/b0af052971013371f8ec93e999099aea74a386d6">b0af052</a>.</li>
</ol>
<h1 id="specification">Specification</h1>
The following section outlines the main changes made to protocol's functionality at a high level, based on their implementation in the codebase. Any perceived points of conflict should be highlighted with the auditing team to determine the source of the discrepancy.
In addition to the named changes below, several code quality improvements were implemented, including the use of modern <code>require</code> statements with custom errors and the removal of legacy contracts.
<h2 id="cover-edit">Cover Edit</h2>
Users can now edit cover they have previously purchased – for example, changing the period or amount of the cover. Internally, this works by expiring the existing cover and creating a new one with the updated parameters. The premium is used to purchase the new cover.
The following risks were stated and accepted by Nexus Mutual:
<ul>
<li>Users could to edit their cover immediately before claiming, potentially reducing the cover period.</li>
<li>Users could significantly extend the period of a given cover if the NXM or asset price drops between initial purchase and cover editing.</li>
</ul>
<h2 id="limit-orders">Limit Orders</h2>
A new <code>LimitOrders</code> contract makes use of EIP-712 to allow users to set up recurring cover purchases. Users specify several details such as the maximum premium to pay and the execution period for the order and renewal. These orders are submitted to the Limit Orders contract by an authorised Solver contract.
<h2 id="staking-pool-fix">Staking Pool Fix</h2>
A bug in the <code>StakingPool</code> led to incorrect calculations of manager rewards when extending a deposit. This was fixed.

</article>
</main>
</div>

‍