builtin option chain builder

[ilan-pinto]

Many people are building the option chain on their own. It could be nice having a built function that builds the option chain based on multiple params like: symbol,day to expiration, right range of strike/delta and more

[mattsta]

The primary problem is IBKR is a fairly bad bulk data service. Fetching more than one option chain per minute slows down to blocking for 20 seconds to 90 seconds each time where no other data requests can happen due to IBKR's "data pacing limits" (there is no practical reason for slow data retrieval other than IBKR still acts like it's the 1970s in some of their APIs).

Services with usable data APIs like Tradier or Polygon.io provide better loading of the same data in milliseconds instead of 90 seconds through IBKR.

Also, since option chains don't change during the day (they can only add new strikes overnight between market sessions), fetched chains should be cached for the remainder of the day after their first request.

The real problems with option chain fetching all just on the user:

• figuring out the expiration dates per instrument
• deciding when requesting too many strikes at once blocks your client for too much time
• deciding what to cache and for how long (then how to integrate the cache into your application)

We don't have an additional utility library for extra non-network-API usage like that, but feel free to sponsor additional work.

Practically, ib_async should probably remain a simple dependency-light IBKR-API-only library, but we could make an additional higher level utility library package including things like transparent caching, automatic market date discovery, data pacing awareness, etc.

[westonplatter]

I've run into similar needs to what @ilan-pinto is describing. See below screenshot of logic to pull down an IB option chain for future options.

There's some nuance to making the final data structure look like the UI shown in the TWS Option Trader UI. For example, to get Option Bid/Ask/Last and Option greeks, one has to qualify the option contract by conId, request the tickers for each of the Option/FutureOption contracts, and then extract the desired ticker fields out and merge onto the option chain (at least, that's how I've gotten it to work on my end - there could be better approaches). Given those operations, I agree with @mattsta's point that this belongs in a higher level library and probably not in ib_insync.

@mattsta would be you open to creating an option chain specific repo under ib-api-reloaded? If so, I'd be curious in developing a package for this.