Brahma - LinKenji's results

Brahma Console is a custody and DeFi execution environment.

General Information

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

Brahma

Findings Distribution

Researcher Performance

Rank: 44/51

Findings: 1

Award: $14.47

Analysis:
grade-b

🌟 Selected for report: 0

🚀 Solo Findings: 0

Awards

14.466 USDC - $14.47

Labels

analysis-advanced
grade-b
sufficient quality report
A-11

External Links

Overview

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.

Architecture

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 -

    • WalletRegistry: Maps wallet and subaccount addresses
    • PolicyRegistry: Maps policy commit hashes to accounts
    • ExecutorRegistry: Maps approved executors to subaccounts
  • Services: Key logical components enabling core functionality. These include -

    • SafeDeployer: Deploys new Console accounts and subaccounts
    • TransactionValidator: Validates transactions pre and post execution
    • PolicyValidator: Validates policy signatures
    • ExecutorPlugin: Enables execution via approved third party executors
  • Libraries: Helpful utilities like -

    • SafeHelper: Interacting with Gnosis safes
    • TypeHashHelper: Builds EIP712 digests
  • Constants: Common constants used across contracts

  • Interfaces: Interface definitions for interacting with external protocols

Key Mechanisms

Wallet & Subaccount Management

  • 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.

Transaction Validation

  • All transactions on Brahma console accounts and subaccounts must pass the policy validation checks enforced by the SafeModerator guard contract.
  • The PolicyValidator contract verifiessignatures against transaction digests and registered policy commits to authorize transactions.
  • TransactionValidator orchestrates overall transaction validation, both pre and post execution.

Executor Plugin

  • ExecutorPlugin enables execution on subaccounts via pre-approved executors rather than direct Safe owners.
  • ExecutorRegistry maintains the mapping of approved executors for each subaccount.

Overrides for Console Accounts

  • Console accounts have a special SafeModeratorOverridable guard that allows overriding policies by removing the guard or fallback handler. This provides root access.

Code Quality

  • The code generally follows best practices like separation of concerns, use of libraries, interface-based design, etc.
  • Critical security mechanisms like access control and transaction validation are well implemented.
  • Heavy reuse of battle-tested dependencies like OpenZeppelin contracts.
  • Comprehensive unit test coverage for core functionality.

Risk Analysis

Centralization Risks

  • 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.

Systemic Risks

  • 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.

Recommendations

  • 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.

Time spent:

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

AuditHub

A portfolio for auditors, a security profile for protocols, a hub for web3 security.

Built bymalatrax © 2024

Auditors

Browse

Contests

Browse

Get in touch

ContactTwitter