Skip to main content

Strategy Development Guide

Configuration Guide

The Injective Trader uses a YAML configuration file to define behavior, components, and strategy parameters. The most important configuration sections to focus on are:
  • LogLevel
  • Network and MarketTickers in the Initializer under the Components section
  • Strategies section
Here’s a detailed breakdown of the configuration structure:

Top-Level Parameters

Components Section

The Components section configures framework components:
Note: Most users only need to take care of Network and include all the markets that they want to listen to in MarketTickers. They won’t need to modify these advanced component settings. The default values work well for most use cases.

Strategies Section

The Strategies section defines each trading strategy:
Required Strategy Parameters:
  • Class: Must exactly match your Python class name
  • MarketIds: List of market IDs to trade on in this strategy (use hex format)
  • AccountAddresses: List of accounts to use for trading in this strategy
  • TradingAccount: Account used for order execution (must be in AccountAddresses) [See more details on Trading Mode Configuration ]
Recommended Parameters:
  • CIDPrefix: Prefix for client order IDs (helps identify your orders)
  • Name: Human-readable name for logs and monitoring
Custom Parameters:
  • You can add any custom parameters your strategy needs
  • All parameters under your strategy name will be available in self.config
  • Group related parameters under the Parameters section for clarity

Trading Mode Configuration

The framework supports two trading modes:

Direct Execution Mode

Authorization (Authz) Mode

Note: You must specify either TradingAccount for direct execution OR Granter and Grantees for authorization mode. The framework enforces this requirement during initialization.

RetryConfig Section

The RetryConfig section controls retry behavior for network operations:
Note: RetryConfig has sensible defaults and typically doesn’t need customization unless you’re experiencing specific connectivity issues.

Now that we understand the overall structure, we are ready to develop custom ones!

Strategy Development Guide

Strategies in the Injective Trader follow a consistent structure based on the Strategy base class. This section explains how to build effective strategies.

Strategy Class Structure

Your strategy class inherits from the base Strategy class:

Strategy Constructor (__init__)

Your strategy class can include a constructor that calls the parent class constructor:
The base class constructor handles:
  1. Parameter validation and extraction
  2. Setting up standard metrics and handlers (See [block link] for more information on writing your own handlers)
  3. Initializing state tracking containers
  4. Setting up trading mode (direct or authz)
Important: The __init__ method cannot access market data or account information. Use on_initialize for operations requiring those resources.
Available properties provided by base __init__ are:

Initialization Method (on_initialize)

The on_initialize method is called once during framework startup, after markets and accounts are loaded. Purpose: Initialize strategy state and parameters Parameters:
  • accounts: Dictionary of account_address → Account objects
  • markets: Dictionary of market_id → Market objects
Returns: [Optional] StrategyResult with initial orders (if any)
This method is part of the strategy initialization sequence:
  1. Framework loads markets and accounts required by this strategy
  2. Your on_initialize method is called with loaded data
  3. Any returned orders are immediately submitted
  4. The strategy moves to running state
Tip: Use on_initialize for parameter initialization that requires market or account data, and to place any initial orders needed for your strategy. For data structure information on Account and Market, see below.

Strategy Logic (_execute_strategy ) Method

The _execute_strategy method is a part of “Strategy Execution (execute) Method”. The base class execute method handles the complete execution flow:
  1. Initialization check: Initializes the strategy if needed
  2. State update: Updates the strategy’s account and market references
  3. Data processing: Processes raw update data through the appropriate handler
  4. Strategy execution: Calls your _execute_strategy method with processed data
  5. Order enrichment: Adds default values to orders (fee recipient, client ID)
You rarely need to override this method. Instead, focus on implementing _execute_strategy where your custom trading logic goes: Purpose: Analyze market data and generate trading signals Parameters: Returns: StrategyResult with orders/cancellations or None
In _execute_strategy you can:
  • Filter by update type to handle specific events
  • Access current market data and account state
  • Check existing positions before placing orders
  • Implement custom trading logic based on market conditions
  • Create new orders and cancel existing ones
  • Update position margins for derivative markets
  • Log strategy decisions for monitoring and debugging
The framework will handle the execution details like transaction creation, simulation, and broadcasting based on your returned StrategyResult.

Best Practices

  1. Initialize all parameters in on_initialize
    • Get parameters from self.config
    • Set default values for missing parameters
    • Initialize internal state variables
  2. Filter update types
    • Only process update types your strategy cares about
    • Always check for required fields in processed_data
  3. Validate market data
    • Check if bid/ask exists before using
    • Verify position exists before making decisions based on it
  4. Respect market constraints
    • Round prices and quantities to market tick sizes
    • Check minimum order size and notional requirements
  5. Handle trading account properly
    • Ensure trading account is in AccountAddresses
    • Specify correct subaccount_id for orders
  6. Implement proper logging
    • Log strategy decisions and important events
    • Use appropriate log levels (info, warning, error)
  7. Set custom parameters
    • Use the Parameters section for strategy-specific values
    • Document expected parameters
This guide should give you a solid foundation for creating and configuring effective trading strategies with the framework.

Custom Handlers

The framework processes updates through specialized handlers before passing the data to your strategy. You can create custom handlers for more control over data processing.

Handler Base Class

All handlers inherit from the UpdateHandler base class:

Creating a Custom Handler

To create a custom handler:
  1. Inherit from the appropriate handler base class
  2. Override the _process_update method
  3. Register your handler in your strategy’s constructor

Registering Custom Handlers

Register your custom handlers in your strategy constructor:

Available Handler Types

The framework provides these handler types that you can extend:

Key Data Structure

Update Types and Corresponding Data Fields

The framework processes these main event types that your strategy can react to:

Strategy Result

When your strategy decides to take action, return a StrategyResult object with:

Market

Orderbook

Account

BankBalance

Balance

SubAccount

Deposit

Position

Order

OrderStatus (Enum)

Side (Enum)

MarketType (Enum)

Last modified on March 30, 2026