Counterparty Risk

Introduction

Brahma is a comprehensive execution interface designed for sophisticated interaction with DeFi ecosystems across Ethereum and other EVM-compatible chains. It represents a leap forward in DeFi management and execution, particularly for institutions, DAOs, and advanced users seeking a blend of security, efficiency, and autonomy in their transactions.

Central to its value proposition is the full self-custodial nature of your account, ensuring that users retain complete control over their assets in their Safe Smart Wallets without compromising on functionality or security.

It introduces a multi-layered structure that includes Main Accounts, Sub-Accounts, and detailed transaction policies, all aimed at providing users with unparalleled control and flexibility over their DeFi operations.

Key Features:

  • Sub-Accounts: Users can create Sub-Accounts under the Main Account, enabling risk segregation and operational delegation. Each Sub-Account can be configured with unique roles, permissions, and transaction policies.

  • Transaction Policies: Detailed policies can be set to govern transactions, including restrictions on asset transfers to certain addresses or protocols, enhancing security and compliance.

  • Automation: Your account supports automated routines for recurring transactions and risk management, allowing users to set up automatic responses to specific market events.

  • Security: Leveraging Safe's account abstraction and security features, Brahma ensures that users have a robust layer of protection for their assets, maintaining self-custody at all times.

Counterparty Risks and Mitigation

Counterparty risks in DeFi operations often stem from reliance on external entities for asset custody or access to keys/recovery execution. Brahma mitigates these risks through its design and architecture, with continuous user control and redundant access and execution, with self-custody.

Self-Custody

Users onboard to Brahma by setting up or importing a Safe wallet, over which they have sole ownership and signature rights. This approach ensures that users' assets remain under their control, protected by Safe's unmodified open source contracts, and not susceptible to counterparty risks associated with traditional custody solutions.

  • The created imported Safe is unmodified by Brahma and doesn’t run any custom code. Users can access it at any time on alternative frontends like Safe’s, or directly using contract interfaces.

  • Created SubAccounts are also individual Safes, owned on-chain by the Main Safe, and by derivation by the Main Safe owners. Sub-Accounts have a custom Transaction Guard installed on it on-chain, which can be removed anytime by the user with an on-chain transaction from the Safe UI/contracts (we have a decentralised IPFS-based tool to generate the required call-data to make it simple).

Decentralized Execution

Brahma's execution framework has no counterparty risk. Your account employs a relayer to route transactions, enhancing execution without ever taking custody of assets. Users can execute transactions across multiple accounts, leveraging auto-gas and RPC selection, with optimised handling to navigate gas fees and network congestion effectively.

Brahma never has co-signing or signing rights on any user's Account Safe or SubAccount. Brahma doesn’t generate or store user keys. Any transaction requires the Safe owners signature. Brahma simply provides the best UX for execution including batching, routing, relaying and automations.

Execution Flow:

  • The user connects any EOA that owns a Safe smart contract wallet, which can be created or imported on Brahma.

  • The user can connect to any dApp, or utilize an in-app feature, like in-app swap. When the user defines what action to execute, the transaction is shown and simulated with Tenderly, showing token changes, and estimated fee to the user. The user can then sign with their EOA wallet owning that Safe. The calldata they see and sign is to directly perform an action on the end protocol (Uniswap, AAVE, 1inch, with the relayer handling the gas payment and relaying on their behalf).

  • The "Safe wallet open source contract" performs a check on any transaction being executed from the wallet, ensuring the integrity and authorization of the transaction.

  • If the user doesn’t sign calldata for an execution, Brahma and its relayer cannot perform any operation on behalf of the user

Transaction Relaying

  • After a user's signatures are collected and meet the predefined threshold and verified by the Safe contract, the transaction is picked up by the Brahma Relayer for relaying with the most accurate parameters for efficient execution.

  • The transaction relaying process involves a Gas estimation, followed by the selection of an RPC ensuring the transaction is optimised for execution speed and quality.

  • The relayer, at its own expense, posts the transaction to the blockchain and collects the corresponding gas fee, in the same transaction.

Automated Execution

Last updated