Kalshiyes there's self trade prevention
yes there's self trade prevention
james参与话题 16消息总数 132
该用户的聊天记录定位。
聊天记录
共 132 条，显示第 1-50 条its slower than N parallel order creates
its slower than N parallel order creates
hah this is a website only thing so I had nothing to do with it
hah this is a website only thing so I had nothing to do with it
30 order updates per second is a lot of order updates!
30 order updates per second is a lot of order updates!
it is already shut down. but good point, I can remove them from the gets
it is already shut down. but good point, I can remove them from the gets
but broadly speaking I would recommend to everyone to use regular create order rather than batch
but broadly speaking I would recommend to everyone to use regular create order rather than batch
the upper cap is still 30 I believe, even if you have sufficient rate limit tokens
the upper cap is still 30 I believe, even if you have sufficient rate limit tokens
gut feeling, I think this would probably lead to more confusion than benefits if it were to be added natively. (e.g. what if you get a partial fill above your minimum price parameter. do we just give you the partial fill?)
gut feeling, I think this would probably lead to more confusion than benefits if it were to be added natively. (e.g. what if you get a partial fill above your minimum price parameter. do we just give you the partial fill?)
just because its such a very minor feature that doesn't really add any functionality and would benefit a very small number of users
just because its such a very minor feature that doesn't really add any functionality and would benefit a very small number of users
but not for xss risk
but not for xss risk
yeah, I think this is unlikely anytime in the near future
yeah, I think this is unlikely anytime in the near future
missed chance, will have to be another flag maybe we'll see
missed chance, will have to be another flag maybe we'll see
the flag was just there to prevent breaking people's stuff
the flag was just there to prevent breaking people's stuff
there's a flag you can use to get everything in terms of yes
there's a flag you can use to get everything in terms of yes
the price is the "yes price" at which you want to sell
the price is the "yes price" at which you want to sell
you're just submitting bids and asks
you're just submitting bids and asks
theres only one price
theres only one price
price for yes and no is the same
price for yes and no is the same
lol the alternative is just imposing a per-rfq cost beyond the first X RFQs submitted a day
lol the alternative is just imposing a per-rfq cost beyond the first X RFQs submitted a day
and we need to choose how to allocate them
and we need to choose how to allocate them
like ultimately some of these things are fixed resources that need to be allocated
like ultimately some of these things are fixed resources that need to be allocated
same as we do for non-RFQs
same as we do for non-RFQs
we won't permanently ban behavior like this, we'll just impose rate limits and allow higher rate limits for people who trade more
we won't permanently ban behavior like this, we'll just impose rate limits and allow higher rate limits for people who trade more
we're not expecting an 80% acceptance rate. we understand the differences here.
we're not expecting an 80% acceptance rate. we understand the differences here.
on CME if you start pinging desks asking for quotes and have some of the acceptance rates we're seeing here I can guarantee these desks will tell you to get lost
on CME if you start pinging desks asking for quotes and have some of the acceptance rates we're seeing here I can guarantee these desks will tell you to get lost
hi team - RFQ updates https://docs.kalshi.com/changelog#june-25-2026
hi team - RFQ updates https://docs.kalshi.com/changelog#june-25-2026
we'll have more coming down
we'll have more coming down
yeah
yeah
look ultimately it's going to be a non-issue after tonight (hopefully) but from our perspective when we're choosing what traffic to cut (if we need to cut traffic), our preference is to cut traffic that is unlikely to lead to any trades on the platform as a primary objective, and unlikely to lead to any orders that improve visible liquidity as a secondary objective
look ultimately it's going to be a non-issue after tonight (hopefully) but from our perspective when we're choosing what traffic to cut (if we need to cut traffic), our preference is to cut traffic that is unlikely to lead to any trades on the platform as a primary objective, and unlikely to lead to any orders that improve visible liquidity as a secondary objective
(and I understand people may not be intentionally submitting noncompetitive quotes)
(and I understand people may not be intentionally submitting noncompetitive quotes)
well if you respond with garbage quotes it's the same issue, no?
well if you respond with garbage quotes it's the same issue, no?
(as far as the stability concerns go)
(as far as the stability concerns go)
no I understand that, but the issue is on both sides
no I understand that, but the issue is on both sides
well this wasn't evaluated in a vacuum... if other makers are getting accepted significantly more frequently, then that's a data point for us. in any case this will go back to normal with tonights release
well this wasn't evaluated in a vacuum... if other makers are getting accepted significantly more frequently, then that's a data point for us. in any case this will go back to normal with tonights release
not per 1000
not per 1000
sorry -- per 10000
sorry -- per 10000
we temporarily limited both for stability reasons. should be back to normal after tonight's release. there were only a handful of makers whose quote requests were limited, and the quote acceptance rates were <5 per 10000 (sometimes <1 per 10000) while sending like 10s of millions of quotes.
we temporarily limited both for stability reasons. should be back to normal after tonight's release. there were only a handful of makers whose quote requests were limited, and the quote acceptance rates were <5 per 10000 (sometimes <1 per 10000) while sending like 10s of millions of quotes.
there were very small number of people who should've been affected, and their fill rates were very low even before the 19th
there were very small number of people who should've been affected, and their fill rates were very low even before the 19th
that should already be getting resolved
that should already be getting resolved
they probably should've been 429s
they probably should've been 429s
400s
400s
ok we are working on fixing but might take a bit
ok we are working on fixing but might take a bit
pls dm me your user email
pls dm me your user email
are none getting through at all? or just a small number of them
are none getting through at all? or just a small number of them
hm, on every POST call seems quite strange, I'll look into it
hm, on every POST call seems quite strange, I'll look into it
I'm not seeing anything recently re: RFQs (they'are a parallel system so RFQ load shouldn't really affect exch. performance). are you having issues now?
I'm not seeing anything recently re: RFQs (they'are a parallel system so RFQ load shouldn't really affect exch. performance). are you having issues now?
we're just trying it for a bit 🙂 hopefully it'll stay, but like anything there's always a chance we'll need to move back
we're just trying it for a bit 🙂 hopefully it'll stay, but like anything there's always a chance we'll need to move back
esp. since some people have have still used yes/no semantics in their code
esp. since some people have have still used yes/no semantics in their code
yeah it was just meant to make the transition easier
yeah it was just meant to make the transition easier
trying to but there's always people on the old versions so it's an incremental task to try to make it as painless as possible for the most people
trying to but there's always people on the old versions so it's an incremental task to try to make it as painless as possible for the most people
第 1 / 3 页
下一页 →