Maia DAO - Ulysses

Maia DAO - Ulysses audit details

• Total Prize Pool: $100,000 USDC
  • HM awards: $69,712.50 USDC
  • Analysis awards: $4,225 USDC
  • QA awards: $2,112.50 USDC
  • Bot Race awards: $6,337.50 USDC
  • Gas awards: $2,112.50 USDC
  • Judge awards: $9,000 USDC
  • Lookout awards: $6,000 USDC
  • Scout awards: $500 USDC
• Join C4 Discord to register
• Submit findings using the C4 form
• Read our guidelines for more details
• Starts September 22, 2023 20:00 UTC
• Ends October 06, 2023 20:00 UTC

Automated Findings / Publicly Known Issues

Automated findings output for the audit can be found here within 24 hours of audit opening.

Note for C4 wardens: Anything included in the automated findings output is considered a publicly known issue and is ineligible for awards.

Publicly Known Issues

• Some chains may demand different block timestamp settings.
• Using your Virtual Account as refundee for a the creation of cross-chain messages with or without settlement attached as well as retrySettlement or retryDeposit will result in gas refunds of excess gas on branch chains being inaccessible since the refundee is not an EOA able to claim receive the funds on any branch chain.
• Floating pragma, code will be deployed with 0.8.19.
• There are contracts that allow to renounce ownership and do not override renounceOwnership function from solady library.
• Our protocol has permissionless factories where anyone can create with for example deposit poison erc20 tokens in ports or create malicious routers. While contracts generated by these are not in scope, if it does affect other contracts or other balances, it is in scope.
• All admin functions are either only callable by other contracts in this system or by Hermes Protocol's Governance. Except for each RootBridgeAgent Manager that is open to whoever creates it. Misuse of these functions by Hermes Governance is out of scope, for example adding a Port strategy to an iliquid token or an iliquid chain. But misuse by the Manager of RootBridgeAgent is valid only if it affects other contracts or other balances.

Overview

Maia DAO V2 Ecosytem docs section that explains the business logic and technical references for Ulysses Protocol, can be found here.

Ulysses

Ulysses scope for this audit focuses on Ulysses Omnichain our Liquidity and Execution Platform built on top of Layer Zero.

This can be divided in two main features:

1. Virtualized liquidity is achieved by connecting Ports within a Pool and Spoke architecture, comprising both the Root Chain and multiple Branch Chains. These contracts are responsible for managing token balances and address mappings across environments. In addition, means that an asset deposited from a specific chain, is recognized as a different asset from the "same" asset but from a different chain (ex: arb ETH is different from mainnet ETH).

2. Arbitrary Cross-Chain Execution is facilitated by an expandable set of routers such as the Multicall Root Router that can be permissionlessly deployed through the Bridge Agent Factories. For more insight on Bridge Agents, please refer to our documentation here. Our Virtual Account contract simplifies remote asset management and interaction within the Root chain.

Areas of Concern

While this audit has all the Ulysses Omnichain components and features in scope, there are specific concerns that we would like to highlight for the wardens to pay special attention to. These are:

• BranchPort's Strategy Token and Port Strategy related functions.
• Omnichain balance accounting.
• Omnichain execution management aspects, particularly related to transaction nonce retry, as well as the retrieve and redeem patterns:
  1. srChain settlement and deposits should either have status set to STATUS_SUCCESS and STATUS_FAILED depending on their redeemability by the user on the source.
  2. dstChain settlement and deposit execution should have executionState set to STATUS_READY, STATUS_DONE or STATUS_RETRIEVE according to user input fallback and destination execution outcome.

Links

Previous audits:

Previous Audits by Zellic and Code4rena can be found in the audits folder. There are three audits, two of them featuring Ulysses:

• Zellic Audit
• Code 4rena Contest

Other links:

• Documentation
• Website
• Twitter
• Discord

Scope

See scope.txt

Out of scope

Everything out of "src" is out of scope, namely "lib" and "test".

Additional Context

Describe any novel or unique curve logic or mathematical models implemented in the contracts

Branch / Root Bridge Agent and Bridge Agent Executor packed payload decoding and encoding.

Please list specific ERC20 that your protocol is anticipated to interact with. Could be "any" (literally anything, fee on transfer tokens, ERC777 tokens and so forth) or a list of tokens you envision using on launch.

Arbitrum's deployment of UniswapV3 and Balancer.

Please list specific ERC721 that your protocol is anticipated to interact with.

Virtual Account should be able to keep and use UniswapV3 NFT's.

Which blockchains will this code be deployed to, and are considered in scope for this audit?

Root contracts are to be deployed on Arbitrum and Branch contracts in several L1 and L2 networks such as Ethereum mainnet, Polygon, Base and Optimism

Please list all trusted roles (e.g. operators, slashers, pausers, etc.), the privileges they hold, and any conditions under which privilege escalation is expected/allowable:

Only our governance has access to key admin state changing functions present in the RootPort and CoreRootRouter and the Root Bridge Agent deployer (referred to in the codebase as manager) is responsible for allowing new branch chains to connect to their Root Bridge Agent in order to prevent griefing.

In the event of a DOS, could you outline a minimum duration after which you would consider a finding to be valid? This question is asked in the context of most systems' capacity to handle DoS attacks gracefully for a certain period.

Unless there is the need to upgrade and migrate any component of Ulysses via governance ( e.g. Bridge Agents or Core Routers) downtime should be negligible to ensure assets are available at any time to their different users.

Is any part of your implementation intended to conform to any EIP's? If yes, please list the contracts in this format:

• ERC20hTokenBranch: Should comply with ERC20/EIP20
• ERC20hTokenRoot: Should comply with ERC20/EIP20

Attack ideas (Where to look for bugs)

• Double spending of deposit and settlement nonces / assets (Bridge Agents and Bridge Agent Executors).
• Griefing of user deposits and settlements (Bridge Agents).
• Bricking of Bridge Agent and subsequent Omnichain dApps that rely on it.
• Circumventing Bridge Agent's encoding rules to manipulate remote chain state.

Main invariants

• The total balance of any given Virtualized Liquidity Token should never be greater than the amount of Underlying Tokens deposited in the asset's origin chain Branch Port.
• A Deposit / Settlement can never be redeemable and retryable at the same time.

Scoping Details

- If you have a public code repo, please share it here:
- How many contracts are in scope?:  50
- Total SLoC for these contracts?:  4281
- How many external imports are there?: 33
- How many separate interfaces and struct definitions are there for the contracts within scope?:  42
- Does most of your code generally use composition or inheritance?:   Inheritance
- How many external calls?:   17
- What is the overall line coverage percentage provided by your tests?: 69%
- Is this an upgrade of an existing system?: False
- Check all that apply (e.g. timelock, NFT, AMM, ERC20, rollups, etc.): Uses L2, Multi-Chain, Side-Chain, ERC-20 Token, Timelock function
- Is there a need to understand a separate part of the codebase / get context in order to audit this part of the protocol?:   Yes
- Please describe required context:   Layerzero Messaging layer, namely Endpoint contract: https://github.com/LayerZero-Labs/LayerZero/blob/main/contracts/Endpoint.sol
- Does it use an oracle?:  No
- Describe any novel or unique curve logic or mathematical models your code uses: None
- Is this either a fork of or an alternate implementation of another project?:   No
- Does it use a side-chain?: True
- Describe any specific areas you would like addressed: Please try to break token deposits and settlements patterns - retry, retrieve, and redeem - to avoid double spending, reentrancy and race conditions. Ensure proper asset management of different ports. Encoding and decoding of cross-chain payloads/data on bridge agents and routers.

Tests

Here is an example of a full script to run the first time you build the contracts in both Windows and Linux:

• Remove .example from the provided .env file and edit the uncommented RPC and RPC_API_KEY values to your preferences. These values will be used by our fork testing suite.

forge install
forge build
forge test --gas-report
forge snapshot --diff

Default gas price is 10,000, but you can change it by adding --gas-price <gas price> to the command or by setting the gas_price property in the foundry.toml file.

Install and First Build

Install libraries using forge and compile contracts.

forge install
forge build

Layer Zero Fork Testing Environment

Requirements

only uses native foundry tools (VM.fork)

Set-up

• open the file '.env.sample' and populate the API_KEY and RPC_URL of the chains ARBITRUM, AVAX and FTM (FTM public RPC should be used). Add any other chain you want. Afterwards remove '.sample' from the file name.
• If you're creating a new test file extend 'LzForkTest' contract
• override the internal function 'setUpLzChains()' to start forks for the chains useful for your testing purposes you'll need to indicate the network chainId, name and the chain's Layer Zero 'Endpoint.sol' address.
• In the test's 'setUp() make sure to invoke the 'setUpLzChains()' function

Using LzForkTest inside your tests

Whenever you need to change chain during there are 6 functions at your disposal:

• switchLzChain and switchChain: changes the current VM chain, updates any pending packet for the destination chain and executes them. Receives either the layer zero chain Id (e.g. 100 or 110) or the network chainId (e.g. 1 or 42161)
• switchLzChainWithoutExecutePackets and switchChainWithoutExecutePackets: changes the current VM chain, updates any pending packet for the destination chain and without executing them. Receives either the layer zero chain Id (e.g. 100 or 110) or the network chainId (e.g. 1 or 42161)
• switchLzChainWithoutExecutePacketsOrUpdate and switchChainWithoutExecutePacketsOrUpdate: changes the current VM chain, without updating any pending packets for the destination chain and without executing them. Receives either the layer zero chain Id (e.g. 100 or 110) or the network chainId (e.g. 1 or 42161)

Slither

If you encounter any issues, please update slither to 0.9.3, the latest version at the moment.

To run slither from root, please specify the src directory.

slither "./src/*"

We have a slither config file that turns on optimization and adds forge remappings.

The output is provided in ./slither.txt