hi <@1294044400065839177> I reached out a couple of months ago about Kalshi API support for buy order with fixed dollar amount (best possible price). Again, I still think this is a natural request. Imagine an end retail user requesting to place an order with $10 dollars -- all he is asking is to fill the order with as many shares as possible with best price (rather than fill-or-kill). I am wondering if this is something Kalshi can consider? Last time, your feedback was this is doable but with lower priority....
hi <@1294044400065839177> I reached out a couple of months ago about Kalshi API support for buy order with fixed dollar amount (best possible price). Again, I still think this is a natural request. Imagine an end retail user requesting to place an order with $10 dollars -- all he is asking is to fill the order with as many shares as possible with best price (rather than fill-or-kill). I am wondering if this is something Kalshi can consider? Last time, your feedback was this is doable but with lower priority....
wdym you can just implement this yourself
wdym you can just implement this yourself
I cannot control the spread... basically i hope to limit the worst case lost to the fixed dollar amount even if the spread is wild.
I cannot control the spread... basically i hope to limit the worst case lost to the fixed dollar amount even if the spread is wild.
I am not sure what exactly are you asking for that you can't implement on your own side
I am not sure what exactly are you asking for that you can't implement on your own side
there doesn't need to be a seperate api call for your use case as I read it
there doesn't need to be a seperate api call for your use case as I read it
or field
or field
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
Kalshi needs to keep the api minimal so its as maintainable and performant as possible imo
Kalshi needs to keep the api minimal so its as maintainable and performant as possible imo
We dont need frivolous endpoints and fields
We dont need frivolous endpoints and fields
your skill issues are not their problem
your skill issues are not their problem
It’s a niche request - neat to have and will make a couple small dollar traders happy - likely not worth the squeeze - if they get to it without hurting the rest of the exchange, great - if not then I don’t see its absence impacting volume
It’s a niche request - neat to have and will make a couple small dollar traders happy - likely not worth the squeeze - if they get to it without hurting the rest of the exchange, great - if not then I don’t see its absence impacting volume
This is essentially a market order with fixed dollar amount. I would assume almost every exchange supports it. why is this niche? the issue i see is that this is not about order book depth. utlimately it is about market maker cancelling the order and other competitors may be faster. the depth you observed is not reachable....you can say my bot is too slow...but i have been trying my best.
This is essentially a market order with fixed dollar amount. I would assume almost every exchange supports it. why is this niche? the issue i see is that this is not about order book depth. utlimately it is about market maker cancelling the order and other competitors may be faster. the depth you observed is not reachable....you can say my bot is too slow...but i have been trying my best.
because the potential slippage you're describing is essentially a rounding error for most automated systems
because the potential slippage you're describing is essentially a rounding error for most automated systems
even the function in the UI is just a brute force fill or kill order type
even the function in the UI is just a brute force fill or kill order type
like bruno said, it would be nice to have but it's asking the matching engine to do more work as opposed to doing it client side and in general that's not where kalshi's priorities are right now
like bruno said, it would be nice to have but it's asking the matching engine to do more work as opposed to doing it client side and in general that's not where kalshi's priorities are right now
Didn’t they have this feature like a year ago? And they got rid of it?
Didn’t they have this feature like a year ago? And they got rid of it?
Thanks for the explanation. sounds like i have to live with it...
Talking about UI, I did try to submit such order by phone or laptop a few times. Often times it just silently got killed without a notice via UI (fill-or-kill type). I thought I have placed the order but it did not happen...It was very very bad user experience.
Thanks for the explanation. sounds like i have to live with it...
Talking about UI, I did try to submit such order by phone or laptop a few times. Often times it just silently got killed without a notice via UI (fill-or-kill type). I thought I have placed the order but it did not happen...It was very very bad user experience.
When a user choose "dollar" option on UI and click "buy" button, what do you expect them to think? I don't believe anyone expect the order be killed. I am disappointed if fixing such bad user experience is not Kalshi's priority.
When a user choose "dollar" option on UI and click "buy" button, what do you expect them to think? I don't believe anyone expect the order be killed. I am disappointed if fixing such bad user experience is not Kalshi's priority.
The feature is there (specify buy_max_cost field) but with "fill-or-kill" property. FOK 's the key problem to me. Most of time when I tried placing an order with "buy_max_cost" amount, it simply got killed.
The feature is there (specify buy_max_cost field) but with "fill-or-kill" property. FOK 's the key problem to me. Most of time when I tried placing an order with "buy_max_cost" amount, it simply got killed.
That isn't what buy_max_cost. It was always confusing. Fact of the matter is the UI is simply not for any kind of sophisticated trading. That feature is for gamblers on slow moving markets with high liquidity who aren't thinking about the server side functionality at all
That isn't what buy_max_cost. It was always confusing. Fact of the matter is the UI is simply not for any kind of sophisticated trading. That feature is for gamblers on slow moving markets with high liquidity who aren't thinking about the server side functionality at all