You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
spot_meta_and_asset_ctxs doesn't inject dex into the payload #257
While the Info class supports perp_dexs constructor argument, when I fetch spot_meta_and_asset_ctxs the dex is not passed in the payload, nor the method supports a dex argument
I looked into this and measured it live today (2026-09-05, mainnet). The short version: the API ignores dex on spotMetaAndAssetCtxs, so injecting it into the payload would be a silent no-op rather than a fix. The reason is that HIP-3 partitions perp markets, not spot.
Spot is not dex-partitioned — verified. The response is structurally identical whether dex is absent, empty, a made-up string, or a real HIP-3 dex name:
Each HIP-3 perp DEX carries its own perp universe; the global spot universe (spotMetaAndAssetCtxs) is shared and has no per-dex view to select. So dex is meaningful on the perp meta/metaAndAssetCtxs/user_state/open_orders family (that gap is being tracked in #278 and documented in #286/#320), but on spotMetaAndAssetCtxs there is nothing for it to switch.
My suggestion: rather than add a dex argument that the API silently drops (which would mislead callers into thinking a per-dex spot view exists), it's more accurate to leave the signature as-is and, if anything, add a one-line docstring note that spot contexts are global and not dex-scoped. Happy to open that docs PR if a maintainer agrees.
(Observed: the identical-structure and count results above, from live mainnet calls. Deduced: the HIP-3 perp-vs-spot partitioning as the cause — consistent with the perp-meta results but I haven't seen it stated in the docs.)
Activity
fix: `spot_meta_and_asset_ctxs` doesn't inject dex into the payload
massimiliano1991 commentedon Sep 5, 2026
I looked into this and measured it live today (2026-09-05, mainnet). The short version: the API ignores
dexonspotMetaAndAssetCtxs, so injecting it into the payload would be a silent no-op rather than a fix. The reason is that HIP-3 partitions perp markets, not spot.Spot is not dex-partitioned — verified. The response is structurally identical whether
dexis absent, empty, a made-up string, or a real HIP-3 dex name:Contrast — the perp endpoints do respond to
dex, which is why the request feels natural but the analogy doesn't hold for spot:Each HIP-3 perp DEX carries its own perp universe; the global spot universe (
spotMetaAndAssetCtxs) is shared and has no per-dex view to select. Sodexis meaningful on the perpmeta/metaAndAssetCtxs/user_state/open_ordersfamily (that gap is being tracked in #278 and documented in #286/#320), but onspotMetaAndAssetCtxsthere is nothing for it to switch.My suggestion: rather than add a
dexargument that the API silently drops (which would mislead callers into thinking a per-dex spot view exists), it's more accurate to leave the signature as-is and, if anything, add a one-line docstring note that spot contexts are global and not dex-scoped. Happy to open that docs PR if a maintainer agrees.(Observed: the identical-structure and count results above, from live mainnet calls. Deduced: the HIP-3 perp-vs-spot partitioning as the cause — consistent with the perp-
metaresults but I haven't seen it stated in the docs.)