Platform: Code4rena
Start Date: 13/10/2023
Pot Size: $31,250 USDC
Total HM: 4
Participants: 51
Period: 7 days
Judge: 0xsomeone
Id: 295
League: ETH
Rank: 40/51
Findings: 1
Award: $14.47
🌟 Selected for report: 0
🚀 Solo Findings: 0
🌟 Selected for report: niroh
Also found by: 0xDetermination, 0xSmartContract, 0xbrett8571, 0xdice91, 0xweb3boy, Bauchibred, Bube, DadeKuma, JCK, K42, LinKenji, Myd, SAAJ, ZanyBonzy, albahaca, castle_chain, catellatech, digitizeworx, emerald7017, fouzantanveer, hunter_w3b, invitedtea, m4ttm, rahul, xiao
14.466 USDC - $14.47
List | Head | Details |
---|---|---|
a) | The approach I followed when reviewing the code | Stages in my code review and analysis |
b) | Analysis of the code base | What is unique? How are the existing patterns used? |
c) | Test analysis | Test scope of the project and quality of tests |
d) | Centralization risks | How was the risk of centralization handled in the project, what could be alternatives? |
e) | Systemic risks | Potential systemic risks in the project |
f) | Competition analysis | What are similar projects? |
g) | Security Approach of the Project | Audit approach of the Project |
h) | Other Audit Reports and Automated Findings | What are the previous Audit reports and their analysis |
Determine the scope of code audit: https://github.com/code-423n4/2023-10-brahma
Number | Stage | Details | Information |
---|---|---|---|
1 | Compile and Run Test | Installation | Test and installation structure is simple, cleanly designed |
2 | Architecture Review | https://docs.brahma.fi/product/brahma-console | Understand the functions of each module |
3 | Graphical Analysis | Graphical Analysis with vscode-solidity-auditor | Solidity language support and visual security auditor for Visual Studio Code |
4 | Test Suits | Tests | In this section, the scope and content of the tests of the project are analyzed. |
5 | Code Review | Scope | Top-down analysis of codes according to architectural design, IDE used: VsCode |
6 | What Is Brahma? | Brahma | |
7 | Infographic | Excalidraw | I made Visual drawings to understand the hard-to-understand mechanisms |
Number | Head | Test Details |
---|---|---|
1) | AddressProvider | Governance replacement, setting and obtaining addresses, and handling of various error situations |
2) | AddressProviderService | Other contracts can easily resolve the addresses of other services through the "AddressProvider" and include the necessary error handling and permission checking mechanisms. |
3) | ConsoleFallbackHandler | Handles signature verification and execution operations |
4) | ConsoleOpBuilder | This contract is designed to generate bytecode for multiple operations in order to perform those operations in the Brahma Console account |
5) | Constants | Provides a centralized place to manage and reuse constants for multiple contracts |
6) | ExecutorPlugin | Allows executors with module permissions to execute transactions and provides a mechanism to verify the legitimacy of execution requests |
7) | PolicyValidator | Verify policy signatures for secure contract transactions, ensuring that only verified signatures can execute transactions, thereby increasing security |
8) | SafeDeployer | Manage and create Brahma Console accounts and sub-accounts and ensure their initial setup |
9) | SafeEnabler | Provides a way to initialize and configure Gnosis Safe's modules and daemons, allowing certain checks to be bypassed during initialization for setup |
10) | SafeModerator | The "SafeModerator" contract acts as a guard for Safe accounts, validating transactions and ensuring they comply with policy requirements |
11) | SafeModeratorOverridable | Act as a guardian for Safe accounts, validating transactions and ensuring they comply with policy requirements. But unlike "SafeModerator", it allows rewriting by removing guards |
12) | ExecutorRegistry | It allows the owner of a sub-account to register and unregister executors and provides functionality to check if a specific executor has been registered as an executor for the sub-account |
13) | PolicyRegistry | The "PolicyRegistry" contract allows different roles to update an account's policy submission based on a set of conditions. |
14) | WalletRegistry | The "WalletRegistry" contract is used to manage and track the relationship between wallets and their subaccounts, as well as record which addresses are marked as wallets |
Users cannot provide their own main wallet to call the function of registering a sub-wallet, and can only be assigned by the project party. This is a centralization risk. https://github.com/code-423n4/2023-10-brahma/blob/main/contracts/src/core/registries/WalletRegistry.sol#L50C91-L50C91
In the same way, ExecutorRegistry.sol
and PolicyRegistry.sol
are also affected
Pay attention to version issues when deploying on some l2 chains https://docs.arbitrum.io/solidity-support
It must be ensured that the project party does not interfere with the operation of the project, so that it will be safer. The control of this type of smart contract project is more centralized, because the deployment of the contract and the setting of key parameters are usually performed by the owner or administrator of the project. The project owner or administrator has the authority to upgrade, maintain, and modify the contract.
Automated Findings: https://github.com/code-423n4/2023-10-brahma/blob/main/bot-report.md
Other Audit Reports: https://github.com/Brahma-fi/brahma-security/tree/master/audits
37 hours
37 hours
#0 - c4-pre-sort
2023-10-22T21:11:40Z
raymondfam marked the issue as sufficient quality report
#1 - c4-judge
2023-10-27T13:41:38Z
alex-ppg marked the issue as grade-b
#2 - alex-ppg
2023-10-27T13:41:41Z
Very brief, lists an incorrect competitor, and does not contain any statements that indicate an in-depth understanding of the Brahma system. Borderline B rating.