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:LogLevelNetworkandMarketTickersin theInitializerunder theComponentssectionStrategiessection
Top-Level Parameters
Components Section
TheComponents 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
TheStrategies section defines each trading strategy:
Class: Must exactly match your Python class nameMarketIds: List of market IDs to trade on in this strategy (use hex format)AccountAddresses: List of accounts to use for trading in this strategyTradingAccount: Account used for order execution (must be inAccountAddresses) [See more details on Trading Mode Configuration ]
CIDPrefix: Prefix for client order IDs (helps identify your orders)Name: Human-readable name for logs and monitoring
- 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
Parameterssection 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
TheRetryConfig 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 theStrategy base class. This section explains how to build effective strategies.
Strategy Class Structure
Your strategy class inherits from the baseStrategy class:
Strategy Constructor (__init__)
Your strategy class can include a constructor that calls the parent class constructor:
- Parameter validation and extraction
- Setting up standard metrics and handlers (See [block link] for more information on writing your own handlers)
- Initializing state tracking containers
- 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.__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 →Accountobjectsmarkets: Dictionary of market_id →Marketobjects
StrategyResult with initial orders (if any)
- Framework loads markets and accounts required by this strategy
- Your
on_initializemethod is called with loaded data - Any returned orders are immediately submitted
- 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:
- Initialization check: Initializes the strategy if needed
- State update: Updates the strategy’s account and market references
- Data processing: Processes raw update data through the appropriate handler
- Strategy execution: Calls your
_execute_strategymethod with processed data - Order enrichment: Adds default values to orders (fee recipient, client ID)
_execute_strategy where your custom trading logic goes:
Purpose: Analyze market data and generate trading signals Parameters:
update_type: Type of update being processed [See Update Types and Corresponding Data Fields for more information]processed_data: Handler-processed data dictionary with relevant fields
StrategyResult with orders/cancellations or None
_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
StrategyResult.
Best Practices
- Initialize all parameters in
on_initialize- Get parameters from
self.config - Set default values for missing parameters
- Initialize internal state variables
- Get parameters from
- Filter update types
- Only process update types your strategy cares about
- Always check for required fields in processed_data
- Validate market data
- Check if bid/ask exists before using
- Verify position exists before making decisions based on it
- Respect market constraints
- Round prices and quantities to market tick sizes
- Check minimum order size and notional requirements
- Handle trading account properly
- Ensure trading account is in AccountAddresses
- Specify correct subaccount_id for orders
- Implement proper logging
- Log strategy decisions and important events
- Use appropriate log levels (info, warning, error)
- Set custom parameters
- Use the
Parameterssection for strategy-specific values - Document expected parameters
- Use the
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 theUpdateHandler base class:
Creating a Custom Handler
To create a custom handler:- Inherit from the appropriate handler base class
- Override the
_process_updatemethod - 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 aStrategyResult object with:
