该用户的聊天记录定位。
more cheese! organize a group buy! one time i bought a can from a guy outside a train station for $40 cash who had ordered like 30 of them
more cheese! organize a group buy! one time i bought a can from a guy outside a train station for $40 cash who had ordered like 30 of them
sorry i'm retracting my 🔥 react, i thought that was an order confirmation screenshot
sorry i'm retracting my 🔥 react, i thought that was an order confirmation screenshot
solution: order more cheese to improve unit economics
solution: order more cheese to improve unit economics
they're certainly not shrinkflating and my last order (last year) was as tasty as ever
they're certainly not shrinkflating and my last order (last year) was as tasty as ever
best cheese in the world. i am a bit biased, both my parents were alumni and it was a household staple growing up
best cheese in the world. i am a bit biased, both my parents were alumni and it was a household staple growing up
thank you for the reminder, i need to place another order
thank you for the reminder, i need to place another order
not worth the minor possibility of a surprise 1099 with an unexpected characterization blowing up my tax planning. plus, out of all of these assets, there's only one that i have burning desire to take a position on, and that's holding the underlying directly in cold storage on a 10+yr timeframe
not worth the minor possibility of a surprise 1099 with an unexpected characterization blowing up my tax planning. plus, out of all of these assets, there's only one that i have burning desire to take a position on, and that's holding the underlying directly in cold storage on a 10+yr timeframe
i'm waiting until they answer questions about how perps tax reporting is going to work. which probably means i'll be waiting forever, or at least until next tax season
i'm waiting until they answer questions about how perps tax reporting is going to work. which probably means i'll be waiting forever, or at least until next tax season
https://docs.kalshi.com/changelog#june-20-2026 > effective immediately
https://docs.kalshi.com/changelog#june-20-2026 > effective immediately
i think they're having pgsql index troubles today
i think they're having pgsql index troubles today
yes sir, excellent idea sir
yes sir, excellent idea sir
yes, before i added batch support, i was submitting them in parallel and would sometimes have them execute out of order
yes, before i added batch support, i was submitting them in parallel and would sometimes have them execute out of order
James directly replied to you and confirmed that they execute in the specified order https://discord.com/channels/871819895443189862/927686720990892032/1511795384832495758
James directly replied to you and confirmed that they execute in the specified order https://discord.com/channels/871819895443189862/927686720990892032/1511795384832495758
endpoints without a documented cost override are 10 tokens per request https://docs.kalshi.com/getting_started/rate_limits
endpoints without a documented cost override are 10 tokens per request https://docs.kalshi.com/getting_started/rate_limits
strange! it used to be there for me too, until today. now i see this:
strange! it used to be there for me too, until today. now i see this:
is this still available on the ui? can no longer see it on portfolio page
is this still available on the ui? can no longer see it on portfolio page
right click, copy user id. all manual! 😏
right click, copy user id. all manual! 😏
scammer user id 1516827190187266172 <@&1432453406018113596>
scammer user id 1516827190187266172 <@&1432453406018113596>
one other notable feature FIX has that i wish websocket did too is `CancelOrdersOnDisconnect=Y` https://docs.kalshi.com/fix/authentication
one other notable feature FIX has that i wish websocket did too is `CancelOrdersOnDisconnect=Y` https://docs.kalshi.com/fix/authentication
it's homegrown, a cron job that emails me diffs when certain things change (not limited to kalshi). not something i can easily break off and make public, sorry
it's homegrown, a cron job that emails me diffs when certain things change (not limited to kalshi). not something i can easily break off and make public, sorry
and the changelog entry that used to announce it has been revised to remove mention of a new error https://docs.kalshi.com/changelog#june-18-2026-8
and the changelog entry that used to announce it has been revised to remove mention of a new error https://docs.kalshi.com/changelog#june-18-2026-8
error 28 was just removed from the docs...? ```diff --- kalshi_asyncapi.txt 2026-06-18 08:55:06.503500559 -0700 +++ kalshi_asyncapi.txt~ 2026-06-18 09:55:06.494238542 -0700 @@ -84 +84,0 @@ - | 28 | Markets not found | Unknown tickers were not subscribed | @@ -1394,2 +1408,0 @@ - - | 28 | Markets not found | Unknown tickers were not subscribed | @@ -2476,2 +2488,0 @@ - - - 28: Markets not found - Unknown tickers were not subscribed @@ -2479 +2490 @@ - maximum: 28 + maximum: 27 @@ -2489,5 +2499,0 @@ - market_tickers: - type: array - items: - type: string - description: Market tickers if error is market-specific (optional) @@ -4007,3 +4012,0 @@ - - code: 28 - name: Markets not found - description: Unknown tickers were not subscribed ```
error 28 was just removed from the docs...? ```diff --- kalshi_asyncapi.txt 2026-06-18 08:55:06.503500559 -0700 +++ kalshi_asyncapi.txt~ 2026-06-18 09:55:06.494238542 -0700 @@ -84 +84,0 @@ - | 28 | Markets not found | Unknown tickers were not subscribed | @@ -1394,2 +1408,0 @@ - - | 28 | Markets not found | Unknown tickers were not subscribed | @@ -2476,2 +2488,0 @@ - - - 28: Markets not found - Unknown tickers were not subscribed @@ -2479 +2490 @@ - maximum: 28 + maximum: 27 @@ -2489,5 +2499,0 @@ - market_tickers: - type: array - items: - type: string - description: Market tickers if error is market-specific (optional) @@ -4007,3 +4012,0 @@ - - code: 28 - name: Markets not found - description: Unknown tickers were not subscribed ```
any chance you're receiving and ignoring one of the newfangled error 28s with the correct seq no? i see it using seq 1 for that error (and starting snapshots at seq 2) when my initial ticker list contains at least 1 invalid ticker. when they're all valid tickers there's no error and the snapshots start with seq 1 like before
any chance you're receiving and ignoring one of the newfangled error 28s with the correct seq no? i see it using seq 1 for that error (and starting snapshots at seq 2) when my initial ticker list contains at least 1 invalid ticker. when they're all valid tickers there's no error and the snapshots start with seq 1 like before
<@&1432453406018113596>
<@&1432453406018113596>
scammer user id 1516881223106953488
scammer user id 1516881223106953488
well, in this case it's displaying inaccurate data
well, in this case it's displaying inaccurate data
the new combo ui widget is a visual improvement and i like it, but omitting positions seems like a problem
the new combo ui widget is a visual improvement and i like it, but omitting positions seems like a problem
with the recent ui updates, the portfolio page on web (combos/history tabs) no longer displays multiple MVE markets within the same MVE event. it seems like it just arbitrarily picks one combo in the event, displays that, and omits the others entirely. and by "MVE event" here i mean the thing with a two-segment KXMVEFOO-BAR event ticker, not the underlying events that the combo covers. i know i'm going to hear "write your own, the ui isn't meant for you", but i think this is something that can happen to retail users too if they pick up multiple related positions with the ui, not just devs acquiring them via api
with the recent ui updates, the portfolio page on web (combos/history tabs) no longer displays multiple MVE markets within the same MVE event. it seems like it just arbitrarily picks one combo in the event, displays that, and omits the others entirely. and by "MVE event" here i mean the thing with a two-segment KXMVEFOO-BAR event ticker, not the underlying events that the combo covers. i know i'm going to hear "write your own, the ui isn't meant for you", but i think this is something that can happen to retail users too if they pick up multiple related positions with the ui, not just devs acquiring them via api
yes submitting a single 99c limit buy can result in slippage, but you could instead fetch the order book, see how many shares are available at each price level, and pick them off one by one across multiple orders until your desired total qty/price is met. the batch order create endpoint lets you do this without incurring round trip latency between each order
yes submitting a single 99c limit buy can result in slippage, but you could instead fetch the order book, see how many shares are available at each price level, and pick them off one by one across multiple orders until your desired total qty/price is met. the batch order create endpoint lets you do this without incurring round trip latency between each order
buy yes = sell no. sell yes = buy no. since v2, api users can no longer use the 'no'-oriented view; that is a privilege reserved for ui users. yes it is annoying if you're used to thinking in terms of 'no', no they're not going to change it
buy yes = sell no. sell yes = buy no. since v2, api users can no longer use the 'no'-oriented view; that is a privilege reserved for ui users. yes it is annoying if you're used to thinking in terms of 'no', no they're not going to change it
resting orders will have fill priority over rfq participants - rulebook 5.3(b) gives a more detailed description
resting orders will have fill priority over rfq participants - rulebook 5.3(b) gives a more detailed description
on this information i've just started doing this partitioning client-side instead of allowing unrelated orders in the same batch, and if it matters could be nudged by token cost changes to start submitting single-order batches via the non-batch endpoint
on this information i've just started doing this partitioning client-side instead of allowing unrelated orders in the same batch, and if it matters could be nudged by token cost changes to start submitting single-order batches via the non-batch endpoint
interesting, so it's sequential but not atomic
interesting, so it's sequential but not atomic
(or maybe by event ticker in case of mecnet etc? haven't thought that path through)
(or maybe by event ticker in case of mecnet etc? haven't thought that path through)
agreed about different markets though - the api could totally split them up by ticker before submitting them for atomic matching and i don't think anyone would notice or care
agreed about different markets though - the api could totally split them up by ticker before submitting them for atomic matching and i don't think anyone would notice or care
James has stated that they are sequential https://discord.com/channels/871819895443189862/927686720990892032/1511795384832495758
James has stated that they are sequential https://discord.com/channels/871819895443189862/927686720990892032/1511795384832495758
i think they're handled as an atomic unit all the way from api -> matching engine, but the matching engine synchronization overhead is larger for a batch tx than it is for many independent single-order txs. i don't believe i've ever seen anything like a partial 429, but i (possibly unnecessarily?) limit myself to batches of 20
i think they're handled as an atomic unit all the way from api -> matching engine, but the matching engine synchronization overhead is larger for a batch tx than it is for many independent single-order txs. i don't believe i've ever seen anything like a partial 429, but i (possibly unnecessarily?) limit myself to batches of 20
agreed, and to substantiate this, i had it happen more than once during development before i added batch submission
agreed, and to substantiate this, i had it happen more than once during development before i added batch submission
read linked message
read linked message
since we're discussing batch ops, i'd like to publicly state that i still rely on batch order create in a way that cannot be simply replaced by parallel single-order create https://discord.com/channels/871819895443189862/927686720990892032/1511797177456791715
since we're discussing batch ops, i'd like to publicly state that i still rely on batch order create in a way that cannot be simply replaced by parallel single-order create https://discord.com/channels/871819895443189862/927686720990892032/1511797177456791715
(i did have a terrible trading day for unrelated reasons and would have been better off staying offline, though... oh well!)
(i did have a terrible trading day for unrelated reasons and would have been better off staying offline, though... oh well!)
following up on the "Subscription buffer overflow" / error code 25 from yesterday - sharding across multiple websocket conns solved it completely, haven't had a disconnect since implementing it. was worried that 10x connections = 10x risk surface area for random disconnects, but they've been stable for 17h+
following up on the "Subscription buffer overflow" / error code 25 from yesterday - sharding across multiple websocket conns solved it completely, haven't had a disconnect since implementing it. was worried that 10x connections = 10x risk surface area for random disconnects, but they've been stable for 17h+
just orderbook deltas (edit: and trades), not including rfq activity
just orderbook deltas (edit: and trades), not including rfq activity
just mve
just mve
2 megabits per second
2 megabits per second
the firehose is like 2mbit...
the firehose is like 2mbit...
i'm back up and trading with 10x sharding, currently subscribed to 186k tickers per connection. hopefully this eliminates the new error 25s. i'm still confident i can promptly consume an orderbook firehose on a single connection, but 10 connections works too
i'm back up and trading with 10x sharding, currently subscribed to 186k tickers per connection. hopefully this eliminates the new error 25s. i'm still confident i can promptly consume an orderbook firehose on a single connection, but 10 connections works too
they have effectively announced this deprecation with the upcoming 500k ticker cap. there are regularly 2M+ active tickers on the exchange at one time now
they have effectively announced this deprecation with the upcoming 500k ticker cap. there are regularly 2M+ active tickers on the exchange at one time now
is there current evidence that "people are having backpressure" and not "kalshi is having backpressure"?
is there current evidence that "people are having backpressure" and not "kalshi is having backpressure"?
i only subscribe to MVEs, but non-MVEs are a rounding error - there are currently 1.7M open MVEs
i only subscribe to MVEs, but non-MVEs are a rounding error - there are currently 1.7M open MVEs
Kalshi