Security-First Design of Brahma

Based on Safe

Brahma is an on-chain custody and execution layer based on Safe. This is a strategic decision to leverage the industry's highest security standard and the most widespread multi-sig.

Using Safe as our custody stack also fits within our main value proposition: improving multi-sig operations' efficiency. Console = Multi-sig on Steroids. Over 6 million Safe have been created, securing $89b.

Institutional and retail investors are wary of new tools or changing their routines and habits regarding security. By leveraging Safe, using Console is frictionless as users don’t need to create any extra wallet or operate in a separate environment: using Safe guarantees that Brahma is using the best standard in terms of security. 

Using Console, users always have complete self-custody, as Brahma never has access to funds.

Transaction Simulator

Not all users have the technical understanding to read transactions before executing them. Scams involving malicious contracts and wrong addresses steal hundreds of millions of dollars every year. How can users know that the contract they are executing is correct?

To avoid unpleasant surprises, one of the best practices in the industry is to leverage a transaction simulator. Nowadays, we can find transaction simulators in most wallets.

In Brahma, before you execute a transaction, you can check a Tenderly Simulation to observe the changes in the balance. If the simulation is what is expected, users can then proceed to execute the transaction. Simulating transactions ensures an extra security step before the execution.

Sub-Account Policies

Delegating operations within protocols or DAOs using a multi-sig still suffers from several pain points, including implementing trustless delegation mechanisms without introducing a trust component.

Let’s use the example of governance. Executing governance operations from a multi-sig can take time and effort, especially regarding coordination to sign transactions. 

Imagine voting for 100 proposals. To avoid this problem, some protocols delegate their governance and voting to one of their team members using a classic EOA wallet.

However, regardless of the trusted relationship, this process is imperfect and opens up the protocol to risk:

• What happens if the EOA account gets hacked? The security features of EOA wallets are much lower compared to Safe.

• What happens if the team members go rogue? He could just send the money somewhere else and blame it on a hack. “Oh damn! My $ARB delegation was just hacked”.

  
  

To improve the way protocols and DAOs can participate in on-chain governance securely, Brahma allows them to create Sub-Accounts.

Sub-Accounts are Safes hierarchically controlled by the main Console (which is controlled by the original multi-sig used by the DAO or protocol). 

In this way, DAOs and protocols could assign ownership of the Sub-Account to one of their team members, with a lower threshold execution to avoid the coordination problem of having to sign with the threshold of the main Safe for every vote.

Console differs from sending the delegation to an EOA account because it allows the creation of Policies, which define the interactions each Sub-Account can carry out in advance.

For instance, in the case of a voting sub-account, a DAO or protocol would restrict this specific Sub-Account to only sending transactions with 0 value. Voting transactions are simple signatures and don’t involve any value transfer. This framework would apply to any transaction carried out by the Sub-Account: if the Sub-Account operators tried to scam you and withdraw the money, the transaction would fail. 

Policies are customizable at the protocol, asset, and timeframe level, ensuring complete flexibility and programmability. Any Sub-Account transaction violating the Policies would automatically fail. By using Brahma, DAOs and protocols could achieve trustless delegation.