Security and Authentication

The Brava system implements a multi-layered security approach, combining role-based access control, time-locked operations, secure execution models, and comprehensive logging.

Role-Based Access Control (RBAC)

The system uses a hierarchical RBAC model implemented in the AdminVault contract, based on AccessControlDelayed, which extends OpenZeppelin's AccessControl library. The role system is designed with a clear hierarchy and separation of duties.

Role Hierarchy

OWNER_ROLE

The highest role in the hierarchy, reserved for emergencies and critical operations. This role:

• Has unrestricted ability to grant and revoke any role, including other OWNER_ROLEs

• Can bypass the delay system

• Should be extremely secure and rarely used

• Ideally only used in emergency situations

• Has ultimate control over all roles

ROLE_MANAGER_ROLE

The administrative role for day-to-day role management, managed by OWNER_ROLE. This role:

• Can propose, grant, and revoke any role except OWNER_ROLE

• All operations are subject to a time delay for security

• Should be secured appropriately

• Manages all operational roles through the delayed proposal system

Operational Roles

The system implements domain-specific roles for different operational aspects. Each domain (FEE, POOL, ACTION, TRANSACTION) follows a consistent pattern:

Proposer Roles

• {DOMAIN}_PROPOSER_ROLE: Can propose new configurations

• Typically secured behind multi-sig wallets

• Only proposals that have passed off-chain vetting should be submitted

• Examples: FEE_PROPOSER_ROLE, POOL_PROPOSER_ROLE, ACTION_PROPOSER_ROLE, TRANSACTION_PROPOSER_ROLE

Executor Roles

• {DOMAIN}_EXECUTOR_ROLE: Can execute proposed configurations

• Lower permission threshold than proposer roles

• Should be reasonably accessible for team members to execute approved changes

• Examples: FEE_EXECUTOR_ROLE, POOL_EXECUTOR_ROLE, ACTION_EXECUTOR_ROLE, TRANSACTION_EXECUTOR_ROLE

Canceler Roles

• {DOMAIN}_CANCELER_ROLE: Can cancel proposals

• Acts as a defense mechanism

• Treated as relatively less secure

• May be assigned to monitoring bots or team members

• Examples: FEE_CANCELER_ROLE, POOL_CANCELER_ROLE, ACTION_CANCELER_ROLE, TRANSACTION_CANCELER_ROLE

Disposer Roles

• {DOMAIN}_DISPOSER_ROLE: Can remove configurations

• Not frequently required

• Typically assigned to the same addresses as proposers

• Examples: POOL_DISPOSER_ROLE, ACTION_DISPOSER_ROLE, TRANSACTION_DISPOSER_ROLE

• Note: No FEE_DISPOSER_ROLE as we always maintain a fee configuration

Special Roles

• FEE_TAKER_ROLE: Specific role for triggering the fee-taking mechanism

Role Assignment Rules

1. Lower privileged roles may be assigned to addresses that hold higher privileged roles

2. A single address can hold multiple roles (e.g., a PROPOSER can also be an EXECUTOR or CANCELER)

3. Role assignments by ROLE_MANAGER_ROLE are subject to time-locked operations

4. All role changes are logged through the system's logging infrastructure

Time-Locked Role Management

The AccessControlDelayed contract implements a time-lock mechanism for role assignments:

1. Roles must first be proposed using proposeRole() or proposeRoles()

2. A mandatory delay period must pass before the role can be granted

3. Proposals can be cancelled during the delay period using cancelRoleProposal()

4. The delay period can be adjusted but reductions in delay are subject to additional safety constraints

Time-Locked Management Operations

Critical operations, such as adding new pools or actions, are subject to a time-lock mechanism. This delay period allows for community oversight and provides a window to detect and prevent potentially malicious changes.

Execution

The Brava system leverages the Safe (formerly Gnosis Safe) smart account system as a foundation for secure and flexible DeFi operations.

The system uses a sequence of delegatecalls from the user's Safe smart wallet to execute actions. This approach allows for:

• Composability: Multiple actions can be combined in a single transaction.

• Flexibility: Complex DeFi operations can be constructed from simpler actions.

• Gas Efficiency: Multiple operations are executed in one transaction, optimizing gas costs.

    /// @notice Called directly through user wallet to execute a sequence
    /// @dev This is the main entry point for Sequences executed manually
    /// @param _currSequence Sequence to be executed
    function executeSequence(Sequence calldata _currSequence) public payable {
        _executeActions(_currSequence);
    }

The SequenceExecutor contract acts as the entry point for executing sequences of actions. It interacts with the user's Safe wallet through delegate calls. This design ensures that all actions are executed within the context of the user's Safe wallet, maintaining security and ownership of assets.

Fee Management

The AdminVault contract defines a range for acceptable fee percentages. These values represent the minimum and maximum allowed fee basis points. The range can be adjusted by the (ROLE) using the setFeeRange function. The AdminVault keeps track of when fees were last taken for each pool. Fees are calculated based on the time passed since the last fee collection. The fee is a percentage of the total deposit, prorated for the time passed. Fees are not taken twice for the same time period. The system uses a basis point system for fee percentages. This allows for precise fee calculations (e.g., 100 basis points = 1%).