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: 44/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
The Brahma console codebase provides an institutional-grade custody and DeFi execution environment. It aims to enable secure and compliant access to decentralized finance for entities like traditional financial institutions.
The core architecture consists of the following components:
AddressProvider: Single source of truth for resolving addresses of core components and external contracts. It maps registry and authorized contract addresses to a unique key.
Registries: Maintain mappings of key data like wallet addresses, policies, executors. These include -
Services: Key logical components enabling core functionality. These include -
Libraries: Helpful utilities like -
Constants: Common constants used across contracts
Interfaces: Interface definitions for interacting with external protocols
WalletRegistry
tracks mapping of top-level wallets and their associated subaccounts.SafeDeployer
handles deployment of console accounts and subaccounts via createProxyWithNonce
. It initializes them with required modules and access control policies.SafeModerator
guard contract.PolicyValidator
contract verifiessignatures against transaction digests and registered policy commits to authorize transactions.TransactionValidator
orchestrates overall transaction validation, both pre and post execution.ExecutorPlugin
enables execution on subaccounts via pre-approved executors rather than direct Safe owners.ExecutorRegistry
maintains the mapping of approved executors for each subaccount.SafeModeratorOverridable
guard that allows overriding policies by removing the guard or fallback handler. This provides root access.Reliance on a single AddressProvider
as the source of truth for contract addresses is a central point of failure. Compromise of the AddressProvider
would allow swapping any authorized address.
The PolicyRegistry
controls binding of policies to accounts. Compromise of the registry contract would allow changing policies arbitrarily.
Bug in PolicyValidator
implementation could lead to unauthorized transactions being allowed on all accounts.
Compromise of the TRUSTED_VALIDATOR
key controlling policy signatures poses a systemic risk. It could lead to loss of funds on any subaccount.
Use a DAO-governed AddressProvider
contract to mitigate centralization risks.
Adopt a decentralized multi-sig based TRUSTED_VALIDATOR
setup.
Conduct comprehensive audits focused on transaction validation and policy authorization logic.
Implement additional post-execution checks in the guard like monitoring critical module changes.
Consider mechanisms like liquid staking or slashing to align validator incentives with system security.
Careful implementation of the validation and policy logic is critical for security. Adopting decentralized and trust-minimized mechanisms can help reduce systemic risks. Comprehensive audits are highly recommended before large value deposits.
5 hours
#0 - c4-pre-sort
2023-10-22T21:14:11Z
raymondfam marked the issue as sufficient quality report
#1 - alex-ppg
2023-10-27T13:33:30Z
The analysis is correct and decent with some minor incorrect statements, overall quality is B.
#2 - c4-judge
2023-10-27T13:33:35Z
alex-ppg marked the issue as grade-b