Nexus Mutual RI Cover Changes Smart Contract Audit

</nav>
<article class="report">
<h1 id="introduction">Introduction</h1>
<p>iosiro was commissioned by Nexus Mutual to perform a smart contract audit of changes made to their Cover contract to accomodate purchasing of ReInsurance (RI) cover. The audit was conducted between the 14th and 16th of October 2025, using 3 audit days.</p>
<h4 id="overview">Overview</h4>
<p>Two low-risk issues were identified during the audit, both of which were closed due to sufficient mitigating factors. These issues related to the potential for a front-run attack on a member purchasing RI cover, using their signed <code>RiRequest</code>, as well as members not being able to reduce their cover without paying a premium.</p>
<table class="findings-count">
<thead>
<tr>
<th> </th>
<th>Critical</th>
<th>High</th>
<th>Medium</th>
<th>Low</th>
</tr>
</thead>
<tbody>
<tr>
<td>Open</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>
</tr>
<tr>
<td>Closed</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>2</td>
</tr>
</tbody>
</table>
<h4 id="scope">Scope</h4>
<p>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.</p>
<ul>
<li><strong>Project name:</strong> <a href="https://github.com/NexusMutual/smart-contracts">smart-contracts</a></li>
<li><strong>Initial audit commit:</strong> <a href="https://github.com/NexusMutual/smart-contracts/tree/b3cf7ebdec9a2882be7f323e19f0bed2545ecc58">b3cf7eb</a></li>
<li><strong>Final review commit:</strong> <a href="https://github.com/NexusMutual/smart-contracts/tree/b3cf7ebdec9a2882be7f323e19f0bed2545ecc58">b3cf7eb</a></li>
<li><strong>Files:</strong> Cover.sol, Pool.sol, RegistryAware.sol, CoverNFTDescriptor.sol</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-RIC-001">IO-NXM-RIC-001</a></td>
<td>Potential RI cover purchase front-run</td>
<td class="rating-low">Low</td>
<td class="status-closed">Closed</td>
</tr>
<tr>
<td><a href="#IO-NXM-RIC-002">IO-NXM-RIC-002</a></td>
<td>RI cover cannot be edited to lower amount</td>
<td class="rating-low">Low</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-RIC-001"></a><h2 id="io-nxm-ric-001-potential-ri-cover-purchase-front-run" class="break-before"><strong>IO-NXM-RIC-001</strong> Potential RI cover purchase front-run</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-low">Low</td>
<td class="status-closed">Closed</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/a3ab81c9bca191242b3641711817f194d676313e/contracts/modules/cover/Cover.sol#L235">Cover.sol#L235</a></td>
</tr>
</tbody>
</table>
<p>The <code>riPremiumInPaymentAsset != 0</code> check in <code>Cover::_buyCover()</code> prevents editing an RI cover to a lower amount without paying a premium, which is likely not to be required in most cases.</p>
<h3 id="recommendation-1">Recommendation</h3>
<p>The actual <code>riAmount</code> should be used instead.</p>
<h3 id="client-response-1">Client response</h3>
<p>As this is an MVP implementation, and due to stack too deep errors when using the amount in the check, this edge case will not be addressed at this time.</p>
<h1 id="code-quality-improvement-suggestions">Code quality improvement suggestions</h1>
<p>Code improvement suggestions without security implications are listed below.</p>
<table class="codequality">
<thead>
<tr>
<th>ID</th>
<th>Location</th>
<th>Details</th>
</tr>
</thead>
<tbody>
<tr>
<td>IO-NXM-RIC-003</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/a3ab81c9bca191242b3641711817f194d676313e/contracts/modules/cover/Cover.sol#L744-L746">Cover.sol#L744-L746</a></td>
<td>Consider adding a check for whether the address passed into <code>Cover::setRiSigner()</code> is zero.</td>
</tr>
<tr>
<td>IO-NXM-RIC-004</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/a3ab81c9bca191242b3641711817f194d676313e/contracts/modules/cover/Cover.sol#L744-L750">Cover.sol#L744-L750</a></td>
<td>Consider adding events for <code>Cover::setRiSigner()</code> and <code>Cover::setRiConfig()</code>.</td>
</tr>
</tbody>
</table>
<h2 id="client-response-2">Client response</h2>
<p><strong>IO-NXM-RIC-003</strong>: Address zero will be used to disable the purchase of RI cover.</p>
<p><strong>IO-NXM-RIC-004</strong>: Acknowledged but leaving as is, as these functions will rarely be called.</p>
<h1 id="specification">Specification</h1>
<p>The following section outlines the changes made 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>
<h2 id="reinsurance-cover">ReInsurance Cover</h2>
<p>Nexus Mutual added MVP support for purchasing cover backed by external ReInsurance pools into their existing Cover contract. Specifically, a new <code>buyCoverWithRi()</code> function was added that was callable by members to either purchase pure RI cover, or a blend of RI and normal cover.</p>
<p>When calling <code>buyCoverWithRi()</code>, members could pass in details of the cover product being purchased in a <code>BuyCoverParams</code> struct, similar to other cover purchase functions. If buying blended cover, they can also pass in an array of pool allocation requests for the non-RI cover amounts. The amount, premium and RI cover provider were specified in a newly introduced <code>RiRequest</code> struct, which is signed off-chain. Nexus intend to introduce an API to allow any member to request a signed <code>RiRequest</code> when they wish to purchase RI cover. A per-provider nonce was implemented to protect against re-use of signed <code>RiRequest</code> objects and ensure provider capacity is not exceeded. The premium for RI cover was sent to a provider-specific address, settable through a governance-gated function.</p>
<p>Similar to normal cover, a Cover NFT was issued for purchased RI cover, and members could edit RI cover. RI cover amounts were not included as part of protocol parameters such as total active cover and minimum capital requirements. As external pools underwrite RI covers, claims for these covers are not processed through the Claims & Assessments contracts – such claims will be processed outside of the protocol's smart contracts. For this MVP, buying cover through the Limit Orders contract was not yet supported.</p>
<h2 id="other-changes">Other changes</h2>
<p>In addition to added MVP support for RI cover, the Cover contract was also made <code>RegistryAware</code>, to align with the new registry system introduced in the recent protocol upgrade. Nexus also amended the existing <code>_coverMetadata</code> mapping to include the cover's ipfs data; to this end, a function to populate existing cover with their corresponding IPFS metadata was added. Finally, the <code>CoverBought</code> event was modified to include the ID of the member who purchased the cover.</p>

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

‍