Introduction

iosiro was commissioned by Nexus Mutual to conduct a smart contract audit of their Safe Tracker. The audit was performed by 2 auditors between 23 and 24 January 2024, using 3 audit days.

Overview

This report presents the findings of an audit performed by iosiro of Nexus Mutual's Safe Tracker smart contracts. iosiro identified two medium risk issues, as well as one low risk issue and several informational issues. The two medium issues could have resulted in:

• A malicious Safe having the ability to arbitrarily adjust the reported value of the Safe Tracker.
• A malicious Safe front-running an approval transaction from the Controller, approving an unexpected token type and amount of tokens for transfer.

Overall, the code was found to be of a high standard. The changes covered by the audit were relatively small and straightforward. Both unit tests and fork tests were provided with the code changes.

The table below shows the status of reported findings at the conclusion of the assessment.

Scope

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.

• Project name: smart-contracts
• Commits: 47580f2, a3e4806, 9b406fb, aa38334, 740815f, a9eca85, 5674767, 3fef214, 189b493, a63ee34
• Files: PriceFeedOracle.sol, SafeTracker.sol, SwapOperator.sol

A specification is available in the Specification section of this report.

Disclaimer

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:

• Identify potential security flaws.
• Verify that the smart contracts' functionality aligned with the provided documentation.

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 which takes into account the experimental and rapidly evolving nature of blockchain technology. To encourage secure code development, developers should:

• Integrate security throughout the development lifecycle.
• Employ defensive programming to mitigate the risks posed by unexpected events.
• Adhere to current best practices wherever possible.

Methodology

The audit was conducted using the techniques described below.

Code review

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.

Dynamic analysis

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.

Automated analysis

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.

Audit findings

The table below provides an overview of the audit's findings. Detailed write-ups are provided below.

Each issue identified during the audit has been assigned a risk rating. The rating is determined based on the criteria outlined below.

Critical risk

The issue could result in the theft of funds from the contract or its users.

High risk

The issue could result in the loss of funds for the contract or its users.

Medium risk

The issue resulted in the code being dysfunctional or the specification being implemented incorrectly.

Low risk

A design or best practice issue that could affect the ordinary functioning of the contract.

Informational

An improvement related to best practice or a suboptimal design pattern.

In addition to a risk rating, each issue is assigned a status:

Open

The issue remained present in the code as of the final commit reviewed and may still pose a risk.

Resolved

The issue was identified during the audit and has since been satisfactorily addressed, removing the risk it posed.

Closed

The issue was identified during the audit and acknowledged by the developers as an acceptable risk without actioning any change.

IO-NXM-SFT-001 Missing validation of Cover Re investment amount

TheupdateCoverReInvestmentUSDC function allows the Safe to arbitrarily set the value of coverReInvestmentUSDC, which in turn impacts the total value of the Safe Tracker and thereby the book value of NXM in the RAMM. As Safe members have a vested interest in the NXM exchange rate, it is advisable to validate that this amount is within a range deemed to be acceptable beforehand.

Recommendation

As the value of the Cover Re investment cannot be determined on-chain without an Oracle system, a simpler control to put in place would be to hardcode an absolute limit for the investment value. While this approach would theoretically still allow for manipulation of the value, it would limit the potential impact of doing so.

Client response

A limit was implemented in a3e4806.

IO-NXM-SFT-002 Potential for front-running to manipulate requested amount

ThetransferRequestedAsset function relies on a previously stored transferRequest. This pattern makes it possible for the Safe to either intentionally or unintentionally front-run an approval by the controller, resulting in the approval of an unexpected token type and amount.

Recommendation

The transferRequestedAsset function should require the caller to pass in the expected values for validation.

Client response

The recommendation was implemented in 9b406fb.

IO-NXM-SFT-003 Potential underflow in asset value calcuation

The order of operations in the final line of _calculateBalance could lead to an underflow in some circumstances, causing the function to revert.

Recommendation

In the _calculateBalance function, subtraction of debt should be done after all the positive values have been summed to avoid the potential for an underflow that may result in the function reverting unnecessarily.

Client response

The recommendation was implemented in aa38334.

IO-NXM-SFT-004 Potential for setting of MasterAware contract to be front-run

The MasterAware pattern is susceptible to front-running as the master is set separately from the contract deployment. It is advisable to set the master address in the constructor.

However, the Safe contract is intended to be deployed as a proxy, so the master address will be set atomically during its deployment. In this scenario, this finding poses no risk.

Client response

The team noted the issue and accepted the risk.

IO-NXM-SFT-005 No staleness check of Chainlink values

The recency of the Chainlink value can be used to determine whether the value is stale and revert if the price is too old.

Client response

The team noted the issue and accepted the risk.

IO-NXM-SFT-006 Lack of outflow limit

Currently there is no mechanism for controlling the net outflow of assets from the Pool to the Safe. The Safe and Swap Controllers could theoretically collude to steal the entirety of the funds of the Pool. It may be desirable to limit the gross outflow of assets to a given amount that can be adjusted by another role, such as onlyAuthorizedToGovern.

Due to trust assumptions elsewhere in Nexus Mutual’s protocol, if these actors were to collude they would be able to push through malicious governance proposals or use other means to achieve similar goals. As throttling fund flows in this context might impact the Safe’s ability to manage its debt positions, adding such a control would likely only serve to increase the risk faced by the system.

Client response

The team noted the issue and accepted the risk.

Code quality improvement suggestions

Code improvement suggestions without security implications are listed below.

1. The formatting issues were addressed in 740815f.
2. The recommendation was implemented in a9eca85.
3. The preceding underscore was removed in 5674767.
4. Validation was added in 3fef214.
5. The event was added in 189b493.
6. The recommendation was implemented in a63ee34.

Specification

The following section outlines the intended functionality of the system at a high level. This specification is based on the implementation in the codebase. Any perceived points of conflict should be highlighted with the auditing team to determine the source of the discrepancy.

Safe

This is a Gnosis Safe controlled by three of five Advisory Board members. It is able to receive ETH from the Pool in order to perform various investment related operations, such as managing Aave V3 loans and set the amount of the Cover Re USDC investment.

Safe Tracker

The Safe Tracker is a new contract in the system that follows the ERC-20 standard. The balance of the Safe and the total supply are calculated as the total value of the assets in terms of ETH.

The calculation to determine the total value is as follows (all values are denominated in ETH terms):

ETH balance of the Safe +
Aave Wrapped ETH balance of the Safe +
USDC balance of the Safe +
Amount allocated to the Cover Re (as specified by the Pool) -
Aave USDC debt value 

The USDC to ETH conversion rate is based on the exchange rate reported by Chainlink. Any further assets in the pool are excluded from the calculation.

The Safe Tracker is upgradeable through a proxy.

Swap Operator

The existing Safe Tracker was adapted to allow the Safe to initiate a two-stage process to transfer assets from the Pool to the Safe, as follows:

1. The Safe calls the Swap Operator indicating a token type and amount requested from the Pool.
2. The Controller then calls the Swap Operator accepting the transfer request, thereby actioning the transfer of assets from the Pool to the Safe.