Nexus Mutual Product Pricing Changes Smart Contract Audit

</nav>
<article class="report">
<h1 id="introduction">Introduction</h1>
<p>iosiro was commissioned by Nexus Mutual to perform an audit of changes made to their protocol's smart contracts that modified how cover products are priced. The audit was conducted between the 18th of December 2024 and the 6th of January 2025, using 4 audit days.</p>
<h4 id="overview">Overview</h4>
<p>The audit uncovered one informational issue which could arise in the event of products being restored from deprecation, as well as one potential code improvement. All issues were appropriately addressed by the team by the end of the audit, as shown in the table below.</p>
<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>0</td>
<td>0</td>
<td>0</td>
<td>1</td>
</tr>
<tr>
<td>Closed</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>1</td>
</tr>
</tbody>
</table>
<h4 id="scope">Scope</h4>
<p>The assessment focused on changes made to the source files listed below and related interfaces, 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.</p>
<ul>
<li><strong>Project name:</strong> <code>smart-contracts</code></li>
<li><strong>Initial audit commit:</strong> <a href="https://github.com/NexusMutual/smart-contracts/commit/275d1823b941e72bc75883b0f166c4198de1a8a8">275d182</a></li>
<li><strong>Final review commit:</strong> <a href="https://github.com/NexusMutual/smart-contracts/commit/e3a79973bba35907d6e9ffa84b609045eaadd73e">e3a7997</a></li>
<li><strong>Files:</strong> <code>Cover.sol</code>, <code>CoverProducts.sol</code>, <code>StakingPool.sol</code> <code>StakingProducts.sol</code></li>
</ul>
<p>A specification is available in the <a href="#specification">Specification section</a> of this report.</p>
<h1 id="disclaimer">Disclaimer</h1>
<p>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:</p>
<ul>
<li>Identify potential security flaws.</li>
<li>Verify that the smart contracts' functionality aligns with their documentation.</li>
</ul>
<p>Off-chain components, such as backend web application code, keeper functionality, and deployment scripts were explicitly not in-scope of this audit.</p>
<p>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:</p>
<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>
<p>The audit was conducted using the techniques described below.</p>
<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>
<p>The table below provides an overview of the audit's findings. Detailed write-ups are provided below.</p>
<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-PPC-001">IO-NXM-PPC-001</a></td>
<td>No mechanism to change <code>minPrice</code></td>
<td class="rating-informational">Informational</td>
<td class="status-resolved">Resolved</td>
</tr>
<tr>
<td><a href="#IO-NXM-PPC-002">IO-NXM-PPC-002</a></td>
<td>Potential storage collision</td>
<td class="rating-informational">Informational</td>
<td class="status-closed">Closed</td>
</tr>
</tbody>
</table>
<p>Each issue identified during the audit has been assigned a risk rating. The rating is determined based on the criteria outlined below.</p>
<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>
<p>In addition to a risk rating, each issue is assigned a status:</p>
<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-PPC-001"></a><h2 id="io-nxm-ppc-001-no-mechanism-to-change-minprice" class="break-before"><strong>IO-NXM-PPC-001</strong> No mechanism to change <code>minPrice</code></h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-informational">Informational</td>
<td class="status-resolved">Resolved</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/275d1823b941e72bc75883b0f166c4198de1a8a8/contracts/modules/cover/CoverProducts.sol#L213-L303">CoverProducts.sol#L213-L303</a></td>
</tr>
</tbody>
</table>
<p>There is no way to adjust the <code>minPrice</code> for existing products in <code>CoverProducts::setProduct()</code> . As such, it would not be possible to adjust this value for existing products, which may be undesirable.</p>
<h3 id="recommendation">Recommendation</h3>
<p>Functionality should be added to allow a product's <code>minPrice</code> value to be changed.</p>
<h3 id="client-response">Client response</h3>
<p>Fixed in <a href="https://github.com/NexusMutual/smart-contracts/commit/fd260f7edefb601bf02c654d8b1c40cd43f32731#diff-52d825e849d6c5456e0745daf1f7a5bd2ab127c74de57843f3441d42ef27f39b">fd260f7</a>.</p>
<a name="IO-NXM-PPC-002"></a><h2 id="io-nxm-ppc-002-potential-storage-collision" class="break-before"><strong>IO-NXM-PPC-002</strong> Potential storage collision</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-informational">Informational</td>
<td class="status-closed">Closed</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/275d1823b941e72bc75883b0f166c4198de1a8a8/contracts/interfaces/ICoverProducts.sol#L20">ICoverProducts.sol#L20</a></td>
</tr>
</tbody>
</table>
<p>The new per-product <code>minPrice</code> uses the storage slot that was previously used for a cover product’s <code>yieldTokenAddress</code> . Some deprecated products had this address set to a non zero value. As such, on upgrading <code>CoverProducts</code> with the in-scope changes, these products will have a non zero <code>minPrice</code> . As these products are deprecated, this would only pose a risk if they were restored.</p>
<h3 id="recommendation-1">Recommendation</h3>
<p>The <code>minPrice</code> could be explicitly be set to zero should these products be restored or on the upgrade of the protocol with these changes. This will require adding a mechanism to change <code>minPrice</code> .</p>
<h3 id="update">Update</h3>
<p>Functionality was added to change the <code>minPrice</code> of any product. As such, the affected deprecated products can have the <code>minPrice</code> value set, should they be restored.</p>
<h1 id="specification">Specification</h1>
<p>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.</p>
<p>Nexus Mutual made several cover product pricing adjustments to their smart contracts.</p>
<p>The main change was the removal of surge pricing – as such, a surge premium was no longer charged when buying cover that resulted in the consumption of the last 10% of capacity in a staking pool.</p>
<p>Additionally, the price bump ratio was adjusted from 20% to 5%. This meant that the price increase during periods of high frequency cover buys for a product was more gradual, up to a limit of 5%.</p>
<p>The protocol was also adjusted to allow the advisory board to set a per-product minimum price ratio instead of using a global minimum ratio for all products. The global minimum ratio will still be used as a fallback, if no minimum price ratio was set for a given product.</p>
<p>Finally, the <code>YieldTokenIncidents</code> contract and related interfaces were removed, as they were no longer in use, and several stylistic changes were made to the code.</p>

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

‍