Nexus Mutual Protocol Upgrade 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 the updated Assessments and Governance modules. The audit was conducted by two auditors over 24 audit days, between 20 August and 9 September 2025.
<h4 id="overview">Overview</h4>
The audit identified one high-risk, six low-risk, and seventeen informational issues – all of these were either resolved or closed during the audit.
The resolved high-risk pertained to an issue in the migration of assets in the capital pool during the protocol upgrade, which would have resulted in an incorrect total active cover value.
The resolved low-risk issues included memory changes not committed to storage, TWAP updates during system pauses, global pause checks, incorrect handling of assessor group creation, and zero address validation for proxy ownership transfers.
The open low-risk issue pertains to improper handling of assessor group creation.
Informational findings highlighted areas for code quality improvements, such as parameter validation, redundant checks, and unused contracts. All issues were addressed appropriately, enhancing the protocol's security and operational robustness.
<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>0</td>
<td>6</td>
<td>13</td>
</tr>
<tr>
<td>Closed</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>4</td>
</tr>
</tbody>
</table>
<h4 id="scope">Scope</h4>
The assessment focused on the 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: Protocol Upgrade</li>
<li>Initial audit commit: <a href="https://github.com/NexusMutual/smart-contracts/tree/37884fb496af98848b1076142aaf27d42a789954">37884fb</a></li>
<li>Final review commit: <a href="https://github.com/NexusMutual/smart-contracts/tree/dfb83d2d9362367bcd70b2dd3a50d9e347f1af03">aa18d78</a></li>
<li>Files: EIP712.sol, ReentrancyGuard.sol, RegistryAware.sol, WETH9.sol, CoverBroker.sol, Pool.sol, Ramm.sol, SafeTracker.sol, SwapOperator.sol, Governor.sol, NXMaster.sol, Registry.sol, TemporaryGovernance.sol, UpgradeableProxy.sol, LegacyAssessment.sol, LegacyMCR.sol, LegacyMemberRoles.sol, StakingProducts.sol, StakingViewer.sol, TokenController.sol, EnumerableSet.sol, Assessment.sol, Claims.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 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-PGR-024">IO-NXM-PGR-024</a></td>
<td>Total active cover incorrect after migration</td>
<td class="rating-high">High</td>
<td class="status-resolved">Resolved</td>
</tr>
<tr>
<td><a href="#IO-NXM-PGR-001">IO-NXM-PGR-001</a></td>
<td>Changes to memory not committed to storage</td>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
</tr>
<tr>
<td><a href="#IO-NXM-PGR-002">IO-NXM-PGR-002</a></td>
<td>TWAP can be updated during system pause</td>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
</tr>
<tr>
<td><a href="#IO-NXM-PGR-003">IO-NXM-PGR-003</a></td>
<td>Global pause not checked</td>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
</tr>
<tr>
<td><a href="#IO-NXM-PGR-004">IO-NXM-PGR-004</a></td>
<td>Add zero address check for new proxy owner</td>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
</tr>
<tr>
<td><a href="#IO-NXM-PGR-019">IO-NXM-PGR-019</a></td>
<td>AB member votes are not tallied by seat</td>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
</tr>
<tr>
<td><a href="#IO-NXM-PGR-021">IO-NXM-PGR-021</a></td>
<td>Assessor groups can be created without specifying 0 as the groupId</td>
<td class="rating-low">Low</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-PGR-024"></a><h2 id="io-nxm-pgr-024-total-active-cover-incorrect-after-migration" class="break-before">IO-NXM-PGR-024 Total active cover incorrect after migration</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/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/capital/Pool.sol#L498-L500">Pool.sol#L498-L500</a></td>
</tr>
</tbody>
</table>
<code>Pool::migrate()</code> skips DAI when moving supported assets from the previous pool. This causes the asset IDs in <code>Pool::getTotalActiveCoverAmount()</code> to mismatch the asset IDs still in the Cover contract, resulting in an incorrect calculation of total active cover, which is relied on in critical areas of the protocol, including when updating MCR.
<h3 id="recommendation">Recommendation</h3>
DAI should not be skipped during the migration, but rather marked as abandoned.
<h3 id="client-response">Client response</h3>
Fixed in <a href="https://github.com/NexusMutual/smart-contracts/commit/0f280c7e989a4a5d9321648d1de4f3919cd6c9c1">0f280c7</a>.
<a name="IO-NXM-PGR-001"></a><h2 id="io-nxm-pgr-001-changes-to-memory-not-committed-to-storage" class="break-before">IO-NXM-PGR-001 Changes to memory not committed to storage</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/governance/Governor.sol#L170">Governor.sol#L170</a></td>
</tr>
</tbody>
</table>
The timelock cooldown is not automatically started when an Advisory Board proposal reaches its threshold due to the updated <code>executeAfter</code> value being set in <code>memory</code> and not saved to <code>storage</code>.
The following snippet shows a proof of concept for this vulnerability.
<pre tabindex="0" class="chroma"><code>const { loadFixture , time } = require('@nomicfoundation/hardhat-network-helpers');
const { expect } = require('chai');

const setup = require('test/unit/Governor/setup');
const { parseEther } = require('ethers');
const { ethers, nexus } = require('hardhat');

const { Choice } = nexus.constants;

it('does not start timelock cooldown when AB threshold is met (executeAfter not updated in storage)', async () => {
 const { governor, accounts, registry, tokenController } = await loadFixture(setup);
 const abMembers = accounts.advisoryBoardMembers;
 const [member] = accounts.members;
 const abMemberIds = await Promise.all(abMembers.map(m => registry.memberIds(m.address)));
 const memberId = await registry.memberIds(member.address);

 // Give member enough tokens to propose
 await tokenController.setTotalBalanceOf(member.address, parseEther('100'));
 await tokenController.setTotalSupply(parseEther('10000'));

 // Create a board swap proposal
 const txs = [
 {
 target: registry.target,
 value: 0,
 data: "0x",
 },
 ];

 // Propose
 const tx = await governor.connect(abMembers[0]).propose(txs, 'X');
 const receipt = await tx.wait();
 const proposalBlockTimestamp = (await ethers.provider.getBlock(receipt.blockNumber)).timestamp;

 const proposalId = 1; // Assuming proposal ID is 1 for simplicity

 // Calculate expected executeAfter values
 const VOTING_PERIOD = 3 * 24 * 60 * 60; // 3 days in seconds
 const TIMELOCK_PERIOD = 24 * 60 * 60; // 1 day in seconds
 const expectedOriginalExecuteAfter = proposalBlockTimestamp + VOTING_PERIOD + TIMELOCK_PERIOD;

 // Check proposal storage for executeAfter
 let proposal = await governor.getProposal(proposalId);
 expect(proposal.executeAfter).to.equal(expectedOriginalExecuteAfter);

 // Cast votes from enough AB members to meet threshold
 for (let i = 0; i < 3; i++) {
 let voteTx = await governor.connect(abMembers[i]).vote(proposalId, Choice.For);
 }

 proposal = await governor.getProposal(proposalId);
 const tally = await governor.getProposalTally(proposalId);
 expect(tally.forVotes).to.be.gte(3); // Ensure votes exceed 3 votes to pass threshhold
 const blockTimestamp = (await ethers.provider.getBlock('latest')).timestamp;
 const expectedExecuteAfter = blockTimestamp + TIMELOCK_PERIOD;


 // Assert executeAfter is updated to the expected value
 expect(ethers.toBigInt(proposal.executeAfter)).to.equal(ethers.toBigInt(expectedExecuteAfter));
 expect(proposal.executeAfter).to.not.equal(expectedOriginalExecuteAfter);

 });
</code></pre><h3 id="recommendation-1">Recommendation</h3>
The contract should instead set
<pre tabindex="0" class="chroma"><code>proposals[proposalId].executeAfter = (block.timestamp + TIMELOCK_PERIOD).toUint32();
</code></pre><h3 id="client-response-1">Client response</h3>
Fixed in <a href="https://github.com/NexusMutual/smart-contracts/pull/1429/commits/18b32b2df1b40d91d32fc6644d4461a29ab0a067">18b32b2</a>.
<a name="IO-NXM-PGR-002"></a><h2 id="io-nxm-pgr-002-twap-can-be-updated-during-system-pause" class="break-before">IO-NXM-PGR-002 TWAP can be updated during system pause</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/capital/Ramm.sol#L636">Ramm.sol#L636</a></td>
</tr>
</tbody>
</table>
Anyone can call <code>Ramm::updateTwap()</code> even when the global system pause has been enabled. The function queries values such as the capital pool's balances and the MCR, which might be unreliable during a system upgrade.
<h3 id="recommendation-2">Recommendation</h3>
To prevent artificial and unexpected fluctuations in the reported TWAP value during system maintenance, a <code>WhenNotPaused()</code> modifier should be added. This issue also affects <code>Ramm::getInternalPriceAndUpdateTwap()</code> . As such, the <code>WhenNotPaused()</code> modifier could be added to the internal <code>_updateTwap()</code> to cover both functions. Alternatively, and ideally, <code>Ramm::getInternalPriceAndUpdateTwap()</code> could be refactored to call <code>updateTwap()</code> as the TWAP update logic is the same in both functions.
<h3 id="client-response-2">Client response</h3>
Fixed in <a href="https://github.com/NexusMutual/smart-contracts/commit/feef986a79206176ec8e8863c13857b1dc9b4176">feef986</a> and <a href="https://github.com/NexusMutual/smart-contracts/pull/1429/commits/d8ef8da514bd960db274538becfad1443c83e913">d8ef8da</a>.
<a name="IO-NXM-PGR-003"></a><h2 id="io-nxm-pgr-003-global-pause-not-checked" class="break-before">IO-NXM-PGR-003 Global pause not checked</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/governance/Registry.sol#L96-L98">Registry.sol#L96-L98</a></td>
</tr>
</tbody>
</table>
<code>Registry::isPaused</code> does not check whether the system is paused globally, similar to the <code>WhenNotPaused()</code> modifier. This currently has no impact, as the only <a href="https://github.com/NexusMutual/smart-contracts/blob/b6943cf7ca27212416e45a5a6b21ebf73bda2214/contracts/modules/governance/NXMaster.sol#L36">caller</a> of this function passes in a <code>PAUSE_GLOBAL</code> mask. However, bugs may be introduced if additional features are added in the future that use this function.
<h3 id="recommendation-3">Recommendation</h3>
<code>Registry::isPaused</code> should check for a global system pause by performing a bitwise and between the mask and the <code>PAUSE_GLOBAL</code> value, similar to the <code>whenNotPaused</code> modifier.
<h3 id="client-response-3">Client response</h3>
Fixed in <a href="https://github.com/NexusMutual/smart-contracts/pull/1429/commits/4d69169e5925f4a3fedb1db034e8bb40a1eaadcd">4d69169</a>.
<a name="IO-NXM-PGR-004"></a><h2 id="io-nxm-pgr-004-add-zero-address-check-for-new-proxy-owner" class="break-before">IO-NXM-PGR-004 Add zero address check for new proxy owner</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/governance/UpgradeableProxy.sol#L39-L43">UpgradeableProxy.sol#L39-L43</a></td>
</tr>
</tbody>
</table>
<code>UpgradeableProxy::transferProxyOwnership()</code> should check that the <code>_newOwner</code> address is not zero, and revert if so, to avoid accidentally losing ownership of a proxy.
<h3 id="recommendation-4">Recommendation</h3>
Add a zero address check to the argument passed in to prevent loss of proxy ownership.
<h3 id="client-response-4">Client response</h3>
Fixed in <a href="https://github.com/NexusMutual/smart-contracts/pull/1429/commits/b9f07ef7fbfaa7ae27818303efb77030070ca5fa">b9f07ef</a>.
<a name="IO-NXM-PGR-019"></a><h2 id="io-nxm-pgr-019-ab-member-votes-are-not-tallied-by-seat" class="break-before">IO-NXM-PGR-019 AB member votes are not tallied by seat</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/governance/Governor.sol#L145">Govenor.sol#L145</a></td>
</tr>
</tbody>
</table>
After a <code>swapAdvisoryBoardMember</code> proposal, the votes of the advisory board member are not transferred to the new member. This can cause AB member proposals to have more than five votes in total.
The following snippet shows a proof of concept for this vulnerability.
<pre tabindex="0" class="chroma"><code>const { loadFixture , time } = require('@nomicfoundation/hardhat-network-helpers');
const { expect } = require('chai');

const setup = require('test/unit/Governor/setup');
const { parseEther } = require('ethers');
const { ethers, nexus } = require('hardhat');

const { Choice } = nexus.constants;

 it('does not transfer votes to new AB member after a swapAdvisoryBoardMember proposal', async () => {
 const { governor, accounts, registry, tokenController } = await loadFixture(setup);
 const abMembers = accounts.advisoryBoardMembers;
 const [member] = accounts.members;
 const abMemberIds = await Promise.all(abMembers.map(m => registry.memberIds(m.address)));
 const memberId = await registry.memberIds(member.address);

 // Allocate sufficient tokens to the proposer to meet the proposal threshold
 await tokenController.setTotalBalanceOf(member.address, parseEther('200'));
 await tokenController.setTotalSupply(parseEther('10000'));

 const txs = [
 {
 target: registry.target, // Ensure this is a valid address
 value: 0,
 data: "0x", // Placeholder data
 },
 ];
 const tx = await governor.connect(accounts.advisoryBoardMembers[0]).propose(txs, 'Test Proposal');
 const receipt = await tx.wait();
 const proposalId = 1;

 await tokenController.setTotalBalanceOf(member.address, parseEther('0')); //remove tokens after proposal

 // Cast votes from AB members for a draw
 for (let i = 0; i < 2; i++) {
 await governor.connect(abMembers[i]).vote(proposalId, Choice.For);
 }
 for (let i = 2; i < 4; i++) {
 await governor.connect(abMembers[i]).vote(proposalId, Choice.Against);
 }
 await governor.connect(abMembers[4]).vote(proposalId, Choice.Abstain);

 // Check the total votes
 let tallyForVotesBeforeSwap = await governor.connect(member).getProposalTally(proposalId);
 tallyForVotesBeforeSwap = tallyForVotesBeforeSwap.toString().split(',')[1];

 await registry.connect(member).swapAdvisoryBoardMember(abMemberIds[0], memberId);
 await expect(
 governor.connect(member).vote(proposalId, Choice.For)
 ).to.be.revertedWithCustomError(governor, 'AlreadyVoted');

 let tallyForVotesAfterSwap = await governor.connect(member).getProposalTally(proposalId);
 tallyForVotesAfterSwap = tallyForVotesAfterSwap.toString().split(',')[1];

 expect(tallyForVotesAfterSwap.toString()).to.be.equal(tallyForVotesBeforeSwap.toString()); // Ensure votes are the same

 expect(tallyForVotesAfterSwap).to.be.equal('2');
 });
</code></pre><h3 id="recommendation-5">Recommendation</h3>
AB member votes should be indexed according to seat number instead of <code>memberId</code>. This can be achieved by moving the <code>voterId</code> before the weight check, and using <code>voterId</code> instead of <code>memberId</code>, e.g., <code>votes[proposalId][voterId]</code>. If a new member disagrees with their seat's vote, they can call <code>cancelVote()</code>.
<h3 id="client-response-5">Client response</h3>
Fixed in <a href="https://github.com/NexusMutual/smart-contracts/pull/1429/commits/99bfd61875f516482f50131079021b866c04d63f">99bfd61</a>
<a name="IO-NXM-PGR-021"></a><h2 id="io-nxm-pgr-021-assessor-groups-can-be-created-without-specifying-0-as-the-groupid" class="break-before">IO-NXM-PGR-021 Assessor groups can be created without specifying 0 as the groupId</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/assessment/Assessment.sol#L108">Assessment.sol#108</a></td>
</tr>
</tbody>
</table>
When calling the <code>Assessment::addAssessorsToGroup()</code> function, it is possible to create a new assessor group by specifying any <code>groupId</code> that's not equal to 0 and greater than the current <code>groupCount</code>. If an assessor group is created this way, this will result in the returned <code>groupCount</code> being incorrect, as it will not be incremented. Additionally, any calls to <code>setGroupMetadata()</code>, <code>removeAssessorFromGroup()</code>, and <code>setAssessmentDataForProductTypes()</code> will revert if given the new <code>groupId</code>.
The following snippet shows a proof of concept for this vulnerability.
<pre tabindex="0" class="chroma"><code>const { expect } = require('chai');
const { loadFixture } = require('@nomicfoundation/hardhat-network-helpers');
const { setup } = require('test/unit/Assessment/setup');

it('should revert when groupId is invalid (greater than group count)', async function () {
 const { contracts, accounts } = await loadFixture(setup);
 const { assessment } = contracts;
 const [governanceAccount] = accounts.governanceContracts;

 const currentGroupCount = await assessment.getGroupsCount();
 const invalidGroupId = currentGroupCount + 1n;

 const addAssessorsToGroup = assessment.connect(governanceAccount).addAssessorsToGroup([1n, 2n], invalidGroupId);
 await expect(addAssessorsToGroup).to.be.revertedWithCustomError(assessment, 'InvalidGroupId');
 });
</code></pre><h3 id="recommendation-6">Recommendation</h3>
The function should require that the given <code>groupId</code> is equal to 0 or less than the <code>groupCount</code>; otherwise, revert if it is not.
<h3 id="client-response-6">Client Response</h3>
Fixed in <a href="https://github.com/NexusMutual/smart-contracts/pull/1429/commits/5f05f1a1ef1136b9fd41e835d92878bd9b4bb871">5f05f1a</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>IO-NXM-PGR-005</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/capital/SwapOperator.sol#L395">SwapOperator.sol#L395</a></td>
<td>The <code>receiver</code> parameter in <code>SwapOperator::recoverAsset(...)</code> is not validated to ensure it is a non-zero address. For supported assets, the <code>recipient</code> parameter is unused, and therefore, an AB member might expect that specifying a zero address is reasonable. However, if the pool doesn't support the asset or it has been abandoned without the knowledge of all AB members, the funds could be inadvertently transferred to the zero address.</td>
</tr>
<tr>
<td>IO-NXM-PGR-006</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/governance/Governor.sol#L58">Governor.sol#L58</a>, <a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/governance/Governor.sol#L66">Governor.sol#L66</a></td>
<td>The <code>Governor::proposeAdvisoryBoardSwap(...)</code> and <code>Governor::propose</code> functions do not return the <code>proposalId</code> that is assigned, requiring members to rely on events to obtain the <code>proposalId</code>. This makes atomic proposals and voting difficult, increasing the chance that a proposal might be front-run and result in an unintended vote. In a worst-case scenario, a member might rely on the output from a simulation to create an atomic batch of transactions. A malicious actor could monitor the mempool for such an occurrence and front-run the proposal, causing the victim to inadvertently vote for the malicious actor's proposal instead of their own.</td>
</tr>
<tr>
<td>IO-NXM-PGR-007</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/governance/Governor.sol#L66">Governor.sol#L66</a></td>
<td>To prevent proposals that fail at execution, <code>Governor::proposeAdvisoryBoardSwap(...)</code> should also validate that the <code>from</code> address is an existing AB member, and that the <code>to</code> address belongs to a normal member.</td>
</tr>
<tr>
<td>IO-NXM-PGR-008</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/governance/Governor.sol#L174">Governor.sol#L174</a></td>
<td>When voting, the member's tokens are always locked for <code>VOTING_PERIOD + TIMELOCK_PERIOD</code> seconds regardless of when their vote is cast. Consequently, members' tokens could be locked well after the timelock has already elapsed. Instead, the lock duration should be the difference between the timestamp when the vote is cast and the <code>executeAfter</code> timestamp of the proposal. This can be achieved by simply passing the <code>executeAfter</code> timestamp as the <code>deadline</code> argument to <code>_lockTokenTransfers</code>.</td>
</tr>
<tr>
<td>IO-NXM-PGR-009</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/governance/NXMaster.sol#L35-L37">NXMaster.sol#L35-L37</a></td>
<td><code>NXMaster::isPause()</code> does not check whether migration has been completed and there is a valid instance of registry, similar to <code>NXMaster::isInternal()</code>. In such cases, the function could fall back to returning the last value of the <code>paused</code> storage variable.</td>
</tr>
<tr>
<td>IO-NXM-PGR-010</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/cover/LimitOrders.sol#L298">LimitOrders.sol#L298</a></td>
<td>The <code>LimitOrders</code> contract has not been updated following the changes to <code>TokenController</code> and therefore the <code>whitelistSelf()</code> function will always revert.</td>
</tr>
<tr>
<td>IO-NXM-PGR-011-1</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/governance/Registry.sol#L389">Registry.sol#L389</a></td>
<td><code>memberId</code> can be re-used instead of reloading the value from storage on <a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/governance/Registry.sol#L389">Registry.sol#L389</a>.</td>
</tr>
<tr>
<td>IO-NXM-PGR-011-2</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/capital/SwapOperator.sol#L368-L369">SwapOperator.sol#L368-L369</a></td>
<td>The checks on <a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/capital/SwapOperator.sol#L368-L369">SwapOperator.sol#L368-L369</a> could be performed earlier, before the cross-contract call to Pool.</td>
</tr>
<tr>
<td>IO-NXM-PGR-011-3</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/cover/Cover.sol#L624">Cover.sol#L624</a></td>
<td>The casting to address on <a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/cover/Cover.sol#L624">Cover.sol#L624</a> can be removed as <code>stakingPoolFactory</code> is now an address</td>
</tr>
<tr>
<td>IO-NXM-PGR-012</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/governance/Governor.sol#L203-L236">Governor.sol#L203-L236</a></td>
<td><code>Governor::execute()</code> does not validate whether the ETH sent in the call is not more than what is required to execute the proposal's transactions. Should the caller send too much ETH, the excess would be stuck in the contract. Add a check that requires `(isAbProposal</td>
</tr>
<tr>
<td>IO-NXM-PGR-013</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/assessment/Claims.sol#L240">Claims.sol#L240</a></td>
<td>To enable accurate tracking of claim deposits, the <code>redeemClaimPayout()</code> function should also emit <code>ClaimDepositRetrieved</code> if the deposit has not been retrieved previously.</td>
</tr>
<tr>
<td>IO-NXM-PGR-014</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/assessment/Claims.sol#L257">Claims.sol#L257</a>, <a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/assessment/Claims.sol#L277">Claims.sol#L277</a>, <a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/capital/Pool.sol#L253">Pool.sol#L253</a></td>
<td>By reworking the <code>Pool::sendPayout()</code> function to only call <code>_updateMCR(true)</code> when <code>amount > 0</code>, <code>Claims::retrieveDeposit</code> can be be updated to use <code>Pool::sendPayout()</code> instead of <code>Pool::sendEth()</code>. This allows reducing the access control for <code>Pool::sendEth()</code> to <code>C_RAMM</code> only, ensuring clear access control separation. It is further recommended that <code>Pool::sendPayout()</code> performs a single value transfer when the payout asset is <code>ETH</code>, as opposed to individual calls for the deposit and for the payout amount.</td>
</tr>
<tr>
<td>IO-NXM-PGR-015</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/token/TokenController.sol#L94">TokenController.sol#L94</a></td>
<td>The modifier for <code>TokenController::burnFrom(...)</code> uses addition instead of a bitwise OR for its bit mask. This results in the same bitmask in this instance, but could be dangerous as a general pattern.</td>
</tr>
<tr>
<td>IO-NXM-PGR-016</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/governance/Governor.sol#L151">Governor.sol#L151</a></td>
<td>The check on <a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/governance/Governor.sol#L151">Governor.sol#L151</a> is not necessary as <code>memberId</code> has already been verified to be non-zero on <a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/governance/Governor.sol#L144">Governor.sol#L144</a> and <code>Registry::getAdvisoryBoardSeat()</code> <a href="https://github.com/NexusMutual/smart-contracts/blob/b6943cf7ca27212416e45a5a6b21ebf73bda2214/contracts/modules/governance/Registry.sol#L196">reverts</a> if <code>seat</code> is zero.</td>
</tr>
<tr>
<td>IO-NXM-PGR-017</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/capital/Pool.sol#L216-L235">Pool.sol#L216-L235</a></td>
<td>A asset transfer event similar to that emitted in <code>Pool::transferAssetToSafe()</code> could be added to <code>Pool::transferAssetToSwapOperator()</code>.</td>
</tr>
<tr>
<td>IO-NXM-PGR-018</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/governance/Governor.sol#L170">Governor.sol#L170</a></td>
<td>A vote after an AB proposal's timelock has already been advanced will extend the timelock. <code>executeAfter</code> should be set to be the minimum between <code>block.timestamp + TIMELOCK_PERIOD</code> and the current <code>executeAfter</code>. Alternatively, <code>proposals[proposalId].voteBefore</code> should be set to the current <code>block.timestamp</code> in addition to setting <code>executeAfter</code>.</td>
</tr>
<tr>
<td>IO-NXM-PGR-023</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/governance/Governor.sol#L211C2-L212C6">Govenor.sol#L211-212</a></td>
<td>In <code>Governor::execute(…)</code> the statements `require(isAbProposal</td>
</tr>
<tr>
<td>IO-NXM-PGR-020</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/governance/Governor.sol#L153">Governor.sol#L153</a></td>
<td>Votes are tracked as <code>uint96</code>, which does not result in well-packed Vote or Tally structs.</td>
</tr>
<tr>
<td>IO-NXM-PGR-022</td>
<td><a href="https://github.com/NexusMutual/smart-contracts/blob/37884fb496af98848b1076142aaf27d42a789954/contracts/modules/governance/VotePower.sol">VotePower.sol</a></td>
<td>The <code>VotePower</code> contract is not referenced by any other contracts and therefore is not used in the current protocol implementation. This contract should be removed or added to legacy, as it is no longer required.</td>
</tr>
</tbody>
</table>
<h3 id="client-response-7">Client response</h3>
<dl>
<dt>IO-NXM-PGR-005</dt>
<dd>Fixed in <a href="https://github.com/NexusMutual/smart-contracts/commit/03de8f52de72cd302cbf5fd72590f2ac9b117938">03de8f5</a>.</dd>
<dt>IO-NXM-PGR-006</dt>
<dd>Fixed in <a href="https://github.com/NexusMutual/smart-contracts/pull/1429/commits/9cff2072c5d085f55d65bff11f1966df14fbbbac">9cff207</a>.</dd>
<dt>IO-NXM-PGR-007</dt>
<dd>Fixed in <a href="https://github.com/NexusMutual/smart-contracts/pull/1429/commits/468e5f26222b0679615ba868551bfecbb9548d14">468e5f2</a>.</dd>
<dt>IO-NXM-PGR-008</dt>
<dd>Fixed in <a href="https://github.com/NexusMutual/smart-contracts/pull/1429/commits/b94d314f6206477822d4b6093dc9f23ee92783fb">b94d314</a>.</dd>
<dt>IO-NXM-PGR-009</dt>
<dd>Fixed in <a href="https://github.com/NexusMutual/smart-contracts/pull/1429/commits/8860cc4baece87c4ae2b884457045392f00ea5d1">8860cc4</a>.</dd>
<dt>IO-NXM-PGR-010</dt>
<dd>Fixed in <a href="https://github.com/NexusMutual/smart-contracts/pull/1429/commits/4ec0abf5242c8417af96d2eca983f873b7fae210">4ec0abf</a>.</dd>
<dt>IO-NXM-PGR-011-1</dt>
<dd>Fixed in <a href="https://github.com/NexusMutual/smart-contracts/commit/7923d9f7fbb95a16a5b29617529bbd856f055c0b">7923d9f</a>.</dd>
<dt>IO-NXM-PGR-011-2</dt>
<dd>Closed.</dd>
<dt>IO-NXM-PGR-011-3</dt>
<dd>Closed.</dd>
<dt>IO-NXM-PGR-012</dt>
<dd>Closed.</dd>
<dt>IO-NXM-PGR-013</dt>
<dd>Fixed in <a href="https://github.com/NexusMutual/smart-contracts/pull/1429/commits/55e1bacbb6bffb778f354aba9c4a2a75cc51cc7f">55e1bac</a>.</dd>
<dt>IO-NXM-PGR-014</dt>
<dd>Fixed in <a href="https://github.com/NexusMutual/smart-contracts/pull/1429/commits/02e38d0f2f5dc7ebefe448d1c769bf2e8005152e">02e38d0</a>.</dd>
<dt>IO-NXM-PGR-015</dt>
<dd>Fixed in <a href="https://github.com/NexusMutual/smart-contracts/pull/1429/commits/ea1e623a580a7753dc8a1823a040f6710189e62b">ea1e623</a>.</dd>
<dt>IO-NXM-PGR-016</dt>
<dd>Fixed in <a href="https://github.com/NexusMutual/smart-contracts/pull/1429/commits/ff9ceb50f5fdab4f486137a282c990e118fc1d2d">ff9ceb5</a>.</dd>
<dt>IO-NXM-PGR-017</dt>
<dd>Fixed in <a href="https://github.com/NexusMutual/smart-contracts/pull/1429/commits/18eebde8b774695a1fd1cf16442ee1bf50ad8372">18eebde</a>.</dd>
<dt>IO-NXM-PGR-018</dt>
<dd>Fixed in <a href="https://github.com/NexusMutual/smart-contracts/pull/1429/commits/30351eb9b7e3a1ad28d157d74103881b085ed0ec">30351eb</a>.</dd>
<dt>IO-NXM-PGR-023</dt>
<dd>Closed.</dd>
<dt>IO-NXM-PGR-020</dt>
<dd>Closed.</dd>
<dt>IO-NXM-PGR-022</dt>
<dd>Fixed in <a href="https://github.com/NexusMutual/smart-contracts/pull/1457/commits/080c188195bc3d0b335230db9f8a4a1e08f52f17">080c188</a> and <a href="https://github.com/NexusMutual/smart-contracts/pull/1457/commits/8c4475889d76a45df34da9531303f7e5be535288">8c44758</a>.</dd>
</dl>
<h1 id="specification">Specification</h1>
The following section outlines the system's intended functionality at a high level, based on its implementation in the codebase. Any perceived points of conflict should be highlighted with the auditing team to determine the source of the discrepancy.
<h2 id="governance">Governance</h2>
Nexus Mutual have migrated to a new governance system with the introduction of the Governor contract and the deprecation of the previous Governance contract. The new system allows for the submission of two types of proposals:
Advisory Board (AB) Proposals, which can execute one or more arbitrary transactions, and proposals to swap Advisory Board members.
AB Proposals can only be submitted by advisory board members, whereas proposals to swap advisory board members can be submitted by any member of the mutual, provided they hold a minimum of 100 NXM tokens at the time of proposal submission.
AB proposals can only be voted on by AB members, each of whom have a single vote, whereas AB swap proposals can be voted on by any member, with their vote power being equal to their NXM token balance, capped to 5% of the total supply at the time of voting.
AB and AB swap proposals are considered passed through a simple majority, provided a quorum is reached – quorum requirements for AB proposals are three out of the five AB seats, while AB swap proposals require approximately 15% of the total supply as quorum for a vote to be passed. Voting periods are three days for all proposals. Once a proposal is passed, it enters a time lock period of one day before it can be executed.
Similar to the previous governance system, staking pool managers can vote on behalf of stakers through their delegated NXM in AB swap proposals, with their vote weight also capped to 5%. In AB swap proposals, NXM token transfers are locked after voting and until the time lock period has passed to prevent double voting.
<h2 id="registry">Registry</h2>
A Registry contract was introduced to replace the NXMaster and Member Roles contracts. The Registry is meant to serve as a central point of truth for current members, advisory board members, and their respective member IDs and seat numbers. To this end, the Registry also exposes functionality for new members to join the mutual, once they have completed the off-chain KYC process and have a join request signed by the KYC authentication address. Additionally, member access control checks across the protocol are now routed to the Registry.
The Registry also serves as the central directory for all internal contracts in the protocol, allowing contracts to query the addresses of other internal contracts through a contract index system, and limit access to privileged functions to specific internal contracts. New contracts can be added and upgraded through Registry, after an AB governance proposal has been passed to do so.
<h2 id="assessments">Assessments</h2>
The new Assessment module implements a permissioned assessor model where only Governance-approved assessors can participate in claim voting. Assessors are organized into assessment groups, with each product type assigned to a specific group. The Advisory Board, via governance proposals, manages the assessor groups by adding and removing members and setting product-type parameters, including cooldown periods, redemption periods, and assessment group assignments.
Each member of an assessment group has one vote. The default voting period is 72 hours, which can end early if all assessors in the group have voted. After voting concludes, a configurable cooldown period begins during which Governance can investigate potential fraud, extend voting periods, or undo fraudulent votes. Claims are decided by majority vote, with no minimum participation requirement – a single vote can approve a claim if no other votes are cast. Draw outcomes result in no payout but allow claimants to retrieve their deposit.
The Advisory Board can pause assessments, extend voting periods by 72 hours, and explicitly undo votes. Votes from assessors removed mid-assessment remain valid unless explicitly undone by an Advisory Board proposal.
<h3 id="migration">Migration</h3>
The migration process upgrades the Nexus Mutual governance system to a new architecture while ensuring compatibility with legacy contracts. It begins with deploying the Registry implementation and proxy contracts, transferring ownership to the Advisory Board (AB) multisig, and deploying temporary contract implementations such as TemporaryGovernance, LegacyAssessment, and LegacyMemberRoles.
The first AB actions involve upgrading the Governance contract to use TemporaryGovernance, upgrading Assessment and MemberRoles to their legacy implementations, and migrating the Registry to upgrade the Governor to TemporaryGovernance. Next, member data is migrated, ETH is recovered from MemberRoles, legacy assessment stakes and rewards are pushed, and new contract implementations for modules like Pool, SwapOperator, Ramm, SafeTracker, Assessments, Claims, TokenController, Cover, CoverProducts, and Governor are deployed.
The last phase involves upgrading the proxies of these contracts to the new implementations, setting emergency admin addresses, initialising the Claims contract, migrating the Pool and Master contracts to transfer assets and funds, transferring ownership of the Registry proxy to the Governor, and establishing assessment groups for product types. Finally, the Governor is upgraded to its new implementation, and the existing CoverProduct product types are updated with new parameters.
<h3 id="swap-operator">Swap Operator</h3>
The <code>SwapOperator</code> contract has been updated to function as a proxy, enabling easier upgrades and maintenance. The contract is used by a <code>swapController</code> address, which is set by the advisory board.
The previous slippage checks have been removed, simplifying the swap execution process. A new swap request feature has been introduced, allowing the Governor, through an AB proposal, to define and manage asset swaps with specific parameters such as the source asset, target asset, amounts, and deadlines. These swaps are then executed by the <code>swapController</code>.
The contract integrates with the CoW protocol for asset swaps and includes validations for asset compatibility, deadlines, and amounts. Additionally, the contract supports asset recovery to the pool or a specified receiver, ensuring no ongoing CoW swap orders during recovery operations. Swapping Enzyme vault shares for ETH and vice versa is also supported.
<h1 id="test-coverage-report">Test coverage report</h1>
The coverage report of the provided tests as of the final day of the audit is given below.
<table>
<thead>
<tr>
<th>File</th>
<th>% Lines</th>
<th>% Statements</th>
<th>% Branches</th>
<th>% Funcs</th>
</tr>
</thead>
<tbody>
<tr>
<td>Assessments.sol</td>
<td>99.02%</td>
<td>98.7%</td>
<td>98.44%</td>
<td>95.65%</td>
</tr>
<tr>
<td>Claims.sol</td>
<td>100.00%</td>
<td>100.00%</td>
<td>92.00%</td>
<td>100.00%</td>
</tr>
<tr>
<td>Pool.sol</td>
<td>93.63%</td>
<td>95.24%</td>
<td>76.27%</td>
<td>96.30%</td>
</tr>
<tr>
<td>Ramm.sol</td>
<td>49.42%</td>
<td>50.54%</td>
<td>36.27%</td>
<td>57.14%</td>
</tr>
<tr>
<td>SafeTracker.sol</td>
<td>53.33%</td>
<td>40.91%</td>
<td>11.11%</td>
<td>33.33%</td>
</tr>
<tr>
<td>SwapOperator.sol</td>
<td>100.00%</td>
<td>100.00%</td>
<td>98.08%</td>
<td>100.00%</td>
</tr>
<tr>
<td>Governor.sol</td>
<td>91.75%</td>
<td>92.41%</td>
<td>93.90%</td>
<td>75.00%</td>
</tr>
<tr>
<td>NXMaster.sol</td>
<td>15.79%</td>
<td>17.65%</td>
<td>45.65%</td>
<td>33.33%</td>
</tr>
<tr>
<td>Registry.sol</td>
<td>80.72%</td>
<td>78.13%</td>
<td>88.79%</td>
<td>90.48%</td>
</tr>
<tr>
<td>TemporaryGovernance.sol</td>
<td>11.11%</td>
<td>0.00%</td>
<td>0.00%</td>
<td>25.00%</td>
</tr>
<tr>
<td>UpgradeableProxy.sol</td>
<td>100.00%</td>
<td>100.00%</td>
<td>60.00%</td>
<td>100.00%</td>
</tr>
<tr>
<td>StakingProducts.sol</td>
<td>60.71%</td>
<td>61.86%</td>
<td>42.42%</td>
<td>55.56%</td>
</tr>
<tr>
<td>TokenController.sol</td>
<td>96.70%</td>
<td>95.71%</td>
<td>96.77%</td>
<td>96.97%</td>
</tr>
<tr>
<td>All files</td>
<td>56.32%</td>
<td>56.45%</td>
<td>49.28%</td>
<td>55.92%</td>
</tr>
</tbody>
</table>
The in-scope source files demonstrated strong test coverage for the primary use cases. To further enhance robustness, expanding coverage to edge cases and less-tested modules is recommended.

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

‍

Secure your system.

Request a service

Start Now →