Bot System

Gearbox V3 features a sophisticated bot permission system that allows automated management of Credit Accounts. Bots can execute operations on behalf of account owners with granular, revocable permissions.

BotList Architecture

Components

Component
Description

BotListV3

Registry storing (bot, creditManager, creditAccount) -> permissions

IBot interface

Bots implement requiredPermissions() to declare needed permissions

CreditFacadeV3

Entry point for bot execution via botMulticall

Permission Storage

// BotListV3 storage
mapping(address bot =>
    mapping(address creditManager =>
        mapping(address creditAccount => uint192 permissions)
    )
) internal _permissions;

Permission Model

Permission Flags

Permissions are stored as a uint192 bitmask:

Permission
Value
Operation

ADD_COLLATERAL_PERMISSION

1 << 0

Add funds to account

INCREASE_DEBT_PERMISSION

1 << 1

Borrow more from pool

DECREASE_DEBT_PERMISSION

1 << 2

Repay debt

WITHDRAW_COLLATERAL_PERMISSION

1 << 5

Withdraw assets

UPDATE_QUOTA_PERMISSION

1 << 6

Change token quotas

SET_BOT_PERMISSIONS_PERMISSION

1 << 8

Manage other bots

EXTERNAL_CALLS_PERMISSION

1 << 16

Execute adapter calls

ALL_PERMISSIONS Constant

Note: SET_BOT_PERMISSIONS_PERMISSION is excluded from ALL_PERMISSIONS - bots cannot grant permissions to other bots.


Granting Permissions

Setting Bot Permissions

Account owners grant permissions through a multicall:

Process

  1. Owner calls setBotPermissions(botAddress, permissions) in multicall

  2. BotListV3 validates permissions match bot's requiredPermissions()

  3. Max 5 active bots per account (MAX_SANE_ACTIVE_BOTS)

  4. Revoke by setting permissions = 0

  5. eraseAllBotPermissions() clears all (called automatically on account close)

BOT_PERMISSIONS_SET_FLAG

This optimization flag indicates whether an account has any authorized bots:

  • Set true when first bot is added

  • Set false when last bot is removed

  • Checked in botMulticall before querying BotListV3


Bot Operations

botMulticall Execution

Execution Flow

  1. Status Check: Query BotListV3 for permissions & forbidden status

  2. Flag Check: Verify BOT_PERMISSIONS_SET_FLAG is set

  3. Granular Authorization: Each call checked against permission bitmask

  4. Solvency Guard: Always fullCollateralCheck after all calls

  5. Revert: If HF < 1 after execution

Permission Enforcement

Used throughout multicall processing:


Safety Model

Security Properties

Property
Mechanism

Isolation

Permissions are account-specific (not global)

Immutability

Bots are typically immutable contracts

DAO Override

Global "forbid" list in BotListV3

Atomic Safety

Post-execution collateral check prevents fund theft

No Bad Debt

Bots cannot leave protocol with losses

Forbidden Bot List

The DAO can globally forbid malicious bots:

A forbidden bot cannot execute on any account, regardless of individual permissions.

Collateral Check Protection

Even with all permissions, a bot cannot:

  • Leave account with HF < 1

  • Increase forbidden token balances

  • Bypass debt limits

The final collateral check after botMulticall ensures account remains healthy.


Bot Development

Implementing IBot Interface

Bots should declare minimum permissions needed:

Common Bot Patterns

Bot Type
Typical Permissions

Rebalance Bot

UPDATE_QUOTA_PERMISSION, EXTERNAL_CALLS_PERMISSION

Collateral Manager

ADD_COLLATERAL_PERMISSION, WITHDRAW_COLLATERAL_PERMISSION

Debt Manager

INCREASE_DEBT_PERMISSION, DECREASE_DEBT_PERMISSION

Partial Liquidation Bot

DECREASE_DEBT_PERMISSION, EXTERNAL_CALLS_PERMISSION

chevron-rightSourceshashtag

Last updated