Ethereum, in the future we will consider Base or Arbitrum

The system is expected to work with standard ERC20 tokens as well as non-standard tokens like USDT.

There are three privileged roles in the system which are whitelisted in AddressRegistry.sol

• upgradeAdmin: allowed to upgrade contracts with a 7 day timelock (see: TimelockUpgradeableProxy) and list withdraw request managers and allowed vaults for withdraw managers, lending routers, and update the reward tokens via the RewardManagerMixin.
• pauseAdmin: allowed to pause the system and selectively whitelist selectors
• feeReceiver: receives accrued fees from vaults

upgradeAdmin and pauseAdmin should not be able to bypass the restrictions set out in TimelockUpgradeableProxy.

No

No

No

Each vault must remain solvent with respect to the amount of yield tokens and vault shares. In other words, the convertYieldTokenToShares and convertSharesToYieldToken should return the proper values to ensure that every token holder can redeem their funds appropriately. This should remain true with respect to pending withdraw requests which create "escrowed shares".

Any escrowed shares should not accrue fees or rewards while they are escrowed.

Accounts can only have a position that is natively held on the contract or in a single lending router. An account cannot have both a native balance and a position in a lending router.

Accounts that initiate a withdraw request cannot hold an additional balance. That is, a withdraw request should always include the account's entire balance and should not longer be able to increase that balance.

After each action via a lending router (enterPosition, exitPosition, migratePosition, liquidate, initiateWithdraw, forceWithdraw, claimRewards, healthFactor), any transient variables on the vault are cleared and cannot be re-used in another call back to the lending router in the same transaction.

All vault share transfers must be first authorized by a whitelisted lending router.

Notional Exponent is designed to be extendable to new yield strategies and opportunities as well as new lending platforms. If there are ways to bypass the restrictions put in place by our system by the target lending platform (in this case Morpho) or a yield strategy then that may be a valid finding.

All previous audits of various Notional systems are linked here. Some of the code from the leveraged vaults audits is re-used in this repository, although much of that code has been re-written to accommodate the Notional Exponent design.
https://github.com/notional-finance/contracts-v3/tree/master-v3/audits

The Notional Trading Module is used in Notional Exponent to both execute trades and receive oracle prices. It was audited in this contest:
https://audits.sherlock.xyz/contests/2

Another audit report to consider:
https://audits.sherlock.xyz/contests/446

With code located here:
https://github.com/notional-finance/leveraged-vaults/blob/master/contracts/trading/TradingModule.sol

And deployed to this location:
https://etherscan.io/address/0x594734c7e06C3D483466ADBCe401C6Bd269746C8

Protocol documentation is in the audit folder of the repo.

Some of the code is derived from previous Notional Leveraged Vaults:
https://github.com/notional-finance/leveraged-vaults/tree/master

However, the code as been rewritten to work with a more modular system so the diff from the leveraged vaults code is significant. It would be more accurate to say that the strategies are derived from similar ideas from the Notional Leveraged Vault system.