Brahma Docs
Ask or search…


Policies stand as one of the most powerful and functional features, screening every transaction conducted via Console Safes with extensive granularity, thus serving as the core policy layer within Console. As a Console owner, you control end-to-end asset policies, thresholds, and functions, both before and post-transaction initiation.
Policies act as the guiding mechanism for managing the flow of transactions initiated on your Console. It's a customisable framework that empowers users to define the conditions under which operators can execute transactions, allowing you to specify these conditions based on a multitude of parameters, such as the asset type, timing, utilised protocols, and the intended operators.
Sub-Accounts introduce varying levels of policy depth during creation. Global Policy, the highest grade of policy overlooking all sub-policies restricts contract interactions, creating a controlled "Walled Garden". Transactions are limited to a specific set of recipients, asset policy governs token thresholds and beyond. The Interaction Policy regulates system interactions by whitelisting approved protocols and custom contracts
Initially, each Sub-Account is set to an open state, allowing transactions freely. To implement a policy, owners must activate the 'walled garden' feature, which limits transactions to pre-approved recipients/contracts, effectively sealing the account from any outside transfers, this happens by enforcing the Safe Guard on the deployment of every Sub-Account that ensures on-chain checks With this in place, users can then proceed to fine-tune transactional and protocol-specific rules within the Policy Authenticator.
Once a policy is signed on a Sub-Account, it starts being enforced on each transaction, irrespective of its origin — be it directly through the Console UI or executed through the Console API. When an operator initiates a transaction, the policies in your Access Control it is allowed to be added to the Transaction builder, or otherwise it will be blocked accordingly.
While adding a transaction to be signed, the Policy Manager verifies the transaction against the policy rules defined by the owners and the policy authenticator appends an attestation unique to the transaction hash with the nonce, policy commit, and time stamp. This process establishes unalterable on-chain assurances by the Safe guard that verifies the attestation reducing potential for any malicious actions should the Policy Manager's integrity be breached.
Some practical use cases illustrating the versatility of this system:
  1. 1.
    A DAO can empower an external trader to oversee their native token within a Uniswap pool, enabling market-making on decentralised exchanges. They can limit the trader's operations to pool tokens and prohibit transfers to external owned accounts (EOAs).
  2. 2.
    An experienced user may grant an operator permission to conduct transactions on GMX, but only with select pairs. They can also impose a daily trading volume cap and restrict withdrawals.
  3. 3.
    A DAO can add an external accountant or internal finance team member as an operator to a Sub-Account, and make it a 'walled garden' by setting a whitelist of recipient wallets, and setting monthly payment budgets, eliminating the need for manual oversight and allowing quick operations with lower signature thresholds in the Sub-Account.
  4. 4.
    An investment fund can utilise Policies in combination with the Console API to pre-set allowed protocols, amounts, and operations to be conducted. They can then integrate the Console API with their existing backend systems to trigger automated execution within the boundaries defined in the policy (e.g. triggering the withdrawal from a protocol).
  5. 5.
    Developers can curate applications designed to optimise yield farming across various protocols, with users authorising a list of protocols, contracts, tokens, and amounts that can be used directly from their Console.