The GP Safe consists of a core Safe account with three main modules attached:
  1. Core Safe Account: The base Safe that holds funds and manages ownership
  2. Delay Module: Controls transaction timing and provides security delays
  3. Roles Module: Manages spending permissions and allowance limits
  4. Bouncer Module: Handles account access validation and security

​
GP Safe Setup Process

To understand how a GP Safe differs from a standard Safe, let’s examine the account setup flow that transforms a basic 1/1 Safe into a fully configured GP Safe Account:
1

Safe Configuration

  • Ownership Transfer: Swaps the Safe owner to an inaccessible address (0x0000000000000000000000000000000000000002)
  • Module Enablement: Enables both the Roles and Delay modules on the Safe
2

Delay Module Setup

  • Deployment: Creates a new Delay module instance for the account
  • Cooldown Configuration: Sets the transaction delay period (typically 3 minutes)
  • Expiration Setting: Configures how long queued transactions remain valid
  • Owner Access: Grants the initial Safe owner (the owner before the ownership transfer) access to the delay module
3

Roles Module Setup

  • Deployment: Creates a new Roles module instance for the account
  • Allowance Configuration: Sets up spending limits with:
    • Initial balance amount
    • Maximum balance cap
    • Refill amount per period
    • Time period for refills
  • Role Assignment: Grants spending permissions to designated spender addresses
  • Target Scoping: Restricts spending to specific token contracts
  • Function Scoping: Limits operations to ERC20 transfer functions only
  • Ownership Transfer: Transfers control to the Bouncer module
4

Bouncer Module

  • Deployment: Creates the final security layer
  • Access Control: Manages who can interact with the account

​
Spending Control Flow

The spending process follows this pattern:
  1. Spender Request: A designated spender requests a transaction
  2. Allowance Check: The Roles module verifies spending limits
  3. Delay Enforcement: If limits allow, the transaction enters the delay queue
  4. Time Delay: The transaction waits for the configured cooldown period
  5. Execution: After the delay, the transaction can be executed
  6. Balance Update: The allowance balance is updated accordingly