Spec version 2.3.0. Two properties of basic_response have no description in the spec, and both change how a client must interpret the data. I could not resolve either from the payloads alone.
1. Sign convention of the per-strike GEX values
strikes is declared as an array of arrays of numbers, with no description of the components. From the README example, the shape is [strike, gex_vol, gex_oi, priors].
The sign of gex_vol and gex_oi carries a modelling assumption, and the spec does not say which one:
- Is the sign derived from the contract type — calls positive, puts negative, i.e. an assumed dealer position?
- Or from something else?
A related question on the same schema: is sum_gex_vol the sum of the per-strike gex_vol over the returned strikes, or over the full chain?
A one-line description on strikes, sum_gex_vol and sum_gex_oi would settle this.
2. Strike coverage of strikes
On NQ_NDX I receive about 140 strikes over about 1,100 points.
- Is this the complete chain for the selected category, or a server-side window around
spot?
- If it is a window, what sets its width?
This matters for any client that aggregates gamma across the returned strikes. A window whose width is fixed in points, while the underlying moves, truncates a different share of the chain on a quiet day than on a volatile one — and a client cannot detect that from the payload.
Suggested change
Add a description to strikes, sum_gex_vol and sum_gex_oi in latest/gexbot.spec3.yaml, stating the sign convention and whether the returned strikes are the full chain or a window.
Thanks for publishing the spec — having it in a repository is a real improvement.
Spec version 2.3.0. Two properties of
basic_responsehave no description in the spec, and both change how a client must interpret the data. I could not resolve either from the payloads alone.1. Sign convention of the per-strike GEX values
strikesis declared as an array of arrays of numbers, with no description of the components. From the README example, the shape is[strike, gex_vol, gex_oi, priors].The sign of
gex_volandgex_oicarries a modelling assumption, and the spec does not say which one:A related question on the same schema: is
sum_gex_volthe sum of the per-strikegex_volover the returned strikes, or over the full chain?A one-line
descriptiononstrikes,sum_gex_volandsum_gex_oiwould settle this.2. Strike coverage of
strikesOn
NQ_NDXI receive about 140 strikes over about 1,100 points.spot?This matters for any client that aggregates gamma across the returned strikes. A window whose width is fixed in points, while the underlying moves, truncates a different share of the chain on a quiet day than on a volatile one — and a client cannot detect that from the payload.
Suggested change
Add a
descriptiontostrikes,sum_gex_volandsum_gex_oiinlatest/gexbot.spec3.yaml, stating the sign convention and whether the returned strikes are the full chain or a window.Thanks for publishing the spec — having it in a repository is a real improvement.