KalshiKalshi just has technical debt and zero respect for users. The outcome is unsurprising.
Kalshi just has technical debt and zero respect for users. The outcome is unsurprising.
Bumbling Bayesian参与话题 33消息总数 209
该用户的聊天记录定位。
聊天记录
共 209 条，显示第 101-150 条https://docs.kalshi.com/changelog#apr-22-2026-2
https://docs.kalshi.com/changelog#apr-22-2026-2
I highly encourage others to do it.
I highly encourage others to do it.
https://docs.kalshi.com/api-reference/exchange/get-series-fee-changes has `show_historical`.
https://docs.kalshi.com/api-reference/exchange/get-series-fee-changes has `show_historical`.
yes
yes
You can see which series have maker fees with something like: `curl https://external-api.kalshi.com/trade-api/v2/series | jq -r '.series[] | select(.fee_type == "quadratic_with_maker_fees") | .ticker'`
You can see which series have maker fees with something like: `curl https://external-api.kalshi.com/trade-api/v2/series | jq -r '.series[] | select(.fee_type == "quadratic_with_maker_fees") | .ticker'`
Yes, but then <@1307399713108135956> pointed out that this is currently the only way to indicate to the exchange that you want to put requests into a particular order. (https://discord.com/channels/871819895443189862/927686720990892032/1511797177456791715) We are hoping that Kalshi takes user input into account before removing batch support.
Yes, but then <@1307399713108135956> pointed out that this is currently the only way to indicate to the exchange that you want to put requests into a particular order. (https://discord.com/channels/871819895443189862/927686720990892032/1511797177456791715) We are hoping that Kalshi takes user input into account before removing batch support.
See previous discussions. One might find latency advantages in some cases. One might also benefit from order of execution.
See previous discussions. One might find latency advantages in some cases. One might also benefit from order of execution.
no
no
That is, what you get back from Get Order(s).
That is, what you get back from Get Order(s).
It is a new property of the Order object.
It is a new property of the Order object.
I usually roll my eyes at suggestions that everything should be on a blockchain, but having the changelog changing history is a good argument for having an immutable log managed by a trustworthy entity.
I usually roll my eyes at suggestions that everything should be on a blockchain, but having the changelog changing history is a good argument for having an immutable log managed by a trustworthy entity.
But is it even a problem? Can't we just ignore the errors for closed markets?
But is it even a problem? Can't we just ignore the errors for closed markets?
But it is not just a race, right? Lots of open events can have closed markets for a long time?
But it is not just a race, right? Lots of open events can have closed markets for a long time?
That is, at subscription time, not asynchronously as a market closes. But maybe that also.
That is, at subscription time, not asynchronously as a market closes. But maybe that also.
My system iterates over events of interest at startup and tries to subscribe to all markets in the event. I don't currently check that each market is open before this subscription, so I suspect I am getting this error for that reason.
My system iterates over events of interest at startup and tries to subscribe to all markets in the event. I don't currently check that each market is open before this subscription, so I suspect I am getting this error for that reason.
This makes sense. Thanks.
This makes sense. Thanks.
I am still trying to figure out how I am referencing invalid markets. But I am at 34,000 feet and have had an espresso martini, so being careful not to push a change that breaks anything more.
I am still trying to figure out how I am referencing invalid markets. But I am at 34,000 feet and have had an espresso martini, so being careful not to push a change that breaks anything more.
Yes, I am definitely getting a 28 at first.
Yes, I am definitely getting a 28 at first.
Are you using `skip_ticker_ack`? https://docs.kalshi.com/changelog#feb-11-2026-2
Are you using `skip_ticker_ack`? https://docs.kalshi.com/changelog#feb-11-2026-2
I added more logging and will look for that error 28.
I added more logging and will look for that error 28.
Maybe? Definitely something changed this morning.
Maybe? Definitely something changed this morning.
Something seems to have changed with how WS sequence numbers work after this morning's update. An assertion keeps triggering on my side when I connect. My logging throws `IllegalStateException: expected sequence number 1 for id=3 channel=orderbook_delta but got 2`. I have disabled my assertion for now while I try to figure it out.
Something seems to have changed with how WS sequence numbers work after this morning's update. An assertion keeps triggering on my side when I connect. My logging throws `IllegalStateException: expected sequence number 1 for id=3 channel=orderbook_delta but got 2`. I have disabled my assertion for now while I try to figure it out.
https://docs.kalshi.com/margin
https://docs.kalshi.com/margin
I think that `side` being limited to `bid` and `ask` is self-explanatory. Maybe you just could add something to the documentation instead of adding a new field/property.
I think that `side` being limited to `bid` and `ask` is self-explanatory. Maybe you just could add something to the documentation instead of adding a new field/property.
I noticed that change also. I have no idea what the intent is.
I noticed that change also. I have no idea what the intent is.
It was under the CloudFront implementation when I was tinkering with different ways to send batch orders, but I found that two batches sent concurrently, partitioned due to the max 20 order limitation previously mentioned, seemed to sometimes overlap in execution. This is entirely unsurprising, but should probably be documented.
It was under the CloudFront implementation when I was tinkering with different ways to send batch orders, but I found that two batches sent concurrently, partitioned due to the max 20 order limitation previously mentioned, seemed to sometimes overlap in execution. This is entirely unsurprising, but should probably be documented.
This is not surprising and I would want them to make optimizations that improve overall bandwidth and latency at the expense of a well-defined order unless one is using an endpoint that guarantees that. I think they just need to document whether or not batches guarantee order and think about the use case <@1307399713108135956> described.
This is not surprising and I would want them to make optimizations that improve overall bandwidth and latency at the expense of a well-defined order unless one is using an endpoint that guarantees that. I think they just need to document whether or not batches guarantee order and think about the use case <@1307399713108135956> described.
This is very much the case, as one would expect from a load balancer.
This is very much the case, as one would expect from a load balancer.
Yes, but depending on where that layer is, one gets different behavior.
Yes, but depending on where that layer is, one gets different behavior.
By the way, <@378727998121181184>, my SDK has a complicated path inspired by your skepticism that batches always win from a performance point of view. As I said before, you are right and this is not a valid assumption in all cases.
By the way, <@378727998121181184>, my SDK has a complicated path inspired by your skepticism that batches always win from a performance point of view. As I said before, you are right and this is not a valid assumption in all cases.
My bespoke SDK just accepts a collection of orders to create or cancel and then decides whether to use batch or not and how to partition the batches. I just want to know if the old partitioning requirement still applies.
My bespoke SDK just accepts a collection of orders to create or cancel and then decides whether to use batch or not and how to partition the batches. I just want to know if the old partitioning requirement still applies.
Exactly. It would require them to estimate the consumption ahead of time, which I am skeptical that they are doing.
Exactly. It would require them to estimate the consumption ahead of time, which I am skeptical that they are doing.
20, I mean.
20, I mean.
Because that is the formerly documented max.
Because that is the formerly documented max.
25
25
Yes. Thanks. I am aware. He last said '>50%'. Before I remove my code that partitions batches into chunks, I would like to see if anyone knows the answer.
Yes. Thanks. I am aware. He last said '>50%'. Before I remove my code that partitions batches into chunks, I would like to see if anyone knows the answer.
LOL, indeed.
LOL, indeed.
That is not the question I am asking.
That is not the question I am asking.
yes
yes
Yes, I am aware of what the current documentation claims.
Yes, I am aware of what the current documentation claims.
I am talking about an older restriction on v1.
I am talking about an older restriction on v1.
This is one of the reasons that I am asking. My logs are showing inconsistent states now that I have migrated from v1 of v2 to v2 of v2. Were you sending multiple operations per batch using the v1 endpoint?
This is one of the reasons that I am asking. My logs are showing inconsistent states now that I have migrated from v1 of v2 to v2 of v2. Were you sending multiple operations per batch using the v1 endpoint?
I get that the entire batch should be rejected if it would exceed the rate limit. I am skeptical that this is what happens. I am asking if there is still a maximum number of operations permitted per batch.
I get that the entire batch should be rejected if it would exceed the rate limit. I am skeptical that this is what happens. I am asking if there is still a maximum number of operations permitted per batch.
Rate limit is tokens/second. This is orthogonal to how many operations can be placed into a single batch. Formerly, v1 of v2, there was a limit of 20 operations per batch.
Rate limit is tokens/second. This is orthogonal to how many operations can be placed into a single batch. Formerly, v1 of v2, there was a limit of 20 operations per batch.
But we have no idea how many seconds a batch operation might take.
But we have no idea how many seconds a batch operation might take.
I am confused on the maximum number of operations that can be batched in a single call to Batch Create Orders V2 / Batch Cancel Orders V2. The v1 version of v2 had a per-tier definition and Advanced was 20 per batch. I don't see such a definition any more. The OpenAPI documentation says, "The maximum batch size scales with your tier’s write budget — see Rate Limits and Tiers.", but I see no reference to the max batch size in https://docs.kalshi.com/getting_started/rate_limits. Is there just no limit now other than the token cost?
I am confused on the maximum number of operations that can be batched in a single call to Batch Create Orders V2 / Batch Cancel Orders V2. The v1 version of v2 had a per-tier definition and Advanced was 20 per batch. I don't see such a definition any more. The OpenAPI documentation says, "The maximum batch size scales with your tier’s write budget — see Rate Limits and Tiers.", but I see no reference to the max batch size in https://docs.kalshi.com/getting_started/rate_limits. Is there just no limit now other than the token cost?
Implementation detail leaking through the API.
Implementation detail leaking through the API.
The speed of light is finite and constant and slower than we would like.
The speed of light is finite and constant and slower than we would like.
One should definitely queue WS messages and handle them on another thread. But you still need the same amount of compute regardless.
One should definitely queue WS messages and handle them on another thread. But you still need the same amount of compute regardless.