ajhpark / ib_nope Goto Github PK

When NOPE entry is selected, pick the strike closest to 30 delta (or -30 delta in the case of a put) in order to take advantage of an OTM's gamma move towards ITM.

Two possible scenarios:
Scene. 1.

1. NOPE reaches long_enter threshold so the bot buy calls
2. However, instead of a reversion NOPE keeps going down until market close
3. Bot is holding calls at close (default configuration should not buy 0dte contracts, so we may not want to sell before close if we're down since it could go up next day)

Scene. 2.

1. NOPE reaches short_enter threshold so the bot buys puts
2. No reversion, NOPE keeps going up until market close
3. Bot is holding puts at close (same as above, we do not sell since it could go down next day)

Currently the bot closes the open positions from the above scenarios as soon as the market opens, since all it looks at is NOPE and NOPE resets to 0 at open. This is not ideal, need a better exit strategy for this case.

After an auto restart enter/exit tasks are duplicated

1. Buy order placed but unfilled
2. Sells are triggered on held contracts
3. Sells are blocked since you can't have open buy and sell orders on the same contract

Use kelly criterion to dynamically size max call/put contract limits based on portfolio value to avoid portfolio blowout.

https://explore.paulbutler.org/bet/

Half kelly is normally a good betting size if you want to stay conservative, but base logic is that you don't bet so much that you blow up your account in a few trades.

Log trades after fills not submits

list(filter(lambda a: a.tag == 'CashBalance' and a.currency == 'USD', self.ib.accountValues(account='MYACCOUNT')))

asyncio needs to be patched to handle nested event loops, otherwise we see an event loop already running error when using ib_insync

Unit/integration

"After a certain NOPE intraday (at least, assuming all trades close out EOD), you are better to play directionally with the trend than against it. This since 2018 shows up around +70/-100 or so."

https://twitter.com/nope_its_lily/status/1375548914842050562

Reason for using Questrade for NOPE data is because there's no efficient way to use IB API to get NOPE, especially since we need to update frequently. Click here see how to get option chain data using the IB API. You need to send a separate request for each contract in the chain which is too slow and there is no endpoint to get it all at once.

Why Questrade? Because I happened to have a Questrade account and their API is good for NOPE, that's about it. Good news is this project can very easily be modified to use a different source for NOPE such as TDA or ORATS if you don't have a Questrade account.

How:

1. Remove these two lines in NopeStrategy.__init__:
   self.qt = QuestradeClient(token_yaml=self.QT_ACCESS_TOKEN)
self.run_qt_tasks()
2. Change NopeStrategy.set_nope_value to use the client you want. For example if using TDA, import the TDAClient from tda/tda_client.py and replace self.qt.get_nope() with self.tda.get_nope(). If using neither TDA or Questrade, you will need to write your own client for your NOPE source.
3. Add an asyncio task to run NopeStrategy.set_nope_value every minute (see NopeStrategy.run_qt_tasks to see how it's done)

The rest of NopeStrategy doesn't care how the NOPE value is set and should work fine.