Skip to content
This repository has been archived by the owner on Nov 19, 2023. It is now read-only.

sherlock-audit/2023-03-notional

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

11 Commits
 
 
 
 
 
 
 
 

Repository files navigation

Notional V3 contest details

Resources

This is an upgrade to a fairly complex protocol that is running in production. A strong understanding of Notional V2 will definitely aid in understanding the changes. This pull request defines the full scope of changes to the protocol.

It's recommended that auditors take a look at the individual commits in order to understand the nature of the changes. The commits have been rebased into thematic chunks that broadly correlate with the documentation in the Notional V3 Specification.

On-chain context

DEPLOYMENT: Currently Mainnet, considering Arbitrum and Optimisim in the near future.
ERC20:  Any Non-Rebasing token. ex. USDC, DAI, USDT (future), wstETH, WETH, WBTC, FRAX, CRV, etc.
ERC721: None
ERC777: None
FEE-ON-TRANSFER: None planned, some support for fee on transfer
REBASING TOKENS: None, strictly prohibited due to balance tracking mechanism. Must use wrapped token versions.
ADMIN: Trusted
EXTERNAL-ADMINS: Trusted

Please answer the following questions to provide more context:

Q: Are there any additional protocol roles? If yes, please explain in detail:

  1. The roles
  2. The actions those roles can take
  3. Outcomes that are expected from those roles
  4. Specific actions/outcomes NOT intended to be possible for those roles

A:

  1. Notional Owner is permitted to upgrade the contract and set governance parameters. It is a Gnosis multisig. It is expected to act in accordance with Snapshot votes from NOTE token holders.

  2. Pause Guardian is permitted to downgrade the contract to the Pause Router in emergency scenarios. Only Notional Owner can upgrade the contract.

  3. Notional Manager is permitted to set total fCash debt outstanding figures in the Migrate Prime Cash contract during the Notional V2 to Notional V3 migration. It is trusted that this manaager will set the proper values for total fCash debt, which can only be inspected off chain at the moment.

  4. Treasury Manager is a smart contract that is permitted to claim COMP incentives, withdraw excess fee reserves to the protocol, and rebalance invested money market tokens. It is only permitted to do a handful of actions allowed by the Treasury Action contract.


Q: Is the code/contract expected to comply with any EIPs? Are there specific assumptions around adhering to those EIPs that Watsons should be aware of?

A: Yes. The Notional V3 Proxy should adhere to ERC1155 for fCash and vault tokens. Note that fCash is transferrable, while Vault tokens are not. Events for both fCash and Vault tokens should be properly emitted from Notional V3. Balances for both fCash and vault tokens should be query-able via Notional V3.

The Notional V3 proxy will also deploy ERC20/ERC4626 compatible proxies for Prime Cash, nTokens and Prime Debt. All three should emit proper Transfer events for mints, burns and transfers. Existing Notional V2 nToken proxies do not emit proper Transfer events and cannot be upgraded. Full ERC4626 compatibility is not in this version (deposit, mint, withdraw, redeem are not fully functional) but view methods are implemented.


Q: Please list any known issues/acceptable risks that should not result in a valid finding.

A:

Common audit issues that have already been considered:

  • ETH transfers do not use .call() and use .transfer() instead. This mitigates re-entrancy and read-only re-entrancy issues.
  • Chainlink oracle prices are not validated to be stale on the main Notional V3 proxy. We have made the design choice to ensure that liquidations can proceed in the face of a stale Chainlink price over reverting due to a stale price.

Q: Please provide links to previous audits (if any).

A:

https://github.com/notional-finance/contracts-v2/tree/master/audits


Q: Are there any off-chain mechanisms or off-chain procedures for the protocol (keeper bots, input validation expectations, etc)?

A:

  1. Treasury Manager is expected to regularly run the rebalancing mechanism based on the rebalancing cool down time, currently expected to be once or twice a week.

  2. Liquidation bots are expected to be online, this is a reasonable expectation. Notional V2 has a robust liquidator community.


Q: In case of external protocol integrations, are the risks of an external protocol pausing or executing an emergency withdrawal acceptable? If not, Watsons will submit issues related to these situations that can harm your protocol's functionality.

A: Pausing is acceptable, emergency withdraws from the system would be strictly prohibited. This depends on the external money market that is integrated via IPrimeCashHoldingsOracles.

Running Tests

  1. Setup brownie and install hardhat (bin/setup.sh)
  2. Run tests: (bin/runTests.sh)

There are a lot of tests and it make take awhile (it takes a few hours on my M2 Apple Silicon). You can run individual test files via brownie test [path] or add the decorator @pytest.mark.only to a function and run a file using brownie test [path] -m only

You may run into a compilation error on IERC20.sol package in the OpenZeppelin Contracts 3.4.2-solc-0.7 dependency. Change the pragma in that file from:

pragma solidity ^0.7.0

to

pragma solidity >=0.7.0

Audit scope

contracts-v2 @ b20a45c912785fab5f2b62992e5260f44dbae197

About Notional Finance

Notional Finance is a lending protocol on Ethereum Mainnet. Notional V2 has been in production for over a year and has processed over $750 million in lending and borrowing volume via its fixed rate marketse. Notional V3 is an upgrade to that system which enables variable rate lending and borrowing markets.

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published