Renko Brick strategy

Author: J0E 0x520

Original Post Date: 22 May 2022

Snapshot Proposal Link

Hi,

As per HGP-4 [DG] Creation & Improvement of Hummingbot Client strategies (Commonwealth) would like to propose a new client strategy. This also requires additional changes to strategybase, common datatype and binance connectors to support MARKET, STOP_LOSS*,* STOPLOSSLIMIT*, TAKE* PROFIT, TAKEPROFIT LIMIT. Initial logic for trailing stop has been added, to be improved when binance spot pairs support them.

Title: HGP-4 [DG] Renko Brick strategy

Category: Strategy

Summary: Add Renko Brick strategy

Linked HGP: HGP-4

Description: See text below.

Github Handle: lt7 (J0E) · GitHub

Ethereum Wallet: 0x520403D82a08cff5331D0764e2B6a8056074E622

Total HBOT requested: 300,000 HBOT

Estimated Dev Days: 15 development days

HBOT Per Day: 20,000 HBOT

Description

Add Renko Brick strategy that allows trend/momentum trading, it submits limit orders based on set parameters for renko bricks formed on price movements on a pair - Renko Chart Definition and Uses and Profitable Renko Strategy – Building your Account, One Brick at a Time and creates a STOP_LOSS_LIMIT order in opposite direction to hedge against trend reversal. On trend reversal orders are submitted in opposite direction, and stop_loss will be triggered.

Initial version comprises of the following parameters:

strategy: renko_brick

The following configurations are only required for the Renko_Brick strategy

Exchange and market and asset parameters

exchange: binance

trading_pair: BTC-UDST

Size of the order to create

order_amount: 0.01

Define the size of the renko brick that will be created as a percentage of last trade price.

e.g. if BTC-USDT last traded at 40000 and 1% brick size, then bricks will be constructed at 400 points thus an Ask

brick would be created at 39600 or a Bid brick at 40400 and corresponding bid/ask order triggered

(Enter 10 for 10%, 1 for 1%, 0.17 for 0.17% etc)

brick_size: 0.001

Define the level that the order will be submitted at, where brick_size = 1

e.g. if BTC-USDT last traded at 40000 and brick_size=1% and order_level=1, then bricks will be constructed at 400

points, thus an Ask brick would be created at 39600 or a Bid brick at 40400 and corresponding limit bid/ask order at

one brick higher, Buy order @ 40800.

If brick_size=1% and order_level=0.5 then Buy order @ 40200

If brick_size=1% and order_level=2 then Buy order @ 40800

If order_level = 0 then market order will be submitted.

order_level: 1.0

Define the stopPrice of the order that will be created, as a percentage of the order_price

(Enter 10 for 10%, 1 for 1%, 0.17 for 0.17% etc)

e.g. if BTC-USDT last traded at 40000 and brick_size=1%, order_level=1 and stop_loss_level=2, then bricks will be constructed at 400

points, thus an Ask brick would be created at 39600 or a Bid brick at 40400 and corresponding stop_loss_limit bid/ask order at

one brick higher, Buy order @ 40800 with stop_loss_limit @ 40000.

If brick_size=1% and order_level=0.5 and stop_loss_level=1 then Buy order @ 40200 with stop_loss_limit Ask @ 39800

If brick_size=1% and order_level=2 and stop_loss_level=1 then Buy order @ 40800 with stop_loss_limit Ask@ 40000

If trend is following and next brick is hit, stop_loss is cancelled/replaced at next stop_loss_limit for that brick level.

If trend reverses, stop_loss_limit in other direction is placed

If stop_loss_level=0 then market order will be submitted (currently disabled)

stop_loss_size: 1.0

Boolean: If true then place a new limit order as each brick is hit.

e.g. trend up for BTC-USDT@40000 and brick_size=1% and order_level=1, place bid limit orders at 40400, 40800, 41200 etc.

Stop loss is changed as per stop_loss_size until trend reversal when ask market order placed for 3

e.g. trend up for BTC-USDT@40000 and brick_size=1% and order_level=1, place bid orders 1@40400 only if false until trend

reversal when ask market order is placed for 1

order_at_each_level: false

trailing_stop: NOT SUPPORTED ON SPOT PAIRS YET https://api.binance.com/api/v3/exchangeInfo?symbol=BTCUSDT look for “allowTrailingStop”:false to be true

as such logic can either on trend reversal

1 - wait for spot_loss_limit (SIDE) to be hit on trend reversal (default)

2 - execute market order to close position straight away (currently disabled, need to add back)

3 - execute limit_order at appropriate price (not implemented yet)

From - Binance API Documentation 2022-04-13

Trailing Stop is a type of algo order where the activation is based on a percentage of a price change in the market using the new parameter trailingDelta.

This can only used with any of the following order types: STOP_LOSS, STOP_LOSS_LIMIT, TAKE_PROFIT, TAKE_PROFIT_LIMIT.

The trailingDelta parameter will be done in Basis Points or BIPS.

For example: a STOP_LOSS SELL order with a trailingDelta of 100 will trigger after a price decrease of 1%. (100 / 10,000 => 0.01 => 1%)

When trailingDelta is used in combination with stopPrice, once the stopPrice condition is met,

the trailing stop starts tracking the price change from the stopPrice based on the trailingDelta provided.

When no stopPrice is sent, the trailing stop starts tracking the price changes from the last price based on the trailingDelta provided.

For renko brick trading strategy trailing_delta is used without a spotPrice and entered as a % that is then converted to

Basis points based on lastTradePrice.

e.g. LastTradePrice of BTC-USDT@40000 and we set trailing_delta @ 1 (1%) protection and brick_size=2% and order_level=1

we will place bid limit orders @40800 with trailingStop @40400. If price moves up to 41250 then trailingStop will move

automatically to 40837, thus locking in 37.5 BIPS if there is trend reversal.

trailing_delta:

Boolean: enable/disable trailingSpot

use_trailing_delta: false

That’s about it, happy to take feature requests and work collaboratively to improve this further.

Future enhancements/versions could include :-

Brick size is currently Traditional (manual, pre-defined), look at calculating Average True Range (ATR), possibly via TA-Lib integration.

Add take_profit orders based on x% parameter.

Re-enable market orders on trend reversal if % profit realised rather than wait for stop loss to be hit.

Hedge position on perpetual exchange

Add Inventory Skew

Any feedback or other suggestions welcomed, comment here or ping me on discord.

Author: fengtality 0x352

I would vote in favor of this approving HIP for this strategy, JOE. Do you need help from the Foundation submitting it?

Author: J0E 0x520

Thanks, but it was rejected without any questions or discussion unfortunately.

Author: fengtality 0x352

I spoke with Tech Review DAO who reviewed it. They didn’t understand how a trader would use the strategy to make money, so that’s why they recommended against it, but they said if you re-submit with a paragraph explaining how to use the strategy, they will reassess.

The links in the description provide some examples of how renko strategies work. The general idea was directional trading where a trend is identified and order placed to follow that trend, and the ability to place opposing order with trailing stop loss for to protect trend reversal.

The strategy code has been written and binance spot connector support for stop_loss, stop_loss_limit etc order types added.

The PR is ready to be raised, but I’m not sure how what the process is now the epoch has ended, do I need to raise another snapshot for voting?

Thanks for the detailed description of the strategy and update. I think this proposal would be an excellent candidate for the Improvement Proposals process described in the Epoch 2 Governance Process, or possibly the Pull Request Process if you just want to contribute without receiving tokens.

Since the process is new, Hummingbot Foundation will guide the you and the community in deciding:

  • Should adding this new strategy and new Binance new order types to the Hummingbot codebase warrant giving the developer (you in the case) a portion of the Epoch 2 HBOT budget?
  • If so, what is a reasonable amount of HBOT?

A few suggestions to guide the discussion:

  1. If possible, I think we should separate this into 2 improvements: a) new Binance order types for spot_loss, spot_loss_limit, etc, b) new Renko Brick strategy. That way, the community can give feedback, allocate tokens, and vote on the proposals separately.
  2. To size the potential HBOT grant, I think the community should take into account the value to the overall Hummingbot user base, the level of effort entailed, and the remaining budget amount. Epoch 2 recently started and we propose to allocate 30 million HBOT tokens for distribution. What percentage of that budget should be allocated to these proposed improvements? (0%? 1%? 2%? 5%?)

I’ll post this topic in Discord and mention it in the Wednesday community call so that we can hopefully spark some discussion by the community.

2 Likes

Thanks for the reply. In response to your points

  1. If possible, I think we should separate this into 2 improvements: a) new Binance order types for spot_loss, spot_loss_limit, etc, b) new Renko Brick strategy. That way, the community can give feedback, allocate tokens, and vote on the proposals separately.

Technically it’s possible to separate them, and it might make more sense if appropriate unit tests are built to validate that a) is implemented correctly. With limited experience/knowledge and little documentation to figure out how to write the test cases and the constantly evolving connector code and no visibility of what coinalpha will refactor in the next release it wasn’t a priority for me. Would love some assistance here if test cases are a hard requirement.

b) the renko strategy has a dependency on trailing_stop (binance-spot-api-docs/trailing-stop-faq.md at master · binance/binance-spot-api-docs · GitHub) whilst it could be voted on separately and that makes sense, if a) doesn’t pass then there no point proceeding with b).

That said I iterated through binance connector changes as binance added the functionality to their API, and the renko strategy evolved to require it and I used the renko strategy effectively as the test of those changes. The list of changes looks like exchange_base python/cython, trading_rules, data_types, strategy_base etc, e.g.

1 Like