Brahma - SAAJ's results

Introduction

This analysis summarise the Brahma codebase by focusing on areas that benefits in ensuring proper working of users wallets in a more automatic way with having secure custody of wallets.

Brahma Console in its V2 have developed a unique value proposition that enables users to automate their DeFi interactions while retaining full custody of their funds. This not only adds an extra layer of security with granting users more control while navigating the complex DeFi landscape.

Mechanism Review

Brahma Console v2 key components are based on SubAccount, Operators and Executor.

SubAccount

SubAccount are linked to Gnosis Safes operated by delegatee accounts known as Operators. The Console Account owns these sub-accounts and configures them by enabling Console Account as a safe module and SafeModerator as a safeguard. Operators are granted specific transaction execution rights, which are enabled by the Console Account (Owner).

Operator

Operators are accounts that have been delegated ownership rights for specific sub-accounts, with their capabilities restricted by SafeModerator. These rights can be updated and managed by the ConsoleAccount, offering a flexible and adaptive approach to control and security.

Executor

Executors are accounts that have been authorized to make module transactions on a subAccount through ExecutorPlugin. ExecutorPlugin must be enabled as a module on the subAccount for this purpose. This feature enables efficient and controlled execution of transactions within the sub-account structure.

Brahma Console main feature is introduced with the SafeSub-accounts, which are designed to mitigate risks associated with DeFi protocols.

Brahma Console v2 aims to provide a seamless DeFi experience by offering various functionalities and integrations, including:

• DCA (Dollar-Cost Averaging) automation
• Auto-compound strategies
• Position management
• Advanced order types
• ETH staking (upcoming feature)

The Console also offers features like WalletConnect, Address Book, Access Control, and Custom Sub-Accounts (upcoming feature) to enhance user control and interaction with DeFi protocols.

Codebase Analysis

• TypeHashHelper.sol:

TypeHashHelper is a library contract that plays a critical role in constructing struct hashes that are fundamental for the generation of EIP712 digests.

The TypeHashHelper library simplifies the process of struct hash creation, making it easier for developers to generate EIP712 digests. This, in turn, enhances the security and trustworthiness of DeFi transactions, as it ensures that data is structured and signed correctly.

• SafeHelper.sol:

The SafeHelper library complements the TypeHashHelper by providing essential functions for interactions with the "Safe." SafeHelper assists in executing transactions, generating calldata (data used in Ethereum transactions), acquiring the necessary storage slots, and parsing data.

SafeHelper library simplifies complex operations related to Safe, making it more accessible and efficient for developers. It's especially valuable in DeFi applications, where precise and secure interactions with smart contracts are paramount.

• TransactionValidator.sol:

The TransactionValidator contract is a vital component that ensures the security and integrity of transactions in the system. It provides hooks for validating different types of transactions, both for the primary "Console" and for "SubAccount" structures.

The validations include policy and state compliance checks, which occur before and after transactions. The involvement of guards, such as "SafeModerator" and "SafeModeratorOverridable," adds an additional layer of security and governance, ensuring that transactions meet predefined rules and policies.

The TransactionValidator is responsible for validating module executions on SubAccount through "ExecutorPlugin." This comprehensive approach to transaction validation is crucial in DeFi, where the accuracy and safety of every operation are of utmost importance.

• SafeModeratorOverridable.sol:

This plays a crucial role in transaction validation, ensuring that transactions comply with predefined policies using the TransactionValidator contract. It conducts these checks both before and after the execution of transactions.

SafeModeratorOverridable enhances the security and reliability of transactions associated with Console accounts, thereby safeguarding users' assets and upholding the integrity of the platform.

• SafeEnabler.sol

The SafeEnabler contract is responsible for providing the bytecode required to enable modules and guards on a Safe, a smart contract wallet.

During the initialization process, it utilizes DELEGATECALL by the safe itself to enable these modules and guards. Notably, it bypasses the selfAuthorized check on Safe's ModuleManager and GuardManager, a feature that contributes to efficient management of module and guard states.

• SafeModerator.sol:

The SafeModerator contract is another vital component of the DeFi system, primarily serving as a safeguard for transactions executed on Console sub-accounts.

The core responsibility lies in ensuring that these transactions conform to predefined policies, and it achieves this by validating them with the TransactionValidator contract.

SafeModerator also conducts checks before and after transaction execution to guarantee policy adherence.

Robust transaction validation mechanism adds an extra layer of security and policy enforcement to sub-accounts, making them integral to the DeFi platform's governance and security infrastructure.

• Constants.sol:

Constants are essential for maintaining consistency and coherence in the codebase.

They provide a single source of truth for values that need to be referenced in various parts of the system.

Centralizing values in the Constants contract, developers can easily update and maintain them, which is crucial for ensuring that the system functions smoothly and securely.

• ConsoleFallbackHandler.sol:

The ConsoleFallbackHandler contract serves as a fallback handler for a smart contract system referred to as "Safe."

It ensures that transactions and functions previously supported by the CompatibilityFallbackHandler in version 1.3.0 remain intact.

The critical distinction lies in the added functionality for policy validation. ConsoleAccounts and SubAccounts within the system are required to adhere to certain policy compliance standards.

The contract performs additional checks on transaction signatures, ensuring that they meet the policy requirements before execution.

• AddressProvider.sol:

The AddressProvider contract plays a pivotal role in managing and updating the addresses of authorized contracts and registries within the system.

This means that various components of the system can refer to the AddressProvider to obtain the most up-to-date information on where different services and contracts are located.

this contract enforces governance control, ensuring that only authorized entities can modify or update these addresses.

It acts as a safeguard to prevent unauthorized changes that could compromise the integrity of the system.

It requires that addresses adhere to a specific interface, namely, the IAddressProviderService, ensuring consistency and compatibility within the system

• PolicyValidator.sol:

The PolicyValidator contract is responsible for validating validator signatures against account policies. I

This contract performs critical checks on transaction signatures and their associated timestamps. It ensures that these signatures are not only valid but also adhere to the policies defined for the accounts in question.

The purpose of this contract is to prevent unauthorized or non-compliant transactions from being executed, thereby maintaining the security and policy compliance of the system.

• PolicyRegistry.sol:

The PolicyRegistry serves as a registry contract within the decentralized system. Its primary purpose is to facilitate the registration of policy commits, which are essentially agreements or commitments related to specific wallets and sub-accounts.

Authorized entities, including the Safe deployer and registered wallets, can set and update these policy commitments for specific accounts.

PolicyRegistry acts as a ledger for these commitments, ensuring that they are recorded and maintained in a transparent and secure manner.

It provides a mechanism for maintaining policies that dictate the behavior and permissions associated with different accounts, enhancing the overall security and governance of the decentralized system.

• ExecutorRegistry.sol:

The ExecutorRegistry is another registry contract, but its role is distinct. It focuses on the registration and removal of executor addresses associated with sub-accounts. Executors are entities with the authority to execute module transactions on Console Accounts via the ExecutorPlugin contract

One of its key features is ensuring that only the owner of a sub-account, as determined by the "WalletRegistry," can register or deregister executors.

This feature maintains strict control over the management of executors, preventing unauthorized entities from taking actions that could compromise the integrity of the system.

• WalletRegistry.sol:

The WalletRegistry serves as a central registry for wallets and their associated sub-accounts. This contract provides various functions that allow for the registration of wallets and sub-accounts within the system.

It facilitates the querying of sub-accounts associated with a wallet and checks ownership relationships between wallets and sub-accounts

The WalletRegistry is responsible for maintaining a structured and organized record of wallets and their sub-accounts, allowing for easy management and retrieval of information.

• AddressProviderService:

The AddressProviderService contract is an abstract foundation that underpins many core contracts within the Gnosis ecosystem. Its primary role is to provide an AddressProvider as a fundamental dependency to other inheriting contracts.

Mechanism allows multiple contracts to interact seamlessly while ensuring consistency in the addresses they rely on.

AddressProviderService equips inheriting contracts with essential constants and helper functions that simplify the process of querying and interacting with the AddressProvider. I

• SafeDeployer:

The SafeDeployer contract is a pivotal piece of the Gnosis ecosystem responsible for facilitating the deployment of Gnosis Safe accounts while configuring them as console accounts.

Console accounts are integral to the Gnosis Safe setup as they provide the foundation for secure and decentralized management of assets. SafeDeployer allows users to create console accounts, offering optional policy commitments, and then registers them.

It supports the creation of sub-accounts with policy commitments, enabling users to customize their Safe accounts as per their requirements. The SafeDeployer contract streamlines the process of account creation and registration, ensuring that they are seamlessly integrated into the Gnosis ecosystem.

• ExecutorPlugin:

The ExecutorPlugin contract, acting as a safe module, plays a crucial role in facilitating the execution of requests on console accounts with specific permissions.

This contract is essential for managing the execution of transactions within the Gnosis ecosystem securely. Executors can raise requests, which are then executed as module transactions on console accounts.

ExecutorPlugin validates the executor's signature, checks the executor's validity for the account, and verifies the policy for execution using the TransactionValidator contract.

ExecutorPlugin executes the transaction and handles the return data that ensures that transactions on console accounts are executed securely and in accordance with predefined policies, safeguarding the assets and operations within the Gnosis ecosystem.

Architecture recommendation

The architecture presented in the provided code is a comprehensive and well-structured framework for managing and securing transactions in the context of the Gnosis Safe platform.

There are some areas where improvements and recommendations is made to enhance efficiency and security of the overall protocol.

• Error Handling and Logging:

  • Implementing comprehensive error handling and logging mechanisms is essential for monitoring in case of issues, making it easier to identify and resolve problems promptly.

  • Detailed logs can also provide valuable insights for security audits.

• Access Control:

  • Access control is not implemented in a comprehensive manner that ensures only authorized entities can make changes to the system is crucial.

  • Access control mechanisms should be thoroughly reviewed and improved if necessary to prevent unauthorized modifications.

• Upgradeability:

  • Implementing upgradability mechanisms can allow for smoother transitions when introducing new features or improving security.

  • Upgradability mechanisms should be designed and tested with utmost care to avoid potential vulnerabilities.

• Consistent Constants:

  • Ensuring consistency and coherence in the values defined in constant contract is necessary.

  • This should be maintained and monitored in a rigorous manner to avoid potential inconsistencies that could lead to issues in the system.

Potential Vulnerabilities

The potential vulnerability identified are summarised as below:

• Policy Compliance:

  • The contracts rely heavily on EIP compliance. A potential vulnerability could arise if the eip compliance not well-defined or are not enforced rigorously.

  • Ensuring EIP compliance are clear, well-audited, and correctly implemented is crucial.

• Access Control:

  • Unauthorized access to critical functions or data within the contracts can be a significant vulnerability.

  • Implementing robust access control mechanisms to restrict access to authorized entities is vital.

• External Calls:

  • Contracts that interact with other contracts or external data sources should handle these interactions carefully.
  • Failing to validate inputs or outputs of external calls can lead to vulnerabilities, including reentrancy attacks.

• DelegateCall:

  • SafeEnabler contract employs DELEGATECALL, which can be risky. Proper checks and security measures to ensure that the code being executed via DELEGATECALL is secure and doesn't compromise the Safe's security.

• Fallback Functions:

  • The ConsoleFallbackHandler acts as a fallback handler, and any vulnerabilities or inconsistencies in its implementation could be exploited.

• Timestamp Dependence:

  • Contracts that depend on timestamps for validation can be vulnerable to manipulation.
  • It's essential to mitigate timestamps vulnerabilities by using effective checks through by syncing with both on-chain and off-chain data.

Conclusion

I spent around 50 hours reviewing the project that helps in identifying 02 medium and 03 low risk issues that can impact the project working flow.

One of the medium finding is related to using external library of EnumerableSet by OZ's that can lead to DOS.

The other finding is linked to payable use for address that can result in possible loss of fund for user a user as there is no means for withdrawing them.

Issues of low risk are found which are reported as a separate report and will ensure better code quality which is necessary for any protocol if implemented as recommended.

Time spent:

50 hours