Maia DAO - Ulysses - SAAJ's results

Introduction

This report provides comprehensive analysis of ulysses protocol with analysing the code based for audit purpose. The protocol as a part of Maia ecosystem is developed as a permissionless model to mitigates the downsides of current defi market. The key aspects of benefits provided by ulysses protocol are as under:

• Ulysses protocol aims to optimize capital utilisation across various blockchains through a mechanism of allowing liquidity providers to deploy their assets on one chain and earn from multiple chains.
• Ulysses is developed on foundation of virtualized and unified liquidity management.
• Ulysses have innovate composability with a token that represents a stable Liquidity pool sourced from multiple chains. Users across various platforms i.e., uniswap v3, aave, enhancing flexibility and utility.

Mechanism Review

Ulysses protocol architecture is centered around below discussed foundational element.

• Ports

Ports act as repositories of liquidity, managing the capital deposited into ulysses across various chains.

Ports are further divided into two types:

Branch ports are specific to each chain and root ports on the root chain to cater local operations, handling user requests and system responses within a chain.

Root ports are situated on root chain, and act as global state of virtualized tokens and maintain vital registries for token mapping, balances, and actions that involve token addition, removal, or verification.

• Virtual liquidity

Virtual liquidity mechanism allows assets locking in different chains to be mirrored within a unified environment which ensure unparalleled composability. Providers of liquidity can offer liquidity by utilizing branch tokens across various pools and protocols like uniswap v3 and aave.

The liquidity mechanism approach not only increases capital efficiency but also educe loss, presenting a lucrative opportunity for liquidity providers to have revenue from diverse chain activities.

• Bridge agents

Bridge agents they facilitate efficient communication between blockchain networks, acting as pivotal intermediaries within the system. They have a vital role in ensuring smooth connections by handling user requests and managing system responses. There are two types of bridge agents:

1. Branch bridge agents
2. Root bridge agents

Branch bridge agents

Branch bridge agents are deployed to mediate interactions with a branch router, overseeing user deposits, asset transfers, and engagements with virtualized token contracts within a local chain. The flow involves the submission of a swap request by the user, validation and execution of the request across chains, and token transfer to the desired destination chain.

Bridge agents serve as the neural pathways of the ulysses protocol, efficiently relaying information between different chains and acting as intermediaries for user-system interactions. Their role is fundamental in ensuring that transactions and communications between users and the broader system occur seamlessly, embodying the protocol's commitment to facilitating frictionless cross-chain operations.

Root bridge agents

Root bridge agents, are present on root chain to establish connections with multiple branch chains and respective bridge agents. They are crucial in monitoring pending user settlements and interact with ports and virtualized assets while integrating with other dapps on the root chain.

• Virtual Accounts

Virtual account functions as an omnichain wallet, providing organised and efficient means to manage user balances across multiple blockchain networks. This cross-chain capability streamlines actions within the arbitrum ecosystem, eliminating the need for users to navigate through various blockchain networks manually.

Virtual account maintains separate accounting for each user without altering existing smart contracts, enhancing security, maintainability, and overall efficiency by improving cross-chain interactions, ensuring a smoother and more secure user experience.

Integration with the ulysses branch chain is another standout feature of the virtual account. This integration ensures that users can access their balances and interact with dapps in the arbitrum environment effortlessly. This ease of use and seamless integration are vital in driving broader adoption of the arbitrum ecosystem, attracting both developers and users alike.

CodeBase

This section focus on some of main contracts that contains main logic and work flow for Ulyssess protocol.

• Multicallrootrouter.sol

  • It implements various functionalities to interface with third-party dapps in a root omnichain environment and allows for cross-chain messaging and facilitates asset transfers and calls on the omnichain network.
  • It has core functionalities include executing transactions with different output scenarios, handling multicalls (single and multiple output), and interacting with a bridge agent to transfer assets across chains.
  • this contract also implements error handling mechanisms to revert transactions in case of invalid or unrecognized function calls.

• Corerootrouter.sol

  • It serves as the implementation for the core root router in a root environment deployment. The contract facilitates permissionless addition of new tokens or bridge agents and includes key governance-enabled system functions.
  • This contract has a setup mode and is initialized with essential parameters, including the root chain identifier and the root port address. The initialize function allows the setup to be completed by providing the bridge agent address and htoken factory address.
  • This contract includes functions to add, remove, or update various components related to bridge agents. These functions involve managing branch bridge agents, toggling bridge agent factories, removing bridge agents, managing strategy tokens, and managing port strategies.
  • This contract provides functions to add global tokens and local tokens, set local tokens for a specific chain, and sync local and global tokens.
  • This contract defines functions for executing responses, deposits, and signed operations, along with associated error handling and modifiers to ensure authorized execution.

• Rootbridgeagentexecutor.sol

  • This smart contract is related to cross-chain communication and token bridging within the ethereum block chain ecosystem. As a primary contract it serves as an executor for requests from remote chains, facilitating token settlement and executing transaction requests.
  • The functionality offered includes executing system requests, processing requests without deposits, and handling requests with both single and multiple asset deposits. This contract interfaces with a router contract and other necessary contracts to perform various operations based on the request parameters.

• corebranchrouter.sol

  • This smart contract logic for a core branch router within a blockchain that facilitates the integration of various chains, allowing for token management and interactions across these chains.

  • Functions are token management, enabling the addition of both global and local tokens to different chains. The addglobaltoken function allows the addition of a global token to a specific branch, while the addlocaltoken function enables the addition of a local token to the system.

  • The togglebranchbridgeagentfactory function handles the addition or removal of a bridge agent factory, and the _removebranchbridgeagent function allows the removal of a specific bridge agent.

  • It also supports port strategies, enabling the management of tokens and their associated strategies within the port. The _managestrategytoken function is used to manage strategy tokens, and the _manageportstrategy function is responsible for managing port strategies.

• rootbridgeagent.sol

  • The rootbridgeagent contract represents a root bridge agent that facilitates communication and asset transfers between different blockchain networks, allowing tokens to be bridged between them.
  • It defines structures and mappings to keep track of bridge agents, settlements, execution states, and other essential details. Notable features include handling deposits, managing settlements, estimating fees for transactions, and executing cross-chain calls.
  • The contract employs interfaces for communication with other contracts, such as ilayerzeroendpoint, irootbridgeagent, irootport, and other custom-defined interfaces.
  • rootbridgeagent contract comprises methods to bridge assets into the contract, execute settlements, manage tokens, and interact with layer zero for cross-chain communication.

• branchport.sol

  • branchport contract relates to bridge between blockchain networks, facilitating the transfer of assets and data between them.
  • The contracthave operations related to depositing, redeeming, settling transactions, and managing tokens. It allows users to make cross-chain calls, perform actions on another chain, and manage deposits.
  • The contract includes functions for depositing assets, managing deposits, and retrying transactions in case of failures. The ``lzreceiveandlzreceivenonblocking``` functions handle actions related to layer zero, likely involving interactions with another layer or network.

• basebranchrouter.sol

  • Basebranchrouter contract serves as a foundational component for a decentralized system that facilitates interoperability and asset transfers between different blockchain networks. The contract implements the ibranchrouter interface, which defines functions for handling deposits, settlements, and cross-chain interactions.
  • Key functionalities are related to initializing the contract with the local bridge agent's address, handling deposit-related actions, executing settlement actions, and ensuring proper authorization through modifiers. It defines functions to transfer and approve tokens within the contract, facilitating interactions with the underlying blockchain assets.
  • It lays the groundwork for enabling communication and asset transfers between different blockchains, providing a basis for decentralized finance (defi) applications and systems that require interoperability across various blockchain networks. It establishes essential mechanisms for securely managing deposits, executing cross-chain operations, and handling settlement procedures.

• rootport.sol

  • This contract facilitates the creation, management, and interaction of tokens across different chains within a blockchain network.
  • The contract key functionalities include setting up the local chain and essential addresses, managing virtual accounts associated with users, syncing bridge agents and their factories.
  • rootport main function is setting up core root and branch routers, managing the addition of new chains and ecosystem tokens and enabling the transfer of tokens between different chains.

Systemic risk

Systemic risk is based on potential issues and vulnerabilities identified that can create hurdle in smooth processing and working of the Ulysses protocol partially or as a whole.

• Communication and asset transfer

The core functionality of Ulysses involves cross-chain communication and asset transfers that have a significant risk in the secure and reliable working of these operations. If cross-chain communication are compromised, it could result in unauthorized asset transfers or disruptions in communication between different chains.

• Smart contract

Smart contracts can be prone to vulnerabilities like reentrancy attacks and denial of service attacks. Proper measurs should be taken for input validation, state changes, and handling external calls to prevent potential exploits due to activites between different chains.

• Governance

The presence of governance based functions in Corerootrouter.sol raises concerns about security and decentralization of governance. If governance mechanisms are not well-designed or become centralized, it could lead to biased decision-making or even control of the protocol by a small group of malicious actors.

• Token security:

Managing tokens across different chains opens the system to risks related to the integrity and security of the tokens. Malicious actors may attempt to manipulate tokens, create fake tokens, or exploit vulnerabilities in the token management mechanisms.

• Settlement

Deposits and settlements risks are related to failure or delays in processing deposits, which could result in financial losses for users. Errors or omission in settlement process could lead to incorrect transfers or loss of assets.

• Oracle risk

Depending on the implementation, reliance on oracles for cross-chain information could pose risks related to data accuracy, manipulation, or delays. Secure and reliable integration with multiple oracle is crucial to mitigate these risks.

Codebase Feedback

The overall code is well-structured with clear Natspec making it easy to understand many of the contract's functionality and purpose. The code quality also improves by making use of import statements for modularity, importing relevant functionalities from other contracts that enhances it modularity and reusability.

Usage of modifiers enhances reusability and reduces redundancy which is main context of workflow efficiency. Throughout the codebase logic for updating token debt and withdrawing tokens are repeatedly use in multiple functions like that of replenishReserves in the BranchPort.sol contract. This can be avoided in terms of extracting common functionality into a separate helper function to avoid redundancy.

Architecture Recommendation

The recommendation is made in area of improving efficient and secure interactions across various chains which lies in the efficient functioning of bridge agents. The improvement can be made in terms of enhancing function of all intermediaries contracts that must effectively act as neural pathways within a vast interconnected system ensuring seamless communication between different chains.

Branch bridge agents focus shold expand from just acting as a mediator of interactions with a router that monitors and analyse user deposits, managing asset transactions at the local branch port and engaging with virtualized token contracts. root bridge in the root chain needs to facilitate connection with all connected branch chains and respective bridge agents. Branch bridge should increase monitoring of pending settlements and maintain integration with other dapps within the root chain.

The main recommendation is made in area of connecting all the branch with each other rather than having a inter connection so that they can work independently if one of the branch stop working. This can be done through create a node structure like that exist in the EVM ecosystem that validates every transaction and resist any type of malicious activity.

The connecting of all branch with each other helps every users to initiate swap request and creating branch bridge agent orchestrates the process by locking the necessary balance and forwarding essential data to the other branch agent which does not require root agent verification as all branch are connected and not rely on a sole root agent. Authentication and validation of the request and deposit data occur instantly improving the working and efficiency of all bridge agent, followed by the actual execution of the swap by the router, ultimately resulting in the transfer of output tokens to the desired destination chain.

It is advised to further enhance the working of inter-chain communication infrastructure for optimising time processing efficiency related with every typr of transaction. The imporvement area exists in continuous monitoring and refining of the communication protocols to reduce latency and enhance response times. Exploring possibilities for parallel processing and load balancing can contribute to increased efficiency, ensuring smooth experience for users conducting transaction across different blockchain ecosystems.

Conclusion

The Ulysses protocol has developed an efficient and promising system that enables cross-chain communication and asset transfers. It should be improved with a well-defined governance model and risk management strategies to mitigate any potential issue.

• Note to Judge

  • The code base review was carried out for around 30 hours with finding only some gas optimisation.
  • Some issues were identified but they were already identified known thus no luck in finding any major issue.
  • This provides me consideration for improving my knowledge about cross-chain mechanism and how different protocols work. Improving my understanding of cross-chain working will surely benefit in identify and mitigating any vulnerability that may negatively impact protocol and its user.

Time spent:

30 hours