NOYA

The project utilizes Solidity version 0.8.20 or higher, which includes the introduction of the PUSH0 (0x5f) opcode. This opcode is currently supported on the Ethereum mainnet but may not be universally supported across other blockchain networks. Consequently, deploying the contract on chains other than the Ethereum mainnet, such as certain Layer 2 (L2) chains or alternative networks, might lead to compatibility issues or execution errors due to the lack of support for the PUSH0 opcode. In scenarios where deployment on various chains is anticipated, selecting an appropriate Ethereum Virtual Machine (EVM) version that is widely supported across these networks is crucial to avoid potential operational disruptions or deployment failures.

The usage of a custom minimumHealthFactor in the following connectors: AaveConnector.sol, CompoundConnector.sol, PrismaConnector.sol, SiloConnector.sol, FraxConnector.sol, MorphoBlueConnector.sol creates a risk that the custom minimumHealthFactor will be improperly set by the onlyMaintainer, which will lead to issues.

The value of the fees implemented by the system can change after a user makes a deposit. Thus it is possible a user will interact with the protocol expecting a specific fee (e.g. 5% withdrawal fee) but pay a higher fee later on (e.g. withdrawal fee increased to 10%).

When performing a deposit into the protocol, some ERC20 tokens shares are minted to the specified receiver address. It should be noted that this address should be able to manage those tokens (e.g. EOA). Else, EOA should not be allowed by the system.

The fees are implemented over the same amounts in a redundant matter: management fees, performance fees and withdrawal fees are applied over the same amounts. Although they have different principles applied, it should be noted that they are redundant.

Any actor can send tokens to the AccountingManager contract in order to increase the TVL, affecting the amount of fees recorded, as well as the amount of shares minted by the user during deposits and the amount of received tokens during withdraw. This is due to the fact that TVL depends on balanceOf the contract.

Both AccountingManager and LifiImplementation include functions that allow the retrieval of all native or ERC20 tokens from the contract. It should be noted, however, that those functions have restrictive access control mechanisms.

The project is highly centralized, since it fully controls the timings of the deposits and withdrawals of the clients. This can result in Denial of Service if the protocol owner is not able to access its account to execute the required methods.

Many of the processes and data used in the protocol are off-chain and thus cannot be audited. One example is the usage of the multi-signature process in the Keepers contract. Another example is the usage of data and additionalData in the holding positions structs. One additional example is the usage of cross-chain communication via Layer Zero and Omnichain.

There is no on-chain method that checks that BridgeRequests are not replayed. Therefore there is a risk that the same bridging action is used repeatedly.

The protocol uses TWAP oracles to retrieve the price of assets. It should be noted that TWAP oracles require a uniform liquidity distribution across the fetched pool in order to provide consistent and precise values. The development team should be very careful that this is the case when retrieving data from such oracles, and monitor the used pools to make sure the quality of the pool data provided is good enough.

It should be noted that TWAP oracles provide “smoothened” data, since it uses a time window of price data to prevent flash loan attacks or other kinds of price manipulations that are typical for AMM pools. Therefore, the selected parameters in the TWAP oracle should be chosen wisely to get the best data possible: a very wide window will be more robust to price manipulation but will not reflect the real-time valuation of assets. Due to this, it is recommended to use TWAP data only in case Chainlink data feeds are not available and, moreover, to only use TWAP for healthy pools and tokens.

Noya interacts with several third-party contracts (such as Aave, Stargate or PancakeSwap) that are not part of this audit scope. Although the consistency within those contracts and with the calls to such external protocols has been reviewed and reported if necessary, it is assumed by the audit team that those third-party protocols are done correctly by the development team (see risk statement below).

The performance fee will only work when the vault underlying tokens valuation increases. The reason is that, when calling collectPerformanceFees, the previous value of storedProfitForFee is assigned to totalProfitCalculated and, therefore, only increasing storedProfitForFee will pass the check.

This audit report focuses exclusively on the security assessment of the contracts within the specified review scope. Interactions with out-of-scope contracts are presumed to be correct and are not examined in this audit. We want to highlight that Interactions with contracts outside the specified scope, such as:

have not been verified or assessed as part of this report. This situation is present in all connector contracts that interact with external protocols.

While we have diligently identified and mitigated potential security risks within the defined scope, it is important to note that our assessment is confined to the isolated contracts within this scope. The overall security of the entire system, including external contracts and integrations beyond our audit scope, cannot be guaranteed.

Users and stakeholders are urged to exercise caution when assessing the security of the broader ecosystem and interactions with external contracts. For a comprehensive evaluation of the entire system, additional audits and assessments outside the scope of this report are necessary.

This report serves as a snapshot of the security status of the audited contracts within the specified scope at the time of the audit. We strongly recommend ongoing security evaluations and continuous monitoring to maintain and enhance the overall system's security.