Changelog

Release 4.0.0 (Nov 27, 2023)

Highlights from release 4.0.0 are listed below

Breaking Changes (4.0.0)

  • Broker level square-off is not supported anymore in square_off.

New Features (4.0.0)

  • Improved and faster start-up time in server mode. Support for pause and resume in server mode.

  • Consistent error handling, with introduction of on_error and on_cancel and on_exit handler. See error handlers for more.

  • Run multiple algos using a single asyncio eventloop in live modes.

  • Introduction of sub-strategy - convenient way to define multiple logic routes in a single algo run. See sub-strategies for more.

Bug Fixes and Improvements (4.0.0)

  • Fix stoploss/ take-profit incorrect cool-off period bug.

  • Introduce schedule_soon in live modes to schedule a callback once as soon as possible. In backtest it will behave same as schedule_once.

  • Revamped launch process, with interactive command channel in server mode.

  • Force a reconciliation before square-off to ensure consistent behaviour

  • Introduce checks for stale data in live trading data query.

  • Fix stdout redirection in server mode.

Release 3.0.0 (Sep 3, 2023)

Highlights from release 3.0.0 are listed below

Breaking Changes (3.0.0)

  • Move to Python 3.10. Any strategy code using older version may now generate errors or warning messages. Please re-validate your existing strategies.

  • All constants and enum data types have moved to blueshift.protocol. Earlier it was split between blueshift.api as well.

New Features (3.0.0)

  • New date rules week_day added for schedule_function. Now you can directly specify the day-of-week (e.g. “Thursday” or 3) to schedule a function. See schedule APIs for more.

  • Use the keyword use_spot=True to use offset from spot level (instead of default futures) in the symbol function for a rolling option asset.

  • You can now opt for IOC (immediate or cancel) order types in the square-off api function by specifying keyword argument ioc=True. The square-off function will attempt a maximum 3 times before giving up and issuing an error message. Also, use the keyword skip_exit=True in stoploss and take-proft API functions to invoke callbacks on trigger without square-off (useful for custom handling of stoploss/ take-profit triggers). For more, check out the documentation for set_stoploss.

  • New API functions set_exit_policy set_initial_positions, is_trading_hours and exit_when_done.

Bug Fixes and Improvements (3.0.0)

  • Improved efficiency by tracking when the event loop is idle, and running idle tasks intelligently.

  • Improve oneclick notification expiry time check. Also now sends update if the user discard a notification.

  • Increase niceness of schedule later calls and make it thread-safe.

  • Enforce cool-off period for rejecting orders only for entry orders.

Release 2.1.0 (Jan 16, 2022)

Highlights from release 2.1.0 are listed below

Breaking Changes (2.1.0)

  • Realtime callback function on_data is now upgraded as a main callback function. Instead of adding a handler using the said function, use the function directly to handle arriving events. This also applies to on_trade as well. As a consequence, functions to remove such event handlers (off_data and off_trade) are now deprecated and will throw errors.

  • All imports from blueshift_library are now deprecated and will throw errors. Point all such imports to blueshift.library instead.

  • Futures and options now include lotsize information (previously was 1). Since assets can be traded in multiple of lotsizes only (if not ‘fractional’), the trading capital must be high enough for an order to go through. For e.g. you could trade 1 unit of futures before, but now minimum order size must be the current lotsize.

  • Error handling changes: Repeated errors will now cause the algo to exit after a threshold is breached.

New Features (2.1.0)

  • Additional event scheduling functions schedule_once and schedule_later. See schedule APIs for more.

  • Support for advanced algo order type. See Advanced Algo Orders for more.

  • Option backtesting.

  • Built-in support for stoploss and take profit behaviour. For more on this see Stoploss and Take-profit.

  • Add backtest support for order modification.

  • Enriched Order object - now includes latency metrics as well as parent algo ID.

Bug Fixes and Improvements (2.1.0)

  • Fix reconciliation error in case broker streaming update disconnects (force an API call).

Release 2.0.0 (Nov 2, 2021)

Warning

Blueshift 2.0 includes breaking change. See below for more details.

The new Blueshift engine improves on several aspects of strategy development. Following are major highlights

  • Breaking Change - move away from zipline to Blueshift Python engine.

  • Breaking change - Multi-assets, multi-fields history method now returns MultiIndex dataframes.

  • Breaking change - Attributes for various objects (e.g. asset, position, account, portfolio etc.) may have different names. See the documentation for the attribute names to use.

  • Breaking change - The performance argument to analyze function has new values. See the documentation for more details.

  • Extended liquidity filtered universe for the US and Indian markets.

  • Realistic simulation with explicit margin models.

  • Realistic models for margin and slippage.

  • Historical bid-ask slippage modelling of forex backtest.

  • Pipeline API support in live trading. See Pipeline APIs for more details.

  • Fractional trading - to support fractional trading, the data-type for asset quantity wherever applicable (e.g. order.quantity or position.quantity) are now float type instead of int.

Breaking Changes

Update your strategies to point to blueshift in all places that currently imports from zipline, as shown below

#### change below ....
#from zipline.finance import slippage, commission
#from zipline.api import symbol
#from zipline.pipeline import Pipeline
#### to point to blueshift
from blueshift.finance import slippage, commission
from blueshift.api import symbol
from blueshift.pipeline import Pipeline

Update your strategies to adapt to Pandas MultiIndex dataframes (if required). Otherwise, it may crash. See Upgraded Data Interface.

from blueshift.api import symbol

def initialize(context):
    context.universe = [symbol('AAPL'), symbol('MSFT')]

def handle_data(context, data):
    # a multi-asset, multi-field history call
    prices = data.history(context.universe,['close','volume'],10,'1m')

    # price for AAPL
    # this is deprecated
    # appl_price = prices.minor_xs(context.universe[0])
    # use below to replace minor_xs calls.
    appl_price = prices.xs(context.universe[0])

For other breaking changes, carefully analyse your existing strategy code and refer to the respective documentation for supported attribute names and performance columns. If you have trouble, feel free to contact us at blueshift-support@quantinsti.com. For more on Pandas MultiIndex, see the official documentation

Changes in Blueshift 2.0.0

Blueshift 2.0 release moves away from zipline and introduces major upgrades in many areas, while retaining the existing APIs unchanged. A few improvements are highlighted below:

Extended and Updated Asset Universes

We move to a new liquidity based universe (compared to external benchmark based universe earlier) with assets size substantially expanded.

More Realistic Simulation Behaviour

The simulation engine is re-written to be more realistic with the introduction of an explicit margin model.

The default US execution now is modelled on a Regulation T type margin account - with 50% flat margin requirements (That is, 2x buying power). This avoids the earlier (somewhat strange) behaviour of unlimited (infinite) buying powers. For example, using a $5,000 account to take a position of more than $10,000 worth of net exposure will now throw an insufficient fund error and will stop the backtest, instead of continuing with unrealistic assumptions.

The execution model for the Indian market now assumes cash transactions in the equity/ ETFs segment and margin transactions in the futures segment (with default 10% flat margin). Forex is also explicitly modelled as margin trading with default 5% flat margin.

The default slippage for equities (and futures) continue to be Volume based slippage (a very common model). For forex, however, we have moved to a historical bid-ask based slippage model. This avoids the high sensitivity of forex backtest to trading cost assumptions and produces more accurate results.

In addition, we have introduced stringent and up to the minute checks for backtest account solvency. If your backtest equity is in the negative on a close of business (i.e. a margin call from the broker), the backtest will stop. In such cases, you should reduce the leverage level in your strategy and try to run again.

A couple of things you still need to be careful while testing your strategy

  1. The Reg T account does not track or flag pattern day trading.

  2. The cash equities account does not enforce long-only. This means on a short sell, it will credit the whole transaction value to the backtest account. You can enforce long-only behaviour by using the set_long_only API method.

Changes in Ordering function

With the introduction of the margin model, we have also introduced a 2% margin for order_target_percent. This now calculates the target value based on current portfolio value, after a 2% haircut. This is applicable only for MARKET orders. For LIMIT orders, no such haircut will be applied.

Also, all targeting type order functions will now take into account the pending amount of orders in that asset. This is in addition to considering the existing position in that asset.

Upgraded Data Interface

The data.history method, for multiple assets and multiple fields, will now return Pandas MultiIndex Dataframe (instead of the deprecated Panel data). The required changes in your strategy code is very minimal. Instead of accessing the data for a given asset using prices.minor_xs(asset), you need to use prices.xs(asset).

Using MultiIndex dataframes over Panel data has several advantages (apart from the obvious deprecation). The input data for different assets now need not be homogeneous. This is a more realistic scenario as it does not enforce an unnatural requirement of every asset in the universe to have a trade every minute of every business day.