Kalshithanks for following up, is that convo in a more privileged support thread somewhere? Just wondering how you know that
thanks for following up, is that convo in a more privileged support thread somewhere? Just wondering how you know that
taco_combo参与话题 2消息总数 19
该用户的聊天记录定位。
聊天记录
共 19 条，显示第 1-19 条I'd dig the error message up, but it was too long ago and so the logs have been pruned
I'd dig the error message up, but it was too long ago and so the logs have been pruned
for batch orders at least, you'll get a partial fill, don't ask me how I know 😭
for batch orders at least, you'll get a partial fill, don't ask me how I know 😭
Curious if anyone has seen something like this before. My system processed a market lifecycle v2 update to tickers `KXWNBASPREAD-26JUN30LVNY-NY(22|25|28|31)` of type `metadata_updated` where it looks like the custom strike `basketball_team` was being corrected. Looks like the value I had cached for these markets was actually the value for Las Vegas. And the value in the event payload was the right value, for New York. Unless I've got a sneaky bug somewhere, which is possible, that'd mean the custom strike for these markets was wrong for some period of time, prior to this correction. Anybody run into a situation like that before?
Curious if anyone has seen something like this before. My system processed a market lifecycle v2 update to tickers `KXWNBASPREAD-26JUN30LVNY-NY(22|25|28|31)` of type `metadata_updated` where it looks like the custom strike `basketball_team` was being corrected. Looks like the value I had cached for these markets was actually the value for Las Vegas. And the value in the event payload was the right value, for New York. Unless I've got a sneaky bug somewhere, which is possible, that'd mean the custom strike for these markets was wrong for some period of time, prior to this correction. Anybody run into a situation like that before?
mm that makes sense, and I appreciate the response. I don't do anything latency sensitive anyway, I'm mostly just curious. The sorts of systems I've worked on professionally haven't had the same kind of constraints, and have all basically required a cross AZ footprint for reliability reasons
mm that makes sense, and I appreciate the response. I don't do anything latency sensitive anyway, I'm mostly just curious. The sorts of systems I've worked on professionally haven't had the same kind of constraints, and have all basically required a cross AZ footprint for reliability reasons
Surely the kalshi infra is spread across several us-east-2 AZs tho no? So can you really guarantee you're going to get served by infra in the exact same AZ?
Surely the kalshi infra is spread across several us-east-2 AZs tho no? So can you really guarantee you're going to get served by infra in the exact same AZ?
either way, thanks, I was going nuts trying to figure out where I was going wrong
either way, thanks, I was going nuts trying to figure out where I was going wrong
aha! gosh, is that documented somewhere? I've burned more time than I'd like to admit looking for bottlenecks in my code lol
aha! gosh, is that documented somewhere? I've burned more time than I'd like to admit looking for bottlenecks in my code lol
I've been making some code changes to make use of the L1 ticker price updates using the `ticker` ws channel, the average latency I'm getting from messages to that channel is ~500ms, regardless of the number of markets I subscribe to. The latency I'm used to seeing on the orderbook delta websocket is typically ~25ms. Is the market ticker ws channel just slower by nature?
I've been making some code changes to make use of the L1 ticker price updates using the `ticker` ws channel, the average latency I'm getting from messages to that channel is ~500ms, regardless of the number of markets I subscribe to. The latency I'm used to seeing on the orderbook delta websocket is typically ~25ms. Is the market ticker ws channel just slower by nature?
hm, maybe it’s time to finally get started on StinkBidBot v1
hm, maybe it’s time to finally get started on StinkBidBot v1
curious, were you making or taking?
curious, were you making or taking?
I mean I guess someone creating a market manually could fat finger the floor strike and then need to update it, but idk how that'd work, I'm assuming a lot of people's bots would be negatively impacted by a floor strike that's off
I mean I guess someone creating a market manually could fat finger the floor strike and then need to update it, but idk how that'd work, I'm assuming a lot of people's bots would be negatively impacted by a floor strike that's off
that's what I figured and have observed the same with the 15m markets. the description just gave me pause because I assumed that floor strikes would be immutable, after set to a non-null value, but the doc doesn't really confirm that
that's what I figured and have observed the same with the 15m markets. the description just gave me pause because I assumed that floor strikes would be immutable, after set to a non-null value, but the doc doesn't really confirm that
For the `metadata_updated` event type messages that can be published to the `market_lifecycle_v2` channel, the changelog from May 5th says that the messages will "will only be triggered by a floor strike update". Are these updates only ever going to update the floor strike from `null` to `non-null` values (like for the 15m crypto markets)? Or is there some reason that a floor strike would be updated from say `1`, to `2`?
For the `metadata_updated` event type messages that can be published to the `market_lifecycle_v2` channel, the changelog from May 5th says that the messages will "will only be triggered by a floor strike update". Are these updates only ever going to update the floor strike from `null` to `non-null` values (like for the 15m crypto markets)? Or is there some reason that a floor strike would be updated from say `1`, to `2`?
why?
why?
hm, TIL
hm, TIL
so what I’m hearing is that if you want n orders to execute as quickly as possible (and don’t care about the order in which they’re executed), you’re better off firing off n parallel single order requests, versus 1 batch request with n orders in it?
so what I’m hearing is that if you want n orders to execute as quickly as possible (and don’t care about the order in which they’re executed), you’re better off firing off n parallel single order requests, versus 1 batch request with n orders in it?
great, thank you
great, thank you
For v2 order responses, the docs for `remaining_count` say > Number of contracts remaining after placement. For IOC orders, this reflects the final state after unfilled contracts are canceled. I'm having a hard time with the IOC caveat there. If I make an IOC order for `50` contracts, and only `10` get filled, should I expect `remaining_count` to equal `40` or `0`, since the remainder would have been cancelled? I think in this case, `remaining_count` would equal `0`, but I wanted to double check my understanding, thanks
For v2 order responses, the docs for `remaining_count` say > Number of contracts remaining after placement. For IOC orders, this reflects the final state after unfilled contracts are canceled. I'm having a hard time with the IOC caveat there. If I make an IOC order for `50` contracts, and only `10` get filled, should I expect `remaining_count` to equal `40` or `0`, since the remainder would have been cancelled? I think in this case, `remaining_count` would equal `0`, but I wanted to double check my understanding, thanks