Maia DAO - Ulysses - jauvany's results

Approach taken in evaluating the codebase

• During this analysis, my main focus was to understand the Virtualized liquidity system and the use of Bridge agents to permissionlessly deploy Multicall Root Routers in the Ulysses platform.

• Day 1: I spent time understanding the overall working of the Virtualized liquidity system and getting an overview of the codebase.

• Day 2: I read through the documentation to further understand the Virtualized liquidity system and the functioning of bridge agents.

• Day 3: I went through the codebase and did a comprehensive review of Mechanism and centralization risks as well as possible optimization issues and proposed recommendations

• Day 4: I dedicated this day to preparing the final report and analysis, summarizing the findings and recommendations.

Architecture recommendations

Ulysses protocol’s architecture is well-designed, with clear separation of unified and virtualized liquidity. Non the less, there are a few areas where improvements could be made:

Gas Optimizations

• Review data types : Analyze the data types used in Ulysses smart contracts and consider if they can be further optimized. For example, changing uint256 to uint128 or uint94 can save gas and storage slots.

• Struct packing : Look for opportunities to pack structs into fewer storage slots. By carefully selecting appropriate data types for struct members, overall storage usage can be reduced.

• Use constant values : If certain values in your contracts are constant and do not change, declare them as constants rather than storing them as state variables. This can significantly save gas costs.

• Avoid unnecessary storage : Examine your code and eliminate any unnecessary storage of variables or addresses that are not required for contract functionality.

• Storage vs. memory usage : When working with arrays or structs, consider whether using storage instead of memory can save gas. Using storage allows direct access to the state variables and avoids unnecessary copying of data.

• Replacing the use of memory with calldata for read-only arguments in external functions .

Other recommendations

• Regular code reviews and adherence to best practices.
• Conduct external audits by security experts.
• Consider open sourcing the contract for community review.
• Maintain comprehensive security documentation.
• Establish a responsible disclosure policy for vulnerabilities.
• Implement continuous monitoring for unusual activity.

Codebase quality analysis

• The Ulysses codebase is well-structured, well-documented, and includes comprehensive tests. However, there are areas where improvements could be made, particularly in terms of gas efficiency and permission management.

Analysis of the codebase (What’s unique? What’s using existing patterns?):

• Unique: This contract carries out specific governance mechanisms that are uniquely designed for its specific use case.

• Existing Patterns: The contract uses standard Solidity and Ethereum patterns. It uses the ERC20 standards and Ownable pattern for ownership management.

Centralization risks

• The owner is a single point of failure and a centralization risk Having a single EOA as the only owner of contracts is a large centralization risk and a single point of failure. A single private key may be taken in a hack, or the sole holder of the key may become unable to retrieve the key when necessary, or the single owner can become malicious and perform a rug-pull. Consider changing to a multi-signature setup, and or having a role-based authorization model.

Mechanism review

• Ulysses Protocol is a decentralized and permissionless community-owned 'Omnichain Liquidity Protocol' designed to promote capital efficiency. Enabling Liquidity Providers to deploy their assets from one chain and earn revenue from activity in an array of chains all while mitigating the negative effects of current market solutions.

The Following are the major parts of Ulysses Protocol:

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.

Systemic risks

• External Contract Dependencies: Ulysses relies on the solady, solmate and openzeppelin contracts. If any of these contracts have vulnerabilities, it would affect this contract.

• Like any smart contract-based system, Ulysses is exposed to potential coding bugs or vulnerabilities. Exploiting these issues could result in the loss of funds or manipulation of the protocol.

• Governance Mechanism Security: Ulysses’s governance mechanism is critical for its operation. A poorly implemented governance mechanism could lead to system-wide issues.

• Test Coverage: the test coverage provided by Venus is the 69%, however I recommend 100% of the test coverage.

Time spent:

32 hours