Policies

Policies stand as one of the most powerful and functional features, screening every transaction conducted via Console Sub-Accounts 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.

Policy creation and management - tutorial

Policies act as the guiding mechanism for managing the flow of transactions initiated on your Console Sub-Accounts. 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.

An on-chain Safe Transaction Guard called Safe Moderator by Brahma is added to Sub-Accounts in their creation transaction. This Guard, Console Guard complies with Safe's transaction validation specs, and can be removed at any time by the user with a module transaction [see ]. The Console Guard instates pre-and-post transaction checks to every transaction that is built/sent in that SubAccount.

The checks are performed off-chain by the Brahma Policy Manager to be able to decode and simulate complex transaction states, as well as ensuring privacy of the Policy parameters set by the users. The policy parameters set by the Console owners with the policy creation transaction are stored off-chain, and its commit hash is posted on-chain for auditability.

Console Policies can only perform checks against the owner-set parameters and act as a semaphore, but don't have any permission or key to be able to sign transactions on users' behalf.

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" limiting asset transfers to a specific set of recipients and assets with timeframes.

• Protocol Policy regulates contract interactions by whitelisting approved protocols and contracts, with specific input tokens and amounts to be used on each contract.

Initially, each Sub-Account is set to an open state, allowing transactions freely. To implement a policy, owners must activate the Global Policy, which limits transactions to pre-approved recipients/contracts, effectively sealing the account from any outside transfers. This happens by enforcing the Console 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 Policy Manager in your Access Control simulates and verifies if the transaction output complies with the owner-set policy.

While adding a transaction to be signed, the Policy Manager verifies the transaction against the policy rules defined by the owners, and 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. A DAO can empower an external trader to oversee their native token within an AMM 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. 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. 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. 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. 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.