Nexus Mutual RWI Vault 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 their RWI Vault, an ERC-7540-inspired smart contract that enables select members to back and earn yield from off-chain insurance opportunities. One auditor conducted the initial audit between 29 September and 26 November 2025, using four audit days. Two follow-up reviews were conducted, each using one audit day: the first on 3 February 2026 covering rate calculation and naming changes, and the second on 18 March 2026 covering changes to the emergency pause mechanism and lock extension logic.
<h4 id="overview">Overview</h4>
The initial audit identified one high-risk, one medium-risk and five low-risk issues. Several informational issues and code quality improvement suggestions were also found. All findings from the initial audit were resolved or closed at its conclusion.
The high-risk finding was a potential redemption fullfillment denial of service in the event of a member being removed after they had requested a redemption. The medium-risk finding pertained to an issue in the share-locking mechanism, which allowed members to bypass the minimum and maximum lock periods defined in the contract.
The low-risk issues included the possibility of funds becoming stuck, shares being locked even when the share locking mechanism is paused, and the extended lock period exceeding the maximum lock period when editing an existing lock.
The follow-up reviews identified two additional low-risk issues: removed members being unable to withdraw locked shares, and missing bounds validation on proposed rate changes. The rate bounds issue was resolved during the review.
During the audits, the vault and registry contracts were renamed from <code>RWAVault</code> and <code>Registry</code> to <code>RWIVault</code> and <code>RWIRegistry</code> respectively. References to the original names in this report should be read as pertaining to their renamed counterparts.
<table>
<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>5</td>
<td>2</td>
</tr>
<tr>
<td>Closed</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>2</td>
<td>1</td>
</tr>
</tbody>
</table>
<h4 id="scope">Scope</h4>
The assessment focused on the source files 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: RWI Vault</li>
<li>Initial audit commit: <a href="https://github.com/NexusMutual/rwi-vault/tree/ce47d1e0e7e59ebf3104fc76606a771497e2390e">ce47d1e</a></li>
<li>Final review commit: <a href="https://github.com/NexusMutual/rwi-vault/commit/326d4ab0b75acfbc0500a1bd021beee17955fa2a">326d4ab</a></li>
<li>Files: ERC20.sol, ERC7540.sol, Locks.sol, RWIRegistry.sol (renamed from Registry.sol), RegistryAware.sol, RWIVault.sol (renamed from RWAVault.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>
<thead>
<tr>
<th>ID</th>
<th>Issue</th>
<th>Risk</th>
<th>Status</th>
</tr>
</thead>
<tbody>
<tr>
<td><a href="#IO-NXM-RWI-018">IO-NXM-RWI-018</a></td>
<td>Removing member with pending redemption</td>
<td>High</td>
<td>Resolved</td>
</tr>
<tr>
<td><a href="#IO-NXM-RWI-001">IO-NXM-RWI-001</a></td>
<td>No period validation for locked deposits</td>
<td>Medium</td>
<td>Resolved</td>
</tr>
<tr>
<td><a href="#IO-NXM-RWI-002">IO-NXM-RWI-002</a></td>
<td>Can lock shares when paused</td>
<td>Low</td>
<td>Resolved</td>
</tr>
<tr>
<td><a href="#IO-NXM-RWI-003">IO-NXM-RWI-003</a></td>
<td>Extended lock period can exceed maximum</td>
<td>Low</td>
<td>Closed</td>
</tr>
<tr>
<td><a href="#IO-NXM-RWI-004">IO-NXM-RWI-004</a></td>
<td>Stuck funds</td>
<td>Low</td>
<td>Resolved</td>
</tr>
<tr>
<td><a href="#IO-NXM-RWI-016">IO-NXM-RWI-016</a></td>
<td>Loss of assets due to rounding</td>
<td>Low</td>
<td>Resolved</td>
</tr>
<tr>
<td><a href="#IO-NXM-RWI-019">IO-NXM-RWI-019</a></td>
<td>Removing member with pending deposit</td>
<td>Low</td>
<td>Resolved</td>
</tr>
<tr>
<td><a href="#IO-NXM-RWI-020">IO-NXM-RWI-020</a></td>
<td>Removed members cannot withdraw locked shares</td>
<td>Low</td>
<td>Closed</td>
</tr>
<tr>
<td><a href="#IO-NXM-RWI-024">IO-NXM-RWI-024</a></td>
<td>No bounds validation on proposed rate change</td>
<td>Low</td>
<td>Resolved</td>
</tr>
<tr>
<td><a href="#IO-NXM-RWI-009">IO-NXM-RWI-009</a></td>
<td>ERC-7540 return values</td>
<td>Informational</td>
<td>Resolved</td>
</tr>
<tr>
<td><a href="#IO-NXM-RWI-011">IO-NXM-RWI-011</a></td>
<td>Check-Effects-Interactions pattern</td>
<td>Informational</td>
<td>Resolved</td>
</tr>
<tr>
<td><a href="#IO-NXM-RWI-017">IO-NXM-RWI-017</a></td>
<td>Counter not incremented when redeeming max assets</td>
<td>Informational</td>
<td>Closed</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-RWI-018"></a><h2 id="io-nxm-rwi-018-removing-member-with-pending-redemption" class="break-before">IO-NXM-RWI-018 Removing member with pending redemption</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/rwi-vault/blob/ce47d1e0e7e59ebf3104fc76606a771497e2390e/contracts/RWAVault.sol#L232">RWAVault.sol#L232</a></td>
</tr>
</tbody>
</table>
If a member with a pending redemption request opts to leave or is removed by the operator, it will be impossible to process subsequent redemptions, as attempts to fulfill the previous member’s request will attempt to transfer assets to <code>address(0)</code> and thus revert.
It is also not possible to cancel the previous member’s request, as the function will attempt to return the shares to <code>address(0)</code> and revert.
The following proof of concept demonstrates this issue.
<pre tabindex="0" class="chroma"><code>it('can process redeem requests even if user is removed from registry', async function () {
 await _requestRedeem(user, userShares);

 await registry.connect(membershipManager).removeMember(await registry.getMemberId(user.address));

 await expect(rwaVault.connect(vaultManager).cancelRedeemRequest(1)).to.be.revertedWithCustomError(rwaVault, 'ERC20InvalidReceiver');

 await usdcMock.connect(vaultManager).approve(await rwaVault.getAddress(), userShares);
 await rwaVault.connect(vaultManager).fulfillRedeems(1, userShares);

});
</code></pre><h3 id="recommendation">Recommendation</h3>
<code>if (registry.getMemberAddress(redeemRequest.memberId) == address(0)) continue;</code> should be added to the loop in <code>RWAVault::fulFillRedeems()</code>.
<h3 id="client-response">Client response</h3>
Fixed in <a href="https://github.com/NexusMutual/rwi-vault/commit/ca33cb630624744d201432b43af2dc29cbed61dc">ca33cb6</a>.
<a name="IO-NXM-RWI-001"></a><h2 id="io-nxm-rwi-001-no-period-validation-for-locked-deposits" class="break-before">IO-NXM-RWI-001 No period validation for locked deposits</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/rwi-vault/blob/ce47d1e0e7e59ebf3104fc76606a771497e2390e/contracts/Locks.sol#L48">Locks.sol#L48</a></td>
</tr>
</tbody>
</table>
The <code>Locks::lockSharesOnDeposit(...)</code> function does not validate the lock period. Furthermore, the period is entirely under the caller’s control and not constrained by the <code>RWAVault</code> contract. This implementation allows members to lock their deposits for a period of arbitrary length, from <code>1 second</code> to far in excess of <code>MAX_LOCK_PERIOD</code>. The following proof of concept demonstrates this.
<pre tabindex="0" class="chroma"><code>it('locked deposit request allows users to lock shares without validating the lock period.', async function () {
 const { accounts: {members, vaultManager}, contracts: {rwaVault, usdcMock, locks} } = await networkHelpers.loadFixture(setupFixture);
 const user = members[0];
 const depositAmount = parseUsdc("1000");

 await usdcMock.connect(user).approve(await rwaVault.getAddress(), depositAmount);
 const expectedShares = await rwaVault.convertToShares(depositAmount);
 await rwaVault.connect(user).requestDepositAndLock(depositAmount, user.address, user.address, duration.seconds(30));

 expect(await rwaVault.balanceOf(await locks.getAddress())).to.equal(expectedShares);

 // assets should be transferred to the vault manager directly
 expect(await usdcMock.balanceOf(vaultManager.address)).to.equal(depositAmount);
 expect(await usdcMock.balanceOf(await rwaVault.getAddress())).to.equal(0);
 });
</code></pre><h3 id="recommendation-1">Recommendation</h3>
The <code>Locks::lockSharesOnDeposit(...)</code> function should ensure that the lock period is greater than the minimum lock period and less than the maximum lock period.
<h3 id="client-response-1">Client response</h3>
Fixed in <a href="https://github.com/NexusMutual/rwi-vault/commit/39ce5deb3ccea6a4d37d5ac26727f52b8ab6424a">39ce5de</a>.
<a name="IO-NXM-RWI-002"></a><h2 id="io-nxm-rwi-002-can-lock-shares-when-paused" class="break-before">IO-NXM-RWI-002 Can lock shares when paused</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/rwi-vault/blob/ce47d1e0e7e59ebf3104fc76606a771497e2390e/contracts/Locks.sol#L48">Locks.sol#L48</a></td>
</tr>
</tbody>
</table>
The function <code>Locks::lockSharesOnDeposit(...)</code> does not implement the <code>whenNotPaused(PAUSE_LOCKS)</code> modifier, unlike <code>Locks::lockShares(...)</code>. This would allow members to lock shares when depositing, even when the feature has been paused. This is shown in the proof of concept below.
<pre tabindex="0" class="chroma"><code> it('locked deposit request allows users to lock shares without checking if the locks contract is paused.', async function () {
 const { accounts: {members, vaultManager, emergencyAdmin}, contracts: {rwaVault, usdcMock, locks, registry} } = await networkHelpers.loadFixture(setupFixture);
 const user = members[0];
 const depositAmount = parseUsdc("1000");

 await usdcMock.connect(user).approve(await rwaVault.getAddress(), depositAmount);
 const expectedShares = await rwaVault.convertToShares(depositAmount);

 // pause the locks contract
 const PAUSE_LOCKS = 4;
 await expect(
 registry.connect(emergencyAdmin).setPauseConfig(PAUSE_LOCKS)
 ).to.emit(registry, 'PauseConfigConfirmed').withArgs(PAUSE_LOCKS, emergencyAdmin);

 await rwaVault.connect(user).requestDepositAndLock(depositAmount, user.address, user.address, duration.seconds(30));

 expect(await rwaVault.balanceOf(await locks.getAddress())).to.equal(expectedShares);

 // assets should be transferred to the vault manager directly
 expect(await usdcMock.balanceOf(vaultManager.address)).to.equal(depositAmount);
 expect(await usdcMock.balanceOf(await rwaVault.getAddress())).to.equal(0);
 });
</code></pre><h3 id="recommendation-2">Recommendation</h3>
<code>Locks::lockSharesOnDeposit(...)</code> should implement the <code>whenNotPaused(PAUSE_LOCKS)</code> modifier.
<h3 id="client-response-2">Client response</h3>
Fixed in <a href="https://github.com/NexusMutual/rwi-vault/commit/39ce5deb3ccea6a4d37d5ac26727f52b8ab6424a">39ce5de</a>.
<a name="IO-NXM-RWI-003"></a><h2 id="io-nxm-rwi-003-extended-lock-period-can-exceed-maximum" class="break-before">IO-NXM-RWI-003 Extended lock period can exceed maximum</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/rwi-vault/blob/ce47d1e0e7e59ebf3104fc76606a771497e2390e/contracts/Locks.sol#L58">Locks.sol#L58</a></td>
</tr>
</tbody>
</table>
Through editing a lock, a lock’s period can be made to exceed the <code>MAX_LOCK_PERIOD</code>, as only the extension period is validated, not the new total duration. The following proof of concept shows how the maximum lock period can be exceeded.
<pre tabindex="0" class="chroma"><code>it('editing a lock extends the total extended duration to greater than max lock period.', async function () {
 const { accounts: {members}, contracts: {rwaVault, usdcMock, locks} } = await networkHelpers.loadFixture(setupFixture);
 const user = members[0];
 const depositAmount = parseUsdc("1000");

 await usdcMock.connect(user).approve(await rwaVault.getAddress(), depositAmount);
 const expectedShares = await rwaVault.convertToShares(depositAmount);

 await rwaVault.connect(user).requestDepositAndLock(depositAmount, user.address, user.address, duration.years(2));
 expect(await rwaVault.balanceOf(await locks.getAddress())).to.equal(expectedShares);

 const lockBeforeEdit = await locks.getMemberLock(1,0);
 expect(lockBeforeEdit.period).to.equal(duration.years(2));

 await networkHelpers.time.increase(duration.years(1));
 await locks.connect(user).editLock(0, 0, duration.years(2)); // total extended duration = 3 years

 const lockAfterEdit = await locks.getMemberLock(1,0);
 expect(lockAfterEdit.period).to.equal(duration.years(3) + duration.seconds(1)); // +1 second for next block time increase

 });
</code></pre><h3 id="recommendation-3">Recommendation</h3>
To prevent this, the updated <code>lock.period</code> should be validated instead of the extension period.
<h3 id="client-response-3">Client response</h3>
The development team clarified that this functionality is by design. The extension starting from the current timestamp must be less than 2 years; however, the total lasting period can be longer than 2 years.
<h4 id="follow-up-review-note">Follow-up review note</h4>
In commit <a href="https://github.com/NexusMutual/rwi-vault/commit/326d4ab">326d4ab</a>, the <code>editLock</code> function was changed from resetting the period from the current timestamp (<code>lock.period = passedTime + newPeriod</code>) to an additive extension (<code>lock.period += period</code>). The validation was also updated to check that the remaining time until expiry (<code>timeUntilEnd = lock.startTime + lock.period - block.timestamp</code>) falls within <code>[MIN_LOCK_PERIOD, MAX_LOCK_PERIOD]</code>, rather than validating the raw period input. The cumulative <code>lock.period</code> can still grow beyond <code>MAX_LOCK_PERIOD</code> through repeated near-expiry extensions, consistent with the original design decision. Fork testing confirmed this behaviour on the deployed contracts.
<a name="IO-NXM-RWI-004"></a><h2 id="io-nxm-rwi-004-stuck-funds" class="break-before">IO-NXM-RWI-004 Stuck funds</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/rwi-vault/blob/9351e36fb9840805482396a6a42d8f09db92900e/contracts/RWAVault.sol#L239">RWAVault.sol#L239</a></td>
</tr>
</tbody>
</table>
When partially fulfilling redemptions, <code>fulfilledShares</code> is rounded down, while the assets remain the same, resulting in members receiving more assets than they should.
For example, if <code>assetsLeft</code> is 1 wei, <code>convertToShares(assetsLeft)</code> will result in zero if the vault has accrued any yield. The member will then receive 1 wei of assets while <code>fufilledShares</code> remains unchanged.
The following proof of concept demonstrates this.
<pre tabindex="0" class="chroma"><code>it('redeeming 1 wei of shares does not decrease shares but increases assets due to rounding', async function () {

 const userAssetsBefore = await usdcMock.balanceOf(user.address);
 const userSharesBefore = await rwaVault.balanceOf(user.address);

 await _requestRedeem(user, userSharesBefore);

 const [firstRequest] = await rwaVault.getRedeemRequests([1]);

 // Vault manager fulfills the redemption
 await usdcMock.connect(vaultManager).approve(await rwaVault.getAddress(), parseUsdc("1"));
 await rwaVault.connect(vaultManager).fulfillRedeems(1, 1);

 const [updatedFirstRequest] = await rwaVault.getRedeemRequests([1]);
 const userAssetsAfter = await usdcMock.balanceOf(user.address);

 // Verify that assets increased but fulfilled shares remained the same
 expect(userAssetsAfter).to.be.gt(userAssetsBefore);
 expect(updatedFirstRequest.fulfilledShares).to.equal(firstRequest.fulfilledShares);
});
</code></pre><h3 id="recommendation-5">Recommendation</h3>
Assets should be recalculated as <code>assets = convertToAssets(shares)</code> and <code>assetsLeft</code> should be set to zero when partially fulfilling a redemption. <code>assetsLeft -= assets</code> should only be done in the case of a non-partial redemption in the loop.
<h3 id="client-response-5">Client response</h3>
Fixed in <a href="https://github.com/NexusMutual/rwi-vault/commit/033d7fe8cd058dc748ecf7d56f3b3edeb0fcf8b9">033d7fe</a>.
<a name="IO-NXM-RWI-019"></a><h2 id="io-nxm-rwi-019-removing-member-with-pending-deposit" class="break-before">IO-NXM-RWI-019 Removing member with pending deposit</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/rwi-vault/blob/ce47d1e0e7e59ebf3104fc76606a771497e2390e/contracts/RWAVault.sol#L147">RWAVault.sol#L147</a></td>
</tr>
</tbody>
</table>
If a member has a pending deposit request and opts to leave or the operator removes them, it won’t be possible to process the request or refund the user due to attempts to transfer assets or mint shares to <code>address(0)</code>. This will result in funds being stuck in the contract.
The following proof of concept demonstrates this.
<pre tabindex="0" class="chroma"><code>it('can cancel deposit after user is removed from registry', async function () {
 const { accounts: {members, vaultManager, membershipManager}, contracts: {rwaVault, usdcMock, registry} } = await networkHelpers.loadFixture(setupFixture);
 const user = members[0];
 const depositAmount = parseUsdc("1000");

 await rwaVault.connect(vaultManager).setAssetCap(parseUsdc("100"));

 await usdcMock.connect(user).approve(await rwaVault.getAddress(), depositAmount);
 await rwaVault.connect(user).requestDeposit(depositAmount, user.address, user.address);

 await registry.connect(membershipManager).removeMember(await registry.getMemberId(user.address));

 await rwaVault.connect(vaultManager).cancelDepositRequest(1);
});
</code></pre><h3 id="recommendation-6">Recommendation</h3>
A check should be added to <code>RWAVault::cancelDepositRequest()</code> so that if the <code>memberAddress == address(0)</code> the request is cancelled, but the remaining assets are transferred to the <code>vaultManager</code>.
<h3 id="client-response-6">Client response</h3>
Fixed in <a href="https://github.com/NexusMutual/rwi-vault/commit/ca33cb630624744d201432b43af2dc29cbed61dc">ca33cb6</a>.
<a name="IO-NXM-RWI-009"></a><h2 id="io-nxm-rwi-009-erc-7540-return-values" class="break-before">IO-NXM-RWI-009 ERC-7540 return values</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/rwi-vault/blob/ce47d1e0e7e59ebf3104fc76606a771497e2390e/contracts/RWAVault.sol#L152">RWAVault.sol#L152</a>, <a href="https://github.com/NexusMutual/rwi-vault/blob/ce47d1e0e7e59ebf3104fc76606a771497e2390e/contracts/RWAVault.sol#L177">RWAVault.sol#L177</a>, <a href="https://github.com/NexusMutual/rwi-vault/blob/ce47d1e0e7e59ebf3104fc76606a771497e2390e/contracts/RWAVault.sol#L182">RWAVault.sol#L182</a>, <a href="https://github.com/NexusMutual/rwi-vault/blob/ce47d1e0e7e59ebf3104fc76606a771497e2390e/contracts/RWAVault.sol#L235">RWAVault.sol#L235</a>, <a href="https://github.com/NexusMutual/rwi-vault/blob/ce47d1e0e7e59ebf3104fc76606a771497e2390e/contracts/RWAVault.sol#L126">RWAVault.sol#L126</a>, <a href="https://github.com/NexusMutual/rwi-vault/blob/ce47d1e0e7e59ebf3104fc76606a771497e2390e/contracts/RWAVault.sol#L209">RWAVault.sol#L209</a></td>
</tr>
</tbody>
</table>
Although the USDC token does not provide a manner to perform a reentrancy attack, it is advisable to follow the Check-Effects-Interactions security principle where sensible.
<h3 id="recommendation-8">Recommendation</h3>
The following changes are recommended:
<ul>
<li><code>cancelDepositRequest</code> should perform the <code>safeTransfer</code> after all internal state changes (just before emitting <code>DepositRequestCanceled</code>)</li>
<li><code>_fulfillDeposit</code> should perform all transfers after all internal state changes and interactions with the <code>Locks</code> contract (just before emitting <code>DepositFulfilled</code>).</li>
<li><code>fulfillRedeems</code> should perform the <code>safeTransfer</code> after all internal state changes within the loop (before emitting <code>RedeemFulfilled</code>).</li>
<li><code>_requestDeposit</code> should perform the <code>safeTransferFrom</code> before all internal state changes (before <code>depositRequestNextId++</code>).</li>
<li><code>requestRedeem</code> should perform the <code>safeTransferFrom</code> before <code>redeemRequestNexId++</code>.</li>
</ul>
<h3 id="client-response-8">Client response</h3>
Fixed in <a href="https://github.com/NexusMutual/rwi-vault/commit/7d3d4be64d55b50abbde0d9ca1da6bbf319cf73a">7d3d4be</a>.
<a name="IO-NXM-RWI-017"></a><h2 id="io-nxm-rwi-017-counter-not-incremented-when-redeeming-max-assets" class="break-before">IO-NXM-RWI-017 Counter not incremented when redeeming max assets</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/rwi-vault/blob/9351e36fb9840805482396a6a42d8f09db92900e/contracts/RWAVault.sol#L237">RWAVault.sol#L237</a></td>
</tr>
</tbody>
</table>
When a member redeems the maximum asset amount specified by the vault manager, the redemption request’s status is updated to <code>FULFILLED</code> but <code>redeemRequestNextFulfillId</code> is not incremented. This will cause the function to perform unnecessary checks and waste a small amount of gas on the next round of fulfillments, as the first request will already be fulfilled.
The following proof of concept demonstrates this issue:
<pre tabindex="0" class="chroma"><code>it('redeemRequestNextFulfillId is not incremented when assets redeemed equal maxTotalAssets', async function () {
 const userAssetsBefore = await usdcMock.balanceOf(user.address);
 const userShares1 = await rwaVault.balanceOf(user.address);
 // Disable automining
 await ethers.provider.send("evm_setAutomine", [false]);
 // Request redemption
 await rwaVault.connect(user).approve(await rwaVault.getAddress(), userShares1);
 const tx1 = await rwaVault.connect(user).requestRedeem(userShares1, user.address, user.address);

 const storageSlot = 8; // storage slot for `redeemRequestNextFulfillId`
 const initialFulfillId = await ethers.provider.getStorage(await rwaVault.getAddress(), storageSlot);
 console.log(`initialFulfillIdInt: ${BigInt(initialFulfillId)}`);

 // Vault manager fulfills exactly maxTotalAssets
 const maxTotalAssets = await rwaVault.convertToAssets(userShares1);
 await usdcMock.connect(vaultManager).approve(await rwaVault.getAddress(), maxTotalAssets);
 const tx2 = await rwaVault.connect(vaultManager).fulfillRedeems(1, maxTotalAssets);

 // Manually mine a block
 await ethers.provider.send("evm_mine", []);

 // Re-enable automining
 await ethers.provider.send("evm_setAutomine", [true]);

 // Fetch the block details for both transactions
 const receipt1 = await tx1.wait();
 const receipt2 = await tx2.wait();
 const receipt1BlockNumber = receipt1 ? receipt1.blockNumber : 0;
 const receipt2BlockNumber = receipt2 ? receipt2.blockNumber : 0;
 if (receipt1BlockNumber === 0 || receipt2BlockNumber === 0) {
 throw new Error("Failed to fetch transaction receipts or block numbers.");
 }
 const block1 = await ethers.provider.getBlock(receipt1BlockNumber);
 const block2 = await ethers.provider.getBlock(receipt2BlockNumber);

 // Compare the timestamps
 console.log(`Timestamp for tx1: ${block1?.timestamp}`);
 console.log(`Timestamp for tx2: ${block2?.timestamp}`);
 if (block1?.timestamp === block2?.timestamp) {
 console.log("Both transactions have the same timestamp.");
 } else {
 console.log("Transactions have different timestamps.");
 }

 console.log("block1?.timestamp", block1?.timestamp);

 //verify assets redeemed is equal to max total assets
 const [updatedFirstRequest] = await rwaVault.getRedeemRequests([1]);
 expect(updatedFirstRequest.status).to.equal(RequestStatus.FULFILLED);
 const userAssetsAfter = BigInt(await usdcMock.balanceOf(user.address));
 const assetsRedeemed = userAssetsAfter - userAssetsBefore;
 assert(assetsRedeemed === maxTotalAssets, `Assets redeemed (${assetsRedeemed}) do not equal maxTotalAssets (${maxTotalAssets})`);
 console.log("assetsRedeemed", assetsRedeemed);
 console.log("maxTotalAssets", assetsRedeemed);

 // Fetch the storage position again
 const finalFulfillId = await ethers.provider.getStorage(await rwaVault.getAddress(), storageSlot);
 console.log(`finalFulfillId: ${BigInt(finalFulfillId)}`);


 // Verify that redeemRequestNextFulfillId has not been incremented
 expect(initialFulfillId).to.equal(finalFulfillId);

 });
</code></pre><h3 id="recommendation-9">Recommendation</h3>
A possible fix would be to remove the increment from the <code>for</code> statement and increment <code>requestId</code> when setting the status to <code>RequestStatus.FULFILLED</code>
<pre tabindex="0" class="chroma"><code>for(requestId = redeemRequestFulfillId; requestId <= maxRequestId; ) {
</code></pre><h3 id="client-response-9">Client response</h3>
The development team acknowledged this issue but will leave the functionality as-is, due to the low gas impact and low probability of the scenario occurring.
<a name="IO-NXM-RWI-020"></a><h2 id="io-nxm-rwi-020-removed-members-cannot-withdraw-locked-shares" class="break-before">IO-NXM-RWI-020 Removed members cannot withdraw locked shares</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/rwi-vault/blob/4c317b1/contracts/Locks.sol#L81-L93">Locks.sol#L81-L93</a>, <a href="https://github.com/NexusMutual/rwi-vault/blob/4c317b1/contracts/RegistryAware.sol#L48-L52">RegistryAware.sol#L48-L52</a></td>
</tr>
</tbody>
</table>
The <code>withdrawShares</code> function in the <code>Locks</code> contract calls <code>getActiveMemberId(msg.sender)</code>, which requires the caller to be a registered member. If a member removes themselves (or is removed by the MembershipOperator) while they have active locks, the member can never call <code>withdrawShares</code> because their address no longer resolves to a valid member ID. The locked shares remain in the <code>Locks</code> contract.
<pre tabindex="0" class="chroma"><code>function withdrawShares(uint lockId) external whenNotPaused(PAUSE_LOCKS) {
 uint memberId = getActiveMemberId(msg.sender); // @audit reverts if member was removed
 Lock memory lock = memberLocks[memberId][lockId];

 require(lock.shares > 0, LockDoesntExist());
 require(block.timestamp >= lock.startTime + lock.period, NotExpired());

 delete memberLocks[memberId][lockId];

 IERC20(vault).safeTransfer(msg.sender, lock.shares);

 emit SharesWithdrawn(memberId, lockId);
}
</code></pre>There is no administrative function to withdraw shares on behalf of a removed member, and re-registering the same address as a new member would assign a different member ID, leaving the original locks inaccessible.
<h3 id="recommendation-10">Recommendation</h3>
An administrative function should be added to the <code>Locks</code> contract that allows the Governor or VaultOperator to withdraw expired locks on behalf of a removed member to a specified address.
<h3 id="client-response-10">Client response</h3>
This issue has been closed without action. The Locks contract is deployed behind a proxy and a recovery function can be introduced through a governance approved upgrade, should the need arise.
<a name="IO-NXM-RWI-024"></a><h2 id="io-nxm-rwi-024-no-bounds-validation-on-proposed-rate-change" class="break-before">IO-NXM-RWI-024 No bounds validation on proposed rate change</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/rwi-vault/blob/4c317b1/contracts/RWIVault.sol#L90-L100">RWIVault.sol#L90-L100</a></td>
</tr>
</tbody>
</table>
The <code>proposeBaseRateChange</code> function (originally named <code>proposeBaseApyChange</code>) accepted any value for <code>proposalRate</code> without validating it against meaningful bounds. A VaultOperator signer could propose a rate below <code>WAD</code> (1e18), which would cause share values to decrease over time as the compounding rate falls below unity, effectively imposing a negative yield on all depositors. Conversely, an excessively high rate could produce unrealistic APY, inflating share values and distorting the asset-to-share conversion. The only validation present was on <code>proposalActivationTime</code> meeting the 90-day minimum notice period.
<pre tabindex="0" class="chroma"><code>// Before fix (commit 5099ff7)
function proposeBaseApyChange(uint proposalRate, uint proposalActivationTime) external only(A_VAULT_OPERATOR) {
 require(proposalActivationTime > block.timestamp + MIN_APY_PROPOSAL_TIME, ProposalActivationTimeTooSoon());
 // @audit no validation on proposalRate
 apyConfig.proposedRate = proposalRate.toUint64();
 apyConfig.proposedActivationTime = proposalActivationTime.toUint32();
}
</code></pre><h3 id="recommendation-11">Recommendation</h3>
A validation check should be added to ensure the proposed rate is at least <code>WAD</code> (no negative growth) and that the annualised APY does not exceed a reasonable upper bound.
<h3 id="client-response-11">Client response</h3>
Fixed in <a href="https://github.com/NexusMutual/rwi-vault/commit/667f52c">667f52c</a>. Added <code>require(proposalRate >= WAD && proposedApy <= MAX_APY, InvalidRate())</code> where <code>MAX_APY</code> is set to <code>1.5e18</code> (150%).
<h1 id="code-quality-improvement-suggestions">Code quality improvement suggestions</h1>
Code improvement suggestions without security implications are listed below.
<table>
<thead>
<tr>
<th>ID</th>
<th>Location</th>
<th>Details</th>
</tr>
</thead>
<tbody>
<tr>
<td>IO-NXM-RWI-005</td>
<td><a href="https://github.com/NexusMutual/rwi-vault/blob/ce47d1e0e7e59ebf3104fc76606a771497e2390e/contracts/Locks.sol#L63">Locks.sol#L63</a></td>
<td>When specifying a zero amount for <code>topUpShares</code>, it should not be necessary to call <code>transferFrom</code>. Recommend adding the following: <code>if (topUpShares > 0) IERC20(vault).safeTransferFrom(msg.sender, address(this), topUpShares);</code></td>
</tr>
<tr>
<td>IO-NXM-RWI-006</td>
<td><a href="https://github.com/NexusMutual/rwi-vault/blob/ce47d1e0e7e59ebf3104fc76606a771497e2390e/contracts/Registry.sol#L207">Registry.sol#L207</a></td>
<td>The Governor can remove itself from the registry. Recommend validating that the <code>index != C_GOVERNOR</code> in <code>removeContract</code></td>
</tr>
<tr>
<td>IO-NXM-RWI-007</td>
<td><a href="https://github.com/NexusMutual/rwi-vault/blob/ce47d1e0e7e59ebf3104fc76606a771497e2390e/contracts/Registry.sol#L53">Registry.sol#L53</a></td>
<td>In <code>Registry::setPauseConfig(...)</code>, a <code>PauseConfigConfirmed</code> event is emitted. The name of the event does not match the pattern used in the contract and should rather be updated to be <code>PauseConfigSet</code>. The main NXM protocol Registry requires two emergency admins – a proposer and a confirmer – to toggle the pause configuration, whereas this version of the Registry requires only a single Emergency Admin.</td>
</tr>
<tr>
<td>IO-NXM-RWI-008</td>
<td><a href="https://github.com/NexusMutual/rwi-vault/blob/ce47d1e0e7e59ebf3104fc76606a771497e2390e/contracts/Locks.sol#L22">Locks.sol#L22</a></td>
<td>The <code>constructor</code> for the <code>Locks</code> contract dynamically queries the Registry to determine the <code>vault</code> address. The <code>vault</code> address is stored as an <code>immutable</code> and cannot be changed afterward. This pattern unnecessarily complicates the deployment process because the <code>vault</code> must first be deployed and registered with the Registry before the <code>Locks</code> contract can be deployed and registered. By passing the <code>vault</code> as a constructor argument, the contracts can be deployed first and then registered in tandem.</td>
</tr>
<tr>
<td>IO-NXM-RWI-010</td>
<td><a href="https://github.com/NexusMutual/rwi-vault/blob/ce47d1e0e7e59ebf3104fc76606a771497e2390e/contracts/RWAVault.sol#L289">RWAVault.sol#L289</a></td>
<td>The ERC-7540 specification for <code>totalAssets()</code> includes the following: “SHOULD include any compounding that occurs from yield.” To match the specification, the function should instead return the current asset value of the vault’s total supply, e.g., <code>convertToAssets(totalSupply())</code></td>
</tr>
<tr>
<td>IO-NXM-RWI-012</td>
<td><a href="https://github.com/NexusMutual/rwi-vault/blob/ce47d1e0e7e59ebf3104fc76606a771497e2390e/contracts/Locks.sol#L33">Locks.sol#L33</a></td>
<td>When calling <code>Locks:lockShares()</code>, the function does not return the <code>lockId</code> for the newly locked shares, and as the <code>memberLocks</code> mapping is private, there is no way to query the Id before creation. The <code>Locks:lockShares()</code> function should return the <code>lockId</code> for the newly locked shares.</td>
</tr>
<tr>
<td>IO-NXM-RWI-013</td>
<td><a href="https://github.com/NexusMutual/rwi-vault/blob/ce47d1e0e7e59ebf3104fc76606a771497e2390e/contracts/RWAVault.sol#L17">RWAVault.sol#L17</a></td>
<td>The <code>RWAVault</code> contains a typo in the declaration for the variable for <code>BPS</code>, which is set to <code>100_00</code>. The <code>BPS</code> variable should be set to <code>10_000</code> as it is easier to read and the units are grouped correctly.</td>
</tr>
<tr>
<td>IO-NXM-RWI-014</td>
<td><a href="https://github.com/NexusMutual/rwi-vault/blob/ce47d1e0e7e59ebf3104fc76606a771497e2390e/contracts/RWAVault.sol#L24">RWAVault.sol#L24</a></td>
<td>The <code>RWAVault</code> contains a typo in the declaration of the variable to track redeem request IDs, which was named <code>redeemRequestNexId</code> but should be <code>redeemRequestNextId</code>.</td>
</tr>
<tr>
<td>IO-NXM-RWI-015</td>
<td><a href="https://github.com/NexusMutual/rwi-vault/blob/ce47d1e0e7e59ebf3104fc76606a771497e2390e/contracts/RWAVault.sol#L225">RWAVault.sol#L225</a></td>
<td>In <code>fulfillRedeems</code>, there is no validation that <code>untilRequestId</code> is within the bounds of existing requests. This will result in an <code>ERC20InvalidReceiver</code> revert when specifying an <code>untilRequestId</code> higher than <code>redeemRequestNextId - 1</code>. Recommend using the minimum between <code>untilRequestId</code> and <code>redeemRequestNextId - 1</code> to prevent attempts to process non-existent requests, e.g.: <code>untilRequestId = untilRequestId < redeemRequestNextId ? untilRequestId: redeemRequestNextId - 1;</code></td>
</tr>
<tr>
<td>IO-NXM-RWI-025</td>
<td><a href="https://github.com/NexusMutual/rwi-vault/blob/4c317b1/contracts/RWIVault.sol">RWIVault.sol</a>, <a href="https://github.com/NexusMutual/rwi-vault/blob/4c317b1/contracts/interfaces/IRWIVault.sol">IRWIVault.sol</a></td>
<td>The codebase used “APY” terminology throughout its structs, functions, events, and state variables (<code>BaseApyConfig</code>, <code>proposeBaseApyChange</code>, <code>executeBaseApyChange</code>, <code>BaseApyChangeProposed</code>, <code>MIN_APY_PROPOSAL_TIME</code>) despite these values representing a per-second compounding rate rather than an annual percentage yield. Only <code>getBaseApy</code> actually returns an annualized value. Recommend renaming all references to use “rate” terminology, retaining <code>getBaseApy</code> as the sole APY-denominated accessor.</td>
</tr>
</tbody>
</table>
<h3 id="client-response-12">Client response</h3>
<dl>
<dt>IO-NXM-RWI-005</dt>
<dd>Fixed in <a href="https://github.com/NexusMutual/rwi-vault/commit/a6b561c04cc98b82404e8ff53c0a42eb5e6399a6">a6b561c</a>.</dd>
<dt>IO-NXM-RWI-006</dt>
<dd>Fixed in <a href="https://github.com/NexusMutual/rwi-vault/commit/0c921661685d97088b03972ee408526b88ecd132">0c92166</a>.</dd>
<dt>IO-NXM-RWI-007</dt>
<dd>Fixed in <a href="https://github.com/NexusMutual/rwi-vault/commit/0c921661685d97088b03972ee408526b88ecd132">0c92166</a>.</dd>
<dt>IO-NXM-RWI-008</dt>
<dd>Fixed in <a href="https://github.com/NexusMutual/rwi-vault/commit/a6b561c04cc98b82404e8ff53c0a42eb5e6399a6">a6b561c</a>.</dd>
<dt>IO-NXM-RWI-010</dt>
<dd>Fixed in <a href="https://github.com/NexusMutual/rwi-vault/commit/9c83e591dbf451650158b79a69063f70bcd8fcbf">9c83e59</a>.</dd>
<dt>IO-NXM-RWI-012</dt>
<dd>Acknowledged without any fix. There is a public getter for the member locks; the next ID can be determined from there, but it should not be important in general.</dd>
<dt>IO-NXM-RWI-013</dt>
<dd>Acknowledged without any fix. This is not a typo; it is a subjective preference, as it represents one hundred percent (100_00 => 100.00%).</dd>
<dt>IO-NXM-RWI-014</dt>
<dd>Fixed in <a href="https://github.com/NexusMutual/rwi-vault/commit/8dee0802d1e70fff377f53823a83a3d88c07f993">8dee080</a>.</dd>
<dt>IO-NXM-RWI-015</dt>
<dd>Fixed in <a href="https://github.com/NexusMutual/rwi-vault/commit/eee04c16773bfb6442acf978a68f0b6598f414ea">eee04c1</a>.</dd>
<dt>IO-NXM-RWI-025</dt>
<dd>Fixed in <a href="https://github.com/NexusMutual/rwi-vault/commit/667f52c">667f52c</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="vault">Vault</h2>
The RWI Vault system is designed to allow selected Nexus Mutual members, mainly institutional investors, to earn returns on their USDC deposits. The system comprises several smart contracts that manage deposits, withdrawals, LP share locking, and the distribution of additional returns. The vault adheres to the ERC-7540 standard for asynchronous deposits and redemptions, with some modifications to enhance the user experience.
The vault only allows deposits from whitelisted members, and depositors receive LP tokens in exchange for their USDC deposits. The vault has a cap on total deposits, which the vault manager can adjust as needed. If the total deposits exceed the cap, deposits are marked as pending for vault manager approval. Pending deposits do not earn interest until approved. The vault manager can approve the deposit in full, partially approve it, or reject it entirely. In the case of partial approval, LP tokens are minted for the approved amount, and the remaining USDC is returned to the depositor.
The vault accrues value at a fixed annual percentage yield (APY), which is calculated on a per-second basis using the formula <code>rate = startRate * ratePerSecond ^ timePassed</code>. The vault operator can propose changes to the rate, which take effect after a 90-day notice period has elapsed. The proposed rate must be at least <code>WAD</code> (1e18) and produce an annualised APY of at most 150%. Anyone can execute a pending rate change once the activation time has passed. Depositors can request withdrawals immediately after depositing, provided their shares are not locked; no default lock-up period is enforced on deposits. Members must opt in to lock their shares. Withdrawals are processed asynchronously, adhering to the ERC-7540 standard.
<h2 id="locking-shares">Locking shares</h2>
The system includes a mechanism for locking shares, which allows depositors to earn additional returns from surplus distributions by insurance partners. Rewards are distributed to depositors who lock their tokens between the effective dates of distribution. The locking mechanism enforces a minimum lock period of 30 days and a maximum lock period of 732 days (approximately two years). Lock periods can be extended additively via <code>editLock</code>, but the remaining time after the edit must be at least 30 days and at most 732 days. Members can top up shares to an existing lock when editing. Depositors can also choose to lock shares immediately when requesting a deposit.
<h2 id="erc-7540-compliance">ERC-7540 compliance</h2>
The vault implements the ERC-7540 standard for asynchronous deposits and redemptions, with deviations to improve user experience. Shares are directly transferred to user wallets upon deposit fulfillment, eliminating the need for users to claim them. This deviation is justified as the vault is intended for a limited number of whitelisted members.
<h2 id="governance">Governance</h2>
The registry contract (<code>RWIRegistry</code>, renamed from <code>Registry</code>) manages contracts, roles, and whitelisted members. The membership operator adds members, and both members and the membership operator can update member addresses or withdraw memberships. Members are referenced by their IDs rather than their addresses.
The system defines several roles to manage its operations:
<dl>
<dt><code>C_GOVERNOR</code></dt>
<dd>A multisig role (three-of-five) with the ability to upgrade all proxy contracts, deploy new contracts, manage the contract registry, and set emergency admins.</dd>
<dt><code>A_VAULT_OPERATOR</code></dt>
<dd>Responsible for vault maintenance, including setting the asset cap, proposing rate changes, fulfilling deposit and redeem requests, canceling requests, and distributing rewards via the <code>Locks</code> contract. This will be configured as a three-of-five multisig.</dd>
<dt><code>A_MEMBERSHIP_OPERATOR</code></dt>
<dd>Responsible for adding members. Currently held by the same multisig as the VaultOperator.</dd>
<dt><code>EmergencyAdmin</code></dt>
<dd>A role with the ability to pause all operations or specific functionality (vault, locks, or global) in the event of an emergency. Pausing requires two distinct emergency admins: one to propose and a different one to confirm.</dd>
</dl>
<h1 id="test-coverage-report">Test coverage report</h1>
The coverage report of the provided tests as of the final review is given below.
<table>
<thead>
<tr>
<th>File Path</th>
<th>Line %</th>
<th>Statement %</th>
</tr>
</thead>
<tbody>
<tr>
<td>contracts/ERC20.sol</td>
<td>97.47</td>
<td>73.91</td>
</tr>
<tr>
<td>contracts/ERC7540.sol</td>
<td>21.74</td>
<td>21.74</td>
</tr>
<tr>
<td>contracts/Locks.sol</td>
<td>100.00</td>
<td>100.00</td>
</tr>
<tr>
<td>contracts/RegistryAware.sol</td>
<td>88.24</td>
<td>86.67</td>
</tr>
<tr>
<td>contracts/RWIVault.sol</td>
<td>96.57</td>
<td>88.54</td>
</tr>
<tr>
<td>contracts/UpgradeableProxy.sol</td>
<td>35.48</td>
<td>52.94</td>
</tr>
<tr>
<td>contracts/RWIRegistry.sol</td>
<td>95.76</td>
<td>95.15</td>
</tr>
</tbody>
</table>
Overall, test coverage was found to be satisfactory. <code>Locks.sol</code> has 100% line and statement coverage, and <code>RWIRegistry.sol</code> improved significantly from the initial audit (38.10% to 95.76% line coverage) following the addition of dedicated unit tests. <code>UpgradeableProxy.sol</code> has the lowest in-scope coverage at 35.48%, as <code>transferProxyOwnership</code>, the delegation logic, and the <code>fallback</code>/<code>receive</code> functions are not exercised by the test suite.

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

‍