Kalshisee rulebook 5.3(e)
see rulebook 5.3(e)
lactobacillus参与话题 25消息总数 155
该用户的聊天记录定位。
聊天记录
共 155 条，显示第 1-50 条rfq participants can match against resting liquidity instead of their rfq counterparty, in some cases reversing maker-taker roles. this exempts quoters from the possibility, unless the order was resting for more than 5 seconds. is how i'm reading it, at least
rfq participants can match against resting liquidity instead of their rfq counterparty, in some cases reversing maker-taker roles. this exempts quoters from the possibility, unless the order was resting for more than 5 seconds. is how i'm reading it, at least
https://kalshi-public-docs.s3.amazonaws.com/regulatory/notices/RFQ%20Fee%20Schedule%20Filing.docx.pdf
https://kalshi-public-docs.s3.amazonaws.com/regulatory/notices/RFQ%20Fee%20Schedule%20Filing.docx.pdf
spent all day wondering why my taker:maker ratio was unusually high until i realized the change. `is_taker` on the websocket is still accurate, at least
spent all day wondering why my taker:maker ratio was unusually high until i realized the change. `is_taker` on the websocket is still accurate, at least
ios push notifications for fills used to have subtly different formats for taker vs maker fills (taker included ✅ emoji, maker did not), and now they're indistinguishable 😭
ios push notifications for fills used to have subtly different formats for taker vs maker fills (taker included ✅ emoji, maker did not), and now they're indistinguishable 😭
i treat it as inclusive [start, end], and validate that each range's end is always equal to the next range's start, which seems to have held for all of the existing structures, but agree that it's underspecified in the docs and we'll see if my assumption holds with these new ones
i treat it as inclusive [start, end], and validate that each range's end is always equal to the next range's start, which seems to have held for all of the existing structures, but agree that it's underspecified in the docs and we'll see if my assumption holds with these new ones
sorry, no can do, according to KXPENNY-26, cents don't exist anymore
sorry, no can do, according to KXPENNY-26, cents don't exist anymore
kalshi's ipgeo might be getting it wrong. you can hit https://api.elections.kalshi.com/v1/location to see where it thinks you're located. if that says michigan, switching to a different internet connection might help
kalshi's ipgeo might be getting it wrong. you can hit https://api.elections.kalshi.com/v1/location to see where it thinks you're located. if that says michigan, switching to a different internet connection might help
linear_cent, deci_cent, tapered_deci_cent, center_whole_edge_half_cent, center_whole_edge_quint_cent, center_half_edge_half_cent, center_half_edge_quint_cent, center_half_edge_deci_cent, center_quint_edge_quint_cent, center_quint_edge_deci_cent, oh my! https://docs.kalshi.com/changelog#july-23-2026
linear_cent, deci_cent, tapered_deci_cent, center_whole_edge_half_cent, center_whole_edge_quint_cent, center_half_edge_half_cent, center_half_edge_quint_cent, center_half_edge_deci_cent, center_quint_edge_quint_cent, center_quint_edge_deci_cent, oh my! https://docs.kalshi.com/changelog#july-23-2026
that did clear it but the backlog seems to have returned
that did clear it but the backlog seems to have returned
tfw you wish your competition would stop trading for the next few days for no particular reason
tfw you wish your competition would stop trading for the next few days for no particular reason
limit is maximum, this would be minimum. the idea i guess being if there's TOO MUCH price improvement then maybe the conditions your order was based on have changed. probably wouldn't use it personally but i can see how it might be useful for some strategies
limit is maximum, this would be minimum. the idea i guess being if there's TOO MUCH price improvement then maybe the conditions your order was based on have changed. probably wouldn't use it personally but i can see how it might be useful for some strategies
way less useful for risk management if they don't track fills spanning different indexes
way less useful for risk management if they don't track fills spanning different indexes
the upcoming exchange index stuff is going to nerf order groups
the upcoming exchange index stuff is going to nerf order groups
> Members may only create a Quote and/or a RFQ for the purpose of executing bona fide Transactions yes the first 2 combos weren't executed, but they were created "for the purpose of" a bona fide 3-legged combo tx. they weren't randomly selected just to cause grief to quoters; they're an artifact of the process used to select a combo. i see what you're saying but i think it's an unnecessarily narrow reading of the rule
> Members may only create a Quote and/or a RFQ for the purpose of executing bona fide Transactions yes the first 2 combos weren't executed, but they were created "for the purpose of" a bona fide 3-legged combo tx. they weren't randomly selected just to cause grief to quoters; they're an artifact of the process used to select a combo. i see what you're saying but i think it's an unnecessarily narrow reading of the rule
is building a combo not a "bona fide Transaction"?
is building a combo not a "bona fide Transaction"?
they can say "here is what you need to do in order to not put strain on our systems or those of quoters" without taking a moral position on spam, or even trying to define spam
they can say "here is what you need to do in order to not put strain on our systems or those of quoters" without taking a moral position on spam, or even trying to define spam
the rulebook says "bona fide Transactions", not trades, and the mobile app makes an rfq every time you look at a combo position that you hold. not advocating for a particular side here and i don't use rfqs at all myself
the rulebook says "bona fide Transactions", not trades, and the mobile app makes an rfq every time you look at a combo position that you hold. not advocating for a particular side here and i don't use rfqs at all myself
i subscribe to all MVE markets. because of the 500k/conn sub limit, i have to shard this across multiple connections. instead of scaling the number of connections i use dynamically, i started with a fixed set of 10 connections, which seemed like more than plenty at the time. i bumped it to 15 for now and will have to start scaling dynamically
i subscribe to all MVE markets. because of the 500k/conn sub limit, i have to shard this across multiple connections. instead of scaling the number of connections i use dynamically, i started with a fixed set of 10 connections, which seemed like more than plenty at the time. i bumped it to 15 for now and will have to start scaling dynamically
tweaked some constants and we're back in business, but wow, we have a lot of markets today
tweaked some constants and we're back in business, but wow, we have a lot of markets today
returned to my desk to find my bot in a crash loop because of an old assumption that no more than 5 million markets would ever be open at one time
returned to my desk to find my bot in a crash loop because of an old assumption that no more than 5 million markets would ever be open at one time
fees: the cause, and solution to, all of life's problems
fees: the cause, and solution to, all of life's problems
charge 1c for every rfq made after the first 10k per month. charge 1c for every unconfirmed accepted quote. optionally, rebate it to the wronged counterparty/ies. now nobody needs to argue about which strategies are morally acceptable
charge 1c for every rfq made after the first 10k per month. charge 1c for every unconfirmed accepted quote. optionally, rebate it to the wronged counterparty/ies. now nobody needs to argue about which strategies are morally acceptable
i don't think this can be done within the existing rulebook structure. i'm in favor of these bans, but by the rules they *are* obligated to be transparent about them
i don't think this can be done within the existing rulebook structure. i'm in favor of these bans, but by the rules they *are* obligated to be transparent about them
how are you counting fills that you miss because the rfq was confirmed, but an existing resting order took fill priority over your accepted quote?
how are you counting fills that you miss because the rfq was confirmed, but an existing resting order took fill priority over your accepted quote?
i think it still ultimately is, but the complexity falls onto us in order to avoid needing to do atomic cross-shard balance comparisons, James spoke about it here https://discord.com/channels/871819895443189862/927686720990892032/1504628916776865843
i think it still ultimately is, but the complexity falls onto us in order to avoid needing to do atomic cross-shard balance comparisons, James spoke about it here https://discord.com/channels/871819895443189862/927686720990892032/1504628916776865843
looks like the old https://docs.kalshi.com/getting_started/exchange_sharding url never made it into the internet archive so i can't pull it up verbatim, but the short version (from memory) is that each market is assigned to one index, and you need to maintain separate per-index balances to collateralize resting orders on that index only
looks like the old https://docs.kalshi.com/getting_started/exchange_sharding url never made it into the internet archive so i can't pull it up verbatim, but the short version (from memory) is that each market is assigned to one index, and you need to maintain separate per-index balances to collateralize resting orders on that index only
there's def some semantic overloading, or at least crowding, going on
there's def some semantic overloading, or at least crowding, going on
i think events vs perps is "instance" not "index"/"shard"
i think events vs perps is "instance" not "index"/"shard"
the "exchange sharding" page still 404s but it looks like they're going ahead and implementing it, judging by these changelog entries https://docs.kalshi.com/changelog#july-2-2026 + https://docs.kalshi.com/changelog#june-25-2026-2
the "exchange sharding" page still 404s but it looks like they're going ahead and implementing it, judging by these changelog entries https://docs.kalshi.com/changelog#july-2-2026 + https://docs.kalshi.com/changelog#june-25-2026-2
multivariate events
multivariate events
thanks for looking into this!
thanks for looking into this!
do you remember where it said that? i'm not sure it's still accurate - i'm currently able to (and in fact, need to with the new 500k market/conn limit) use more than 6 connections at once
do you remember where it said that? i'm not sure it's still accurate - i'm currently able to (and in fact, need to with the new 500k market/conn limit) use more than 6 connections at once
60k doesn't ring a bell for me, sorry
60k doesn't ring a bell for me, sorry
used to be documented as 200k (https://discord.com/channels/871819895443189862/927686720990892032/1514671192445948067), now no longer explicitly mentioned anywhere afaik
used to be documented as 200k (https://discord.com/channels/871819895443189862/927686720990892032/1514671192445948067), now no longer explicitly mentioned anywhere afaik
still looks like an unusually large backlog but i'm seeing these start to resolve now
still looks like an unusually large backlog but i'm seeing these start to resolve now
possibly related, i'm seeing a large number of MVE markets that should have resolved by now but are still open
possibly related, i'm seeing a large number of MVE markets that should have resolved by now but are still open
an api-only limitation is still a limitation, i don't see a way out of the notice requirement in that case
an api-only limitation is still a limitation, i don't see a way out of the notice requirement in that case
if these are in fact bans rather than a technical error, kalshi is within their rights to enact them, but should do so transparently > RULE 3.11 REJECTION OF APPLICANT AND LIMITATIONS OF TRADING PRIVILEGES > (a) Notwithstanding Kalshi’s authority granted under any other Rule, Kalshi may, in its sole discretion, deny any Member Application, or suspend, revoke, limit, condition, restrict, or qualify the trading privileges of any Trader) or Authorized Trader of a Member as it deems necessary or appropriate. > (b) Anyone who has had trading privileges limited pursuant to Section (a) of this Rule will be provided, in writing, the reason such action was taken.
if these are in fact bans rather than a technical error, kalshi is within their rights to enact them, but should do so transparently > RULE 3.11 REJECTION OF APPLICANT AND LIMITATIONS OF TRADING PRIVILEGES > (a) Notwithstanding Kalshi’s authority granted under any other Rule, Kalshi may, in its sole discretion, deny any Member Application, or suspend, revoke, limit, condition, restrict, or qualify the trading privileges of any Trader) or Authorized Trader of a Member as it deems necessary or appropriate. > (b) Anyone who has had trading privileges limited pursuant to Section (a) of this Rule will be provided, in writing, the reason such action was taken.
if they match, yes. if they don't match, no
if they match, yes. if they don't match, no
the executions are visible after the fact. other quoters quotes are private unless they match
the executions are visible after the fact. other quoters quotes are private unless they match
i've seen at least one quoter do that, but it's not universal
i've seen at least one quoter do that, but it's not universal
this means your pricing needs to be improved - you only match if you beat the best quoter
this means your pricing needs to be improved - you only match if you beat the best quoter
rulebook 5.3 explains how they're matched https://kalshi-public-docs.s3.amazonaws.com/regulatory/rulebook/Kalshi%20DCM%20Rulebook%20v.1.28%20clean.docx.pdf#page=43
rulebook 5.3 explains how they're matched https://kalshi-public-docs.s3.amazonaws.com/regulatory/rulebook/Kalshi%20DCM%20Rulebook%20v.1.28%20clean.docx.pdf#page=43
there is a history of sustained lies in rfq documentation. for example, even today, it still says `rfq_created` `creator_id` is always empty. i won't speculate on why this is, but i tend to trust behavior over documentation for the rfq subsystem. and whatever seems to be happening over the last few days makes me glad i decided to eschew it and just place resting orders directly on the orderbooks
there is a history of sustained lies in rfq documentation. for example, even today, it still says `rfq_created` `creator_id` is always empty. i won't speculate on why this is, but i tend to trust behavior over documentation for the rfq subsystem. and whatever seems to be happening over the last few days makes me glad i decided to eschew it and just place resting orders directly on the orderbooks
they really should add it to websocket. add a `get_connection_order_group` command, returns a new `order_group_id` that, instead of triggering based on fill velocity, triggers on disconnect
they really should add it to websocket. add a `get_connection_order_group` command, returns a new `order_group_id` that, instead of triggering based on fill velocity, triggers on disconnect
(and by "settled" i mean roughly:) ``` start = now() while get_user_data_timestamp() < start: sleep ```
(and by "settled" i mean roughly:) ``` start = now() while get_user_data_timestamp() < start: sleep ```
i'm not sure there is a recommended way. what i do is read my orders once at startup after possibly sleeping until user_data_timestamp is settled, and thereafter maintain my own local view of what orders i currently think i have resting, and update it from websocket data and my own order placement/cancellation. i've found that user_data_timestamp is reliable enough for this. if you really need to rely on getorders instead of keeping local state, yeah, you'll be sleeping a lot
i'm not sure there is a recommended way. what i do is read my orders once at startup after possibly sleeping until user_data_timestamp is settled, and thereafter maintain my own local view of what orders i currently think i have resting, and update it from websocket data and my own order placement/cancellation. i've found that user_data_timestamp is reliable enough for this. if you really need to rely on getorders instead of keeping local state, yeah, you'll be sleeping a lot
https://docs.kalshi.com/api-reference/exchange/get-user-data-timestamp
https://docs.kalshi.com/api-reference/exchange/get-user-data-timestamp
take kalshi profits, buy cheese
take kalshi profits, buy cheese
第 1 / 4 页
下一页 →